Teoria Unificada

Implantación
de sistemas de
información de
empresas
José Ramón Rodríguez
José María Joana
PID_00174747
CC-BY-NC-ND • PID_00174747 Implantación de sistemas de información de empresas
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de
Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos
y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya),
no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/
licenses/by-nc-nd/3.0/es/legalcode.es
CC-BY-NC-ND • PID_00174747 Implantación de sistemas de información de empresas
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Características de los sistemas de información de empresa.... 9

1.1. Consecuencias para la gestión .................................................... 12
2. Fases del ciclo de vida de implantación...................................... 14
3. Fase 1. Adopción del sistema: la decisión de adquirir un

ERP......................................................................................................... 16
4. Fase 2. Selección de la solución estándar.................................... 25
5. Fase 3. Implantación de la solución............................................. 33

5.1. Iniciación y definición del proyecto .......................................... 35
5.2. Planificación y lanzamiento del proyecto .................................. 36
5.3. Análisis de la situación actual .................................................... 37
5.4. Definición de la situación objetivo ............................................ 38
5.5. Construcción y prueba del prototipo ......................................... 39
5.6. Construcción del sistema ............................................................ 42
6. Fase 4. Puesta en marcha................................................................. 44
7. Gestión del cambio............................................................................ 46

7.1. Un modelo de gestión del cambio ............................................. 47
7.2. Análisis de implicados ................................................................ 49
7.3. Causas de las resistencias al cambio ........................................... 51
7.4. Buenas prácticas de intervención sobre la comunicación .......... 52
7.5. El plan de formación .................................................................. 53
8. Gestión de proyecto........................................................................... 55
8.1. Procesos típicos de la gestión de proyectos ................................ 56
8.2. Las áreas de conocimiento .......................................................... 60
8.3. La organización del proyecto ...................................................... 64
8.3.1. Roles clave en el proyecto ............................................. 64
8.3.2. Órganos colegiados ........................................................ 65
Resumen....................................................................................................... 67
Bibliografía................................................................................................. 69
CC-BY-NC-ND • PID_00174747 5 Implantación de sistemas de información de empresas
Introducción
En los módulos anteriores hemos examinado la estructura, el catálogo de so-

luciones existentes y las características principales de los sistemas de informa-
ción de empresa (SIE), desde los ERP tradicionales hasta los más nuevos siste-
mas CRM, SCM, BI, etc.
En la actualidad, los SIE cubren la mayor parte de los procesos de negocio de

cualquier empresa en cualquier sector industrial, y han sido adoptados como
principal estrategia tecnológica por muchas compañías de todos los tamaños.
En este módulo mostramos que la adopción de un SIE, un paquete estándar

de gestión del negocio o de algunas de sus funciones principales, es una elec-
ción estratégica y tecnológica de gran alcance e implicaciones, así como una
decisión prácticamente sin retorno. Por lo tanto, es de gran importancia co-
nocer bien sus características, explicarlas a los usuarios y directivos y tomar
decisiones bien informadas.
También explicamos los aspectos clave del ciclo de vida del ERP: su adopción
(la decisión o no de comprar), la elección de la solución más adecuada, el pro-
ceso de implantación (parametrización, desarrollos a medida, sustitución o
integración con las aplicaciones heredadas) y finalmente el arranque. Propor-
cionamos una metodología abreviada de implantación, basada en la práctica
profesional.
Aun más que en otros ámbitos de la gestión y producción de sistemas de infor-

mación, la implantación de ERP requiere de una especial colaboración entre
usuarios y técnicos, una mayor comprensión de las necesidades estratégicas y
operativas del negocio y un trabajo de "gestión del cambio"; todo para facilitar
los cambios en la organización y las maneras de trabajar de la empresa.
Objetivos
El objetivo de este módulo es familiarizar al estudiante con los procesos de

implantación de sistemas de información de empresa (SIE).
Aunque se proporciona una guía metodológica general para abordar un pro-

yecto de este tipo, lo más importante es que el estudiante comprenda las di-
ferencias entre los proyectos de sistemas de empresa (ERP, CRM, SCM, etc.) y
otras clase de proyectos de construcción e implantación de sistemas de infor-
mación y los aspectos teóricos y prácticos que son clave para una implanta-
ción de éxito.
Más concretamente, estos objetivos son:
1) Conocer las características propias de diseño y construcción de los sistemas

de empresa y qué implicaciones tienen estas características en el proceso de
decisión de adoptar un SIE y en su implantación posterior. En particular, com-
prender las diferencias principales con los proyectos de desarrollo de software
a medida.
2) Entender el ciclo de vida de un SIE y los aspectos clave de cada una de sus
fases:
• La adopción, es decir, cómo se toma o se debe tomar la decisión de adquirir

un SIE, frente a otras opciones posibles.
• La selección, es decir, la elección de un fabricante y un implantador frente
a otros posibles.
• La implantación propiamente dicha en todas sus fases, con un énfasis
particular en los procesos de parametrización y construcción de un proto-
tipo.
• La puesta�en�marcha, es decir, los procesos de arranque y estabilización
del nuevo sistema.
3) Entender los dos procesos de "acompañamiento", que se consideran clave

para la implantación con éxito del SIE:
• La gestión�del�cambio, o sea, los aspectos de organización, procesos de

trabajo, gestión de interesados, comunicación y formación, principalmen-
te, que facilitan o deben facilitar el cumplimiento de los objetivos del pro-
yecto y la adopción de la nueva tecnología.
• La gestión�del�proyecto, esto es, las buenas prácticas de gestión general
que son válidas en cualquier proyecto TIC y su valor y especialidad en la
implantación de un SIE. Se analizará, en particular, la estructura de orga-

nización y gestión de un proyecto de estas características.
1. Características de los sistemas de información de

empresa
Según hemos visto en la introducción y los primeros módulos de la asignatura, SIE

los sistemas de información de empresa (SIE) son paquetes estándar que cu-
Normalmente en este módu-
bren, en principio, los procesos de trabajo habituales de cualquier empresa en lo utilizaremos las expresio-
casi cualquier sector industrial, que se pueden adaptar a las peculiaridades de nes SIE, sistemas de informa-
ción de empresa o sistemas de
cada negocio u organización concreta mediante un menú de opciones y que empresa; aunque a veces po-
damos hablar de ERP para re-
comparten una base de datos común para toda la empresa y para las diferentes ferirnos al conjunto de estos
sistemas o incluso, en ocasio-
aplicaciones o "módulos" del sistema. nes, hablaremos de paquetes
o software estándar. Con to-
do, siempre estaremos hablan-
Hemos visto también la arquitectura y el catálogo típico de los productos que do de la misma realidad, o sea,
paquetes estándar que cubren
incluyen estos sistemas en la actualidad (figura�1). funciones y procesos de traba-
jo de las empresas.
Figura 1. Arquitectura actual de los sistemas de información de empresa
Lectura recomendada
Podéis ver: A.�Gómez�Viei-

tes;�C.�Suárez�Rey (2006).
Sistemas de información: He-
rramientas para la gestión em-
presarial (2.ª ed.). Madrid:
Editorial Ra-Ma. Paracuellos
del Jarama.
1)�Los�ERP (enterprise resource planning o sistemas de gestión de recursos) clási-

cos, que cubren los procesos internos de la empresa (contabilidad y finanzas,
recursos humanos, compras y aprovisionamiento, gestión de la producción,
etc.).
2)�Los�sistemas�de�relación�con�los�proveedores, o sistemas de gestión de la

cadena de suministros (SCM, supply chain management), que incluyen los pro-
cesos de previsión de la producción y demanda de materias primas, reposición
de inventarios, almacenamiento y distribución.
3)�Los�sistemas�de�gestión�comercial�y�de�relaciones�con�los�clientes (CRM,
o customer relationship management), donde se registran todos los contactos y
operaciones que la empresa tiene con sus clientes y la gestión del canal co-
mercial directo (vendedores y representantes) e indirecto (distribuidores o re-
vendedores).
4)�Los�nuevos�sistemas�que�comienzan�a�llamarse�PRM (partnership relations-

hip management), que gestionan las relaciones con los socios y otros agentes
de la cadena de valor. Poníamos el ejemplo de los programas de fidelización
de las empresas turísticas o de transporte de personas.
5)�El�conjunto�de�sistemas�de�relaciones�con�los�directivos�y�empleados, Ved también

como son los sistemas de inteligencia de negocio (BI, o business intelligence),
Ved el módulo didáctico "Sis-
gestión del conocimiento (KM, o knowledge manament), los sistemas de apoyo tema de información empresa-
a la toma de decisiones (DSS, o decisión support systems) y otros. rial" de esta asignatura.
En este apartado, profundizaremos en las características funcionales de los sis-

temas integrados de empresa, es decir, cómo son y funcionan los sistemas de
información de empresa. Como veremos, tener en cuenta estas características
de diseño es algo crítico para tomar la decisión de adquirir un sistema integra-
do y para su implantación, que es sustancialmente diferente de la del ciclo�de
vida�de�desarrollo�a�medida (software development life cycle, o SDLC).
Estas características principales, o criterios de diseño, son las siguientes:
1) El software se organiza por procesos�de�trabajo, es decir, cada aplicación o Proceso

módulo cubre todos o la mayoría de los procesos o procedimientos de trabajo
Un proceso es una secuencia
de un departamento o de una empresa, sus requerimientos funcionales. de actividades que transforma
unas entradas (inputs) en unos
resultados (outputs), median-
2) El sistema integrado está compuesto de una serie de aplicaciones o grupos de te una serie de herramientas
y operaciones que pueden ser
aplicaciones que se llaman módulos. Normalmente, cada módulo cubre una cálculos matemáticos o proce-
dimientos de gestión.
función organizativa o un departamento de la empresa (contabilidad y finan-
zas; recursos humanos; ventas; compras; producción; etc.). Está orientado�a�la
función, con independencia de las líneas de producto, mercados e incluso de
las formas o jerarquías organizativas que esta función tenga en cada empresa.
3) Probablemente, el aspecto más importante de los modernos sistemas de Workflow

empresa es su elevado�grado�de�integración. Todos los procesos, funciones,
La incorporación más reciente
departamentos (y eventualmente empresas u organizaciones que utilizan el de herramientas de gestión de
mismo software) comparten los mismos datos y utilizan la misma estructura los procesos de trabajo (work-
flow) en los sistemas de empre-
de datos. Se habla también de integración funcional (dos o más funciones sa, teóricamente, refuerza y fa-
cilita estos aspectos de integra-
ción funcional y modular.
que se integran en una función que reclama ciertas operaciones de otra) y de Web services
integración modular (es decir, componentes de un módulo que se utilizan en
Las versiones más recientes de
otros módulos). sistemas de empresa han evo-
lucionado en todo o en parte
hacia arquitecturas�de�servi-
4) Los sistemas integrados son una evolución avanzada de las arquitecturas cios�web (web services) en las
cuales los clientes acceden a
cliente-servidor, o sea, la distribución de componentes (programas, datos) cualquier clase de servicio por
medio de un navegador están-
entre "servidores" donde habitualmente residen los programas y datos comu- dar.
nes y "clientes" (estaciones de trabajo) donde los empleados pueden realizar
ciertas operaciones con autonomía y disponen de algunos programas y datos.
Clientes y servidores se comunican a través de mensajes u órdenes de trabajo.
Esto permite, en principio, economizar tanto las máquinas como el software
y las comunicaciones.
5) El sistema estándar proporciona un menú de opciones funcionales supues-

tamente basado en las buenas o mejores prácticas (best practices) o maneras
de ejecutar una operación o proceso de trabajo, diseñar pantallas o ejecutar
informes. El cliente o implantador elige la opción que mejor se adapta a su ne-
cesidad o, más habitualmente, modifica su manera de trabajar para adaptarse
a la propuesta del software. Asimismo, si se producen cambios en los procesos
de trabajo se puede cambiar la opción de configuración elegida sin necesidad
de modificar el software. Esta característica se llama adaptación dinámica o
parametrización.
6) Una consecuencia de mayor calado de esta filosofía es la estandarización

del�entorno�de�sistemas y la escalabilidad, esto es, el mismo sistema se puede
adaptar a las necesidades de crecimiento de la empresa. Asimismo, es el fabri-
cante el que se ocupa de su puesta al día y evolución. Finalmente, el sistema
permite el desarrollo de componentes a medida del usuario o facilita la comu-
nicación e integración con otras aplicaciones departamentales o corporativas
heredadas. Algunos software estándar tienen su propio entorno y lenguaje de
desarrollo y otros utilizan lenguajes estándar o una mezcla de ambos.
7) Una de las características que más proclamaban en sus inicios los fabrican-
tes de software estándar de empresa era la facilidad y ergonomía�de�uso�del
interfaz�de�usuario, muy similar a la navegación de las aplicaciones de ofici-
na. El interfaz es gráfico y más atractivo, es común para todos los módulos,
contiene herramientas de ayuda, permite hacer peticiones (queries) inmedia-
tas o diferidas de cierta información necesaria para completar un proceso de
trabajo, bajarse esta información al propio PC y puede integrarse con relativa
facilidad con las herramientas de oficina, conservar plantillas o documenta-
ción, enviar mensajes de correo, etc.
La figura�2 contiene un resumen esquemático de todas estas características.

Figura 2. Arquitectura actual de los sistemas de información de empresa
1.1. Consecuencias para la gestión
Este conjunto de diferencias (también similitudes) tiene consecuencias sobre

la manera�en�que�se�organiza�la�informática, las relaciones con los usuarios
y los perfiles profesionales de los informáticos y usuarios. Frecuentemente,
los profesionales y departamentos de informática son percibidos o suponen
realmente un obstáculo para la adopción del ERP en la empresa.
1) La relación con el fabricante es completamente distinta que con un pro- Ejemplo

veedor de servicios de desarrollo. El poder comercial del vendedor es mucho
AUSAPE es la asociación de
mayor, y lo es para siempre. Los compradores necesitan asociarse y establecer usuarios de SAP en España y
estrategias más colectivas. tiene grupos sectoriales y fun-
cionales para cada módulo y
tipo de industria.
2) El poder de directivos y usuarios finales es también mayor y, frecuentemen-

te, se relacionan directamente con el vendedor (y el implantador) tanto en el
momento de la compra como en la ejecución del proyecto.
3) Aparece una tercera figura, el consultor o implantador, que tiene un papel

clave en la configuración del producto, la relación con los usuarios y la gestión
del proyecto.
4) En consecuencia, el papel de los departamentos de informática y sus profe- Intervención de los

sionales es mayor en la gestión de proveedores y proyectos y en la evaluación, departamentos de IT
asesoramiento y control de los desarrollos y mantenimiento adicional que en Los departamentos de IT in-
la propia implantación. tervienen más en la selección
de la solución y en el manteni-
miento futuro y no tanto en la
implantación propiamente di-
5) Esto requiere que los departamentos de IT sean capaces de mantener el cha, donde tienen más un pa-
pel de gestores de proyecto y
conocimiento de los datos y los procesos de negocio, optimizar el uso de los facilitadores de la relación en-
nuevos sistemas y mostrar a usuarios y directivos las capacidades que la nueva tre el personal externo (con-
sultores o implantadores) y los
tecnología les puede aportar. propios usuarios y directivos.
6) Al mismo tiempo, la adquisición e implantación de ERP, para funciones o

procesos con poca diferenciación competitiva, debería liberar recursos para el
desarrollo de sistemas en los que la empresa sí que obtiene ventajas de dife-
renciación en el mercado.
2. Fases del ciclo de vida de implantación
En los apartados siguientes, profundizaremos en el desarrollo metodológico

del ciclo de implantación de los sistemas de empresa y los aspectos clave de
cada una de ellas.
La clasificación de estas fases varía entre autores y también en la práctica pro-

fesional de las empresas que se dedican a la implantación de esta clase de sis-
temas.
El propio enfoque de la implantación (más amplio o más restringido, más rá-

pido o más lento, con mayor o menor reingeniería de los procesos de negocio)
puede hacer variar o matizar cualquier clasificación general.
Finalmente, la metodología o metodologías de gestión de proyecto que utilice

el cliente o el implantador pueden hacer cambiar el contenido, la ubicación
o la denominación de cada fase y etapa.
Con estas limitaciones, hemos adoptado una clasificación bastante ecléctica

que establece cuatro�fases�básicas:
1) Fase 1, o de adopción. Es la fase en que directivos, usuarios y técnicos se

cuestionan la compra de un sistema de información de empresa integrado y
paquetizado, o bien optan por una solución diferente, normalmente un desa-
rrollo a media.
2) Fase 2, o de selección. Una vez tomada la decisión de adoptar un sistema

de empresa, se debe seleccionar qué sistema se adoptará, qué módulos y qué
partes se deberán adaptar o desarrollar a medida.
3) Fase 3, o de implantación del sistema, consistente en la personalización

(parametrización) o adaptación del sistema a las necesidades de la organiza-
ción, incluyendo los desarrollos específicos, en su caso, y la integración con
los sistemas existentes o heredados.
4) Fase 4, de puesta�en�marcha, que incluye el arranque y la estabilización del

sistema y la corrección de errores (mantenimiento correctivo) y su adopción
efectiva por la organización.
A estas fases deben añadirse dos grupos de procesos que son permanentes y
continuos a lo largo de todo el ciclo:
5) La gestión� del� cambio, es decir, todos los procesos de adaptación de la

organización, los procesos y las personas a la nueva tecnología.
6) La gestión�de�proyecto, o sea, el conjunto de procesos y habilidades para

planificar, organizar, dirigir y administrar el proyecto a la hora de asegurar la
consecución de los objetivos.
Una representación gráfica de este ciclo se muestra en la figura siguiente:
Figura 3. El ciclo de vida de la implantación de un sistema de empresa
¿Y qué pasa después? Algunos autores (p. ej., Pastor y Esteves, 1999) hablan
de un conjunto de fases posteriores, que incluyen:
• El mantenimiento, sea de corrección de defectos (correctivo), como de

mejora y adaptación a los cambios de los procesos de la empresa (evolu-
tivo).
• La evolución, que incluye la extensión de la funcionalidad y la instala-

ción de nuevos paquetes o colecciones de mejoras (llamados patxes, si son
pequeños, o releases, si son más grandes).
• La migración a una nueva versión más completa o actualizada técnica o

funcionalmente.
• La adquisición e implantación de nuevos módulos para cubrir nuevas

áreas o procesos de la empresa.
3. Fase 1. Adopción del sistema: la decisión de adquirir

un ERP
Los sistemas de información de empresa proporcionan una infraestructura in-

tegrada de datos y un marco de procesos y relaciones común dentro de la em-
presa, entre sus diferentes departamentos, sucursales y filiales y, en su evolu-
ción más reciente, también con sus proveedores y clientes.
Teóricamente, todo el mundo llama a las cosas de la misma manera, usa los
mismos datos y trabaja de una manera homogénea. El interfaz de usuario (la
organización de la información y la navegación por la aplicación) es también
el mismo. Los usuarios finales tienen acceso a información agregada de una
manera más rápida y autónoma y pueden tomar decisiones más ágiles. Por
último, puede permitir compartir determinados servicios (la gestión de pedi-
dos, la relación con los clientes, la contabilidad o la nómina) y eliminar tareas
duplicadas, o sea, hacer "reingeniería" y reducir o reasignar recursos.
Reingeniería de procesos y sistemas de información de empresa
Michael Hammer, inventor del concepto de reingeniería de procesos, lo definió ini-

cialmente como:
"repensar y rediseñar radicalmente los procesos de negocio para conseguir mejoras

radicales en los indicadores clave de rendimiento, como son los costes, la calidad, el
servicio y la velocidad". M.�Hammer;�J.�Champy (1993). Reengineering the Corporation:
a Manifesto for Business Revolution. Nueva York: Harper Business.
A partir de esta idea, los fabricantes e implantadores de sistemas de empresa enfatizan

la potencia de estos sistemas para transformar los procesos, e incluso se habla de un
enfoque de implantación de ERP "orientado a los procesos" (Kirchmer; Davenport).
En realidad, los ERP y sistemas de información de empresa, en sentido amplio, son

una forma limitada de reingeniería de procesos. En el mejor de los casos, no estamos
reinventando los procesos de la organización desde cero, sino adaptando nuestros
procesos a un conjunto de posibilidades suficientemente buenas (good enough) que
habilita el ERP.
Thomas Davenport (2000) señalaba, precisamente, la "universalidad e integra-

ción de la información" como los rasgos más importantes de los sistemas de
información de empresa:
"La primera gran oportunidad de lograr la verdadera conectividad, con

la que se consigue que todos sepan qué hacen los compañeros de nego-
cio en todo el mundo de manera simultánea".
T.�Davenport (2000). Mission Critical. Realizing the Promise of Enterprise

Systems. Boston: Harvard Business School Press. (Se cita la versión en
español).
De acuerdo con la mayoría de las encuestas entre directivos, las principales

razones de adopción de un sistema de información de empresa son:
• Mejorar la exactitud y disponibilidad de la información.

• Mejorar la información para la toma de decisiones directivas.
• Reducir costes y mejorar la eficiencia.
Desde el punto de vista de la informática, el sistema de empresa debería eli-

minar silos de información y aplicaciones departamentales y reducir drástica-
mente los costes de mantenimiento. El proceso de compra es sencillo y rápido
y, según los vendedores, más barato, porque se reparten los costes de desarro-
llo y actualización entre muchos clientes.
Como puede suponerse y conocen bien quienes utilizan o han implantado

sistemas de empresa (sean empleados y directivos de las áreas de negocio o sean
informáticos de los departamentos de sistemas), estas virtudes que prometen
la teoría y los fabricantes se cumplen en un grado muy desigual y, además, no
funcionan ni resultan de la misma manera para todas las empresas y sectores.
Uno de los trabajos de la empresa que está considerando la adopción de un

ERP, o en general, cualquiera de los que llamamos sistemas de información
de empresa, es conocer bien antes de comenzar las consecuencias que tendrá
ahora y en el futuro esta clase de modelo de sistema de información con rela-
ción a otros posibles, su complejidad y costes asociados, así como las diferen-
cias entre las promesas y la realidad.
¿Por qué implantar un sistema de información de empresa?
Es frecuente que muchas empresas adopten esta decisión por la obsolescencia de sus
sistemas actuales, por la urgencia de un departamento para disponer de una determi-
nada funcionalidad, por el consejo de un inversor o porque está de moda.
Proporcionamos a continuación una lista de comprobación que podrían utilizar las

empresas antes de tomar una decisión de este tipo:
• ¿En qué forma están organizados los datos, sobre todo los datos esenciales y co-
munes para todos los departamentos? Cuando decimos cliente, ¿esto quiere decir
lo mismo para todo el mundo y todo el mundo tiene los mismos clientes y los
mismos datos de cada cliente?
• ¿Cómo de complejos o específicos son los procesos básicos del negocio? ¿Qué
nivel de esfuerzo o de adaptación será necesario? ¿Tenemos la organización, los
ejecutivos principales y los cuadros intermedios preparados para este esfuerzo?
• ¿En qué nivel está nuestra infraestructura tecnológica (hardware, software de base
y, sobre todo, el gestor de base de datos)? ¿Están actualizados? ¿Son flexibles y
robustos? ¿Qué nivel de inversión requerirá la adopción de un ERP?
• ¿Qué ventajas competitivas o mejoras sustanciales de eficiencia podemos alcanzar

con la implantación de un sistema de empresa? ¿Las podemos medir? ¿Podemos
hacer a alguien responsable de la obtención de estas ventajas?
• ¿Cuánto nos costará y cómo lo financiaremos?
• Todo el mundo ha oído hablar del esfuerzo y los fracasos de la implantación de

estos sistemas. ¿Qué percepción existe entre los directivos y cuadros acerca de un
sistema de empresa? ¿Entienden las consecuencias para su organización y forma
de trabajar? ¿Lo aceptan? ¿Estarán en condiciones de aceptarlo más adelante?
• ¿Se prevén o están en marcha cambios sustanciales en la estrategia del negocio,

en la estructura de la organización o en los sistemas tecnológicos que aconsejen
especialmente o desaconsejen este esfuerzo? ¿Es ahora el momento?
• ¿Tendremos la capacidad y la paciencia para dedicar recursos técnicos, funciona-

les y directivos a este esfuerzo? ¿Quién lo liderará?
Fuente: Davenport (2000) y elaboración propia.
En función de lo anterior, se deberá diseñar un enfoque y proceso de implan-

tación y comunicación coherente con lo anterior y suficientemente profesio-
nal y robusto. Este enfoque debe reconocer y actuar sobre las resistencias al
cambio e incluir una estrategia activa para conseguir y materializar los bene-
ficios prometidos por el sistema.
La primera fase del ciclo de vida de los sistemas de empresa es la adopción, es

decir, la decisión de adquirir un ERP. Seguidamente examinamos los aspectos
clave, ventajas e inconvenientes de esta decisión.
En el mundo de los sistemas de información de empresa, es importante tener

en cuenta los criterios de diseño del sistema (su arquitectura funcional y téc-
nica) y sus consecuencias para el negocio y la gestión tecnológica. Es crítica
también la gestión del proyecto de implantación, en particular la relación con
directivos y usuarios y la gestión�del�cambio, o sea, lo que tiene que hacer la
empresa necesita en su organización, sus procesos de trabajo y en la actitud
de las personas para que el proyecto sea un éxito.
Finalmente, pero no en último lugar, es importante ser consciente y saber ma-

nejar la enorme presión comercial –también la que procede desde los medios
de comunicación–que rodea al mundo de los sistemas de empresa, así como
poder distinguir con criterio entre promesas y realidades, o, por decirlo más
suavemente, entre el potencial que representa la adquisición del sistema y la
capacidad de la organización y los implantadores de convertir estas promesas
en beneficios para la empresa.
Las�consecuencias�de�adoptar�un�SIE:�temas�clave
1) En primer lugar, recordemos, el criterio básico de diseño del ERP es su orien- Ejemplo
tación�a�la�función. El sistema cubre o debería cubrir los requerimientos fun-
El camarero del bar apunta lo
cionales más comunes de cualquier empresa, esto es, los procesos de trabajo que le ha pedido el cliente y
que realiza el personal dentro de cada departamento. no le importa mucho cómo se
hará la factura. El departamen-
to de compras hace un contra-
to y no le importa mucho ni el
Una vez más, la visión por procesos que ofrecen los ERP es "suficientemente pedido ni la entrega.
buena" para la mayoría de las empresas. Frecuentemente, es una excusa para
documentar y homogeneizar prácticas informales, establecer procedimientos
estándar e introducir mejoras de calidad y tiempo.
Sin embargo, en algunas empresas modernas, organizadas por procesos y pro-

yectos, como hemos visto en los materiales de la asignatura, esta visión no
es suficiente ni competitiva. Un sistema de empresa de un hospital registra
episodios (ingresos, tratamientos, altas), pero no la evolución del estado de
salud, la mejora o el empeoramiento, o las condiciones del enfermo que le
hacen propenso a una enfermedad o al agravamiento de su condición. Un
sistema de información de una empresa de ingeniería registra estados de una
obra (contratos, certificaciones, recepciones), pero no la evolución de la obra,
los problemas aparecidos en el replanteo o las desviaciones de tiempo y coste.
Esta visión funcional o departamental se replica en el diseño del ERP por mó- La cadena de valor
dulos�funcionales y en los propios implantadores. Los consultores o analistas
Es importante diferenciar, por
saben la funcionalidad de un módulo, pero rara vez tienen la visión global de lo tanto, entre procesos�de
los procesos de la empresa. Actualmente, se habla de implantación enfocada trabajo o procedimientos den-
tro de una función o departa-
a los procesos (Kirchmer; Davenport), pero pocas veces resulta así. Paradójica- mento y procesos de negocio,
que se corresponden con los
mente, esto puede resultar frecuentemente una ventaja, porque no es necesa- procesos de la cadena de va-
lor de Porter. Un proceso de
rio introducir grandes cambios organizativos durante la implantación, en es- negocio (por ejemplo, la aten-
pecial si esta afecta a uno solo o pocos módulos del sistema. ción al cliente o la gestión de
un pedido) es transversal e in-
dependiente de una función o
un departamento.
La figura siguiente muestra, de forma un poco distinta de la habitual, la representa-
ción de la cadena de valor. En la parte superior se encuentran reflejados los procesos
básicos del negocio (o cadena de valor primaria), en los que se transforman unas de-
Lectura recomendada
terminadas entradas (inputs) en unos determinados resultados (outputs).
Hemos tratado estos temas
En la parte inferior se muestran los procesos de soporte, o cadena de valor secundaria,
en el módulo 4 de los mate-
es decir, los procesos de infraestructura que resultan necesarios para que la empresa
riales de la asignatura Direc-
funcione, aunque no aporten directamente un valor al producto.
ción estratégica de sistemas y
tecnologías de la información.
J.�R.�Rodríguez;�I.�Lamarca
(2011). Sistemas de informa-
ción y procesos de negocio. Bar-
celona: FUOC.
Figura 4. La cadena de valor
Fuente: Andreu, Ricard, Valor (1996).
Los sistemas incorporados más recientemente al mercado, como los SCM y

CRM, corrigen bastante esta visión si se implantan correctamente. Por ejem-
plo, un CRM moderno permite registrar todos los contactos de la empresa con
un cliente, cualquiera que sea el departamento, y realizar una gestión integra-
da de las ventas y los servicios.
2) Esto hace más importante aún el trabajo de arquitectura�e�integración�de

datos. Lo que el ERP no nos da, por lo menos que nos lo dé la estructura y
jerarquía de datos. Por un lado, se requiere un esfuerzo de integración entre
los sistemas nuevos y aquellos sistemas anteriores, departamentales o locales
(las aplicaciones "heredadas" o legacy), que nunca desaparecen del todo. La
integración es relativamente fácil "dentro" del paquete, pero más complicada
"fuera".
La implantación de un sistema de empresa requiere una estrategia explícita y

completa de sistemas de información (datos, procesos, aplicaciones y tecno-
logía). No es un simple ejercicio táctico de cubrir una determinada funciona-
lidad y sustituir una aplicación histórica por una solución nueva.
También requiere de una particular disciplina organizativa, para que la estruc-

tura de los datos básicos (raw data, o datos raíz, como la información de clien-
tes, proveedores o referencias de productos) sea única e inamovible y toda la
empresa se comprometa a respetarla y mantenerla. En un sistema de informa-
ción de empresa, hay "una�sola�verdad�y�una�sola�manera�de�llamar�a�la
verdad".
3) Desde el punto de vista del negocio, se cuestiona con razón que el ERP hace
a todas las empresas más o menos iguales, eliminando las ventajas�competi-
tivas o culturales de cada empresa. Los sistemas de empresa contienen una
colección de "mejores prácticas" (dejémoslo en "buenas") o de las maneras de
hacer las cosas más frecuentes (cómo se contabiliza el IVA retenido o cómo
se registra un contrato de suplencia en un centro de contactos). Los sistemas
dirigidos a un sector (un hospital o una compañía eléctrica) hacen lo mismo
para todas las empresas del sector. Un ejercicio importante (y estratégico) es

poder distinguir qué ganamos y perdemos en cada caso sustituyendo nuestra
manera de hacer. Es posible que la contabilidad no sea un ejercicio especial-
mente creativo, pero los procesos del core business (la gestión de los pedidos o
del servicio al cliente, por ejemplo) es para muchas empresas lo que les hace
diferentes y mejores (Davenport, 2000). Y, en todo caso, vale la pena recordar
que lo que proporciona o no una potencial "ventaja competitiva" no es un sis-
tema de información, sino una manera diferente y superior de hacer las cosas.
Ved también
Ventajas competitivas genéricas
Una revisión más extensa con
Qué puede ser o no una fuente de ventaja competitiva varía en cada empresa o sec- diferentes ejemplos se puede
tor. Algunas ventajas competitivas que se reportan habitualmente de la adopción de ver en Davenport (2000) y en
sistemas de información de empresa son: las colecciones de artículos y
actas de tipo más académico
• Reducción de costes de almacenamiento e inventario e implantación de sistemas editadas por la profesora Cruz-
Cunha que citamos en la bi-
de suministro just in time.
bliografía.
• Centralización de ciertas funciones de la cadena de valor (por ejemplo, compras),
que permiten aumentar el poder de negociación con proveedores.
• Centralización de ciertas funciones de soporte administrativo (por ejemplo, la

contabilidad, la nómina o los centros de atención de llamadas) mediante la crea-
ción de centros de servicios compartidos.
• Mejora de la agilidad de la gestión de ventas y pedidos, mediante el conocimien-

to de todas las interacciones con el cliente y de compartir datos (por ejemplo,
existencia de inventario de un determinado producto).
• Facilita las operaciones de fusión y adquisición de compañías y la implantación

de métodos de trabajo comunes.
4) Es verdad que el interfaz� de� usuario ha mejorado sensiblemente y cada

vez se parece más a las aplicaciones de oficina. Esta es una ventaja diferencial
para empresas y usuarios acostumbrados a aplicaciones de pantallas negras y
verdes de los entornos "host", pero no tanto para usuarios acostumbrados a
aplicaciones con navegador o a sus hojas de cálculo particulares, por no ha-
blar de los usuarios masivos de las redes sociales o de los gestores digitales de
música y películas. En todo caso, los sistemas de empresa más completos y so-
fisticados contienen una secuencia de procesos, controles, peticiones y panta-
llas habitualmente mucho más complicada que la que el usuario utilizaba con
anterioridad. No es infrecuente que los mayores detractores de los sistemas de
empresa sean los usuarios y operadores finales de las aplicaciones, aún más
que los cuadros directivos y mandos intermedios.
5) Al mismo tiempo, por más que haya aumentado la flexibilidad, modulari-

dad y pluralidad de opciones, los sistemas de empresa raramente se adaptan
como un guante a la organización y sus maneras de hacer, sino más bien es la
empresa la que tiene que adaptar sus procesos de trabajo y maneras de hacer,
o bien desarrollar partes a medida, que el fabricante no incorpora ni mantiene
en sus nuevas versiones. A medida que aumentan las adaptaciones o variacio-
nes sobre el estándar, aumentan los riesgos del proyecto y su sostenibilidad.

Las decisiones de compra e implantación del ERP tienen que tener en cuenta
este equilibrio de ventajas y riesgos.
La implantación de un sistema de empresa puede representar cambios en la

organización, los procesos y circuitos de trabajo y la posición de las personas,
que producen resistencias por parte de los empleados y directivos y que nece-
sitan ser abordados de manera inteligente y efectiva por el cliente.
En realidad, medir este esfuerzo y valorar sus consecuencias suele ser la clave
del éxito –si tuviéramos que señalar una– de la implantación de un sistema de
empresa. De hecho, la mayoría de los fracasos en la implantación de sistemas
de empresa se deben más a causas relacionadas con la organización y las per-
sonas que a causas relacionadas con la tecnología o las capacidades técnicas
de los participantes.
Sistemas de información y cambios organizativos
En líneas generales, la implantación de un sistema de información de empresa repre-

senta siempre una mayor disciplina, un mayor nivel de formalización y homogenei-
dad de los procesos y un nivel de centralización de la información. Por decirlo colo-
quialmente, ya "nadie puede esconderse".
Por mayor que sea la flexibilidad de una implantación, la sensibilidad a las prácticas
de una organización concreta o la participación de los usuarios en el diseño, un sis-
tema de información de empresa es lo que es y lo es para siempre.
Dice Thomas Davenport que adoptar un ERP o un sistema de empresa genérico es

"un estilo de vida".
6) Más en general, es bueno reflexionar de antemano en el tipo de enfoque

de�la�implantación (más táctico o más estratégico, con más o menos "reinge-
niería" de la organización y los procesos) y los beneficios que se desean obte-
ner, porque eso determinará en buena medida el tipo y el nivel de esfuerzo. Y
es bueno disponer de una estrategia para realizar o materializar los beneficios
prometidos por el proyecto.
Enfoque de implantación
Una decisión esencial en la implantación de sistemas de empresa es "la manera" como

el ERP se implantará. Las dimensiones principales a tener en cuenta son:
• El tiempo (y normalmente esfuerzo) que se quiere dedicar a la implantación, o sea,

que la implantación sea más o menos rápida. (Hay empresas que optan por una
implantación más "técnica" y rápida, y piensan que ya desarrollarán más adelante
la reingeniería y la estrategia de realización o materialización de beneficios).
• El grado de cambio en el negocio y, por lo tanto, la adquisición mayor o menor

de una ventaja competitiva (sea por diferenciación, reducción de costes, etc.) o
una mejora sustancial de la eficiencia.
• El mayor o menor número y complejidad de los cambios sobre la solución están-

dar que proporciona el fabricante.
• El alcance de las funciones o unidades empresariales afectadas.
Frecuentemente, muchas decisiones posteriores (la selección del paquete, el lideraz-

go de la implantación, la involucración de usuarios y técnicos, la decisión sobre el
consultor o implantador...) son una consecuencia del enfoque elegido.
7) La integración y migración de los datos procedentes de las antiguas apli-

caciones no es tampoco sencilla y consume muchos recursos. Se requiere un
trabajo de arquitectura previa de datos (qué datos se recogen, dónde y cómo
se recogen, se trasmiten y se guardan, qué aplicaciones y servicios usan estos
datos) y un proyecto�complejo�de�migración o transformación.
8) Habitualmente, la empresa necesita asignar�equipos de personas valiosas

(las que conocen los procesos de trabajo y la estructura de datos), tanto del
negocio como de informática, durante periodos prolongados para que parti-
cipen en el proyecto. Se necesita la implicación de los directivos, cuadros in-
termedios y usuarios que hacen de líderes de opinión y animadores entre sus
colegas para ayudar al éxito.
9) Finalmente, se requieren normalmente servicios�externos muy profesiona-

les y una gestión de proyecto firme que asegure que se consiguen los resulta-
dos de alcance, tiempo, calidad y coste que se prometieron. Frecuentemente,
tanto el implantador como el cliente ven la compra e implantación del siste-
ma como un esfuerzo "táctico" para cubrir una determinada funcionalidad y
el mejor implantador parece que es el que conoce mejor los módulos y los
configura más rápido y más barato.
La compra de software no suele representar más allá del 15% al 20% de la Coste-beneficio
inversión, mientras que los gastos de implantación, "reingeniería", formación
No es infrecuente que las em-
y "gestión del cambio" llegan al 40% o 50% en muchos casos. El coste habitual presas establezcan análisis de
del mantenimiento anual está entre el 15% y el 20% de la inversión inicial. coste-beneficio a la hora de
decidir sobre un sistema de in-
A la hora de la inversión, calcular el coste�total�de�la�propiedad (total cost formación de empresa y que
establezcan incentivos econó-
of ownership) y aflorar lo máximo posible los costes (y beneficios) ocultos es micos para los directivos y téc-
nicos involucrados en función
muy importante. de la consecución de los bene-
ficios esperados.
Puede verse un ejemplo de
Los costes y riesgos de fracaso en la implantación de ERP y otros sistemas de análisis coste-beneficio en Da-
empresa son sustanciales, y pueden afectar dramáticamente a la capacidad de venport (2000), pág. 67.
la empresa de funcionar y dar los servicios básicos de forma interna y a los

clientes y, finalmente, tienen un impacto sobre su cuenta de resultados.
En la literatura empresarial y científica se reporta un gran número de casos de

fracaso en toda clase de empresas y sectores: proyectos que no han cumplido
sus objetivos, sistemas que se han tenido que abandonar o reiniciar, impor-
tantes desviaciones de costes y tiempos, crisis organizativas, etc.
Ya se ve, por lo tanto, que las decisiones de adquirir e implantar en todo o en

parte un sistema de información de empresa, con qué objetivos, qué estrategia
de implantación y despliegue y con qué costes, a corto y largo plazo, son com-
plejas y tienen muchas consecuencias. En realidad, la decisión de adquirir e
implantar un sistema estándar de empresa debería ser una decisión estratégica,
tanto desde el punto de vista del negocio como de la gestión de sus sistemas
y tecnologías de la información (Gartner, 2010).
Quién debe tomar la decisión
Por todos estos motivos, la decisión de adoptar un ERP no es una decisión tecnológi-
ca, sino directiva, y más directiva cuanto mayor sea la dimensión estratégica (obten-
ción de ventaja competitiva), organizativa (cambios mayores en la organización y los
procesos de trabajo), de alcance (funciones, empresas o departamentos afectados) y
de tiempo, coste y esfuerzo.
Es lo que llamábamos más arriba "el enfoque de implantación" (ved recuadro).
El personal de IT puede y debe instruir a los directivos sobre cómo funciona un sis-
tema de empresa, cuáles son las diferencias sobre cómo se venía trabajando hasta
ahora y las consecuencias de la decisión. Puede explicar también el nivel de esfuerzo
requerido y ayudar a "visualizar" el proyecto. También tiene un papel muy activo en
establecer y gestionar el proceso de decisión y, seguidamente, en la decisión de qué
ERP o sistema elegir, según veremos en el apartado siguiente.
4. Fase 2. Selección de la solución estándar
En los apartados anteriores hemos examinado las principales diferencias, ven-

tajas y desventajas de la elección de un software estándar frente a un desarro-
llo a medida.
Una vez se ha decidido que la mejor solución es el software estándar, hay que
seleccionar la aplicación más adecuada entre las existentes en el mercado.
En el caso de que el alcance abarque varias áreas funcionales (por ejemplo, The best of breed
área financiera y recursos humanos), tendremos que tomar la decisión de si
En ocasiones, en lugar de esco-
escogemos dos soluciones de fabricantes distintos buscando la mejor para la ger un software estándar que
gestión del área financiera y la mejor para la gestión de recursos humanos, o integre varias funciones, las
empresas eligen una estrate-
implantaremos la solución integrada de un solo fabricante. gia de diversificación, normal-
mente por razones funciona-
les y también para reducir su
dependencia de un solo pro-
Esta decisión todavía podría ser más compleja en el sentido de decidir, por veedor. Se trata de escoger "lo
ejemplo, que implantamos la solución del mismo fabricante para el área fi- mejor de cada casa" o, como
se dice en inglés, the best of
nanciera y administración de personal y, en cambio, adquirimos una solución breed.
de otro fabricante para el desarrollo de recursos humanos (sistema de compe-
tencias, evaluación del personal y gestión de formación).
En esta clase de estrategia, las múltiples ventajas de integración a que nos he-
mos referido se reducen, aunque empieza a ser frecuente en algunas solucio-
nes de "nicho", que el fabricante haya optimizado la compatibilidad o llegado
a acuerdos con el fabricante del ERP generalista.
Soluciones de ''nicho''
Si la vocación de un sistema de empresa es ser generalista (es decir, cubrir todas o la ma-
yoría de las funcionalidades de una empresa, un sector o una función), en la práctica
existen proveedores que ofrecen soluciones para una parte de la funcionalidad (un sis-
tema de cuadro de mando para la dirección, un sistema de tesorería...) o una solución
departamental o sectorial (un planificador de turnos, un sistema de control de presencia
del personal o un sistema de gestión de imágenes radiológicas en un laboratorio).
SAP, Oracle y otros proveedores de sistemas de empresa facilitan la conexión de otros

sistemas con los suyos, proporcionando enlaces o interfaces de programas de aplicación
(API, application program interface).
En la tabla siguiente, presentamos los pasos habituales que se tienen que seguir
en el proceso de selección de un ERP o cualquier otro sistema de información
de empresa (SIE). Cómo podéis ver, se parece bastante a un proceso iterativo
y de filtros sucesivos hasta llegar a la decisión final.
Tabla 1. Fases del proceso de selección de un sistema de información de empresa
Fase�1.�Busca�de�candidatos�y�primer�filtra- 1) Organización (quién hará qué; roles y res-

do ponsabilidades)
2) Definición de requisitos mínimos
3) Análisis de alto nivel del mercado de este ti-
po de soluciones
4) Primera selección de candidatos
5) Revisión y aprobación de la decisión
Fase�2.�Búsqueda�de�candidatos�según�fil- 1) Organización: revisión de los participantes

trado 2) Refinar los criterios de evaluación
3) Evaluación detallada de los candidatos ele-
gidos
4) Segunda selección
5) Revisión y aprobación
Fase�3.�Análisis�y�demostración�por�los�can- 1) Organización: revisión de los participantes

didatos�y�visita�a�los�proveedores�y�clientes 2) Revisión de los criterios de evaluación
3) Preparación y asistencia a demostraciones
4) Visita a clientes que tengan implantada la
solución
5) Selección definitiva
Fase�4.�Decisión�final,�negociación�y�planifi- 1) Organización: roles y responsabilidades en

cación la fase final
2) Negociación del contrato
Fuente: adaptado de J. A. Pastor; X. Franch; F. Sistach
Lo más habitual para tomar la decisión es establecer un conjunto de caracte-

rísticas funcionales, técnicas y económicas y examinar hasta qué punto dife-
rentes fabricantes cumplen esos requerimientos. Son los llamados métodos de
screening. En ocasiones, es necesario o conveniente realizar un análisis más
completo y complejo, sobre todo de las componentes funcionales, para exa-
minar la distancia entre los requerimientos del cliente y las características de
la aplicación. Se habla entonces de "análisis del gap" (gap analysis).
Otro método más sofisticado es adjudicar a las características elegidas (cober-

tura funcional, características técnicas, comparación entre fabricantes, nivel
de servicio, costes, etc.) unos determinados pesos y ponderarlos para obtener
un resultado cuantitativo. Son los métodos de scoring.
Criterios�de�evaluacion�y�ofertas
Estos criterios pueden variar de una empresa a otra, aunque normalmente son
los siguientes:
1)� Las� características� de� la� aplicación: cobertura funcional, en especial la

respuesta a requerimientos críticos, calidad de los informes, facilidad de uso,
documentación de usuario, flexibilidad o adaptabilidad a las características de
los procesos y de los usuarios, coherencia con la estrategia de la empresa, etc.
2)�Aspectos�técnicos: entorno de sistemas, entorno de base de datos, entorno

de desarrollo, pruebas de rendimiento conocidas, facilidad de integración, es-
calabilidad, etc.
3)�Comparación�entre�fabricantes: garantías técnicas, solidez financiera, nú-

mero y tipo de referencias, confianza en los comerciales, técnicos y consulto-
res, compromiso con el producto y mapa de ruta de evolución, agrupaciones
de usuarios, etc.
4)�Criterios�económicos: en particular el coste total de la propiedad (TCO, o

total cost of ownership). Se trata de valorar todos los costes directos e indirectos
en el tiempo: coste de adquisición, de mantenimiento, de implantación, del
hardware y sistemas de base asociados, de la conversión y migración de datos,
de las integraciones, de las nuevas versiones, etc.
En la tabla siguiente se muestra una mesa típica de valoración de ofertas.
Tabla 2. Selección de un SIE por un sistema de scoring
Característica Peso Valoración A B C Valoración A B C

individual ponderada
Funcionalidad�de�la�aplicación
Completitud 2,5 9 7 8 22,5 17,5 20,0
Calidad de los in- 1,0 9 5 9 9,0 5,0 9,0

formes
Facilidad de uso 2,3 5 9 6 11,5 20,7 13,8
Documentación 2,8 3 9 7 8,4 25,2 19,6
Características�técnicas
Gestor de base de 2,8 8 7 3 22,4 19,6 8,4

datos
Transportabilidad 0,8 2 5 6 1,6 4,0 4,8
Escalabilidad 1,2 4 5 5 4,8 6,0 6,0
Comparación�entre�fabricantes
Fortaleza financie- 2,0 9 7 5 18,0 14,0 10,0

ra
Fortaleza de direc- 1,3 6 9 8 7,8 11,7 10,4

ción
Compromiso con 2,6 4 7 9 10,4 18,2 23,4

el producto
Fuente: Alter (2002), pág. 495

Característica Peso Valoración A B C Valoración A B C

individual ponderada
Comparación�económica
Precio de compra 2,0 7 5 7 14,0 10,0 14,0
Contrato de man- 1,5 7 7 8 10,5 10,5 12,0

tenimiento
Coste de consulto- 0,6 5 6 8 3,0 3,6 4,8

ría
Coste de conver- 2,3 5 3 5 11,5 6,9 11,5

sión
Total�valoración 155,4 172,9 167,7

ponderada
Fuente: Alter (2002), pág. 495
A continuación, comentaremos los aspectos que acostumbran a ser más im-

portantes en la elección.
1)�La�estrategia�de�la�empresa. Una decisión de este tipo es una decisión es-

tratégica que tiene difícil marcha atrás; significará una inversión importante
de fondos y tiempo de informáticos y usuarios, así que hay que tomar la deci-
sión con perspectiva de futuro. Ello significa identificar cuáles son los princi-
pales aspectos competitivos en los que queremos diferenciarnos y, por tanto,
tener claro los beneficios que queremos conseguir en términos de mejora de
costes, fondos empleados y servicio al cliente externo e interno.
2)�El�funcionamiento�de�la�empresa. Cómo está organizada, los procesos, los

datos que se utilizan y la estructura de los mismos, la información de gestión,
los procesos de tomas de decisiones, los sistemas de evaluación de rendimien-
to, los requerimientos legales de la función y/o el sector.
3)�La�cobertura�de�los�requerimientos�funcionales y su nivel de criticidad o

importancia para el rendimiento del proceso. Sin embargo, volvemos a llamar
la atención sobre el hecho de que el ERP es, principalmente, una colección de
procesos-objetivo (o sea, una decisión sobre cómo haremos las cosas), más que
un traje a medida que confeccionaremos según cómo estamos acostumbrados
a hacer las cosas. En definitiva, cómo de importante sea la cobertura funcional
en la decisión dependerá de la visión estratégica y el enfoque que tiene la
empresa de la implantación del ERP.
Cobertura funcional
El principal criterio de selección suele ser el nivel�de�cobertura�funcional del pa-

quete, es decir, hasta qué punto cubre las necesidades de los procesos de negocio de
la empresa.
Para poder evaluar de forma objetiva esta cobertura funcional, se desarrolla una lista
de requerimientos por área funcional y, para cada uno de ellos, se evalúa si cada una
de las soluciones considerada:
• lo cubre totalmente,
• lo cubre pero de una forma distinta a la que lo hace la empresa,
• es necesaria una pequeña adaptación,
• hace falta un desarrollo importante o
• no lo puede cubrir porque el desarrollo necesario afectaría a la integridad del
paquete (cambios en la base de datos o en el acceso a la misma).
No todos los requerimientos tienen la misma importancia y, por tanto, también ha-
bría que clasificarlos en:
• imprescindibles, la no cobertura sin adaptaciones de ese requerimiento invalida-

ría la solución,
• importantes y
• deseables.
Como resultado del ejercicio, tendríamos un porcentaje de cobertura por importancia

de requerimiento; se considera que para que tenga sentido ir a la solución estándar
esta cobertura debe ser, como mínimo, del 80%.
Algunas empresas consultoras ya tienen confeccionadas listas genéricas de requeri-

mientos para algunas funciones o módulos que ayudan a realizar este análisis.
4)�Costes�asociados. Como hemos comentado, la estimación de la dimensión

de costes es muy compleja e incluye diferentes variables, que se desarrollan
en el recuadro siguiente.
Costes totales
• Costes de adquisición de licencias, tanto las de la aplicación como las de otro

software necesario (por ejemplo, bases de datos).
• Coste del hardware asociado a la solución.
• Coste de implantación, el cual dependerá mucho de la facilidad de parametriza-

ción de la solución, del volumen y complejidad de las adaptaciones necesarias,
de los interfases, conversiones de datos y esfuerzo necesario para formar a los
usuarios, gestionar el cambio y el proyecto. Todos estos costes se traducen en ho-
ras/hombre de consultoría de implantación y de personal interno, que también
se deben valorar para poder determinar los costes completos del proyecto.
• Costes de transición; según la estrategia de implantación, durante cierto tiempo

se tendrán que seguir utilizando y manteniendo las aplicaciones y sistemas vi-
gentes; por tanto, también hay que considerar este coste ya que puede ser dife-
rente según las alternativas.
• Costes de operación y explotación, que incluirían los costes de mantenimiento

de licencias de software y equipos, así como de operación del sistema.
• Costes internos y externos de desarrollo evolutivo y mantenimiento.
5)�Garantías�de�la�solución. Como se ha dicho anteriormente, esta es una

decisión estratégica, de ahí que haya que estar seguros de que "el compañero
de viaje" es fiable y tendrá continuidad en el futuro.
Es bueno utilizar informes de analistas externos (por ejemplo, Gartner) e infor-

mación de la empresa sobre solvencia financiera, compromiso y continuidad
del producto, penetración en el mercado, referencias, satisfacción de clientes,
etc. También es útil visitar algunas instalaciones y hablar con los clientes fun-
cionales e informáticos y usuarios finales.
6)�Predisposición�al�cambio, o sea, la flexibilidad y adaptabilidad de la em-

presa a cambios en su organización, sus procesos y sus prácticas de trabajo. Si
la solución implica un cambio considerable en la forma de trabajar, es muy
importante considerar como un criterio independiente la predisposición y las
resistencias al cambio entre los usuarios y los técnicos.
La implantación de un ERP significa cambios en la manera de trabajar, acaso

una reconversión de recursos, modificación de los equilibrios de poder e in-
fluencia, necesidad de dedicar tiempo y recursos críticos durante un tiempo,
grandes necesidades de formación y, finalmente, una transición que no suele
ser fácil.
Las características de la solución y, sobre todo, el enfoque de implantación y

gestión del cambio es un factor muy importante a valorar. Como hemos se-
ñalado en un apartado anterior, el mayor número de fracasos en la implanta-
ción de sistemas de información de empresa están relacionados con aspectos
de "gestión del cambio".
Muchas compañías dedican entre el 20% y el 50% del coste de los proyectos
de sistemas de información de empresa a aspectos relacionados con la gestión
del cambio.
7)�Consultoría�para�la�implantación. Está muy relacionada con lo anterior.

Las empresas dan, con razón, cada vez más importancia a la selección de un
"partner" o consultor externo para la implantación. Frecuentemente, ya se se-
lecciona al mismo tiempo el binomio sistema-consultor. El "socio" de la im-
plantación tiene un potencial elevado para optimizar la solución desde el pun-
to de vista funcional, manejar la relación con los usuarios y técnicos y con el
propio fabricante y ayudar a "gestionar el cambio".
Los aspectos a tener en cuenta para valorar al equipo de consultoría serían:
• Conocimiento y referencias en implantación de la solución.

• Capacidad para el rediseño de procesos.
• Capacidades para la gestión del cambio.
• Capacidades de gestión de proyecto.
• Conocimiento de las tecnologías IT implicadas en el proyecto, directamen-
te o porque inciden en algunos interfases críticos.
• Conocimiento de la empresa en un sentido amplio: del sector, de las per-
sonas, de la cultura, de los procesos, de los sistemas de partida, etc.
• Estrategia de implantación y puesta en marcha propuesta.
¿Cómo eligen las empresas a un consultor/implantador?
Según las encuestas disponibles, las razones más habituales de selección de un im-
plantador frente a otro son:
• Coste
• Reputación
• Referencias
• Compromiso con la solución
• Aptitud para manejar el cambio
• Conocimiento del sector
• Conocimiento y experiencia del software seleccionado
• Disponibilidad de recursos experimentados
• Conocimiento de los procesos de negocio objeto de la implantación
Frecuentemente las decisiones, o al menos las propuestas, son realizadas por

un comité en el que hay usuarios y técnicos; por consiguiente, esta clase de
sistemas parece objetivar la decisión. En esta fase, el papel del departamento
de sistemas de información es mayor, tanto en la gestión del proceso como
en su ejecución.
En realidad, como dice Alter, estos sistemas son fáciles de manipular y deben
usarse más como una manera de excluir soluciones no válidas que como un
procedimiento matemático de escoger el proveedor más válido (Alter, 2002,
pág. 495).
Probablemente, es más útil tener bien claro qué se quiere conseguir, cuál puede Lecturas
ser entre pocos el mejor "compañero de viaje" y cuáles de toda la larga lista de complementarias
requerimientos son los que verdaderamente hacen la diferencia. Puede ser que Podéis ver también Sistach y
haya dos ERP idénticos y que eso diluya la presunta "ventaja competitiva" de Pastor (1999); Pastor, Franch
y Sistach (2002) y, sobre to-
adquirir un ERP. Lo que es seguro es que no hay dos implantaciones idénticas do, Botella y otros (2003).
del mismo ERP. Y, si es así, la dimensión de "coste" no debería tener un peso
tan elevado como parecen indicar las encuestas existentes.
Por ejemplo, la tabla muestra un resumen de los aspectos que se consideraban

clave en un proceso en el cual hemos participado recientemente.
Tabla 3. Ficha resumen de selección de proveedores
Proveedor
Opción (si hay más de una con el mismo proveedor)
Producto/s
Cobertura funcional
Cobertura técnica (en especial aspectos excluidos)
Consultoría, gestión de proyecto, gestión del cambio
Tiempo y fases
Elaboración propia (J. R. Rodríguez)

Equipo
Coste total y por fases (atención con los aspectos excluidos)
Referencias
Aspectos a destacar del enfoque
Dudas o preocupaciones iniciales con el enfoque
Elaboración propia (J. R. Rodríguez)

5. Fase 3. Implantación de la solución
Como suele ocurrir con la mayoría de los proyectos de sistemas de informa-

ción, los procesos, decisiones y productos obtenidos en las fases anteriores de-
ben confirmarse y refinarse en la fase siguiente.
El análisis de requerimientos funcionales, el análisis de la solución estándar,

la evaluación de la organización y su "predisposición al cambio", el mapa de
datos y procesos, la propuesta de implantación formulada por el consultor...
que habremos utilizado para decidir la adquisición de un sistema de empresa,
un fabricante y un implantador son el punto de partida (los inputs) para la
implantación.
La fase de implantación consiste en la personalización (parametrización) o

adaptación del sistema a las necesidades de la organización. Es la fase que
normalmente representa mayor tiempo, complejidad y consumo de recursos.
Los grandes fabricantes, por ejemplo, SAP, requieren de sus partners o socios de Web recomendada
implantación la utilización de unos principios metodológicos básicos y la cer-
ASAP (www.sap.com/asap/
tificación de los practicantes de acuerdo con los procedimientos de la compa- help.) Descargado el 19 de ju-
ñía. Por ejemplo, la metodología Accelerated SAP (ASAP) dispone de un con- lio del 2011.
junto muy amplio de bibliotecas para abordar la implantación de los diferen-

tes tipos de producto.
A partir de este estándar, los diferentes partners, han desarrollado adaptaciones

propias, que suelen incluir aspectos de gestión de proyecto, gestión del cam-
bio, reingeniería, etc. Es el caso de la que presentamos a continuación basada
en la compañía PriceawaterhouseCoopers, que llegó a ser entre 1995 y 2005
líder mundial en la implantación de sistemas SAP. Una particularidad en este
caso es la preparación de un prototipo intermedio, previo a la construcción
definitiva, para asegurar mejor el cumplimiento de la funcionalidad y la co-
modidad del usuario final en el nuevo entorno. A lo largo de la explicación, y

para facilitar la comprensión del estudiante, iremos haciendo referencia a las
denominaciones que usa ASAP.
La implantación se estructura en las siguientes etapas:
Fases 1 y 2
1)�Iniciación�y�definición�del�proyecto, fase en la que se confirman
los objetivos y alcance del proyecto y se determinan los riesgos. En ASAP, las fases 1 y 2 suelen
denominarse project prepara-
tion, e incluyen como aspectos
2)�Planificación�y�lanzamiento�del�proyecto, que incluye la planifi- centrales todos los componen-
tes de organización del pro-
cación detallada, la incorporación del equipo de trabajo, la formación yecto y la definición del alcan-
de los órganos de gestión del proyecto y la comunicación inicial a la ce (scoping).
organización.
Fases 3 y 4
3)�Análisis�de�la�situación�actual, o levantamiento del estado actual
de la organización, los procesos y sistemas de la empresa. En ASAP, las fases 3 y 4 sue-
len denominarse business blue-
print. Como luego veremos, en
4)�Definición�de�la�situación�objetivo, es decir, cómo será el nuevo sis- el enfoque actual de implanta-
tema y qué estrategias y procesos se deberán desplegar para alcanzarlo. ción "rápida" de ERP, el análisis
de la situación actual (as is) es
poco importante y lo que más
5)�Construcción�y�test�del�prototipo en el que se visualiza y se prueba interesa es la modelización de
los procesos futuros de acuer-
el grueso de la funcionalidad en una situación muy similar a la real. do con la propuesta del ERP,
es decir, "cómo serán" las co-
sas (to be).
6)�Construcción�del�sistema, donde se confirma la parametrización del
prototipo, se construyen los desarrollos complementarios y se realiza
la integración y la conversión de datos, la formación de usuarios y se Fase propotipado
planifica el arranque.
En ASAP, la fase de prototipa-
do no existe como fase separa-
da. La fase de construcción se
llama realization.
En ASAP, las fases que nosotros hemos separado como de "Arranque", y que
se estudian en el apartado siguiente, son las de final preparation (que incluye
las pruebas y la formación de usuarios) y el go live (o arranque propiamente
dicho).
En la tabla siguiente, se muestran las fases de la metodología ASAP en su ver-

sión más reciente:
Tabla 4. Implantación de SAP según SAP (accelerated SAP methodology)
1.�Preparación�del�Proyecto�(project�preparation) Objetivos, alcance y entregables

Organización
Planificación
2.�Visión�del�proceso�(business�blueprint) Requisitos de detalle:

Procedimientos, informes, etc.
Integración con otras aplicaciones
3.�Construcción�(realization) Configuración (parametrización)

Construcción de interfaces
Tests individuales
Tests de integración
www.sap.com/asap/help. Descargado el 18 de julio del 2011

4.�Preparación�final�(final�preparation) Estandarización y conversión de datos

Pruebas de usuario
Pruebas de rendimiento
Formación
Administración del sistema
5.�Arranque�(go�live) Pase a producción

Monitorización del uso
Pruebas de rendimiento en productivo
www.sap.com/asap/help. Descargado el 18 de julio del 2011
Como el resto de la metodología que proponemos, estos trabajos técnicos se

deben completar con las actividades de Gestión del proyecto y Gestión del
cambio, que se tratan más extensamente en los apartados posteriores.
5.1. Iniciación y definición del proyecto
En esta etapa confirmamos los temas clave del proyecto, que normalmente ya
se habrán analizado en las fases anteriores, en especial al realizar la selección
de la solución, al pedir y recibir las propuestas de fabricantes e implantadores
y redactar los contratos.
Los elementos a establecer son los siguientes:
• Procesos que cubre el alcance, es decir, qué procesos y procedimientos den-

tro de cada función y/o módulos del ERP forman parte del proyecto.
• Alcance organizativo, o sea, para qué departamentos, geografías o empre-
sas dentro de un grupo.
• Beneficios/objetivos para las funciones implicadas. Qué beneficios se
desean alcanzar en términos de calidad, tiempo y coste.
• Beneficios/objetivos en el ámbito IT.
• Mapa de sistemas e integración con el resto de aplicaciones.
• Impacto y necesidades de infraestructura tecnológica.
• Análisis de las partes interesadas y los aspectos de gestión del cambio en
los que poner mayor foco.
• Business case del proyecto o estudio de retorno de la inversión, en su caso.
• Organización y recursos del proyecto, por parte del cliente y del consultor
o implantador.
• Planificación del proyecto a alto nivel.
• Identificación y análisis de riesgos.
Por su importancia en esta fase y a lo largo del proyecto, en la tabla siguiente

se muestran las diferentes clases de riesgos y su impacto sobre la implantación.
Tabla 5
Riesgos del proyecto de implantación
Riesgo�técnico La arquitectura tecnológica está bien dimensionada y explotada; los siste-

mas de recuperación y de seguridad y control de accesos están previstos.
Riesgos del proyecto de implantación
Riesgo�funcional Los requerimientos están bien identificados, los procesos definidos son
coherentes con la funcionalidad estándar del paquete, los usuarios funcio-
nales clave están incorporados al proyecto y se ha planteado bien la con-
versión de datos.
Riesgo�de El proyecto está bien dimensionado y planificado en el tiempo, el alcance

gestión�del está bien definido y se han establecido los mecanismos para conducir las
proyecto desviaciones del mismo, todos los recursos necesarios se han incorporado,
la toma de decisiones no se demora y los órganos de gestión del proyecto
están constituidos y funcionando correctamente.
Riesgo�de�ges- Los directivos que tienen que apoyar el proyecto están implicados, se han
tión�del�cambio establecido los mecanismos adecuados para manejar las expectativas, están
previstas todas las tareas de comunicación, formación y soporte al arranque
necesarias para que los usuarios "se hagan" con el sistema.
Riesgo�de�ob- Se han tenido en cuenta todos los aspectos que harán posible materializar
tención�de los beneficios de negocio previstos: integridad y adecuación de datos, cam-
los�benefi- bios organizativos, en procesos, personas, sistemas de medición del rendi-
cios�previstos miento de la compañía y los relacionados con actuaciones que tengan que
llevar a cabo terceros (proveedores, clientes, colaboradores...) y que son
necesarios para obtener los beneficios completos de la "nueva forma de tra-
bajar" planteada.
Tal como hemos visto en los apartados anteriores, los de mayor impacto y de
gestión más compleja serán los que manejen las expectativas de los usuarios
para que se adapten al estándar y, por otro lado, los que consigan cambiar la
forma de trabajar para obtener todos los beneficios de negocio que nos hemos
planteado con el proyecto.
5.2. Planificación y lanzamiento del proyecto
En esta fase se pone en marcha la infraestructura que se utilizará para realizar Lanzamiento
el proyecto, se crea y forma el equipo de proyecto, se hace la planificación
En inglés, kick-off.
detallada del proyecto y se da a conocer el proyecto internamente.
Por tanto, las tareas que se llevan a cabo en esta fase son:
• Instalación del software en un entorno de desarrollo en el que se parame-

trizará la solución.
• Incorporación de los miembros del proyecto.
• Formación al equipo del proyecto en la solución a implantar.
• Desarrollo detallado de la planificación del proyecto, en particular la des-
composición en paquetes de trabajo ("estructura de distribución del tra-
bajo" o EDT en la terminología del PMBOK) que tienden a coincidir con
módulos o grandes grupos de procesos de trabajo.
• Definición de estándares de documentación del proyecto.
• Confeccionar la presentación del proyecto.
• Toma de contacto con los principales implicados del proyecto.
• Presentación del proyecto adaptada a los distintos colectivos afectados por
el proyecto.
Los profesores Esteves y Pastor (2004) hicieron un estudio interesante en el que

relacionaban los factores de éxito genéricos para la implantación de proyectos
ERP (en particular, SAP), con las diferentes fases del proyecto. El estudio se basa
en el metaanálisis de trabajos publicados sobre el particular y en la valoración
cualitativa de algunos implantadores expertos. Según su análisis, en las fases
de preparación (la iniciación y la planificación) los factores clave de éxito son:
• El apoyo de la alta dirección

• El trabajo del jefe de proyecto
• La definición del alcance o ámbito del trabajo (qué se hará y qué no se
hará)
• La planificación detallada
• La comunicación interna (dentro del equipo de proyecto) y externa (a la
parte afectada de la empresa)
5.3. Análisis de la situación actual
Esta fase nos tiene que permitir saber de dónde partimos y qué aspectos tene-
mos que tener en cuenta para el sistema objetivo. Sin un buen conocimiento
de la situación actual, será difícil convencer sobre las bondades del sistema y
procesos que propongamos.
En esta fase, hay que saber distinguir entre los aspectos importantes (procesos,
información para toma de decisiones, estructura organizativa, transacciones
que absorben mayor carga de trabajo, calidad de los datos...) de aquellos que
son más bien aspectos formales (diseño de las pantallas o listados).
Un buen análisis de la situación actual tiene que cubrir:
• Estructura organizativa
• Procesos
• Datos maestros
• Mapa de interfases
• Estrategia de conversión de datos
• Información de gestión crítica (permite toma de decisiones o medida del
rendimiento)
• Predisposición al cambio de cada directivo afectado por el proyecto
• Infraestructura tecnológica disponible
Análisis de los procesos actuales
Nótese que, a diferencia de los proyectos clásicos de desarrollo de sistemas (en el lado
tecnológico) o de reingeniería funcional de los procesos (por el lado del negocio), la
implantación de ERP y, en general, sistemas de empresa, incluye solo un análisis muy
ligero de los procesos de partida (as it is).
En realidad, ese análisis debería servirnos para identificar prácticas o usuarios que
pueden ser críticos a lo largo de la implantación del ERP y que requerirán decisiones
directivas de ajuste (es decir, de adaptación al nuevo proceso determinado por el ERP)
o bien de desarrollo a medida. Es valioso, por lo tanto, para el análisis de interesados
y las estrategias de intervención (la gestión del cambio).
Puede resultar también valioso como una referencia del punto de partida ("donde es-
tábamos") para establecer y explicar, antes del proyecto, los beneficios que deseamos
obtener y los cambios que queremos realizar. Y, al final del proyecto, hasta qué punto
hemos alcanzado lo uno y lo otro.
Si el proyecto se ha hecho bien, la mayoría de estas situaciones ya se deberían haber

detectado en el momento de selección del ERP o, como mínimo, en la fase anterior
("iniciación").
5.4. Definición de la situación objetivo
Una vez el equipo está formado en la solución estándar escogida, conocemos Nota
los objetivos del proyecto y la situación actual, se puede definir la situación
Los anglosajones llaman a esta
objetivo. fase el business plueprint, que
puede traducirse por "ante-
proyecto de negocio" o "mo-
Dado que tendremos que desarrollar poco, a diferencia de un desarrollo a me- delo visual del futuro estado
del negocio" (Esteves y Pastor,
dida, en este caso no hace falta diseñar en detalle pantallas o listados, única- 2004).
mente lo tendremos que hacer para la funcionalidad que no cubra el sistema,
pero tampoco lo haremos en esta fase, sino que lo dejaremos para la etapa de
construcción. En realidad, la situación objetivo se visualizará completamente
con los documentos que generemos en esta fase y con la prueba del prototipo
que corresponde a la siguiente fase.
Los documentos que generemos en esta fase deben contemplar:
• Jerarquía organizativa del sistema. Consistiría en la plasmación de la es-

tructura organizativa de la empresa (por ejemplo: entidades legales, fá-
bricas, zonas comerciales, etc.) en las entidades que contemple la solu-
ción (por ejemplo: instancia, mandante, plan de cuentas, centro de bene-
ficio...).
• Procesos objetivo y cobertura respecto al estándar
• Relación de principales informes
• Mapa de interfases
• Estrategia de conversión de datos
• Relación de desarrollos a medida y nivel de criticidad
• Impacto organizativo
• Estrategia de formación
• Contenido del prototipo
• Confirmación de beneficios del proyecto
• Confirmación del alcance y plazos del proyecto

• Actualización del plan de gestión del cambio
Reingeniería facilitada (y restringida) por el ERP
Como hemos señalado más arriba, la diferencia entre la promesa de la reingeniería

"radical" de las primeras obras de Hammer y Champy y la reingeniería "realista" que
se ha practicado en los últimos años es la proximidad entre las necesidades de los
procesos renovados y las posibilidades que ofrece el sistema estándar.
• Mejoras funcionales y posibilidades técnicas se acercan, de manera que el usuario

está en condiciones de explicar qué le gustaría que el nuevo sistema hiciese, y el
fabricante o el consultor están en condiciones de explicar lo que el sistema puede
hacer y lo que no puede hacer.
• En consecuencia, la distancia entre el "cómo es" y el "cómo debería ser" también es

menor y el proceso de implantación consiste en buena medida en irlos acercando.
Sí que es verdad que el alcance de la reingeniería, en cada caso concreto, depende

mucho del enfoque de implantación escogido de entrada y del nivel de esfuerzo,
tiempo y dinero que la organización quiere dedicar y también de las habilidades y
exigencias de cliente y consultor.
Por último, los actuales ERP y sistemas de empresa, y los propios consultores, ofrecen
un conjunto de "buenas prácticas", plantillas de ayuda, etc. que deberían permitir a
la empresa escoger entre muchas maneras diferentes de hacer las cosas y establecer
sus propias innovaciones.
Somos más escépticos, en cambio, sobre la pretensión frecuente de hacer primero una
implantación "rápida y con poca reingeniería" y dejar, para más tarde, un proyecto
de "materialización de beneficios" con un enfoque más ambicioso. El esfuerzo inicial
y las consecuencias de las configuraciones implantadas hacen muy difíciles esta clase
de proyectos.
En todo caso, sí que parece aconsejable el uso de algunas herramientas de "las

de toda la vida", que nos pueden ahorrar algún susto. Entre ellas, destacaría-
mos la matriz de trazabilidad de los requisitos, que establece una relación di-
recta entre los requisitos funcionales y la solución adoptada en cada caso, sea
a través de parametrización o de desarrollo a medida.
En el estudio que hemos citado de Esteves y Pastor (2004), los factores que
aparecían más relevantes en esta fase del trabajo eran "el papel adecuado del
gestor del proyecto, una gestión efectiva del cambio organizacional, el uso
adecuado de consultores y la implicación del usuario". (pág. 8)
5.5. Construcción y prueba del prototipo
A pesar de que también se usan en algunos desarrollos a medida (por ejemplo,

en enfoques tipos "Agile"), en este caso jugará un papel relevante el uso de pro-
totipos, con lo que aprovecharemos la gran ventaja de las soluciones estándar
que ya están desarrolladas. El prototipo permite a los usuarios visualizar bien
la forma de trabajar, objetivar las carencias o necesidad de desarrollos tras ha-
ber visto/probado las diferentes alternativas que plantee la solución estándar
y además facilita que, en un estadio temprano del proyecto, un número sig-
nificativo de usuarios relevantes, mediante las pruebas del mismo, se vayan

haciendo a la idea de la nueva forma de trabajo y, por tanto, vayan cambiando
sus percepciones y venciendo sus "miedos".
Esta fase es la más importante en el proceso de implantación de una

solución estándar, ya que es donde confirmaremos definitivamente la
necesidad de desarrollos a medida y donde los usuarios se darán cuen-
ta de la potencia, integración y amigabilidad "real" de las principales
transacciones.
Si lo pensamos, el desarrollo de prototipo es muy coherente con el enfoque de

implantación de sistemas estándar: por un lado, refuerza y anticipa el control
que finalmente tendrá el cliente, permite obtener una aceptación temprana y
ahorrar costes en el conjunto de la implantación (Alter, pág. 489). Por otro,
este esfuerzo aparente adicional permite reducir sustancialmente el coste de
análisis de la situación actual. Si al final, el usuario tendrá otra cosa diferente
de la que tiene ahora, lo mejor es que la testée cuando antes mejor (Davenport,
pág. 122).
No es infrecuente que, al enfrentarse con el prototipo, los usuarios reales en-

cuentren demoras de tiempos de respuesta, dificultades de navegación o nece-
sidad de pasar por un gran número de pantallas para realizar una transacción
que antes les resultaba más rápida y cómoda.
Esta es una fase a la que hay que prestar especial atención, asegurando que
se haya parametrizado un prototipo que alcance aproximadamente un 80%
de la funcionalidad prevista en el alcance, que las pruebas se hayan hecho
rigurosamente, que haya participado un número relevante de usuarios, que se
haya dedicado tiempo a ver las distintas soluciones que incorpora la solución,
para intentar no salirse del estándar, que se haya tomado nota de todas las
incidencias y al final se haya levantado un acta en el que se refleje la solución
para cada incidencia.
De lo dicho anteriormente se deduce la importancia que tiene esta fase para

gestionar las expectativas de los usuarios y poder planificar con buena base
tanto los desarrollos como la formación y el resto de actividades de gestión
del cambio.
Actividades típicas en esta fase:
• Construcción del prototipo.

• Definición de perfiles de usuario.
• Identificación de usuarios clave y usuarios "típicos" de cada una de las
funciones en un número suficiente para que la prueba sea fiable.
• Construcción de juegos de prueba por función y de integración de proce-

sos.
• Prueba a nivel función y a nivel integrado.
• Análisis de las incidencias y peticiones de cambios, clasificación según cri-
ticidad y evaluación de soluciones propuestas.
• Documentación final de la prueba y comunicación de las acciones a los
órganos de gestión del proyecto y a los usuarios.
• Planificación detallada de la construcción final del sistema y confirmación
de estimaciones y plazos.
Es muy importante, al término de esta fase, cerrar definitivamente el alcance

y aprobar o no las peticiones de cambios y desarrollos a medida.
Qué es parametrizar en la práctica
Un sistema estándar tiene programadas distintas opciones para ejecutar los dife-
rentes procesos, para determinar qué información debe aparecer en las pantallas,
qué reglas de cálculo aplicar, los campos de los informes, etc.; cada empresa, de
acuerdo con sus necesidades, ha de hacer una elección entre estas opciones si-
guiendo un cierto orden, que se acostumbra a llamar guía de parametrización.
Para ello va cumplimentando una serie de campos, parámetros, que el sistema
le va pidiendo.
Normalmente, empezaríamos por los parámetros más generales que se aplican a

todos los módulos del sistema, como podría ser el lenguaje o la moneda de refe-
rencia; a continuación se definiría la estructura organizativa: grupo empresarial,
sociedades dependientes, líneas de negocio, etc.; luego vendrían los parámetros
correspondientes a cada módulo, por ejemplo, en el caso de la contabilidad serían
parámetros del tipo longitud de la cuenta, número de periodos contables, instru-
mentos de cobro y pago que usaremos...; en un módulo de aprovisionamientos
podría ser la definición del código de materiales, las distintas descripciones que
querríamos usar, los distintos modos de cálculo de pedido que desearíamos habi-
litar y así sucesivamente módulo a módulo.
Al ser un sistema integrado, hay parámetros de un módulo que lo relacionan con

otros; por ejemplo, asociado a un material podríamos tener la cuenta contable
en la que queremos que se reflejen sus movimientos de existencias, por lo que la
coordinación entre módulos es fundamental. Para facilitarla, en proyectos com-
plejos hay un miembro del equipo de proyecto que se ocupa de la integración; en
el diseño inicial del sistema objetivo es muy importante reflejar bien estas cone-
xiones entre módulos. Por ello, como es habitual tener una organización del pro-
yecto por áreas funcionales o módulos, se tienen que realizar bastantes reuniones
conjuntas para poder compartir una visión completa del sistema y que aproveche
las ventajas de disponer de un sistema integrado.
Otro aspecto importante a destacar, como se observa en los ejemplos menciona-

dos, es que los parámetros mayoritariamente corresponden a decisiones funcio-
nales y no informáticas, y por tanto las decisiones tienen que tomarlas usuarios
que conozcan muy bien los procesos y la situación objetivo que se quiere alcan-
zar. En este sentido, se acostumbra a nombrar un "usuario clave" por área, que
sería el que tomaría las decisiones críticas en el caso de que la elección entre las
opciones que ofrece el sistema no fuera inmediata.
En una situación ideal, cambiando los parámetros se podría ir adaptando el sis-

tema a la evolución de la empresa, pero en la realidad esto no es tan fácil por la
relación que hay entre unos parámetros y otros, lo que hace que al final todo esté
interrelacionado y no sea fácil de mover, salvo lo que sean funciones indepen-
dientes como cambiar un informe o una pantalla o usar una forma determinada
de calcular los pedidos.
Precisamente por esta complejidad es importante que la guía de parametrización

esté bien documentada y actualizada; algunos sistemas generan de forma auto-
mática esta documentación.
Por estas razones, Davenport (2000, pág. 159) habla de la "naturaleza vital" de la
parametrización: "La configuración es el proceso mediante el cual se definen los
detalles del sistema a fin de ajustarlos al sistema y viceversa". El sistema son los
detalles, cuestan mucho esfuerzo y perduran mucho tiempo.
En las imágenes siguientes se muestran algunas pantallas de un sistema sectorial,

la "estación clínica de trabajo" (o sea, el puesto de trabajo de un médico de hos-
pital), basado en la aplicación sectorial sanitaria de SAP R/3.
Figura 5
Y a continuación, un ejemplo de la "historia clínica individual" o, más bien, un

resumen de los episodios de atención de un paciente de un proveedor sanitario
(cortesía del Institut Català de la Salut, Barcelona).
5.6. Construcción del sistema
Tras la prueba del prototipo ya podemos diseñar en detalle y construir los

desarrollos a medida, alimentar todas las estructuras de datos, construir las
interfases, la conversión de datos, desplegar definitivamente la infraestructura
tecnológica, desarrollar la formación y planificar pruebas finales y planes de
contingencia.
Por tanto, las actividades son:
• Diseño detallado, programación y prueba de desarrollos a medida. Nota

• Diseño detallado, programación y prueba de interfases.
¡Atención! A veces la conver-
• Plan de conversión de datos. sión de datos, por su impor-
• Desarrollo y prueba de programas de conversión. tancia, se tiene que considerar
un proyecto en sí mismo.
• Desarrollo de los contenidos de formación.
• Definición y desarrollo de autorizaciones y perfiles de seguridad.
• Plan de pruebas finales (rendimiento del sistema, integración, interfases,
conversión).
• Plan de pruebas de usuario final o, aún mejor, pruebas de la disponibilidad

operativa, es decir, el funcionamiento real del sistema en un entorno lo
más parecido posible al de producción.
• Formación de formadores y de usuarios.
• Plan de contingencia por si hay problemas en el arranque.
• Desarrollo del plan de soporte al arranque.
En el estudio mencionado de Esteves y Pastor (2004), los factores más impor-

tantes en esta fase del trabajo son las siguientes:
• Infraestructura e interfaces adecuadas

• El rol del jefe de proyecto
• Disponer de un plan de pruebas formalizado
• Uso adecuado de los consultores
• Anticipación de problemas inesperados
• Involucración de los usuarios
La gestión de proyecto en el día a día
En realidad, la práctica de las fases de ejecución tiene que ver solo relativamente con
la teoría. En los proyectos de cierta dimensión, pueden estar asignados uno o más
jefes de proyecto responsables de la evolución del trabajo.
El día a día del trabajo del jefe de proyecto es anticipar, identificar y resolver proble-
mas y, sobre todo, estar atento a la gestión de los cambios, los riesgos y la relación
con los interesados.
Debe entrevistarse, formal o informalmente, con los miembros del equipo de trabajo
y las personas clave del cliente.
Finalmente, tiene que preparar los informes y presentaciones de seguimiento. Pero

este trabajo de control y seguimiento no es más importante ni sustituye a la tarea
principal: gestionar, gestionar y gestionar.
Dice Richard Newton (2006), autor británico de varios libros de gestión de proyectos:
"El jefe de proyecto debería empezar el día pensando:
• ¿Qué cosas están causando en este momento mayores dificultades en el proyecto?

• ¿Qué cosas es más probable que las causen en el futuro?
• ¿Sobre qué cosas podemos influir y son de nuestra responsabilidad?
• ¿Cuál es la más importante que tengo que hacer hoy?".
Por nuestra parte, añadiríamos que debe pensar también sobre en qué cosas puede
influir el cliente para mitigar o resolver las dificultades actuales y futuras, y programar
la manera de influir para que el cliente haga también lo que tiene que hacer.
6. Fase 4. Puesta en marcha
La puesta en marcha es el proceso o conjunto de procesos que permiten el

traslado del producto obtenido a la operación ordinaria de la empresa en la
que tiene que funcionar. Este traslado tiene al menos dos componentes:
• El uso del sistema por los usuarios de diferente perfil para los cuales se
diseñó.
• La explotación y el mantenimiento técnico ordinario por parte de los ser-
vicios de informática de la empresa.
A su vez, la puesta en marcha se compone de un primer momento de "arran- Nota

que" y una fase siguiente de "estabilización", corrección de errores e inciden-
Cómo hemos mencionado,
cias. las metodologías originales de
SAP, por ejemplo, distinguen
entre una fase de "preparación
El hecho de que esta fase sea más fácil o no, como es lógico, depende de la final", que incluye la migración
de datos y las pruebas de fun-
rigurosidad con que hayamos llevado a cabo todas las fases anteriores y de un cionamiento en preproduc-
ción, y la fase propia de go live,
correcto proceso de planificación. El arranque se debe planificar, gestionar y puesta en marcha o arranque,
comunicar adecuadamente. con la subida a producción y
las pruebas de funcionamiento
en operación.
Pero incluso haciéndolo todo escrupulosamente, si se trata de un proyecto
con un alcance amplio y un gran número de usuarios es normal que aparez-
can problemas. No nos olvidemos de que, en general, estaremos cambiando
la forma de trabajar; por tanto, las dudas puede que no sean solo sobre el uso
del sistema, sino que también lo pueden ser de procedimiento, de exactitud
de datos, de interpretación de resultados, de rendimiento del sistema o sim-
plemente de claves de acceso y perfiles de autorizaciones de algunos usuarios
relacionados con su nuevo "contenido de puesto de trabajo".
En el estudio mencionado de Esteves y Pastor (2004), los factores de éxito en

estas etapas finales (recordamos que según ASAP, esto incluye la preparación
y el go live, propiamente), serían las siguientes:
• El papel del jefe de proyecto

• La comunicación efectiva
• La anticipación preventiva de problemas
• El apoyo continuado de la alta dirección
Para gestionar bien el arranque es conveniente centrarse en tres aspec-

tos, desde el punto de vista de los usuarios:
• Un buen soporte a usuarios, cercano, a ser posible de personas del

mismo departamento, con criterios claros de "escalado" de las inci-
dencias.
• Un procedimiento ágil de resolución de incidencias y seguimiento

de las mismas.
• Un procedimiento de monitorización del arranque y de gestión de

la comunicación de los éxitos y problemas para objetivar los avances
y evitar que se magnifiquen los problemas.
Una vez ha transcurrido un plazo razonable desde el arranque y se han resuelto

las incidencias, es interesante hacer encuestas para conocer el uso del sistema
que se está haciendo y planificar acciones de formación de refuerzo, con el
objetivo de poder acabar obteniendo todos los beneficios previstos. Igualmen-
te, en esta fase se acabará de poner en funcionamiento aquella funcionalidad
que no era crítica para el arranque, generalmente listados o consultas, y que
se haya podido planificar para el final del proyecto.
• Desde el punto�de�vista�técnico, el proyecto "acaba" cuando la organiza-

ción de IT del cliente ha asumido la explotación, el mantenimiento ordi-
nario y la resolución de incidencias.
• Desde el punto�de�vista�administrativo, el proyecto acaba con la entrega

de la documentación al cliente y la firma de las actas de aceptación.
• Desde el punto�de�vista�de�negocio, Esteves y Pastor aconsejan la realiza-

ción de una auditoría de "postimplantación", para documentar lecciones
aprendidas y establecer correcciones o gaps pendientes de ejecutar. En un
sentido parecido, recientemente se defiende la importancia de medir las
mejoras de tipo operativo o estratégico que el SIE debería haber incluido
para redefinir o mejorar, en su caso, la estrategia de sistemas de informa-
ción de empresa de una organización (Gartner, 2011).
7. Gestión del cambio
A lo largo de los distintos apartados se ha comentado que, habitualmente, Ejemplo

la implantación de una solución estándar, por ejemplo un ERP, comporta un
Por ejemplo, interactuar con
cambio en la forma en que las personas desarrollan sus tareas. Este cambio unas pantallas distintas, con
puede ser solo en las formas, o que afecten a los procesos y a las prácticas de diferentes criterios de navega-
ción o búsqueda o registro de
trabajo. los datos.
Ejemplo
Que se dejen de hacer ciertas tareas porque se han automatizado, que se incorporen nue-
vos pasos y nueva información y que se puedan delegar decisiones a niveles inferiores
de la organización, ya que se dispone de la información para poder tomarlas con cono-
cimiento de causa, o que la persona o su puesto de trabajo cambie y se enriquezca con
nuevas funciones.
La aproximación clásica ante la adopción de nueva tecnología ha sido invertir

en la documentación y en la formación de usuarios. Pero, cuando se producen
cambios profundos (que pueden afectar a la organización, los procesos de tra-
bajo y los recursos humanos), esto no es suficiente. No todo el mundo está a
favor del cambio o lo vive de la misma manera. Las reacciones ante el cambio
de aquellos que van a perder algo con él y las incertidumbres que provoca el
hecho de tener que cambiar la forma habitual de trabajo aconsejan poner en
marcha acciones para facilitar la adopción de la nueva solución y minimizar
las resistencias.
7.1. Un modelo de gestión del cambio
Llamamos gestión del cambio al conjunto de acciones que tiene que

poner en marcha el cliente, con ayuda del implantador, para asegurar
que se cumplen los resultados del proyecto.
Estas acciones normalmente son de tipo organizativo, de procesos de

trabajo, del contenido, reasignación o cantidad de los puestos de traba-
jo, retributivas y de incentivos (podríamos llamarlas acciones hard o de
estructura) y otras relacionadas con las habilidades (liderazgo, trabajo
en equipo, motivación), la comunicación y la formación (las que po-
dríamos llamar soft).
Un modelo integrado de gestión del cambio que incluye los dos tipos de es-
trategias se muestra en la figura siguiente:
Figura 7. Modelo de gestión del cambio
Fuente: J. R. Rodríguez; I. Lamarca; J. García Minués
Aunque aquí nos referiremos a la segunda clase (las de tipo soft), en particular
las de comunicación y formación, donde la intervención del equipo de pro-
yecto es mayor, no debe olvidarse en ningún momento que, en la mayoría de
los casos, el cliente deberá tomar decisiones comprometidas "de estructura" sin
las cuales las acciones puramente soft pueden ser incluso contraproducentes.
Veámoslo en el ejemplo siguiente:
Las dimensiones ''hard'' de la gestión del cambio. Un ejemplo
Si creamos un canal de atención al público por Internet, lo más probable es que a

medio plazo se modifique nuestra carga de trabajo de atención presencial o telefónica
(disminuyendo o, curiosamente, a veces aumentando) y, por tanto, la estructura de
personal y su cualificación.
Necesitaremos crear de nuevo o contratar externamente un nuevo servicio de front-

office (por ejemplo, para contestar consultas o incidencias por Internet), que puede
funcionar por separado o integrado con nuestro back-office (las diferentes oficinas o
funciones administrativas tradicionales).
Esto precisará de una buena y nueva definición de los circuitos administrativos, el

poder de resolución de cada nivel de la estructura y, por lo tanto, su dimensión,
capacidad y formación necesaria.
Internet representa un servicio permanente y ubicuo, ahora además con los nuevos
terminales telefónicos. Por lo tanto, quizá esto nos obligue a reestructurar los horarios
y turnos del personal.
Todo ello producirá incertidumbres y resistencias en nuestra organización clásica, los

gerentes funcionales y los propios trabajadores. Podemos identificar mejor sus intere-
ses y disposición para el cambio, establecer estrategias de comunicación y formación,
alianzas y otras intervenciones "políticas". Pero no conseguiremos el resultado del
proyecto si no manejamos a la vez las estrategias hard y las estrategias soft.
Basado en J.�R.�Rodríguez;�J.�García�Minués;�I.�Lamarca (2007). Gestión de proyectos

informáticos: métodos, herramientas y casos (cap. IV.7). Barcelona: Editorial UOC.
Un proceso de gestión del cambio pasa por las siguientes etapas:
1)�Análisis�de�implicados, donde establecemos el nivel de influencia de las

diferentes partes de la organización que afectan o son afectadas por el pro-
yecto y su posicionamiento o predisposición hacia los cambios derivados del
proyecto.
2)�Comprensión�de�los�intereses�y�resistencias. La resistencia al cambio es

normal. Se trata de entender las causas de la resistencia y los intereses de cada
una de las partes.
3)�Estrategias�de�intervención�sobre�la�estructura�de�la�empresa: organiza-
ción (jerárquica, funcional, geográfica, por negocios, etc.), procesos y prácticas
de trabajo y circuitos administrativos, definición y asignación de puestos de
trabajo, cantidad de recursos, retribuciones e incentivos.
4)�Estrategias�de�intervención�sobre�el�proyecto�de�implantación�del�SIE:
nivel de centralización y autonomía en las definiciones de los procesos, nivel
de reingeniería, adhesión al estándar o desarrollos a medida, petición y gestión
de cambios, organización (órganos colegiados e individuales) y procesos de
toma de decisiones, estilo de dirección del proyecto, rol de los consultores.
5)�Estrategias�de�intervención sobre la comunicación y la formación.

Debido a la extensión del módulo y la complejidad de abordar todos los temas

involucrados, aquí trataremos aquellos aspectos sobre los que es habitual que
el equipo de proyecto tenga una intervención mayor.
7.2. Análisis de implicados
En su artículo "La elección de estrategias para el cambio", John P. Kotter y Leo-

nard A. Schlesinger analizan los orígenes de la resistencia al cambio y las po-
sibles estrategias para minimizarlas. Según ellos, para hacer una buena gestión
del cambio lo primero es identificar a todos aquellos que se pueden ver afec-
tados por el cambio y a todos aquellos que pueden influir en el mismo, que
no siempre coinciden cien por cien.
• Los afectados por el cambio son las personas del departamento de sistemas
y los usuarios del nuevo sistema, y entre los distintos miembros de estos
dos colectivos no les afectará a todos por igual ni todos tendrán la misma
percepción. También pueden estar o sentirse afectados colectivos de fuera
de la empresa, como son los clientes o proveedores.
• Los que pueden�influir en el cambio normalmente son los directivos de

los departamentos afectados por el mismo, pero dado que en una empresa
existe una red de relaciones podemos encontrar personas que, aunque no
tienen que ver directamente con el cambio, sí nos pueden ayudar a con-
vencer a otros, o al revés, personas que a pesar de que el proyecto no les
afecte –aunque solo sea para que otro "no triunfe"– harán lo posible para
que el proyecto fracase.
A quién afecta el cambio. Un ejemplo
Para ilustrar con un ejemplo sencillo lo que es el análisis de implicados, imaginemos

que estamos en una empresa que trabaja bajo pedido y que el proceso que sigue
para poder dar un precio a un cliente empieza en que los comerciales recogen una
información del tipo de producto que quiere, después comunican esta información a
la oficina técnica, que tiene las listas de materiales, los precios de los mismos y conoce
las distintas operaciones que hay que seguir para fabricar el producto y, utilizando una
hoja de cálculo, calcula un coste que le pasa al director financiero, quien, aplicando
un margen, le asigna un precio de venta y lo comunica por correo electrónico al
comercial para que presente la oferta al cliente.
Resulta que el director general considera que es fundamental ganar agilidad y ha

pedido que se implante un nuevo sistema ERP que permita integrar los flujos de
información de los distintos departamentos y automatice algunos cálculos; como
resultado de ello, los vendedores dispondrán de una aplicación en la que, entrando
ciertas características del producto y del cliente, la aplicación ya les confeccionará el
presupuesto y les sugerirá un precio.
La posible reacción ante este cambio puede ser:
• Comerciales: tendremos algunos que estarán entusiasmados con el nuevo siste-

ma porque les da mayor autonomía y les permite responder más rápido a los
clientes, pero en cambio puede ser que haya otros a los que les dé miedo el ma-
nejo correcto de la aplicación o tengan dudas de si la aplicación funcionará bien
y que, por tanto, al final puedan acabar dando un precio erróneo que tenga con-
secuencias negativas para ellos.
• Oficina� técnica: de entrada, las personas que se dedican a calcular los costes
pensarán que se van a quedar sin trabajo, otros creerán que los comerciales no van
a ser capaces de operar bien la aplicación y, por último, puede haber alguno que
vea positivo el cambio y piense que estas tareas eran muy repetitivas y que ahora
tendrán más tiempo para mejorar los procesos, que es lo realmente importante
de la oficina técnica.
• Dirección�financiera: pueden tener una reacción en el sentido de desconfianza

en que el nuevo sistema sea fiable y piense que ellos deberían seguir siendo los que
repasen los cálculos y asignen precios. Claramente, el director financiero puede
pensar que con este nuevo sistema él pierde información y poder en la empresa.
• Dirección�general: es el impulsor del cambio y, por tanto, lo apoya.
• Dirección�de�sistemas: el director de sistemas puede ser partidario de la mejora

de los procesos y ver el proyecto como una oportunidad para aportar valor al
conjunto de la empresa; en cambio, en su departamento los informáticos que
crearon la aplicación a medida que se usa actualmente pensarán que pierden
relevancia y, además, van a tener que hacer un esfuerzo por aprender el nuevo
sistema.
El análisis de posicionamiento de los implicados se recoge en una matriz en que se

identifica, por un lado, su nivel de influencia en la organización o el proyecto, y en
el segundo eje su propensión (positiva, indiferente o negativa al cambio).
Figura 8. Mapa de implicados
Los colores indican si están a favor o en contra del cambio
Con este ejemplo tan sencillo ya vemos el impacto en una empresa que pue-
de tener la introducción de un sistema integrado y la importancia de conocer
quiénes están afectados, su posición respecto al cambio y su poder de influen-
cia para hacer que sea un éxito o un fracaso. La gestión del cambio consisti-
rá en hacer toda una serie de acciones a lo largo del proyecto que permita
"neutralizar" a los que se oponen al cambio y, apoyándonos en los que están
a favor, mover a la mayoría indecisa a una posición de apoyo al proyecto y
adopción del nuevo sistema.
7.3. Causas de las resistencias al cambio
Las resistencias al cambio tienen su origen en:
• Defensa�de�los�propios�intereses�porque�se�siente�que�se�va�a�perder�algo
con�el�proyecto. Es el caso de las personas de la oficina técnica que tienen
miedo de quedarse sin trabajo o del director financiero que piensa que
perderá relevancia en la empresa. Para minimizar esta resistencia hay que
escuchar a los colectivos afectados –para entender sus argumentos– y, en el
caso que sea posible, tranquilizarlos dándoles una solución. Normalmente
se usan "herramientas políticas" (ved el cuadro anexo).
• Falta� de� comprensión� o� confianza. Muchas veces la resistencia es por

desconocimiento, por no entender por qué hace falta el proyecto, por no
conocer la nueva aplicación y desconfiar de su funcionamiento. Para solu-
cionar este aspecto es fundamental un buen plan de comunicación (en el
cuadro anexo se explica qué debe cumplir). Además, para ganar confian-
za es fundamental acercarse progresivamente al sistema, poder probarlo y
plantear dudas, entender cómo encajan los procesos con la organización y
el nuevo sistema –de ahí la importancia del prototipo que hemos comen-
tado anteriormente– y sobre todo desarrollar un plan de formación com-
pleto, cuyas características comentamos más adelante.
• Percepción�distinta�del�cambio. Por un mal diagnóstico puede haber per-

sonas de la organización que piensen que el proyecto no es una buena de-
cisión; en el ejemplo anterior serían las personas del departamento finan-
ciero que creen que es muy arriesgado que no sean ellos los que finalmente
den los precios. Para minimizar esta resistencia, de nuevo es fundamental
un buen plan de comunicación y formación, todo ello hecho de forma
bidireccional, es decir, pudiendo plantear dudas de una forma abierta y
respondiéndolas con honradez desde el proyecto.
• Escasa�tolerancia�al�cambio. Esto ocurre por miedo a ser capaz de desem-

peñar correctamente el trabajo con el nuevo sistema. Se soluciona con co-
municación, formación y un buen soporte al arranque del sistema. El he-
cho de utilizar formadores del propio departamento que asuman un rol de
"entrenador" o coach da muy buenos resultados.
• Influencia�del�entorno. Como hemos dicho, normalmente la mayoría de Ejemplo

afectados reacciona ante el cambio de una forma pasiva, esperando acon-
El cierre de fases, como es
tecimientos; por tanto, son influenciables por aquellos que son más cíni- la prueba del prototipo, los
cos, escépticos o simplemente están en contra del cambio porque tienen arranques parciales en un pro-
yecto largo o una planificación
algo que perder; para contrarrestar esta corriente opositora, es muy impor- detallada y completa de la for-
mación, son buenos ejemplos
tante obtener éxitos a lo largo del proyecto que permitan demostrar que para dar sensación de avance.
el proyecto es necesario, avanza y está bien gestionado.
7.4. Buenas prácticas de intervención sobre la comunicación
En tabla siguiente mostramos un "catálogo" general de estrategias de interven-

ción generales, centrándonos seguidamente en la comunicación.
Tabla 6. Estrategias genéricas de intervención y gestión del cambio
Situaciones en + - Factor crítico éxito

que se emplearía
Comunicación • Siempre • Ayuda a persuadir • Si está vacía puede ser • Honradez

• Clarifica mala • Ritmo
• Neutraliza rumores • Medios variados
• Implicar organización
Formación • Cambios en procesos y • Se percibe como inver- • Lleva tiempo • Formación a formadores
sistemas sión • Inversión para hacerlo • Ejemplos, prototipos
• Estilo dirección • Consigue "adeptos" "bien" • Profesionalidad
• Tangible
Apoyo,�coaching • Problemas capacita- • Tangible • Caro y lento • Profesionalidad

ción • Alineamiento • No cumplir expectati- • Evaluación de la demanda
• Cambia comportamien- vas • Cercanía
tos
Prototi- • Cambios en procesos y • Reduce riesgos • Inversión • Encontrar equilibrio en-

pos,�pilotos sistemas • Elimina resistencias "ra- • No bien hecho puede tre inversión/efecto de-
• Falta de "credibilidad" cionales" "matar" la iniciativa mostración
• Cambios arriesgados • Clarifica oposiciones "ra- • Participación amplia
cionales" • Asegurar el tiro
• Centrar expectativas • Escuchar resultados prue-
• Apoya formación o co- ba
municación
Fuente: José M.ª Joana; Rafael Gracia; Josep Bolart; Ana Lucía García (2011). Gestión con éxito de grandes proyectos de transformación, el caso del ICS. Barcelona: Editorial Profit.
La comunicación es crítica en el contenido, el formato, la oportunidad o, dicho

en términos clásicos, en el emisor, el receptor, el medio que se utiliza y el
conjunto de ruidos que se generan en medio del proceso.
La comunicación sirve para mitigar las expectativas e incertidumbres de la Ejemplo

organización con relación al cambio. Tan malo es comunicar mucho como
Es bueno, por ejemplo, mos-
hacerlo poco, y siempre es mejor hacerlo sobre hechos que sobre promesas. trar mediante los propios resul-
tados del proyecto (por ejem-
plo, prototipos) los beneficios
La tabla siguiente muestra un conjunto de buenas prácticas de gestión del del nuevo sistema.
cambio en materia de comunicación, extraídas como lecciones de la implan-

tación de un gran ERP en un grupo de servicios sanitarios públicos.
Tabla 7. Principios y buenas prácticas en políticas de comunicación
Comunicar visión y Comunicar con honradez Construir un plan de comunicación

proceso de cambio
• El porqué del cambio. • Diciendo la verdad acerca de los riesgos • Teniendo en cuenta todos los medios de
• Los objetivos que se quieren conseguir y cambios comunicación disponibles
• Los beneficios para la institución y para • Resaltando los aspectos de coherencia y • Asignando responsabilidades
las personas que forman parte de ella alineamiento con el programa de trans- • Creando mecanismos para poder medir
• El proceso que seguirá el proyecto formación y la estrategia la recepción de los mensajes
• Lo que se espera de cada uno y cómo se • Construyendo el futuro sin ser destructi- • Creando foros que permitan escuchar a
les apoyará vo con el pasado, ya que nos dirigimos a los receptores
• Los éxitos y cumplimientos de metas personas que han formado parte de esa • Segmentando los mensajes según desti-
historia y queremos que ahora nos apo- natarios
yen
Fuente: José M.ª Joana; Rafael Gracia; Josep Bolart; Ana Lucía García (2011). Gestión con éxito de grandes proyectos de transformación, el caso del ICS. Barcelona: Editorial Profit.
Herramientas políticas de gestión del cambio
Según Jack Pinto (1999), que es todavía el gran autor clásico sobre la influencia del
factor humano en la implantación de sistemas de información, la "política" es un
factor inherente a cualquier cambio y, por tanto, a casi cualquier proyecto de sistemas
de información. Lo es en el caso de los sistemas de información de empresa, donde
frecuentemente los equilibrios de poder, la influencia, la asignación de funciones y
la autonomía de gestión de las partes pueden ponerse en entredicho.
De hecho, como hemos visto en algunos ejemplos, el origen de muchos proyectos

de ERP es de tipo estratégico, organizativo o político (reorganizaciones de empresas,
fusiones y adquisiciones, centralización de determinados servicios comunes, etc.).
Los miembros del equipo de trabajo y, particularmente, el jefe de proyecto tienen que
ser capaces de identificar estos elementos desde el principio y, en colaboración con
el cliente, desplegar sin miedo un conjunto variado de estrategias de intervención.
En el cuadro siguiente se muestra un ejemplo de esta clase de estrategias "políticas",
basadas en el mismo ejemplo anterior.
Tabla 8
Situaciones en + - Factor crítico éxito

que se emplearía
Participación • Promotores no tienen • Hace que la gente haga • Hace falta tiempo y pa- • Honradez
toda la información y suyo el cambio ciencia • Selección equipos
otros tienen gran poder • Obtienes información • Minusvalorar resisten-
resistencia cias
Negociación • Algún individuo tiene • Reduces resistencias fácil- • Peligro de chantaje • Con quién y cuándo
mucho poder y puede mente • Puede ser caro usarlo
hacer fracasar el cambio
Coopción�y • Alternativas si otros mé- • Barato • Perder confianza • No abusar de este mé-
manipulación todos no funcionan • Persona cooptada jue- todo
• La coopción es fair gue en contra
Coerción • El promotor tiene poder • Ejemplarizante • Puedes dejar a la gente • Si se tiene que utilizar
• No puedes perder tiem- • Rápido resentida no alargar el proceso
po • Puedes perder informa-
ción
7.5. El plan de formación
Un buen plan de formación tiene que cubrir los siguientes objetivos:

• Conseguir que todos los usuarios tengan una visión completa del nuevo
entorno y, por tanto, que entiendan los objetivos del proyecto y la nueva
forma de trabajar, es decir, organización, procesos y sistema. La formación
tiene que centrarse en las necesidades del usuario en su puesto de trabajo,
no en la explicación simple de lo que hace la herramienta informática.
• Desarrollar las habilidades y los conocimientos para un buen uso del sis-
tema, o sea, que sepan operar las pantallas, entiendan el significado de los
campos, etc.
• Crear una red de expertos generando "formadores internos", los cuales se-
rán el primer soporte en el momento del arranque y ayudarán a que el
sistema pueda evolucionar correctamente. También tienen un rol de "lí-
deres de opinión" y son personas de referencia para facilitar la adopción
del nuevo sistema.
• Utilizar el plan de formación como canal de comunicación para canalizar

dudas y sugerencias.
En el recuadro siguiente, mostramos algunas recomendaciones de cómo reali-

zar un buen plan de formación:
Recomendaciones para un buen plan de formación
• Si es un sistema muy amplio, por ejemplo, un ERP, desarrollar la formación en

varios módulos según las distintas funciones y nivel de especialización. Por ejem-
plo, contabilidad general, costes, contabilidad avanzada, construcción de infor-
mes, compras, etc. Esto sería "la oferta" de formación.
• Identificar a todos los usuarios, el contenido de su puesto de trabajo en términos

funcionales y su ubicación física, y "casar" las necesidades de su puesto de trabajo
con "la oferta" de formación. Para ello, se pueden confeccionar unas tablas/cues-
tionarios y enviarlos a los jefes de departamento para que clasifiquen a su perso-
nal, o que ellos mismos se apunten a la formación que consideran necesaria.
• Identificar la infraestructura necesaria para la formación: aulas, PC, cursos en

línea.
• Desarrollar el entorno de formación del sistema; hay que intentar usar casos,
juegos de prueba y datos reales, de tal forma que se parezcan lo más posible a
lo que es el entorno normal de trabajo. Para no distorsionar la construcción del
sistema, lo mejor es tener "una copia" del sistema específico para la formación.
• Asegurarse de que el sistema de formación tiene un buen tiempo de respuesta,

no hay errores, etc. Si la formación falla de forma importante, puede poner en
peligro el éxito del proyecto dada la desconfianza que tal cosa creará.
• Acercar la formación lo máximo posible a la fecha de arranque, con lo que garan-

tizamos que los nuevos conceptos adquiridos estarán "frescos" para los usuarios.
• Crear juegos en línea que permitan la autoformación o el repaso de conceptos.
• Establecer un buen sistema de evaluación y feedback de la formación para asegu-

rarnos que hay la asistencia necesaria y que se adquieren los conceptos.
8. Gestión de proyecto
Una implantación de un sistema de información de empresa es un proyecto.

También lo es el proceso de adopción, la selección del software, el arranque,
la migración de datos... Esto no es trivial, no es una manera de hablar.
En palabras del PMBOK (2008), el estándar más reconocido de la profesión

de gestionar proyectos: un proyecto es un esfuerzo temporal para crear un
producto, servicio o resultado que es único.
Estas características (la temporalidad, la elaboración progresiva y la creación de

un producto único) serían las características intrínsecas del "modo" proyecto,
frente a las operaciones y procesos ordinarios de la empresa, lo que hacemos
cada día.
Lo característico de los proyectos TIC actuales y, particularmente, los sistemas Componentes técnicos
de información de empresa, es su carácter�mixto, "mestizo", una mezcla de
Productos de hardware, soft-
componentes técnicos, componentes de negocio y una interacción particular ware y comunicaciones
con la organización que hace que todo eso pase (lo que llamábamos en el
apartado anterior la gestión del cambio) (Rodríguez y Mariné, 2010).
Componentes de negocio
Según el planteamiento, que compartimos del PMBOK, cada fase o etapa de un Nuevas maneras de trabajar y
estructuras organizativas que
proyecto de implantación de ERP, como de otros productos TIC, puede consi- producen mejoras de la efi-
derarse en sí misma un proyecto o subproyecto con unas reglas y procesos de ciencia y la competitividad.
trabajo que son comunes. También podemos decir que cualquier proyecto TIC
tiene las mismas reglas y habilidades (el mismo "método"), que debe comple-
mentarse en cada caso con las reglas o procesos más específicos de cada tipo
de proyecto (en nuestro caso, las de implantación de un ERP).
Queremos decir que una cosa es un producto�TIC y los métodos y pro-

cesos de creación e implantación de tal producto, y otra un proyecto
TIC, que incluye un conjunto de procesos comunes, más amplio y com-
plementario a la entrega del producto y, por tanto, también un con-
junto de capacidades y habilidades que son diferentes. Un buen jefe de
producción o un buen analista de SAP no es necesariamente un buen
jefe de proyecto.
En un proyecto se hacen más cosas (gestionar personas, presupuestos, riesgos,

facturas, contratos, expectativas de los clientes, peticiones de cambio, trans-
formaciones de la organización...) y se hacen de otra manera (con otra clase
de procesos, documentos y técnicas). En otro lugar hemos dicho que se podría
decir que los ciclos de gestión del proyecto y creación (o implantación) de un
producto son como el "yin" y el "yang", o como dos caras de la misma moneda
(Rodríguez y Mariné, 2010, pág. 13-14).
Es interesante ver, de todas maneras, que esto resulta más fácil de comprender
para los profesionales acostumbrados a la implantación de ERP o sistemas de
empresa en sentido genérico. El profesional implantador de sistemas de em-
presa, los miembros de los equipos, los clientes, entienden bien y pronto que
gestionar�el�proyecto es un elemento central y básico del proceso de implan-
tación, aún más que en los proyectos de desarrollo a medida, a causa del nivel
de complejidad y riesgo. Y es ya muy frecuente, a diferencia de otros proyectos
TIC, que se dedique un jefe de proyecto a tiempo completo para asegurar la
dirección, gestión y administración de todos los componentes y dimensiones
de un trabajo de estas características.
De hecho, muchas de las metodologías de implantación de sistemas de em-

presa, como la que hemos presentado en los apartados anteriores, ya muestran
una cierta convergencia entre los procesos de gestión del proyecto de implan-
tación y los procesos de gestión de cualquier proyecto TIC en general, inclu-
yendo la gestión del cambio.
Como el estudiante ya ha recibido o recibirá una formación más o menos ex-

tensa en las competencias de gestión de proyectos, dedicaremos este apartado
a hacer un recordatorio de los principios y procesos clave y, de alguna mane-
ra, conectarlos con los procesos que acabamos de ver de implantación de SIE,
haciendo énfasis en aquellos aspectos que consideramos más importantes en
los proyectos de esta naturaleza.
8.1. Procesos típicos de la gestión de proyectos
Los procesos básicos de la gestión de cualquier proyecto de cualquier tipo son

(figura�9):
Figura 9. Ciclo de vida del proyecto
1)�Iniciación, cuando la dirección de la compañía identifica de diferentes ma-

neras un problema o necesidad de su negocio, lo interpreta o conceptualiza
en forma de proyecto, encarga y analiza su viabilidad técnica y económica y
los riesgos, y, si procede, lo aprueba.
Los productos de la fase de iniciación son estudios de viabilidad, casos de ne-

gocio, pero el más importante de todos es un documento que la literatura an-
glosajona llama project charter y que aquí se ha traducido por "acta de constitu-
ción", donde se aprueba el proyecto, se establece el alcance preliminar, el orga-
nigrama con los principales participantes y se realiza el análisis de interesados.
En la metodología que hemos presentado en los apartados anteriores, esta fase

de iniciación coincide con trabajos que se realizan en las fases de adopción (la
decisión de comprar un SIE, selección (la elección de una solución concreta)
y, sobre todo, al comienzo de la implantación, en el momento de definición
del proyecto.
2)� Planificación, en la que se realiza la planificación detallada del trabajo,

desde el punto de vista de los productos a obtener, las actividades a realizar
para su consecución, los recursos técnicos y equipos humanos involucrados,
la duración y el coste.
Lo que llamamos las líneas de base (baselines) de alcance, tiempo y coste son los
elementos básicos del plan, contra los cuales iremos comparando el progreso
del proyecto durante su realización. Estos tres elementos están íntimamente
relacionados: una modificación de cualquiera de ellos afecta a los demás. Y el
producto principal es el plan de proyecto.
En la metodología que hemos presentado anteriormente, esta fase vendría a

coincidir con el lanzamiento de proyecto.
3)�Ejecución. La ejecución consiste en la realización del trabajo en el día a día

conforme a los planes y la reacción lo más ordenada posible a los cambios e
incidentes que surgen a lo largo del trabajo. La ejecución incluye el aviso y la
petición de cambios e incidencias y su resolución, así como la replanificación

del proyecto en función de las modificaciones (de alcance, tiempo y recursos)
que se van produciendo y aprobando.
En las metodologías de implantación de un SIE que hemos mostrado más arri-

ba, en esta fase estaría propiamente el análisis, la construcción e incluso el
arranque.
Proyectos TIC
El ciclo de gestión del proyecto comparado con el ciclo de gestión de un
SIE
Un desarrollo a medida, la im-
plantación de un ERP, la ins-
En el enfoque teórico más estricto de la disciplina de gestión de proyectos, cualquier talación de una red wi-fi, la
proyecto TIC de cualquier naturaleza en realidad tiene sus reglas y procesos específi- construcción y publicación de
cos de trabajo, que estarían dentro de la fase de ejecución, todos ellos juntos. una web.
Dicho de otra manera, toda la metodología de implantación que hemos mostrado

en los apartados anteriores sería en la realidad la ejecución de un proyecto de im-
plantación de un SIE, que debería estar precedido, acompañado y enmarcado en la
metodología de gestión de proyectos en general.
La confusión entre lo uno y lo otro es bastante común, y la coincidencia de la termi-

nología en muchos casos contribuye a ello.
La distinción puede parecer un poco académica, aunque tiene consecuencias prácti-

cas cuyo análisis está fuera del alcance de esta introducción. El estudiante encontrará
algunas reflexiones sobre todo esto en los materiales y la bibliografía de las asignatu-
ras de gestión de proyectos, en especial en el PMBOK (J. R. Rodríguez y P. Mariné,
2010, módulo 1, pág. 25-27).
En todo caso, solo dar un vistazo a la colección de procesos, documentos y áreas de

conocimiento que cubre la disciplina de gestión de proyectos (project management),
como hacemos a continuación, da una muestra de que las metodologías al uso de
implantación de ERP, como las de otros productos informáticos, están por desgracia
aún bien lejos del nivel de formalización y rigor que serían deseables en proyectos en
muchas ocasiones de tal envergadura y complejidad. Aunque, probablemente en el
caso de los ERP y SIE, se reconoce mucho más que en otros casos la importancia de
los procesos de gestión económica, gestión de interesados, gestión de las personas,
comunicación, satisfacción del cliente, etc.
A cambio, las metodologías clásicas de gestión de proyectos no contemplan muy ex-

tensamente aspectos como la organización del proyecto, la gestión del cambio y, en
general, "todo lo que tiene que pasar en el cliente" para que el proyecto sea un éxito.
Y solo recientemente se están incorporando aspectos relacionados con las habilida-
des del jefe de proyecto, la comunicación o los aspectos políticos de la gestión de
proyectos complejos, como es la implantación de un SIE.
A efectos prácticos, al comenzar un proyecto de implantación de ERP o de cualquier

otra cosa, es bueno comenzar estableciendo entre todos los participantes una meto-
dología, un diccionario y una documentación común. Normalmente, la mayoría de
los clientes y proveedores de un cierto tamaño tienen una metodología de base.
4)�Seguimiento�y�control. Los procesos de seguimiento (monitorización) y

control (evaluación y corrección), como muestra la figura, se pueden consi-
derar permanentes y paralelos durante todo el proyecto, aunque son especial-
mente pesados en la fase de ejecución.
Todos los aspectos contenidos en el plan de proyecto se deben perseguir, eva-

luar y, si procede, reajustar.
Los procesos más críticos en esta fase son los de control de cambios (peticiones
o incidencias que afectan a la planificación inicial) y los de gestión de riesgos.
5)�Cierre. Esta etapa incluye todas las actividades necesarias para la finaliza-
ción del proyecto y la comprobación del cumplimiento de las obligaciones
contenidas en el contrato (si lo hay) o en el acta de constitución (project char-
ter).
Esta etapa incluye la aceptación de los productos por parte del cliente y las
revisiones acordadas posteriores al cierre (por ejemplo, un determinado nivel
de mantenimiento durante un tiempo). Incluye también actividades internas
al equipo de trabajo como la documentación de lecciones aprendidas y su
traspaso a una biblioteca de conocimiento.
El cierre no coincide con el arranque, la estabilización y el traspaso de los

productos al cliente, que serían propiamente actividades propiamente de la
ejecución, concretamente de las etapas de puesta en marcha. Nuevamente,
diferenciar entre el cierre, desde el punto de vista de la gestión de proyectos, y
el cierre desde el punto de vista de la producción de un entregable o la puesta
en marcha de un producto es el aspecto clave.
Seguidamente, se presenta un resumen de los procesos típicos del ciclo de vida

de la gestión de proyectos TIC, a la luz de estas metodologías.
Tabla 9
Principales procesos del ciclo de vida de la gestión de un proyecto TIC
Procesos Denominaciones�en�inglés
1.�Iniciación
1.0. Estudio de viabilidad Business case
1.1. Aprobación (acta de constitución) Develop project charter
1.2. Identificación de interesados Identify stakeholders
1.3. Definición inicial Preliminary project scope statement
1.4. Organigrama del proyecto Organization chart
2.�Planificación
2.0. Enfoque y plan de gestión del proyecto Project management plan
2.1. Alcance detallado Project scope planning and definition
2.2. Actividades, recursos y tiempo Activity and time planning
2.3. Costes y presupuestos Project cost planning
2.4. Plan de calidad Project quality planning
2.5. Plan de recursos humanos Human resource planning
2.7. Plan de comunicación Project communications planning
2.8. Plan de gestión de riesgos Risk management planning
2.9. Plan de administración y compras Acquisitions and contracting
3.�Ejecución
3.0. Gestión de la ejecución Manage project execution
3.1. Lanzamiento del proyecto Kick-off
3.2. Gestión de incidencias Issue management
3.3. Gestión de cambios Change management
3.4. Aseguramiento de la calidad Quality assurance
3.5. Gestión de los recursos humanos Human resource management
3.6. Distribución de la información Distribute information
3.7. Gestión de expectativas Manage stakeholders expectations
3.8. Gestión de compras y contratación Acquisitions management
Principales procesos del ciclo de vida de la gestión de un proyecto TIC
Procesos Denominaciones�en�inglés
4.�Seguimiento�y�control
4.0. Seguimiento y control del trabajo Monitor and control work
4.1. Control de cambios Integrated change control
4.2. Control del alcance Scope control
4.3. Control del calendario Schelude control
4.4. Control de costes Cost control
4.5. Control de la calidad Quality control
4.6. Información del progreso Performance reporting
4.7. Seguimiento y control de riesgos Risk monitoring and control
4.8. Administración y gestión de compras Contract administration
5.�Cierre
5.0. Cierre del proyecto Close project
5.1. Cierre del contrato Contract closing
8.2. Las áreas de conocimiento
Además de una cierta codificación de los procesos de gestión de proyectos y

una amplia colección de buenas prácticas (good practices), extraídas del ejerci-
cio profesional de muchos jefes de proyecto de muchas disciplinas diferentes,
una aportación muy interesante de la gestión de proyectos como materia in-
dependiente (y de su plasmación en el PMBOK), es el concepto de áreas de
conocimiento.
Las áreas de conocimiento son los aspectos clave que deben manejarse en cual-
quier clase de proyecto para alcanzar los objetivos acordados con el cliente.
Podría decirse que cada área de conocimiento contiene una "caja de herra-
mientas" que el jefe de proyecto experimentado debe adaptar a cada situación
y proyecto. Esta caja de herramientas son procesos, es decir, representan la
transformación de unos inputs (normalmente activos de la organización o bien
resultados o entregables de un proceso anterior) en unos resultados (outputs)
o entregables (deliverables), por medio del empleo de un conjunto de técnicas
y herramientas.
De nuevo vale la pena recordar que estas áreas de conocimiento, sus procesos
y herramientas son independientes de las técnicas y procesos específicos de
cada metodología de construcción o implantación de un producto TIC. Por
ejemplo, el análisis de interesados o la distribución de información entre los
miembros de un comité de dirección es un proceso genérico, común a cual-
quier clase de proyecto. La parametrización de un proceso o la introducción
de una tabla de cuentas en un mandante de SAP es un proceso específico de
la metodología de implantación de un ERP.
Áreas de conocimiento según el PMBOK
Sobre este punto, nada obvio de entender, de las diferencias entre la gestión de pro-
yectos como metodología de propósito general y las metodologías propias de cada
tipo de proyecto, en este caso la implantación de un SIE, puede verse el recuadro "El
ciclo de gestión de proyecto comparado con el ciclo de gestión de un SIE".
Las áreas de conocimiento según el PMBOK son las siguientes:
1) La gestión�de�la�integración, que incluye el conjunto de funciones directivas y

de coordinación que realiza el jefe de proyecto.
2) La gestión�del�alcance, es decir, de los objetivos, resultados y productos que están

incluidos en el proyecto (y los que están excluidos).
3) La gestión�del�tiempo, o sea, el calendario de realización del proyecto y entrega

de los diferentes productos y paquetes de trabajo.
4) La gestión�de�los�costes, particularmente la dedicación del equipo humano y los

costes de los equipamientos y otros materiales.
5) La gestión�de�la�calidad, entendida como la conformidad del proyecto y los pro-

ductos con unas determinadas normas y estándares, así como la calidad percibida,
es decir, la satisfacción del cliente con el trabajo realizado. Muchas compañías de
servicios que implantan SIE tienen actualmente certificados algunos o muchos de sus
procesos de gestión con normas de gestión de la calidad.
6) La gestión�de�los�recursos�humanos, es decir, las políticas de selección, incorpo-

ración, formación, desarrollo y evaluación de las personas en el equipo de proyecto.
7) La gestión�de�la�comunicación, entendida como el conjunto de procesos de re-

cogida, generación, almacenamiento y distribución de información dentro del pro-
yecto y a los diferentes miembros partes interesadas.
8) La gestión�de�riesgos son los procesos necesarios para identificar aquellos acon-

tecimientos potenciales que pueden tener un impacto sobre el proyecto, anticipar
que ocurran, prever las consecuencias y establecer las acciones de corrección o miti-
gación, en caso de ocurrencia.
9) La administración�y�gestión�de�compras�y�contratos, o sea, todos los aspectos

económicos y legales de la relación con los contratistas externos.
Como hemos avanzado ya, creemos que a estas áreas que reconoce el PMBOK, deberían
añadirse al menos dos áreas específicas de enorme importancia en la gestión de proyectos
TIC, y en particular de la implantación de SIE:
1) La gestión�del�cambio, tal como la hemos descrito anteriormente, o sea, el conjunto

de procesos sobre la organización, procesos y personas (aspectos hard) y los aspectos de
comunicación, formación, motivación y liderazgo (aspectos soft) que debe manejar el
cliente con la ayuda del implantador, para conseguir los resultados propuestos.
2) Y la organización,�dirección�y�gobierno del proyecto, es decir, el establecimiento de

los órganos individuales y colegiados de gestión del proyecto y los roles y responsabili-
dades de todos, en los diferentes equipos de trabajo, internos y externos. A este último
aspecto dedicaremos a continuación algunas referencias.
Según el PMBOK y otras metodologías basadas en este enfoque, a cada una de las áreas
de conocimiento le corresponde un conjunto de procesos, de técnicas y entregables. Por
nuestra parte, en otra obra hemos hecho un resumen y clasificación de los que consi-
deramos más importantes en un proyecto TIC y (Rodríguez y Mariné, 2010, módulo 2,
apartados 2 y 4).
Tabla 10. Correspondencia entre grupos de procesos y áreas de conocimiento
Áreas de co- Grupos de procesos de gestión de proyectos

nocimiento
Procesos�de Procesos�de Procesos�de Procesos�de�segui- Procesos�de�cierre
iniciación planificación ejecución miento�y�control
Gestión�de�la�Inte- Desarrollar el acta de Cerrar proyecto o fase

gración�del�proyec- constitución
to
Áreas de co- Grupos de procesos de gestión de proyectos

nocimiento
Procesos�de Procesos�de Procesos�de Procesos�de�segui- Procesos�de�cierre
iniciación planificación ejecución miento�y�control
Gestión�del�alcance • Recopilar requisi- • Verificar el alcan-

del�proyecto tos ce
• Definir el alcance • Realizar el con-
• Crear la EDT trol del alcance
Gestión�del�tiempo • Definir activida- • Realizar el con-

del�proyecto des trol del cronogra-
• Secuenciar activi- ma
dades
• Calcular los re-
cursos de las acti-
vidades
• Calcular la dura-
ción de las activi-
dades
• Desarrollar el
cronograma
Gestión�del�coste • Calcular costes • Realizar el con-

del�proyecto • Determinar el trol del presu-
presupuesto puesto
Gestión�de�la�cali- • Planificar la cali- • Realizar el asegu- • Realizar el con-

dad dad ramiento de la trol de calidad
calidad
Gestión�de�los�RR. • Desarrollar el • Incorporar el

HH. plan de RR. HH. equipo de pro-
yecto
• Desarrollar el
equipo de pro-
yecto
• Dirigir el equipo
de proyecto
Gestión�de�las�co- • Identificar intere- • Planificar las co- • Distribuir la infor- • Informar del ren-
municaciones sados municaciones mación dimiento
• Gestionar las ex-
pectativas de los
interesados
Gestión�de�los�ries- • Planificar la ges- • Hacer segui-

gos tión de riesgos miento y contro-
• Identificar los lar los riesgos
riesgos
• Realizar el análi-
sis cualitativo de
riesgos
• Realizar el aná-
lisis cuantitativo
de riesgos
• Planificar la res-
puesta a riesgos
Gestión�de�compras • Planificar las • Realizar compras • Administrar com- • Cerrar compras y

y�contratos compras y con- y contratos pras y contratos contratos
tratos
Con relación a los proyectos de implantación de sistemas de información de

empresa, llamamos la atención sobre la importancia relativa de los siguientes
procesos:
• La�apertura�y�cierre�de�cada�fase, normalmente estructurada por módu-

los funcionales o grupos de procesos dentro de cada módulo. Es particular-
mente importante obtener la aceptación del cliente después de la presen-
tación del prototipo y, de nuevo, en el momento de las pruebas de usuario.
• El�control�del�alcance, tanto en el aspecto estratégico como el operativo.

Estratégicamente, el enfoque de implantación debe clarificar desde el ini-
cio, por decirlo llanamente, si el SIE se adapta a la empresa o es la empresa
la que se adapta al SIE. De forma operativa, debe definirse inicialmente
y reconfirmarse en el prototipo el alcance de los procesos objetivo y si se-
rán objeto de configuración dentro del estándar ofrecido por el fabricante
u objeto de un desarrollo a medida. El control firme de las peticiones de
cambio suele ser una clave del éxito.
• La� planificación� y� administración� de� tiempos, costes y contratos, en

especial si interviene personal de diferentes empresas y del propio cliente.
La gestión de la dedicación del cliente acostumbra a ser un problema.
• La�calidad�del�producto, como el valor, se le supone. Curiosamente, la

mayoría de los fabricantes de SIE no suelen presentar prueba alguna de
que sus procesos de producción de software pasen ningún control de ca-
lidad ni auditoría externa. En cuanto al implantador, parece dar un plus
de confianza aquel implantador cuyas metodologías, procesos de trabajo y
documentación están acreditados. Este suele ser un valor más reconocido
en la contratación de los mantenimientos de las aplicaciones.
• El�desarrollo,�la�motivación�y�carrera�de�los�equipos es muy importante.

Los proyectos de implantación de SIE, en especial los sistemas integrados y
multiempresa, suelen ser procesos largos. La parametrización es un trabajo
bastante detallado y repetitivo que puede desmotivar a muchas personas.
• La�comunicación,�formal�e�informal, y la gestión de las expectativas de

los clientes son procesos muy críticos, a los que nos hemos referido en un
apartado anterior.
• Los proyectos de implantación de SIE, sobre todo de cierto tamaño, están

expuestos a�riesgos de toda clase, que hemos introducido en un apartado
anterior.
• Cada vez es más importante en proyectos de cierta dimensión la interven-

ción especializada de abogados y contables para asegurar la defensa de las
partes en la�contratación y el seguimiento de los contratos.
8.3. La organización del proyecto
Pero, probablemente, de todas estas, ninguna es más importante que

la organización del proyecto. Entendemos aquí por organización la de-
finición clara de los roles y las responsabilidades de todas las personas
que participan en el proyecto (usuarios, técnicos, implantadores, pro-
gramadores y analistas, contratistas y subcontratistas...) y las estructuras
de distribución del trabajo y toma de decisiones.
8.3.1. Roles clave en el proyecto
Los tres roles más importantes en cualquier implantación de SIE son:
1) El patrocinador (o sponsor). Es la figura de la dirección que conoce los ob-

jetivos del proyecto y su impacto en el negocio. Es quien toma las decisiones
principales de alcance y de cambios y asegura la asignación y dedicación de re-
cursos. Debería ser normalmente un directivo funcional responsable del mó-
dulo que se implanta (el director comercial, si es un CRM; el director financie-
ro, si es un ERP financiero, etc.).
2) El jefe�de�proyecto es la persona que tiene la responsabilidad máxima de

dirigir la ejecución del proyecto y asegurar el cumplimiento de los objetivos.
Tiene la autoridad ordinaria sobre el equipo de trabajo. Debe ser una persona
designada por el patrocinador y puede tener un perfil funcional o técnico. Ac-
tualmente, es frecuente que este papel lo asuma personal de los departamentos
de informática, con un buen conocimiento del área de negocio, pero con un
perfil técnico y conocimiento de la relación con proveedores de servicios in-
formáticos. Normalmente, el proveedor externo aporta su propio jefe de pro-
yecto. Ambos deben trabajar juntos.
3) Los miembros de los equipos, formados normalmente por usuarios y per-

sonal de la empresa o empresas que facilita la implantación (consultores de
parametrización, analistas y programadores de la parte de desarrollo e integra-
ción). Es frecuente establecer una figura o figuras de usuario�clave o super-
usuario, con quien se diseñan y corrigen los prototipos y se ajusta el producto
final. Frecuentemente también actúa como formador y referencia para otros
usuarios.
La definición de roles y responsabilidades se establece mediante una matriz,

en la que se establece para cada proceso o grupo de actividades:
• Quién tiene la competencia para ejecutarla. RACE

• Quién tiene la facultad o autoridad sobre el proceso, aunque pueda ejecu-
El modelo más sencillo de esta
tarlo otra persona. matriz se llama RACE (siglas de
• Quién debe ser consultado o debe participar en la decisión. responsible, accountable, con-
sult, inform) y se puede con-
• Quién debe ser informado. sultar en Rodríguez y Mariné
(2010, pág. 19-23).
8.3.2. Órganos colegiados
Los órganos de coordinación, toma de decisiones y resolución de conflictos

son muy importantes en los proyectos de implantación de sistemas de empre-
sa. En estos órganos están representados las partes interesadas (usuarios, téc-
nicos) y el personal clave de las empresas externas que participan.
Dependiendo de la amplitud del proyecto, hay tres clases de comités:
1) El comité�de�dirección, que preside el patrocinador y en el que participan

los miembros de primer nivel de la estructura de usuarios, técnicos y empresa
externa, y desde luego el jefe de proyecto. También suele participar el director
de sistemas de información. Puede tener un papel informativo y de formación
de la opinión, al servicio del sponsor, que es quien toma las decisiones, aunque
es frecuente hallar comités y procesos más "democráticos", donde las decisio-
nes se toman por consenso.
2) Un comité�operativo, en el que no suelen figurar los directivos. Está presi-

dido por el jefe de proyecto y participan las personas que tienen las responsa-
bilidades en las diferentes partes del proyecto en el día a día. Prepara y revisa
la información y las decisiones que deben tomarse en el comité de dirección.
3) Un comité�de�usuarios, sobre todo en proyectos grandes, que representa

la voz del usuario intermedio y final, tanto en las decisiones de configuración
más importantes, los cambios sobre el estándar y las evoluciones o manteni-
mientos futuros, en especial los cambios de versiones. Tiene un rol de aseso-
ramiento a la dirección de informática y al propio patrocinador del proyecto.
En el estudio de Esteves y Pastor (2004) sobre factores clave de éxito en la im-

plantación de proyectos SAP, en la literatura de gestión de proyectos tecnoló-
gicos (Rodríguez y otros, 2010 y 2011), en los estudios más recientes de Gartner
(2011) y otras empresas de prospectiva, el resultado es siempre el mismo: las
razones de éxito de los proyectos de implantación de sistemas de información
de empresa dependen en mayor medida de razones organizativas y de gestión
de las personas, que de la bondad tecnológica del producto o de la sabiduría
técnica de los implantadores.
Por ejemplo, en el artículo de Esteves y Pastor, los factores que más con-
tribuyen al éxito fueron los siguientes:
• El rol del gestor o jefe de proyecto, de forma muy destacada

• La implicación y participación de los usuarios
• La comunicación hacia dentro y hacia fuera
• La planificación formalizada
• El apoyo continuado de la dirección
• La gestión efectiva del cambio dentro de la organización
• El uso adecuado de los consultores
Resumen
Los sistemas de información de empresa (SIE) son paquetes estándar que cu-
bren, en principio, los procesos de trabajo más habituales de cualquier em-
presa en casi cualquier sector industrial. Actualmente, los SIE han evolucio-
nado desde los ERP tradicionales, para cubrir otras funciones como la comer-
cial (CRM), las compras y la relación con proveedores (SCM) y otros muchos
sistemas menores para la gestión del conocimiento (KM) o la inteligencia de
negocio (BI).
Los SIE han sido adoptados como su opción estratégica principal de tecnolo-
gías de la información por muchas empresas de todos los tamaños y sectores
y constituyen un extraordinario negocio, controlado por un número peque-
ño de grandes fabricantes (SAP, Oracle y Microsoft). También a su alrededor
ha florecido un negocio de implantadores, consultores e integradores de estas
soluciones.
Los SIE cubren los procedimientos o prácticas habituales de cada proceso de

negocio de la empresa por medio de un menú de opciones y plantillas que
el cliente (o un consultor externo) personaliza o adapta (parametriza) a su
manera de trabajar. Esta adaptación no es sencilla ni pacífica en todos los casos,
y más bien las empresas tienen que hacer un ejercicio de adaptación de su
organización y sus procesos (lo que se llama gestión del cambio).
En este módulo hemos examinado las características, ventajas e inconvenien-

tes de la adopción de sistemas de empresa y sus implicaciones. La adopción
de un SIE es una decisión estratégica que afecta al negocio y a la tecnología
para siempre y, por tanto, debe ser examinada muy en serio y decidida por la
dirección de la compañía. Por desgracia, muchas compañías no lo hacen así
y toman decisiones que comprometen su futuro para siempre, sin considerar
las implicaciones estratégicas, operativas, económicas y tecnológicas de la de-
cisión.
En segundo lugar, hemos presentado el ciclo de vida de la implantación de

sistemas de empresa, desde la fase de adopción (la decisión de comprar un ERP)
hasta la puesta en marcha del nuevo sistema. Hemos examinado los criterios
principales para la toma de decisiones y los aspectos clave de la implantación.
Hemos presentado una metodología abreviada para la implantación, basada

en la práctica profesional y en alguna literatura disponible, y la hemos inten-
tado alinear con las metodologías generales de gestión de proyectos TIC que
el estudiante está conociendo en otras asignaturas. En los últimos años, ha

aumentado el interés académico por el estudio de los sistemas de información
de empresa y por las experiencias de éxito y fracaso de su implantación.
Insistimos en que disponer de una estrategia clara de compra e implantación

del sistema de empresa (alineada con la estrategia de negocio y con la estrate-
gia tecnológica), contar con el soporte y liderazgo de la dirección y gestionar
adecuadamente el proceso de implantación y gestión del cambio son los fac-
tores clave del éxito de la implantación de un ERP y, en general, de cualquier
gran sistema de empresa. En esta elección, más que en otras, el trabajo cola-
borativo entre usuarios y técnicos es fundamental. También en esta elección,
la interacción con vendedores y proveedores externos (de producto y servicio)
es mayor y más compleja.
Bibliografía
Bibliografía básica
Alter, S. (2002). Information Systems. The Foundations of E-Business (4.ª ed., cap. 11). Upper
Saddle River, NJ: Pearson.
Austin, R.; Nolan, R.; Cotteler, M. (1998). Cisco Systems, Inc.: Implementing ERP (rev. maig
2002). Boston: Harvard Business School Publishing (case no. 9-699-022). [Se puede encontrar
una versión reducida en Applegate, L.; Austin, R.; Soule, D. (2009). Corporate Information
Strategy and Management: Text and Cases (8a. ed.). Nova York: McGraw Hill Higher Education,
International Edition.]
Davenport, T. (2000). Mission Critical. Realizing the Promise of Enterprise Systems. Boston:
Harvard Business School Press. (Se cita la versión española).
Esteves, J; Pastor J. A. (2004). "Proyectos SAP exitosos como base de ventajas competiti-
vas". Revista de Empresa. Madrid: Instituto de Empresa.
Gartner Research (2010). ERP Strategy: Why You Need One and Key Considerations for Defi-
ning One. [Documento en línea]. [Fecha de consulta: 22 de febrero del 2011].
<www.gartner.com>
Gómez Vieites, A.; Suárez Rey, C. (2005). Sistemas de Información: herramientas prácticas
para la gestión empresarial (5.ª ed.). Madrid: Ra-Ma Editorial.
Joana, J. M.ª; Gracia, R.; Bolart, J.; García, A. L. (2011). Gestión con éxito de grandes
proyectos de transformación, el caso del ICS. Barcelona: Editorial Profit.
Kotter, J. (1996). Leading change. Boston Mass., EE.UU.: Harvard Business School Press.
Marcos, S. y otros (2010). "Sistemes d'informació (a les organitzacions)". Escanejant la in-

formàtica. Barcelona: Editorial UOC.
O'Brien, J. A.; Marakas George, M. (2006). Management Information Systems (7.ª ed., cap.
7 y 8). Nueva York: McGraw-Hill Irwin.
Pastor J.A; Franch X.I.; Sistach F. "Methodological ERP acquisition. The SHERPA expe-
rience" (2002). En: J. de Bol (ed.). The Guide to IT Service Management. Londres (RU): Addi-
son-Wesley.
Pinto, J.; Millet, I. (1999). Successful information system implementation: the human side (2.ª
ed.). Pennsilvania: PMI.
Rodríguez, J. R.; Lamarca, I. (2011). Sistemas de información y procesos de Negocio. Dirección

Estratégica de Sistemas y Tecnologías de la Información. Barcelona: Eurecamedia.
Rodríguez, J. R.; Mariné, P. (2010). Gestión de proyectos (caps. 1, 2 y 8). Barcelona: Eure-
camedia.
Simó, M. y otros (2010). "Sistemes d'informació (a les organitzacions)". En: Escanejant la

informàtica. Barcelona: Editorial UOC.
Bibliografía complementaria
A Guide to the Project Management Body of Knowledge (PMBOK Guide) (2008, 4.ª ed.). Pennsil-
vania: Project Management Institute (PMI). (Hay edición en español).
Autores varios (2001). "Gestión del cambio". Harvard Business Review. Deusto.
Alvárez, J. L. (2009). Decisiones estratégicas. Ed: Lid (Barcelona).
Better Change (1995). "Best practices for transforming your organization". The Price Wa-
terhouse change integration team. Londres: Ed: Irwin.
Botella, P. y otros (2003). "Towards a Quality Model for the Selection of ERP Systems". En:
Cechich y otros (eds). Component based software quality. Berlin-Heidelberg: Springer Verlag.
Cruz-Cunha, M. M.; Varajo, J. (2011). Enterprise Information Systems Design, Implementation

and Management. Organizational Applications. Hershey, PA: Business Science Reference.
Cruz Cunha, M. M. (2010). Enterprise Information Systems for Business Integration in SMEs:
Technological, Organizational and Social Dimensions. Hershey, PA: Business Science Reference.
Esteves, J.; Pastor, J. A. (1999). "An ERP life-cycle-based research agenda". 1° Internatio-
nal Workshop on Enterprise Management Resource and Planning Systems. (pág. 359-371).
Venecia.
Hammer, M.; Champy, J. (1993). Reengineering the Corporation: a Manifesto for Business
Revolution. Nueva York: Harper Business.
Kaplan, R.; Norton, D. (2008). The Execution Premium. Deusto.
Kirchmer, M. (1999). Business Process Oriented Implementation of Standard Software (2.ª ed.,
cap. 1). Berlín-Heidelberg: Springer.
Muñiz, L. (2004). ERP, Guía práctica para la selección e implantación. Edición Gestión 2000.
O'Leary, D. E. (2000). Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Com-
merce, and Risk. Cambridge University Press.
Rashid, M. A.; Hossain, L.; Patrick, J. D. (2002). "The Evolution of ERP Systems: A
Historical Perspective". En: Enterprise Resource Planning: Global Opportunities. In Idea Group
Publishing.
Rodríguez, J. R.; Lamarca, I.; García Minguez, J. R. (2007). Gestión de proyectos: méto-
dos, herramientas y casos. Barcelona: Editorial UOC.
Snyder, C.; Parth, F. (2007). Introduction to IT Project Management. Vienna, Virginia: Mana-
gement Concepts.
Standord, N. (2007). Guide to Organization Design. Londres: The Economist.
Strategy. Harvard Business Essentials (2005). Harvar Business Press. Boston, EE. UU.
Thames, R. C.; Webster D. W. (2009). Chasing Change. Nueva York, USA: Ed. Wiley.
Tomás, J. V.; Expósito, M.; Capó, J. (2008). Los sistemas ERP en la práctica. Valencia: Edi-
torial de la UPV.
Introducción
a la business
intelligence
PID_00238512
Josep Curto Díaz

© FUOC • PID_00238512 Introducción a la business intelligence
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
© FUOC • PID_00238512 Introducción a la business intelligence
Índice
Introducción............................................................................................... 5
1. ¿Qué es la inteligencia de negocio?............................................... 7

1.1. Diferencias entre business intelligence, business analytics y big
data................................................................................................ 9
1.2. Beneficios de un sistema de business intelligence.......................... 11
1.3. ¿Cuándo es necesaria la inteligencia de negocio? ...................... 12
2. Estrategia de business intelligence................................................. 14

2.1. ¿Cómo detectar que no existe una estrategia? ........................... 14
3. Soluciones open source business intelligence............................... 18

3.1. Pentaho ........................................................................................ 19
Abreviaturas............................................................................................... 21
Bibliografía................................................................................................. 22
© FUOC • PID_00238512 5 Introducción a la business intelligence
Introducción
La gestión de una organización se fundamenta en tomar decisiones adecuadas

respecto a clientes, productos, empleados, proveedores y procesos de negocio.
Por lo tanto, es necesario tener mecanismos que den soporte a una toma de
decisiones eficiente.
En los últimos años, ha emergido una nueva forma de competir que se fun- CIO
damenta en tomar decisiones basadas en datos y evidencias dejando atrás la
Son las siglas de chief informa-
intuición. Esta forma de competir combina diferentes estrategias para generar tion officer, que equivalen a di-
valor de negocio: business intelligence (BI), business analytics y big data. No ex- rector de sistemas de una or-
ganización.
traño que los CIO de las principales empresas del mundo destaquen que su
principal prioridad tecnológica son este tipo de iniciativas.
Así, la explotación de la información en el contexto de las organizaciones ha

pasado de ser una necesidad a una prioridad de máxima relevancia. El objetivo
es poder tomar mejores y más rápidas decisiones informadas de negocio.
Aunque vivimos en la era de los datos complejos, conocida como big data,
y la progresiva automatización de nuestras capacidades predictivas, la inteli-
gencia de negocio sigue siendo relevante. Muchas organizaciones aún no han
desplegado este tipo de iniciativas y entre aquellas que lo han hecho no todas
han logrado alcanzar el éxito esperado. No en vano, este tipo de iniciativas
son complejas puesto que suponen una transformación de gran calado en la
organización. Por ello, en esta asignatura nos centraremos tan solo en la inte-
ligencia de negocio.
El mercado de business intelligence existe desde hace bastantes años; ha evolu-

cionado hacia soluciones con mayores prestaciones y podemos considerar que
ha alcanzado una significativa madurez. Destacamos, por ejemplo, que:
• Se ha producido una consolidación mediante la compra de empresas pe-

queñas por parte de los principales agentes del mercado (entre ellas SAP,
IBM, Microsoft u Oracle).
• Se ha enriquecido con soluciones open source que cubren el espectro de

necesidades de una organización para la explotación de la información.
• Han aparecido nuevas empresas con foco en la innovación cubriendo nue-

vos nichos en el mercado de la inteligencia de negocio, como la visuali-
zación, el análisis predictivo, las virtual appliances y/o el real-time business
intelligence (entre ellas Tableau, Qlikview o Yellowfin).
• Las principales soluciones BI open source, a saber Pentaho, JasperSoft y Ac-

tuate, han sido adquiridas por Hitachi Data Systems, Tibco y OpenText,
respectivamente.
• Hemos asistido a la aparición de una nueva generación de soluciones en-

focadas a la generación de valor de conjuntos de datos complejos, lo que
frecuentemente se refiere como big data, que expande el valor de la inte-
ligencia de negocio.
Esta asignatura se centrará en introducir los diferentes conceptos que engloba

la inteligencia de negocio. Se discutirán las diferencias entre business intelligen-
ce, business analytics y big data. Otro de los objetivos es ejemplificar el desarro-
llo de un proyecto de business intelligence mediante herramientas open source
para facilitar la comprensión de los conceptos presentados en la asignatura.
Algunas de las herramientas en el contexto de la inteligencia de negocio acu-

mulan varios años de desarrollo y evolución, y están respaldadas por organi-
zaciones que tienen un claro modelo de negocio y que generan sinergias entre
ellas en forma de ecosistemas. Podemos encontrar tanto herramientas de bases
de datos como de minería de datos. Tal es la madurez de dichas soluciones,
que es posible desarrollar e implementar proyectos de inteligencia de negocio
para todo tipo de organizaciones, tanto pymes como grandes organizaciones.
1. ¿Qué es la inteligencia de negocio?
El objetivo de este primer apartado es introducir la inteligencia de negocio y

enumerar las tecnologías que engloba.
El contexto de la sociedad de la información ha propiciado la necesidad de Lectura recomendada

tener mejores, más rápidos y más eficientes métodos para extraer y transformar
M.�Castells (1997-1998).
los datos de una organización en información y distribuirla a lo largo de la La era de la información: eco-
cadena de valor. nomía, sociedad y cultura (3
vols.). Madrid: Alianza Edito-
rial.
La cadena de valor
Descrita y popularizada por Michael E. Porter en su obra Competitive Advantage: Creating

and sustaining superior performance, la cadena de valor empresarial es un modelo teórico
que permite describir las actividades que generan valor en una organización.
La inteligencia de negocio (business intelligence; BI) responde a dicha necesidad

y podemos entender, en una primera aproximación, que es una evolución de
los sistemas de soporte a las decisiones (decission suport systems; DSS). Sin em-
bargo, este concepto, que actualmente se considera crítico en la gran mayoría
de las empresas, no es nuevo. En octubre de 1958, Hans Peter Luhn, investi-
gador de IBM, acuñó el término en el artículo A Business Intelligence System:
«La habilidad de aprehender las relaciones de hechos presentados de forma que guían
las acciones hacia una meta deseada».
No es hasta 1989 cuando Howard Dresden, en dicho momento analista de

Gartner, propone una definición formal del concepto:
«Conceptos y métodos para mejorar las decisiones de negocio mediante el uso de sistemas
Gartner
de soporte basados en hechos».
Es una de las principales em-

Desde entonces, el concepto del que estamos hablando ha evolucionado au- presas de prospección de mer-
cado.
nando diferentes tecnologías, metodologías y términos bajo su paraguas. Es,
por tanto, necesario establecer una definición formal de uso en el presente
material.
Se entiende por business�intelligence el conjunto de metodologías, apli-

caciones, prácticas y capacidades enfocadas a la creación y administra-
ción de información que permite tomar mejores decisiones a los usua-
rios de una organización.
En esencia, mediante la inteligencia de negocio, podemos romper con la si-

guiente máxima:
«Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que
no se mejora, se degrada siempre».
William Thomson
Algunas de las tecnologías que forman parte de la business intelligence son estas:
• Data warehouse.
• Reporting.
• Análisis OLAP (online analytical processing).
• Análisis visual.
• Análisis predictivo.
• Cuadro de mando.
• Cuadro de mando integral.
• Minería de datos.
• Gestión del rendimiento.
• Previsiones.
• Reglas de negocio.
• Dashboards.
• Integración de datos (que incluye extract, transform and load; ETL).
A lo largo de la asignatura entraremos en detalle en algunas de ellas para tener

claro los componentes mínimos que deben tener este tipo de sistemas.
El siguiente diagrama, creado por Forrester Research, ilustra las diferentes tec- Forrester Research
nologías y aspectos que forman parte de la inteligencia de negocio:
Se trata de una de las principa-
les empresas de prospección
de mercado.
Figura 1. Conceptos y tecnologías en business intelligence
Fuente: Forrester Research (2008).
1.1. Diferencias entre business intelligence, business analytics y

big data
Acabamos de definir lo que es la inteligencia de negocio. Para poder entender

las diferencias entre las tres estrategias de explotación a las que hemos hecho
referencia, necesitamos definirlas también.
Primero definamos qué es business analytics (BA) o analítica de negocio.
Se entiende por business�analytics el conjunto de estrategias, tecnolo-

gías y sistemas que permiten analizar el rendimiento pasado de una or-
ganización para poder predecir comportamientos futuros, así como pa-
ra detectar patrones ocultos en la información.
Ahora definamos que es big data.

Se entiende por big�data el conjunto de estrategias, tecnologías y siste-

mas para el almacenamiento, procesamiento, análisis y visualización de
conjuntos de datos complejos, que frecuentemente, pero no siempre,
viene definida por volumen, velocidad y variedad.
Vamos a comparar estas estrategias respecto a diferentes factores: herramien-

tas, foco, uso, tipo�del�dato, complejidad�del�dato y alcance. Además, in-
dicamos su nivel de madurez en el mercado. La siguiente tabla describe las
diferencias entre estas estrategias:
Tabla 1. Diferencias entre business intelligence, business analytics y big data
BI (madura) BA (madura) Big data

(emergente)
Herra- Consultas, alertas, reporting, Clasificación, Machine learning, visua-

mien- OLAP, etc. clustering, regresión lización, etc.
tas
Foco Qué y cómo pasó, cuántos, Por qué está pasando, qué Capturar, almacenar,
con qué frecuencia, cuál es pasaría si todo continua procesar, analizar
el problema, qué es necesa- igual, qué pasará a continua-
rio hacer ción, qué es lo mejor que
puede pasar
Uso Reactivo Proactivo Todos

Predictivo
Prescriptivo
Tipo�de Estructurados Estructurados Todo tipo

datos Semiestructurados
Com- Baja Baja/media Alta

pleji-
dad
del�da-
to
Alcance Dirección Procesos Vertical/procesos
Aunque queda claro que estas estrategias son diferentes, lo normal es que se
combinen en los proyectos de explotación del dato. La siguiente gráfica per-
mite identificar casos de uso respecto a la complejidad del dato y las capaci-
dades analíticas que desarrollar en la organización.
Figura 2. Combinación de estrategias
Fuente: Josep Curto.
La lectura de este gráfico se realiza a partir de sus ejes. Por ejemplo, cuando
necesitemos desarrollar capacidades analíticas descriptivas y la complejidad
de dato sea alta combinaremos big data con business intelligence formando un
único sistema.
1.2. Beneficios de un sistema de business intelligence
La implantación de estos sistemas de información proporciona diversos bene-

ficios, entre los que podemos destacar:
• Crear un círculo virtuoso de la información: los datos se transforman en

información que genera un conocimiento que permite tomar mejores de-
cisiones que se traducen en mejores resultados y que generan nuevos da-
tos.
• Proporcionar una visión única, conformada, histórica, persistente y de ca-

lidad de toda la información relevante para la organización.
• Crear, manejar y mantener métricas, indicadores claves de rendimiento

(key performance indicador; KPI) e indicadores claves de metas (key goal in-
dicator; KGI) fundamentales para la empresa.
• Habilitar el acceso a información actualizada tanto a nivel agregado como

en detalle.
• Reducir el diferencial de orientación de negocio entre el departamento TI

y la organización.
• Mejor comprensión y documentación de los sistemas de información en

el contexto de una organización.
• Mejor compresión de las opiniones y necesidades de los potenciales clien-

tes a partir del análisis de redes sociales.
• Mejora de la competitividad de la organización como resultado de ser ca-

paces de:
– Diferenciar lo relevante de lo superfluo.
– Acceder más rápido a información.
– Tener mayor agilidad en la toma de las decisiones.
1.3. ¿Cuándo es necesaria la inteligencia de negocio?
Existen situaciones en las que la implantación de un sistema de business inte-

lligence resulta adecuada. Destacamos, entre todas las que existen:
• La toma de decisiones se realiza de manera intuitiva en la organización. Excel caos
Se entiende por Excel caos el

• Identificación de problemas de calidad de información. problema resultante del uso in-
tensivo de Excel como herra-
mienta de análisis. Cada usua-
• Uso de Excel como repositorios de información corporativos o de usuario. rio trabaja con un fichero per-
sonalizado. Como resultado, la
Lo que se conoce como Excel caos. información no cuadra entre
departamentos y el coste de
sincronización es sumamente
• Necesidad de cruzar información de manera ágil entre departamentos. elevado.
• Evitar silos de información.
• Las campañas de marketing no son efectivas por la información base usa-

da.
• Existe demasiada información en la organización para ser analizada de la

manera habitual. Se ha alcanzado la masa crítica de datos.
• Es necesario automatizar los procesos de extracción y distribución de in-

formación.
En definitiva, los sistemas de business intelligence buscan responder a las pre-

guntas:
• ¿Qué pasó?
• ¿Qué pasa ahora?
• ¿Por qué pasó?
• ¿Qué pasará?
Tal y como explica Thomas Davenport en su libro Competing on Analytics

(2007), una nueva forma de estrategia competitiva está emergiendo basada en
el uso de la estadística descriptiva, modelos productivos y complejas técnicas
de optimización, datos de alta calidad y una toma de decisiones basada en
hechos. En dicho contexto, la inteligencia de negocio es el paso previo para
dicha estrategia dado que ayuda a sentar las bases para su futuro despliegue.
2. Estrategia de business intelligence
Desplegar un proyecto de inteligencia de negocio en el seno de una organiza-

ción no es un proceso sencillo. Las buenas prácticas indican que, para llegar a
buen puerto, es necesario tener una estrategia de inteligencia de negocio que
coordine las tecnologías, el uso, los procesos de madurez, la metodología que
emplear, etc.
2.1. ¿Cómo detectar que no existe una estrategia?
Es posible detectar que no existe una estrategia definida a través de los siguien-
tes puntos y percepciones en el seno de una organización:
• Los usuarios identifican el departamento de informática (information tech-

nology; IT) como el origen de sus problemas de inteligencia de negocio.
• La dirección considera que la inteligencia de negocio es otro centro de

coste.
• El departamento de IT continúa preguntando a los usuarios finales sobre

las necesidades de los informes.
• El sistema de BI está soportado por help desk.
• No hay diferencia entre BI y gestión del rendimiento.
• No es posible medir el uso del sistema de inteligencia de negocio.
• No es posible medir el retorno de la inversión (return on invest; ROI) del

proyecto de business intelligence.
• Se considera que la estrategia para el data warehouse es la misma que para

que el sistema de inteligencia de negocio.
• No hay un plan para desarrollar, contratar, retener y crecer el equipo de BI.
• No se sabe si la empresa tiene una estrategia para el BI.
• No existe un responsable funcional (o bien el asignado no es el adecuado).
• No existe un centro de competencia.

• Existen múltiples soluciones en la organización distribuidas en diferentes

departamentos que repiten funcionalidad.
• No hay un plan de formación real y consistente de uso de las herramientas.
• Alguien cree que es un éxito que la información consolidada esté a dispo-

sición de los usuarios finales al cabo de dos semanas.
• Los usuarios creen que la información del data warehouse no es correcta.
• No existe una cultura analítica en la que el dato y los hechos son relevantes
para tomar decisiones sea cual sea el nivel de la organización.
El desarrollo de una estrategia de negocio es un proceso a largo plazo que

incluye múltiples actividades, entre las que es conveniente destacar:
• Crear un centro de competencia (o de excelencia) de BI (BICC). Tiene el

objetivo de aunar conocimiento en tecnologías, metodologías, estrategia,
con la presencia de un patrocinador a nivel ejecutivo y con analistas de
negocio implicados y que tenga responsabilidad compartida en éxitos y
fracasos.
• Establecer los estándares de BI en la organización para racionalizar tanto

las tecnologías existentes como las futuras adquisiciones.
• Identificar qué procesos de negocio necesitan diferentes aplicaciones ana-

líticas que trabajen de manera continua para asegurar que no existen silos
de funcionalidad.
• Desarrollar un framework de métricas a nivel empresarial como el pilar de

una gestión del rendimiento a nivel corporativo.
• Incluir los resultados de aplicaciones analíticas (minería de datos u otras)

en los procesos de negocio con el objetivo de añadir valor a todo tipo de
decisiones.
• Revisar y evaluar el portafolio actual de soluciones en un contexto de ries-

go / recompensas.
• Considerar inversiones tácticas cuyo retorno de inversión estén dentro de

un periodo de tiempo de un año; además tener en cuenta los diferentes
análisis de mercado, de soluciones e incluso el hype cycle de Gartner para
conocer el estado del arte.
• Aprender de los éxitos y fracasos de otras empresas revisando casos de es-

tudio y consultado a las empresas del sector para determinar qué ha fun-
cionado y qué no.
• Evangelizar la organización.
• Alinear el departamento IT y el negocio en caso de no poder organizar un

BICC, fundamental para trabajar como equipo integrado. El departamento
de IT debe entender las necesidades y entregar la mejor solución ajustada
a la necesidad particular y escalable a otras futuras.
• Poner atención a las necesidades que requieren BI en la organización por-

que se suele satisfacer a los usuarios o departamentos que gritan más fuer-
te, y esto no significa que den mayor valor a la compañía. Por ejemplo,
los departamentos de finanzas son un caso típico de baja atención en so-
luciones BI.
El hype cycle de Gartner
Es una representación gráfica de la madurez, adopción y aplicación de negocio de una

o varias tecnologías específicas. Es decir, muestra el ciclo de vida de dichas tecnologías.
Las etapas que componen el ciclo son las siguientes:
• Disparador tecnológico: cuando aparece el concepto en el mercado.
• Pico de expectativa inflada: cuando se habla mucho del concepto, pero está poco
aplicado.
• Valle de la desilusión: cuando la herramienta está por debajo de lo que se esperaba

de ella.
• La pendiente de tolerancia: el camino hacia la madurez.
• Plateau de productividad: cuando alcanza la madurez.
Business�intelligence�maturity�model
Si bien el objetivo de esta asignatura no es dar pautas para definir una estrategia
de business intelligence, sino una introducción de conceptos, un buen punto
de partida es identificar cuál es el grado de madurez de la organización con
respecto a la inteligencia de negocio.
El BIMM (business intelligence maturity model) es un modelo de madurez que COBIT

permite clasificar nuestra organización desde el punto de vista del grado de
Control objectives for informa-
madurez de implantación de sistemas business intelligence en ella (en relación tion and related technology
directa con frameworks como COBIT). (COBIT) es un conjunto de
mejores prácticas para el ma-
nejo de información creado
por la Information Systems Au-
1)�Fase�1:�No�existe�BI. Los datos se hallan en los sistemas de procesamiento dit and Control Association
(ISACA) y el IT Governance Ins-
de transacciones en línea (online transaction processing; OLTP), desperdigados titute (ITGI) en 1992.
en otros soportes o incluso solo contenidos en el know how de la organización.
Las decisiones se basan en la intuición, la experiencia, pero no en datos con-

sistentes. El uso de datos corporativos en la toma de decisiones no ha sido
detectado y tampoco el uso de una herramienta adecuada al respecto.
2)�Fase�2:�No�existe�BI,�pero�los�datos�son�accesibles. No existe un procesado

formal de los datos para la toma de decisiones, aunque algunos usuarios tie-
nen acceso a información de calidad y son capaces de justificar decisiones con
dicha información. Frecuentemente, este proceso se realiza mediante Excel o
algún tipo de reporting. Se intuye que deben existir soluciones para mejorar
este proceso pero se desconoce la existencia del business intelligence.
3)�Fase�3:�Aparición�de�procesos�formales�de�toma�de�decisiones�basada�en Data cleansing

datos. Se establece un equipo que controla los datos y que permite hacer in-
Consiste en el proceso de de-
formes contra estos, que permiten tomar decisiones fundamentadas. Los datos tectar y mejorar (o borrar) re-
son extraídos directamente de los sistemas transaccionales sin data cleansing, gistros incorrectos e incomple-
tos con el objetivo de conse-
ni modelización ni existe un data warehouse. guir datos coherentes y consis-
tentes.
4)�Fase�4:�Data�warehouse. El impacto negativo contra los sistemas OLTP lle-

va a la conclusión de que un repositorio de datos es necesario para la organi-
zación. Se percibe el data warehouse como una solución deseada. El reporting
sigue siendo personal.
5)�Fase�5:�El�data�warehouse�crece�y�el�reporting�se�formaliza. El data wa-

rehouse funciona y se desea que todos se beneficien de él, de modo que el re-
porting corporativo se formaliza. Se habla de OLAP, pero solo algunos identifi-
can realmente sus beneficios.
6)�Fase�6:�Despliegue�de�OLAP. Después de cierto tiempo, ni el reporting ni la

forma de acceso al data warehouse es satisfactoria para responder a preguntas
sofisticadas. OLAP se despliega para dichos perfiles. Las decisiones empiezan
a impactar de manera significativa en los procesos de negocio a lo largo de
la organización.
7)�Fase�7:�El�business�intelligence�se�formaliza. Aparece la necesidad de im-

plantar otros procesos de inteligencia de negocio, como data mining, balanced
scorecard, etc., y procesos de calidad de datos impactan en procesos como cus-
tomer relationship management (CRM), supply chain management (SCM), etc. Se
ha establecido una cultura corporativa que entiende claramente entre sistemas
OLTP y DSS.
Existen otros modelos de madurez, como el modelo Delta analítico de Thomas Lectura complementaria
Davenport o el de TDWI.
T.�H.�Davenport;�J.�G.�Ha-
rris;�R.�Morison (2010).
TDWI Analytics at Work: Smarter De-
cisions, Better Results. Nueva
Es el acrónimo de The Data Warehouse Institute, organización que se dedica a la inves- York: Harvard Business Press.
tigación del business intelligence. En este enlace es posible autoevaluarse contra el modelo
de madurez.
3. Soluciones open source business intelligence
El open source es una filosofía de desarrollo de software que cumple los siguien-
tes principios:
a)� Abierto: la comunidad tiene libre acceso, uso y participación del código
fuente, así como la posibilidad de uso de foros para proporcionar feedback.
b)�Transparencia: la comunidad tiene acceso al roadmap, documentación, de-

fectos y agenda de las milestones.
c)�Early�&�often: la información se publica de manera frecuente y pronto a

través de repositorios públicos (incluyendo el código fuente).
El open source ya no es una tendencia emergente, sino que es un enfoque que

tiene un impacto profundo y una presencia importante en todos los sectores,
tal y como comentaban los analistas de Gartner (Plummer y otros, 2008):
«2012, el 80 % del SW comercial incluirá algún componente open source. Incluir compo-
nentes open source en los productos para abaratar costes es considerado la mínima estra-
tegia que las compañías pueden llevar a cabo para mantener su ventaja competitiva en
5 años».
En los últimos años, el mercado business intelligence se ha enriquecido con so-

luciones open source que cubren todo el espectro de necesidades de una orga-
nización para la explotación de la información. Algunas de estas herramien-
tas tienen ya a sus espaldas varios años de recorrido y actualmente se encuen-
tran respaldadas por organizaciones que tienen un claro modelo de negocio
orientado a los servicios de valor añadido. Es posible encontrar herramientas
solventes y maduras desde el nivel de base de datos hasta el de procesos de
minería de datos que pueden, en algunos casos, adaptarse a las necesidades
de una organización.
De hecho, el advenimiento de las tecnologías de big data, cuyo núcleo está

fundamentado en tecnologías con licencia libre, ha reforzado la idea de que
el movimiento open source es una fuerza de mercado a tener en cuenta para
la generación de ventajas competitivas y, sobre todo, en la explotación de los
datos.
En el mercado de soluciones open source business intelligence (OSBI) existen múl- SpagoBI
tiples soluciones. Las principales son: Pentaho, Tibco Jaspersoft, Birt, que for-
Cabe comentar que SpagoBI
ma parte de OpenText Analytics, y SpagoBI. Entre ellas destaca la solución de es actualmente la única solu-
ción en el mercado BI pura-
mente open source.
Pentaho, que es la que usaremos en esta asignatura porque contiene todas las
componentes mínimas de un sistema de business intelligence y es posible expli-
carlas y usarlas de manera unitaria e independiente.
3.1. Pentaho
Nacida en el año 2006, Pentaho es una de las suites más conocidas del mer-
cado OSBI. Existen dos versiones: community y enterprise. Serán comentadas
a lo largo de los diferentes módulos. Está compuesta por diferentes motores
incluidos en el servidor de Pentaho:
• Reporting: soporta informes estáticos, paramétricos y ad hoc.
• Análisis: soporta OLAP (mediante Mondrian) y minería de datos (median-

te Weka).
• Cuadros� de� mando: mediante CDF (community dashboard framework) y

dashboard designer (Enterprise).
• ETL: mediante la herramienta Pentaho Data Integation (anteriormente

llamada Kettle). Incluye un servidor.
• Metadata: que proporciona una capa de acceso de información basada en

lenguaje de negocio.
El siguiente esquema representa la arquitectura de Pentaho:
Figura 3. Arquitectura de Pentaho
Fuente: Pentaho.
Actualmente, Pentaho está siguiendo la estrategia open core, que consiste en,
a partir de un núcleo open source, ofrecer servicios y módulos mejorados, lo
que frecuentemente también se conoce como commercial open source. Esta es
la razón de encontrarnos dos versiones. La principal diferencia entre ambas es
que la versión enterprise está bajo una modalidad de suscripción (que incluye
funcionalidad extendida) y la versión community es completamente gratuita.
A lo largo de la asignatura la gran mayoría de las veces se hará referencia a la
versión community.
Las principales páginas de referencia de Pentaho son estas:
• Página web de la compañía: http://www.pentaho.com/.

• Página de la comunidad: http://community.pentaho.com/.
• Documentación: https://help.pentaho.com/Documentation.
• Wiki comunidad: http://wiki.pentaho.com/display/COM/Commu-
nity+Wiki+Home.
• Jira Pentaho: http://jira.pentaho.com/.
• Sourceforge Pentaho: http://sourceforge.net/projects/pentaho.
• Sourceforge Mondrian: http://sourceforge.net/projects/mondrian.
• Github Pentaho: https://github.com/pentaho.
Abreviaturas
BI Business intelligence.
BICC Business intelligence competency center.
BIMM Business intelligence maturity model.
COBIT Control objectives for information and related technology.
CRM Customer relationship management.
DSS Decision support systems.
EII Enterprise information integration.
ETL Extract, transform and load.
IBM International business machines.
KGI Key goal indicator.
KPI Key performance indicator.
ODS Operational data store.
OLAP Online analytical processing.
OLTP Online transaction processing.
OSBI Open source business intelligence.
SI Sistemas de información.
SQL Structured query language.
TI Tecnologías de la información.
Bibliografía
Castells, M. (1997-1998). La era de la información: economía, sociedad y cultura (3 vols.). Ma-
drid: Alianza Editorial.
Davenport, T. H.; Harris, J. G. (2007). Competing on Analytics: The New Science of Winning.
Nueva York: Harvard Business Press.
Davenport, T. H.; Harris, J. G.; Morison, R. (2010). Analytics at Work: Smarter Decisions,
Better Results. Nueva York: Harvard Business Press.
Miller, D. (2007). Measuring Business Intelligence Success: A Capability Maturity Model. Nueva
York: D. M. Morrisey.
Miller, G. J.; Brautigam, D. V.; Gerlach, S. (2006). Business Intelligence Competency Cen-
ters: A Team Approach to Maximizing Competitive Advantage. Hoboken: Wiley and SAS Business
Series.
Plummer; D. C.; Smulders, Ch.; Fiering, L.; Natis, Y. V.; Mingay, S.; Driver, M.;
Fenn, J.; McLellan, L.; Wilson, D. R. (2008, 8 de enero). «Gartner’s Top Predictions for
IT Organizations and Users, 2008 and Beyond: Going Green and Self-Healing». Gartner.
Porter, M. E. (1985). The Competitive Advantage: Creating and Sustaining Superior Performance.
Nueva York: Free Press.
Sistema de
información
empresarial
Isabel Guitart Hormigo
PID_00174745
CC-BY-NC-ND • PID_00174745 Sistema de información empresarial
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 7
1. Concepto de sistema de información de empresa..................... 9

1.1. Introducción ................................................................................ 9
1.2. Definición del sistema ERP ......................................................... 11
1.3. Características del sistema ERP ................................................... 12
1.4. Beneficios del sistema ERP .......................................................... 13
1.5. Riesgos del sistema ERP .............................................................. 14
2. Evolución histórica del sistema ERP............................................ 16

2.1. Evolución histórica: del MRP al ERP II ....................................... 16
2.1.1. MRP (planificador de necesidades de materiales) .......... 16
2.1.2. MRP-II (planificador de recursos de fabricación) ........... 16
2.1.3. ERP (planificador de recursos empresariales) ................. 17
2.1.4. ERP-II (planificador de recursos empresariales - II) ........ 17
2.2. El sistema ERP actual .................................................................. 19
2.3. Tendencias de futuro del sistema ERP ........................................ 21
3. Arquitectura del sistema ERP........................................................ 23

3.1. Perspectiva funcional .................................................................. 23
3.2. Perspectiva tecnológica ............................................................... 25
4. Módulos funcionales......................................................................... 27
4.1. La evolución de la empresa y las TIC ......................................... 27
4.2. Las áreas funcionales de la organización .................................... 29
4.3. Los módulos funcionales del sistema ERP .................................. 29
4.3.1. Finanzas ......................................................................... 30
4.3.2. Producción ..................................................................... 31
4.3.3. Compras ......................................................................... 31
4.3.4. Recursos humanos ......................................................... 32
4.3.5. Ventas y distribución ..................................................... 32
4.3.6. Marketing ....................................................................... 33
4.3.7. Gestión de materiales .................................................... 33
4.3.8. Mantenimiento de planta ............................................. 33
4.3.9. Gestión de calidad ......................................................... 34
4.4. Módulo sectorial o soluciones verticales .................................... 34
5. Ciclo de vida del sistema ERP........................................................ 36

5.1. Fases del ciclo de vida ................................................................ 36
5.2. Fase: adopción del sistema ERP .................................................. 36

5.3. Fase: selección del sistema ERP ................................................... 38
5.4. Fase: implantación del sistema ERP ............................................ 39
5.5. Fase: puesta en marcha del sistema ERP ..................................... 41
6. Proveedores de sistemas ERP.......................................................... 42

6.1. Modalidades de sistemas ERP ..................................................... 42
6.1.1. ERP propietario .............................................................. 42
6.1.2. ERP software libre .......................................................... 42
6.2. Los principales proveedores de ERP propietario ......................... 43
6.2.1. SAP ................................................................................. 44
6.2.2. Oracle ............................................................................. 45
6.2.3. Microsoft ........................................................................ 45
6.3. Los principales proveedores de ERP de software libre ................ 46
6.3.1. Openbravo ..................................................................... 46
6.3.2. Adempiere ...................................................................... 46
6.3.3. OpenERP ........................................................................ 47
6.4. Las soluciones SAP ...................................................................... 47
6.4.1. SAP Business Suite ......................................................... 47
6.4.2. SAP Business One .......................................................... 49
6.4.3. SAP Business All-in-One ................................................ 50
6.5. Las soluciones OpenBravo .......................................................... 51
6.5.1. Openbravo 3 .................................................................. 51
6.5.2. Openbravo POS ............................................................. 53
Resumen....................................................................................................... 55
Actividades.................................................................................................. 57
Glosario........................................................................................................ 58
Bibliografía................................................................................................. 59
CC-BY-NC-ND • PID_00174745 5 Sistema de información empresarial
Introducción
Los sistemas de información de empresa también son conocidos por ERP (en-
terprise resource planning), sistemas integrados de gestión, software empaque-
tado de gestión, sistemas de información empresarial, sistemas empresariales
o software empaquetado; tuvieron su momento álgido a finales de los años
noventa, ayudados por la conversión de la moneda al euro y el efecto 2000,
momento en que un gran número de empresas decidieron implantar software
empaquetado ante otras alternativas, como el desarrollo a medida.
La organización, selección e implantación de un sistema de información de

empresa conlleva unos costes y una complejidad más elevada que la selección
e implantación de cualquier otro software. El proyecto de implantación de un
sistema de información de empresa supone un cambio interno de funciona-
miento en los procesos de la organización o la reingeniería de procesos.
Las implantaciones realizadas con éxito aportan beneficios para las organiza-
ciones. Los principales son el aumento de la ventaja competitiva y el alinea-
miento de la estrategia de negocio con las TIC.
Durante el boom de las implantaciones de los ERP, muchas de ellas fueron un

fracaso. La urgencia del momento por el acercamiento de las fechas clave hizo
que muchas organizaciones erraran tanto en su decisión de adoptar un ERP
como en la selección del paquete más adecuado. Este hecho hizo creer que
el número de empresas que decidían implantar ERP dejaría de crecer, aunque
no ha sido así.
Actualmente, en el mundo las organizaciones continúan destinando una parte

considerable de su presupuesto informático a finalizar las implantaciones de
ERP o a ampliar el sistema existente. Uno de los motivos de este continuo
crecimiento tiene que ver con la evolución del software empaquetado, que
se ha adaptado a las necesidades de la empresa integrando nuevos módulos,
como el customer relationship management (CRM), el supply chain management
(SCM) o el business intelligence (BI).
La complejidad del proceso de selección e implantación de un ERP recomien-

da que los clientes externalicen este servicio en empresas consultoras especia-
lizadas. Este continuo crecimiento en la demanda de software empaquetado,
por parte de las organizaciones, ha supuesto un aumento de la oferta de con-
sultores especializados en la implantación de estos servicios.
El módulo "Sistema de información empresarial" está estructurado en seis apar-

tados. En los tres primeros apartados, presentamos el concepto de sistema de
información empresarial: qué es, cómo surgió y cómo funciona. En el cuarto
apartado, tratamos los procesos de negocio de las empresas y lo relacionamos

con la estructura funcional para módulos de los sistemas de información em-
presarial, haciendo énfasis en la compartimentación de información de las di-
ferentes áreas funcionales. En el quinto apartado, describimos las diferentes
etapas por las que tiene que pasar una empresa al mismo tiempo de implan-
tar un sistema de información empresarial: el ciclo de vida. Finalmente, en
el último apartado mostramos los principales vendedores de los sistemas de
información empresarial.
Objetivos
Los principales objetivos que el estudiante podrá alcanzar con este módulo
didáctico son:
1. Conocer el significado del concepto sistema de información de empresa.
2. Entender qué es, cómo surgió y cómo funciona un sistema de información

de empresa.
3. Entender la relevancia de los sistemas ERP dentro de las empresas.
4. Conocer los beneficios y los riesgos de la implantación de un sistema de

información empresarial.
5. Conocer las áreas principales funcionales operativas de una organización

y los módulos principales funcionales de los sistemas de información em-
presarial.
6. Conocer e identificar las etapas por las que pasa una empresa con la im-
plantación de un sistema de información empresarial.
7. Conocer los principales vendedores de sistemas de información empresa-

rial.
1. Concepto de sistema de información de empresa
1.1. Introducción
(1)
Definimos, en sentido amplio, un sistema�de�información como un conjunto Procesos de trabajo, activos téc-
1 nicos de hardware, software y co-
de elementos interrelacionados que permiten transformar los datos en infor- municaciones, las personas...
mación y conocimiento, poniendo todo ello a disposición de los empleados y
directivos de la organización para actuar en consecuencia.
En este módulo y esta asignatura utilizaremos una definición más restringida:
Los sistemas�de�información�de�empresa son programas de aplicación

(aplicaciones) que permiten registrar operaciones, dar apoyo a los pro-
cesos de trabajo, ayudar a la toma de decisiones y obtener ventaja de
eficiencia o competitividad para una organización.
Ejemplos
Los programas que soportan los ingresos y reintegros de los cajeros automáticos, el siste-
ma de gestión automatizada de pedidos de un restaurante, la reposición automática de
existencias de un almacén, la nómina y la contabilidad, el sistema de admisiones, altas
y localización de pacientes en un hospital, el sistema de información comercial y ventas
en una tienda de Internet o la gestión de bicicletas de alquiler de una ciudad... Todos
ellos son sistemas de información de empresa.
Muchos de estos sistemas son comunes para cualquier empresa o sector eco-
nómico y, actualmente, se ofrecen ya acabados y disponibles en el mercado
en forma de "paquetes". Son los llamados sistemas o paquetes�estándar.
Estos "paquetes" pueden adaptarse con un menú de opciones o, si hace falta,

cambiarse con un desarrollo específico.
Ejemplos
Es el caso de los sistemas de presupuestos, contabilidad y finanzas, nómina o la gestión

de almacenes. Otros paquetes pueden ser comunes a todo un sector industrial, como
la gestión de pacientes en un hospital o los sistemas de facturación de las compañías
eléctricas o de telecomunicaciones.
Thomas Davenport acuñó el término de sistemas de misión crítica para referir-

se a los sistemas�de�empresa. Quería decir que son aquellos sistemas que las
empresas y organizaciones necesitan para cumplir su misión; su razón de ser,
aquello a lo que se dedican como negocio, ya sea fabricar zapatos o hacer vo-
lar aviones. Estos procesos de cada empresa son muy estables y normalmente
independientes de la coyuntura económica o de las prioridades estratégicas de
las compañías.
La existencia de una demanda creciente y solvente por parte de las empresas,

las nuevas técnicas de ingeniería del software y la aparición de modelos de
empresa que hacen del diseño, venta e implantación de software estándar un
modelo de negocio rentable y recurrente ha dado lugar, desde los años no-
venta del siglo pasado, a la aparición de soluciones�paquetizadas, así como
de empresas de servicios especializadas en su comercialización, instalación y
adaptación.
En sus inicios, estos sistemas cubrían de forma especializada un área o grupo

de procesos de la empresa, como la función comercial, el proceso económico-
financiero, la planificación y gestión de la producción... Más recientemente,
sistemas que nacieron para cubrir una función o departamento de la empresa
(por ejemplo, el departamento económico-financiero) se han ido combinando
y completando para cubrir todas, o casi todas, las áreas de la empresa. Se habla
entonces de sistemas�integrados.
(2)
El boom de los sistemas integrados se produjo con la adaptación de los siste- Es decir, otra manera más efi-
ciente y barata de hacer las cosas
mas tradicionales en el año 2000. Algo aparentemente tan simple y común
que permitía reducir personal de
como un cambio de dígito en el calendario disparó un negocio multimillona- los departamentos de negocio y
también de informática.
rio. Miles de empresas de todo el mundo y todos los tamaños adoptaron los
sistemas integrados, que prometían, además de una reducción de los costes
de mantenimiento, la compartimentación de datos y procesos entre departa-
mentos, la homogeneización y optimización de los procesos de trabajo dentro
de la empresa o entre sus diferentes filiales, y también la reingeniería2.
La explosión de las comunicaciones entre empresas y, particularmente, de In-

ternet, ha permitido que los sistemas de empresa den apoyo a los procesos in-
ternos de la empresa y además mejoren las relaciones con sus clientes, provee-
dores y socios, como en los sistemas�de�comercio�electrónico�o�los�sistemas
de�gestión�de�producción�y�pedidos�"justo�a�tiempo" (just in time).
Asimismo, el mundo de los sistemas de empresa ha llegado a funciones nuevas

o muy especializadas, como los sistemas de apoyo a la toma de decisiones, las
intranets corporativas y los sistemas de gestión del conocimiento.
Finalmente, en los últimos años, los grandes fabricantes de sistemas de infor-

mación de empresa y otros menores han desarrollado versiones "simplificadas"
dirigidas a los mercados de pequeña y mediana empresa.
1.2. Definición del sistema ERP
Hemos visto que los sistemas de información de empresa son conocidos por
varios nombres, el más destacado de ellos ERP, siglas que provienen de enter-
prise resource planning. Los nombres en inglés más referenciados son: enterprise
information sytems (EIS), enterprise wide systems (EWS) y enterprise systems (SE).
Hasta ahora, hemos puesto en contexto el nacimiento de los sistemas ERP y las
circunstancias que rodean su evolución y que nos hacen entender su expan-
sión, así como el vínculo existente con otros sistemas de empresa y cómo los
ERP se han visto obligados a ampliarse, a redefinirse, para apoyar las nuevas
demandas del mercado. En este punto iremos paso a paso; primero empeza-
remos por conocer qué es un sistema ERP y cuáles son las principales caracte-
rísticas que lo diferencian de otros sistemas de información y cuáles son los
beneficios que aportan a la organización, pero también los riesgos de las im-
plantaciones de un ERP.
En la definición del sistema ERP analizaremos la traducción de las siglas ERP:

planificación de recursos empresariales.
Los "recursos empresariales" nos hablan de un conjunto de aplicaciones aso-

ciadas a los aspectos operativos o productivos de una empresa. La "planifica-
ción" es una trazabilidad de acciones organizadas para llegar a alcanzar un ob-
jetivo, de una forma metódica y, frecuentemente, con una gran amplitud.
Podríamos decir que el� sistema� ERP, o la� planificación� de� recursos
empresariales, es un conjunto de aplicaciones relacionadas con los pro-
cesos de negocio de una empresa, que permite lograr los objetivos es-
tratégicos definidos por los directivos de una organización.
Para conocer el concepto de sistema ERP, os mostramos una serie de definicio-

nes formales de diferentes autores:
"Un sistema ERP es un paquete de software comercial que promete la integración de toda
la información que fluye a través de la empresa: financiera y contable, recursos humanos,
cadena de suministro y cliente".
Davenport (2000)
"Es un método para una planificación efectiva y un control de todos los recursos nece-
sarios para producir, enviar y contabilizar los pedidos realizados por los clientes en una
empresa de producción, distribución o servicios".
M. A. Rashid (2002)
"Los sistemas ERP son sistemas de información que integran los procesos clave del nego-
cio de forma que la información fluya libremente entre las diferentes partes de la empre-
sa, mejorando la coordinación, la eficacia y el proceso de tomar decisiones".
Laudon y Laudon (2004)

"Un ERP es un sistema de información que permite a la organización gestionar sus recur-
sos de forma eficiente y eficaz. Ofreciendo una solución total e integrada, que cubre las
necesidades de procesamiento de la información que fluye a lo largo de la organización.
Soportando una visión orientada a los procesos de las organizaciones".
Nah (2001)
Destacamos la definición del autor Nah (2001) para resaltar el concepto de Nota
orientación�a�procesos, por la importancia del sistema ERP como una herra-
Las definiciones nos han apor-
mienta para la transformación de los procesos de negocio y no como una he- tado los temas principales que
rramienta de gestión pasiva. se irán abordando a lo largo
de este módulo.
Finalmente, vamos a describir el sistema ERP mediante sus rasgos más desta-
cados:
• Tiene una gran capacidad de adaptación, de modularidad, de integración

de la información con otros tipos de programas.
• Está diseñado para cubrir todas las exigencias de las áreas funcionales de
la empresa, creando un flujo de trabajo (workflow) que permite agilizar los
diferentes tipos de trabajo.
• Reduce las tareas repetitivas y facilita la comunicación entre todas las áreas
que integran la empresa (incluso los socios de la cadena de suministro fue-
ra de la organización), con la seguridad de disponer de unos datos correc-
tos.
• Permite personalizar el sistema ERP según las necesidades específicas de

cada empresa, hasta ciertos límites.
1.3. Características del sistema ERP
Los sistemas ERP tienen características que los diferencian de otros sistemas
de información.
Los sistemas ERP disponen de tres rasgos básicos, que son: la modulari-
dad, la integración y la adaptabilidad.
1)�Modularidad
Una de las ventajas, tanto económica como técnica, es que el sistema se divide
en diferentes módulos agrupados por funcionalidades. Cada módulo es una
unidad que realiza una tarea concreta y es capaz de comunicarse con el resto
de módulos u otros sistemas de información. Los módulos de un sistema ERP
pueden funcionar como unidades independientes, o varios módulos se pue-
den combinar entre sí para formar un sistema integrado. La empresa no tiene

que instalar todos los módulos del sistema ERP, solo aquellos que necesite en
función de sus procesos de negocio.
2)�Integración
El sistema está acoplado y unido como un solo sistema, es decir, los diferentes
departamentos se comunican entre ellos de manera que el resultado de un
proceso pasa a ser el inicio de otro. Esta característica nos indica que los datos
se introducen una sola vez en el sistema. La información es compartida y está
disponible a tiempo real para todos los departamentos de la organización. Se
evita la duplicidad de las transacciones y la redundancia de la información.
3)�Adaptabilidad Ejemplo
El sistema ERP, a pesar de ser un software con un diseño estándar, puede con-
Podemos adaptar un módulo
figurarse para adaptarse al entorno, es decir, tiene capacidad para modelarse a las diferentes legislaciones y
en la estructura organizativa, su ciclo vital, en las políticas empresariales y los prácticas específicas de cada
país. Eso permite usar el siste-
requerimientos funcionales de cada empresa, hasta ciertos límites. La adapta- ma ERP en las diferentes dele-
gaciones que tenga la empresa
bilidad se consigue mediante la parametrización de los diferentes módulos en en el mundo.
función de las necesidades de la empresa.
Figura 1. Estructura del sistema ERP Otras características del

sistema ERP
• Los datos son consistentes,

completos y comunes.
• La base de datos es centra-
lizada.
• El procesamiento de todas
las transacciones se produ-
ce dentro de la empresa.
• Eliminación de datos y ope-
raciones innecesarias.
• Apoyar las funciones bási-
cas del negocio.
1.4. Beneficios del sistema ERP
Algunos de los beneficios destacados en la implantación de un sistema ERP

son los siguientes:
(3)
1)�Control�sobre�la�actividad�de�los�diferentes�departamentos�de�la�em- De un área funcional, de un de-
partamento o de una actividad.
presa
La integración de la información de los diferentes departamentos permite te- (4)
Revisar las políticas de reducción
ner una visión global del funcionamiento de la organización. Eso permite un de costes por las áreas funcionales
y su impacto en el coste total.
análisis local y específico3 y un análisis global de la organización4.
2)�Mejora�los�diferentes�procesos�de�la�empresa
La adopción de procesos estándares del sistema ERP (best-practice) supone una

optimización en cuanto a los procesos de negocio, un ahorro de tiempo y
costes y una mejora de la productividad.
3)�Reducción�de�inventario
La mejora en la gestión de la cadena de producción y en la automatización de
los procesos productivos comporta una reducción del inventario, una planifi-
cación más eficiente en la entrega al cliente y, además, evita una acumulación
de productos en el almacén.
4)�Establecer�las�bases�para�el�comercio�electrónico
Permite un crecimiento más rápido de la organización, al facilitar la amplia-
ción de las funcionalidades del sistema ERP incorporando las transacciones de
negocio hacia el comercio electrónico.
5)�Explicitar�el�conocimiento
La elaboración de la documentación de los procesos de negocio y los procesos
de trabajo explicita el conocimiento implícito de los empleados. Se indican los
procesos críticos, las reglas de decisión y la estructura de la información. Esta
documentación facilita y reduce el tiempo de comprensión de los procesos de
trabajo.
6)�Reducción�del�tiempo�del�ciclo Otros beneficios del

Disminución en parámetros de coste y tiempo en los procesos clave de nego- sistema ERP
cio. Optimización del tiempo de producción y entrega. Reducción del tiempo • Mejora del servicio al clien-
del cierre financiero. te.
• Permite una respuesta más
rápida a los cambios en el
negocio y en el sector.
Las expectativas empresariales sobre los beneficios del sistema ERP suelen ser • Reducción del tiempo al
realizar las transacciones.
elevadas. Los empresarios esperan obtener una mejora en los procesos de ne- • Toma de decisiones más rá-
gocio, que repercuta, positivamente y a corto plazo, en la cuenta de resultados pidas al reducir el tiempo
de análisis de la informa-
de la empresa. ción.
• Lleva a la organización ob-
tener una ventaja compe-
1.5. Riesgos del sistema ERP titiva o, en su defecto, ali-
nearse con la ventaja de sus
competidores.
Las implantaciones de sistemas ERP son complejas de poner en marcha, tanto
desde un punto de vista tecnológico como de negocio. Antes de decidir im-
plantar un sistema ERP, se tiene que hacer un balance de los beneficios y los
riesgos.
Los riesgos principales en la implantación de un sistema ERP son:
1)�Inflexibilidad
El ERP es un sistema complejo en su instalación y su posterior mantenimien-
to. Los procesos de negocio están estrechamente ligados al sistema ERP; eso
supone que cualquier cambio en un proceso de la organización implica una
modificación en el sistema ERP.
2)�Periodos�largo�de�implementación
La duración de poner en marcha un proyecto de implantación es muy larga.
Las empresas critican que el mundo empresarial cambia muy rápidamente.
Para solucionar este problema, los vendedores de sistema ERP ofrecen versio-
nes configuradas previamente de sus sistemas que pueden ser instaladas con
un tiempo inferior.
3)�Alcanzar�los�beneficios�estratégicos
Si la organización adopta los procesos de negocio del estándar del sistema
ERP, abandona sus propios procesos de negocio que le podrían proporcionar
la ventaja sobre la competencia.
4)�Estructura�jerárquica
La centralización de la información para la coordinación y la toma de decisio-
nes aportada por el sistema ERP puede ser una dificultad en la forma de operar
internamente en algunas empresas.
5)�Costes�indirectos
A los costes de una implantación del ERP se tienen que sumar los costes de las
licencias que se tienen que renovar anualmente. Una vez el sistema ERP está
implantado, los costes de cambios son muy elevados.
Otros riesgos del sistema ERP
• Dificultad para integrar la información de otros sistemas de información indepen-

dientes.
• Los costes de deshacer una implantación son muy elevados.
• Resistencia a cambios por parte de los usuarios.
• Resistencia a compartir la información entre los departamentos.
• Inflexibilidad en la elaboración de algunos reportes necesarios para la empresa.
2. Evolución histórica del sistema ERP
2.1. Evolución histórica: del MRP al ERP II
El origen de los ERP se encuentra en los años sesenta, con la introducción

en el entorno industrial del Inventory Management & Control. El principal
software desarrollado era hecho a medida y bajo los conceptos tradicionales
de gestión del inventario.
2.1.1. MRP (planificador de necesidades de materiales)
La evolución de estos sistemas hace surgir, en los años�setenta, los llamados

MRP (material requeriments planning), unas siglas conocidas en el ámbito de
producción para gestionar los materiales. A pesar de que los primeros progra-
mas eran costosos, el MRP ganó popularidad en la industria de manufactura
y el concepto fue sobradamente adoptado en la gestión y control de la pro-
ducción. El MRP era eficaz en la planificación y la adquisición de las materias
primas.
El sistema permite planificar los materiales necesarios durante el proceso de

producción y gestionar la adquisición de estos materiales; así se reducían los
niveles de inventario de los materiales que utilizaban y los gastos de compras.
Durante los sesenta�y�setenta, fabricantes como IBM producen computadores SAP

centrales con gran capacidad de procesamiento y almacenaje de información,
En 1972, cuando los MRP eran
los mainframes, propiciando el inicio de la nueva etapa del procesamiento de la difíciles de usar, cinco ingenie-
información. Hasta la llegada de estos computadores, las funciones del control ros de Alemania crearon una
compañía conocida como SAP,
de material eran un problema. Al disponer de capacidad para gestionar un gran con el objetivo de desarrollar
y comercializar un software in-
volumen de información a grandes velocidades, se eliminaban las restricciones dependiente de soluciones in-
tegradas de negocio.
relacionadas con el procesamiento de la información y la obsolescencia de
técnicas desarrolladas en base a estas restricciones.
2.1.2. MRP-II (planificador de recursos de fabricación)
En los ochenta, los MRP se habían convertido en MRP-II (manufacturing re-

sources planning) con el fin de optimizar el proceso de todo el sistema de pro-
ducción.
El MRPII se extendió para incluir las actividades de la planta de producción y la

gestión de la distribución, haciendo énfasis en la optimización de los procesos
de producción.
Los sistemas de ficheros tradicionales son sustituidos por las bases de datos,
permiten mejores sistemas de integración y una mayor capacidad de consultas
para dar apoyo a la toma de decisiones. La red de telecomunicaciones se con-
virtió en una parte integral de estos sistemas distribuidos geográficamente.
El uso del MRP-II se extiende a otras empresas no industriales que necesitan

gestionar sus procesos críticos, como el sector financiero.
La coordinación de los diferentes sistemas de la empresa era deseable. La ma-

yoría de los sistemas se habían desarrollado para realizar funciones específicas
de un departamento; a ello se tiene que añadir que estaban programados en
diferentes lenguajes y no era fácil acceder a los datos entre los sistemas.
2.1.3. ERP (planificador de recursos empresariales)
El rol del MRP-II fue gradualmente extendido en los noventa para incluir otros
departamentos funcionales. Estas extensiones del MRPII que introdujeron es-
tas áreas, a su vez, introdujeron el concepto de ERP.
Basados en el fundamento de la tecnología del MRP y MRP-II, los sistemas

ERP integran los procesos de negocio de una empresa incluyendo fabricación,
distribución, contabilidad, finanzas, gestión de recursos humanos, gestión de
proyectos, gestión de inventario, servicio y mantenimiento, y transporte, per-
mitiendo una integración de datos a lo largo de la organización y proveyendo
accesibilidad, visibilidad y consistencia de datos por medio de toda la organi-
zación.
Los PC ganan popularidad. El sistema ERP emigra del mainframe a una arqui-
tectura cliente/servidor. A�finales�de�los�ochenta ya existen ordenadores más
rápidos, acceso a redes, una avanzada tecnología de bases de datos y, princi-
palmente, una visión más clara de los sistemas integrados. El ERP obtiene una
integración entre sus módulos y entre los sistemas de información existentes
en la empresa, proporcionada por una base de datos centralizada y la arqui-
tectura cliente/servidor.
El mercado de los ERP crece rápidamente en los noventa por el problema del
cambio de dígito del año 2000 y la introducción del euro.
2.1.4. ERP-II (planificador de recursos empresariales - II)
A principios del año�2000 se introdujo el concepto de ERP�extendido o ERP-

II.
El ERP-II es una nueva generación de sistemas empresariales que englo-

ba toda la cadena de negocio, extendiendo el ERP clásico o tradicional a
clientes y proveedores, y optimizando el funcionamiento de las empre-
sas y de las relaciones existentes interempresas.
El concepto de la aplicación clásica ERP está en la gestión eficiente de la infor-

mación interna desde varios procesos de negocio de la empresa, como finan-
zas, logística manufactura, recursos humanos, ventas y marketing.
Figura 2. Extensión del ERP
El ERP-II está conectando con otros sistemas empaquetados de la empresa, co-

mo la gestión�de�las�relaciones�con�el�cliente o customer relationship mana-
gement (CRM) y la gestión�de�la�cadena�de�suministro o supply chain mana-
gement (SCM) para añadir funcionalidades que no se contemplan en determi-
nadas áreas de actividades de la empresa. Este sistema se está convirtiendo en
la columna vertebral de muchas organizaciones, mejorando la satisfacción del
cliente, incrementando el marketing y las oportunidades de ventas y expan-
diendo los canales de distribución.
La gestión�de�las�relaciones�con�el�cliente (CRM) es, principalmente,

una estrategia y una modalidad operativa que tiene como objetivo me-
jorar y extender las relaciones con el cliente, generando nuevas oportu-
nidades de negocio.
La gestión�de�la�cadena�de�suministro (SCM) designa el sistema que

coordina e integra los diferentes flujos de materiales, información y fi-
nanzas a lo largo de la cadena de suministro.
Desde un punto de vista tecnológico, la arquitectura está basada en Internet.

Los sistemas�basados�en�la�web reducen los costes derivados de las infraes-
tructuras de comunicación y añaden la funcionalidad de acceder al sistema
independientemente del lugar que se encuentre el usuario; solo hace falta un
navegador estándar.
Figura 3. Evolución de los sistemas de información empresarial
2.2. El sistema ERP actual
Las empresas han tomado conciencia de que el sistema ERP es la columna ver-
tebral de la empresa; proporcionará un mayor rendimiento al incluir funcio-
nalidades para mejorar las relaciones con clientes y proveedores como CRM y
SCM, pero también para las relaciones con los socios (PRM, gestión de socios)
o con los empleados (KM, gestión del conocimiento) y para facilitar la toma
de decisiones de los directivos (BI, inteligencia de negocio).
Figura 4. El sistema ERP actual
(5)
La tendencia más destacada son las aplicaciones del front-office5 y los procesos El nombre de front-office hace re-
ferencia a los participantes exter-
de negocio interorganizaciones. Las aplicaciones del front-office implican la nos que no ven la parte interna de
interacción con el exterior de la empresa, como los clientes, proveedores y la empresa.
socios. La integración de las funciones internas continúa siendo importante, Back-office

pero parece que la integración externa sea el foco principal a la hora de mejorar
Los sistemas tradicionales ERP
las relaciones con los clientes. son denominados sistemas
back-office, ya que las activida-
des y los procesos implicados
La arquitectura de los sistemas continúa evolucionando para ser más abierta, no tratan a los clientes y al pú-
blico en general, al menos no
flexible e integradora. Los principales sistemas incorporan una arquitectura directamente.
basada en Internet, debido a la mayor importancia del comercio electrónico
(e-commerce) y la globalización de los negocios.
La forma de denominar el sistema ERP cambia según las compañías. Algunas lo

continúan llamando ERP, aunque amplíen su capacidad añadiendo módulos.
Otros han empezado a hablar de suites�de�empresa y finalmente, hay compa-
ñías que usan el término soluciones�de�empresa para describir un grupo de
aplicaciones que incluye, entre otros módulos, el ERP clásico.
1)�El�ERP�en�la�pequeña�y�mediana�empresa
Los proveedores de ERP han encontrado en este sector una nueva línea de
mercado con un gran potencial; se están desarrollando y comercializando pro-
ductos especializados con una reducción del coste económico y del tiempo en
las implantaciones.
Actualmente este sector ha pasado de no tener un producto que resuelva sus

necesidades a poder escoger entre diferentes alternativas: paquetes comerciales
de empresas destacadas, como Oracle y SAP, que ofrecen productos específicos
para las pymes, proveedores que solo ofrecen productos específicos para este
tipo de empresas, ERP de software libre con reducción de costes económicos al
no tener que pagar las licencias de uso, y nuevas modalidades de instalación
como SaaS.
2)�Crisis�financiera�y�económica
En un momento de crisis financiera y económica, las empresas se quieren cen-
trar en aspectos básicos de supervivencia del negocio. Quieren proyectos que
minimicen los riesgos de fracaso y obtener los primeros beneficios sin tener
que esperar mucho tiempo.
El tamaño y el ámbito de aplicación de los nuevos proyectos ERP también han

cambiado. Las empresas no quieren realizar largas y costosas implantaciones,
prefieren implantaciones menos complejas, divididas en etapas y añadiendo
en cada etapa nuevos módulos.
3)�Proveedores�de�sistema�ERP
Las empresas se han fusionado para ofrecer nuevos productos o para tener una
posición de más liderazgo en el mercado.
Ejemplo
Microsoft Dynamics; su nuevo enfoque parte del seguimiento de la evolución hecha por
SAP. La empresa Oracle adquirió Siebel para proporcionar su producto de CRM. La em-
presa SAP responde al mercado mediante el desarrollo de su propio CRM.
4)�Modalidad�de�contratación�SaaS
La nueva tendencia del mercado es la oferta del software como servicio o SaaS
(software as a service); este modelo está extendido en Estados Unidos y su cre-
cimiento en Europa es más lento.
Se proporciona al cliente la contratación de un servicio en lugar de un pro-

ducto. El cliente dispone del sistema alojado en un servidor remoto, el servicio
de mantenimiento y el soporte técnico del software. El coste de la implanta-
ción está asociado al contrato de alquiler del software; no se tienen costes de
implantación ni de integración, ni hay que adquirir licencias, lo cual reduce
notablemente la inversión a realizar.
La principal ventaja es el ahorro en tiempo y coste de la obtención del softwa-

re, una modalidad apropiada para la pequeña y mediana empresa. El principal
inconveniente es la pérdida de privacidad de los datos de la empresa, control
y seguridad. La información está hospedada en un sitio remoto donde la em-
presa contratante podría consultarlo.
2.3. Tendencias de futuro del sistema ERP
El concepto ERP irá evolucionando a lo largo de los años impulsado por los
nuevos entornos de negocio, las innovaciones en las TIC, las necesidades de
las empresas y la capacidad de los proveedores de desarrollo de software.
Los nuevos modelos de negocio son multiempresa con redes de colaboración

y centradas en el cliente, lo que refleja un aumento de la integración externa
de la empresa.
El e-commerce es una de las evoluciones más importantes en los negocios de

los últimos cincuenta años. Internet, intranets y extranets hacen posible las
múltiples formas de e-commerce (B2B, B2C, C2C...). La tecnología inalámbrica
y los dispositivos móviles harán que el m-commerce tome relevancia y des-
place al e-commerce. El uso de Internet en cualquier momento y en cualquier
lugar dará paso a nuevos servicios. Las actividades y los procesos del back-office
y front-office se han adaptado al e-commerce y se verán afectados por el m-
commerce.
Las plataformas de arquitectura deberán tener la capacidad para mover gran

cantidad de datos en cualquier formato, idioma y lugar en un tiempo casi real.
El uso de portales de información, tanto del negocio interno como externo,
será algo habitual.
Los sistemas serán más inteligentes. La minería de datos y las herramientas

de inteligencia, incluyendo los sistemas expertos y sistemas de planificación
avanzados, se usarán más para tomar decisiones o sugerir decisiones de nego-
cio. La simulación se convertirá en un elemento importante dentro de la pla-
nificación de la empresa.
Los sistemas ERP actuales tendrán que madurar y ampliar su uso dentro de las
empresas. El mercado de los proveedores de ERP tendrá que consolidarse con
adquisiciones y fusiones de otros proveedores para obtener más ventaja en el
liderazgo del mercado.
Taula 1. Evolución del sistema de información de empresa
Sistema Necesidad Ámbitos de Tecnología

de negocio aplicación
MRP Eficiencia Gestión de inventario Computadores mainframe

Planificación y control Procesamiento batch
de la producción Sistemas de ficheros tradi-
cionales
MRP-II Eficiencia Extensión a toda la em- Mainframes

Eficacia e integración presa de manufactura Procesamiento en tiempo
con el sistema de pro- real
ducción Sistemas gestores de base
de datos (relacional)
ERP Eficiencia (principal- Extensión a todos los Mainframes

mente del back-office) sistemas de la empresa Microcomputadores red
Eficacia e integración cliente/servidor Procesa-
de todos los sistemas miento distribuido
de la organización Data warehousing
Gestión del conocimiento
ERP-II Eficiencia Extensión al exterior de Sistemas cliente/servidor

Eficacia e integración la empresa Computación distribuida
dentro de y entre em- Relación con el cliente y Tecnología Internet (servi-
presas el proveedor cios web, intranets, extra-
nets)
ERP�actual Eficiencia Toda la organización se Internet

Eficacia e integración extiende a otras organi- Arquitectura
dentro de y entre to- zaciones (socios, clien- Servicios web
dos los componentes tes, proveedores...) Red sin hilos
relevantes (consumi- E-commerce Gestión conocimiento
dores, empresas...) a
escala mundial
ERP�futuro Eficiencia Toda la organización y Internet

(suite�em- Eficacia e integración sus componentes de la Arquitectura más abiertas,
presarial) de los nuevos servicios cadena de valor, así co- red sin hilos, dispositivos
m-commerce mo otras organizaciones móviles, inteligencia artifi-
m-commerce. cial, cloud computing
Fuente: McGaughey & Gunasekaran (2007)

3. Arquitectura del sistema ERP
3.1. Perspectiva funcional
El sistema ERP es un paquete estandarizado de software diseñado para integrar

los procesos de una empresa. El ERP se compone de una base de datos centra-
lizada y varios módulos destinados a dar apoyo a las áreas principales de una
organización.
Figura 5. Catálogo de los sistemas de información de empresa
Las aplicaciones las podemos agrupar en cuatro ámbitos:
1)�Los�clientes
En la parte derecha de la figura podemos observar los sistemas de gestión co-

mercial y relación con los clientes. Normalmente, tendrían que registrar to-
dos los contactos y operaciones que la empresa tiene con sus clientes, sean
de marketing, visitas de representantes, servicio posventa, etc. También pue-
den incluir la relación con los canales de venta, si la venta no es directa y,
actualmente, los sistemas de interacción y respuesta que los clientes estable-
cen con la empresa, ya sean programas de fidelización, gestión de incidencias
y reclamaciones, o incluso, las redes sociales. Sirven también para medir la
efectividad de la fuerza de las ventas. Estos sistemas se llaman gestión�de�las
relaciones�con�los�clientes (CRM, o customer relationship management).
2)�Los�proveedores
(6)
En la parte izquierda de la figura encontraremos los sistemas de relación con Proveedores, productores, alma-
cenes, transportistas, tiendas e in-
los proveedores. Ninguna empresa es autosuficiente ni puede servir a sus clien-
cluso clientes.
tes solo con sus medios. Pero es que además, actualmente, muchos procesos
que antes estaban internalizados están fuera o se comparten con otros provee-
dores. Los sistemas típicos de gestión�de�la�cadena�de�suministro (SCM, o
supply chain management) incluyen los procesos de previsión de la producción
y demanda de materias primas y productos semielaborados, la reposición de
inventarios, el almacenaje y el transporte a almacenes intermedios y al consu-
midor final. Estos procesos y sistemas se comparten entre los diferentes miem-
bros de la cadena6 por Internet.
Hasta aquí hemos hablado de sistemas bien consolidados en la actualidad,

aunque con diferente nivel de presencia y éxito en el mercado. También de
sistemas que frecuentemente se venden integrados, es decir, un ERP como SAP
u Oracle contiene a la vez una solución de CRM y una solución SCM.
3)�Los�gestores�y�los�accionistas
En la parte superior de la figura están los sistemas de relación entre los socios
o los PRM; esta parte es menos obvia. Tienen que servir para gestionar las re-
laciones con "otros agentes" o intermediarios que nos ayuden a hacer o man-
tener nuevos clientes y proveedores o proporcionar servicios de valor añadido
que completen nuestra oferta de servicios. Por eso se les llama sistemas� de
gestión�de�socios (PRM, o partnership relationship management).
Ejemplos
Un ejemplo podrían ser los sistemas de seguimiento de pacientes crónicos o de deriva-

ción de enfermos en los cuales participan un hospital, los médicos de familia y centros
de servicios sociosanitarios. Otro ejemplo es el de los programas de fidelización, en los
que participan líneas aéreas, hoteles, restaurantes o centros comerciales. En el mundo
industrial, estos sistemas suelen forman parte de su SCM o de su CRM.
4)�Los�empleados
En la parte inferior de la figura encontramos un conjunto desigual y desinte-

grado de aplicaciones o soluciones parciales:
• los�sistemas�de�ayuda�a�la�toma�de�decisiones (DSS o decision suport sys-

tems), como un sistema que optimiza las rutas de un transportista;
• los� sistemas� informacionales (BI o business intelligence), que van desde

los cuadros de mandos de dirección hasta los sistemas de análisis de gran
volumen de datos o inteligencia de negocio;
• los�sistemas�de�gestión�del�conocimiento (KM o knowledge management),

que permiten trazar "quién sabe qué" o dónde se puede encontrar una
información dentro de la empresa;
• las puras�intranets y portales�de�servicios al empleado, para pedir unas

vacaciones o apuntarse a un curso.
De hecho, en el mercado para cada grupo de necesidades es posible encontrar

gran número de soluciones parciales. Aunque, de nuevo, los grandes provee-
dores de sistemas de empresa están incorporando soluciones de este tipo entre
sus paquetes.
Por todo ello, los sistemas de información de empresa han evolucionado a

sistemas de información entre empresas y entre empleados, con tecnologías
basadas en la web y bajo la etiqueta de suites�de�negocio�electrónico (e-bu-
siness suites).
3.2. Perspectiva tecnológica
Las diferentes aplicaciones del sistema ERP comparten una base de datos cen-
tralizada, produciendo la integración de la información entre todas las aplica-
ciones. La centralización implica que los datos usados por los diferentes pro-
cesos de la organización son introducidos una sola vez en un solo lugar y ac-
tualizan automáticamente toda la información relacionada con esta.
Los paquetes ERP pueden incorporar su propia base de datos o bien usar otros
estándares en el mercado. Se recomienda utilizar una base de datos estandari-
zada porque ofrece la oportunidad de ser compartida por otras aplicaciones.
La arquitectura�del�sistema�ERP tiene que ser abierta, flexible, escalable

e integrable con el resto de aplicaciones empresariales.
Una arquitectura abierta permite añadir, actualizar y cambiar sus componen-

tes. Tiene que ser flexible para facilitar la expansión y/o adaptabilidad de otros
módulos posteriormente. Ha de ser escalable porque la ampliación del sistema
se tiene que hacer sin perder calidad de los servicios ofrecidos. Debe integrar
el conjunto de aplicaciones dentro de una empresa: integración para que la
información sea consistente e integración de los procesos de negocio entre las
diferentes aplicaciones.
La arquitectura del ERP tiene que soportar plataformas múltiples de hardware,

pues muchas empresas poseen sistemas heterogéneos. Ha de comportar el uso
de un módulo libremente sin que este afecte a los restantes.
Los sistemas ERP son aplicaciones para usar en un entorno cliente/servidor en

tres capas. El uso de la tecnología cliente/servidor crea un entorno descentra-
lizado, hace que sea escalable y permite ofrecer configuraciones óptimas en
hardware, gestión de bases de datos y sistemas abiertos. Este formato de arqui-
tectura abierta facilita a las empresas el hecho de poder seleccionar los equipos
de hardware y los sistemas operativos, de manera que se puedan aprovechar al

máximo los avances tecnológicos. Los sistemas son diseñados para hacer fun-
cionar varias plataformas operativas, como los sistemas UNIX, MS Windows
NT, Windows 2000, IBM AIX y HP-UX.
Figura 6. Arquitectura cliente/servidor de tres capas
• Nivel� presentación: la interfaz gráfica de usuario (GUI) o el navegador

para introducir datos o acceder a funciones del sistema.
• Nivel�aplicación: las reglas de negocio, las funciones, la lógica y los pro-

gramas que actúan sobre los datos de servidores de base de datos.
• Nivel�datos: gestión de datos operativos o transaccionales de la organiza-

ción, incluyendo los metadatos; sobre todo se utiliza el estándar RDBMS
con SQL.
4. Módulos funcionales
4.1. La evolución de la empresa y las TIC
En la visión tradicional de una organización, cada departamento trabaja in-

dependientemente realizando las funciones asignadas de manera eficaz y efi-
ciente. La introducción de las TIC en las empresas permitió automatizar ta-
reas, facilitar gestiones y dar apoyo, aisladamente, a las actividades de cada
departamento. Esto provoca que cada departamento tenga su propio softwa-
re incomunicado del resto. Con este enfoque se tiene una visión parcial del
funcionamiento de la organización. Esta fragmentación, separada por los di-
ferentes sistemas de información, tiene un impacto negativo en la eficiencia
y el rendimiento de la organización.
Figura 7. Visión tradicional de los sistemas de información
Fuente: Landon & Landon (2006)
Nace una nueva forma de trabajar dentro de la organización, orientada al clien-

te y al resultado global de la misma: la�visión�por�procesos. Con este nuevo
enfoque, el funcionamiento de la empresa no es un conjunto aislado de activi-
dades, sino una secuencia coordinada de actividades, con unas entradas y unas
salidas en las que participan diferentes unidades organizativas (departamento
comercial, departamento de producción, departamento administrativo...).
Un proceso es un conjunto estructurado de actividades que se desarro-

llan dentro de una organización con el objetivo de alcanzar un resulta-
do concreto para sus clientes o un mercado específico.
Para conocer las actividades que se hacen dentro de una organización, recu-
rriremos al concepto de cadena�de�valor. Se entiende por valor la cantidad de
clientes que están dispuestos a pagar por lo que la empresa le proporciona.
Cadena de valor es la secuencia de actividades que genera valor para el

cliente final.
Figura 8. La cadena de valor de la empresa
Fuente: Andreu, Ricard, Valor (1996).
La organización necesita comunicación y coordinación entre los diferentes de-

partamentos, pero la diversidad de programas de cada departamento continúa
trabajando de forma aislada. Las TIC tienen que innovar para dar respuesta a
la nueva necesidad de la empresa.
La mejora en la capacidad de almacenaje de la información, la instauración

de la tecnología cliente/servidor y los nuevos sistemas operativos permiten
romper la barrera de espacio y tiempo que dificultaba la comunicación y coor-
dinación interna entre los diferentes departamentos o las áreas funcionales:
nacen los sistemas ERP.
Figura 9. Visión por procesos ERP
Fuente: Landon & Landon (2006)

Los sistemas ERP nacen con el objetivo de facilitar un sistema que cubra todas
las áreas funcionales de una empresa de forma integrada como finanzas, pro-
ducción, compra, ventas, recursos humanos, etc.
4.2. Las áreas funcionales de la organización
Veamos con más detalle las actividades que se tienen que realizar en las prin-
cipales áreas de la organización.
1)�Área�de�contabilidad�y�finanzas
Registra todas las transacciones económicas que hay en la empresa, desde el
pedido del cliente hasta el pago de la compra de la materia prima. Para elaborar
los informes financieros, necesita disponer de todas las transacciones hechas
por los distintos departamentos.
2)�Área�funcional�de�manufactura�y�producción
Es la responsable de producir los bienes y servicios de la organización. El área
de producción tiene que transferir información al área de compra para adqui-
rir la materia prima necesaria en función de los planes de producción, del
transporte, de las fechas de entrega y de los niveles existentes en almacén. El
área de ventas tiene que dar información sobre las necesidades de ventas del
producto en el área de producción.
3)�Área�de�recursos�humanos
Es la responsable de contratar, desarrollar y mantener al personal de la orga-
nización.
4)�Área�funcional�de�ventas�y�marketing
El departamento de ventas y marketing es el responsable de vender el produc-
to o el servicio de la organización. A marketing le corresponde identificar a los
clientes, determinar qué necesitan o desean, y planificar y desarrollar produc-
tos y servicios. A ventas le corresponde contactar con los clientes, vender los
productos o servicios, tomar pedidos y llevar el registro de ventas.
4.3. Los módulos funcionales del sistema ERP
La estructura modular del sistema ERP permite agrupar las funcionalidades Diferentes requerimientos
de las diferentes áreas de negocio en diversos módulos. También facilita a la funcionales según el tipo
de empresas
empresa la selección de los módulos a implantar. Cada cual hará su elección;
depende de las características de la empresa, sus necesidades y procesos de Los requerimientos funcionales
de una empresa basada en la
negocio. producción serán muy diferen-
tes a los de una empresa cuyo
principal negocio es el servi-
Esta composición por módulos también permite a una empresa implementar cio. En otros casos, las empre-
sas ya disponen de un softwa-
el sistema por etapas. Normalmente, el primer módulo que se implementa re para realizar funcionalidades
concretas, y quieren continuar
es el de finanzas y, posteriormente, se van integrando el resto de módulos usándolo.
seleccionados.
Cada uno de los proveedores del sistema ERP define el número, la tipología,
el nombre y las funcionalidades de la estructura modular de sus líneas de pro-
ductos y soluciones. Los proveedores de sistemas ERP, para diferenciarse, pro-
porcionan sistemas ERP con algún grado de especialización, pero los módulos
básicos son similares para todos ellos.
Examinaremos con más detalle los siguientes módulos�funcionales:
• finanzas
• producción
• compras
• recursos humanos
• ventas y distribución
• gestión de materiales
• mantenimiento de planta
• marketing
• calidad
4.3.1. Finanzas
Generalmente, es uno de los primeros módulos en ser implantado en la em-

presa. Reúne los datos contables de varios departamentos funcionales, propor-
cionando una visión completa del estado contable y financiero de la empresa,
facilitando a los directivos la toma de decisiones rápidamente.
El módulo de finanzas de la mayoría de sistemas ERP proporciona la funcio-

nalidad financiera adecuada tanto para pequeñas y medianas empresas, como
para multinacionales. Permite trabajar con diferentes divisas a la vez, favore-
ciendo el análisis del negocio de las delegaciones distribuidas en diferentes
países.
Los módulos de finanzas de la mayoría de los sistemas ERP disponen de sub-

sistemas que realizan:
• contabilidad general
• transacciones bancarias
• gestión de cuentas
• control de caja
• transacciones directas con la Seguridad Social y Hacienda
• pago de impuestos y tributos
• gestión de propiedades y amortizaciones
• creación automática de informes contables
Las aplicaciones del módulo se conectan y se integran con otros módulos fi-
nancieros como la tesorería, así como con otras aplicaciones, como las nómi-
nas de recursos humanos o la logística.
4.3.2. Producción
Es el módulo encargado de gestionar todas las tareas relacionadas con la pro-

ducción de la empresa. El objetivo que se persigue es planificar la producción
conforme a las necesidades del cliente.
El módulo de producción hace que una empresa integre la tecnología con el

proceso de negocio. Proporciona la información para ejecutar toda la opera-
ción base de la empresa. Contiene las reglas de negocio para gestionar el pro-
ceso de la cadena de suministro de proveedores. El módulo de producción de
la mayoría de vendedores no se limita a un único método de producción; se da
la libertad de cambiar de métodos de producción y planificación. Varios mé-
todos de manufactura y planificación se pueden combinar en la misma opera-
ción, con flexibilidad ilimitada para escoger el mejor método –o combinación
de métodos– para cada producto y para cada etapa del ciclo de vida.
Algunos de los subsistemas de módulos de producción son:
• gestión de material
• control de planta
• gestión de calidad y gestión de costes
Entre otros, dispone de las siguientes aplicaciones: el control de stock de las

materias primas, la compra de materiales y los informes sobre la producción.
4.3.3. Compras
Optimiza la compra de la materia prima necesaria y gestiona la creación de

proveedores, el registro de facturas y los pagos.
El módulo de compras tiene que estar integrado con los módulos de produc-
ción y control de inventario, y en la extensión de la funcionalidad de gestión
de la cadena de suministro (SCM).
Las aplicaciones del módulo de compras permiten:
• identificar a los principales proveedores

• negociar precios
• dar la orden de compra al proveedor
• recepción de la facturación
• descuentos sobre compras
• control de compras
• control de pagos pendientes y realizados
• estadísticas de compras
• control de fechas de recepción de pedidos
• predefinir pedidos periódicos
• propuestas de pedidos
• control de las devoluciones de compras
4.3.4. Recursos humanos
Gestiona la información del personal de la empresa, manteniendo los datos

completos de los empleados e incluyendo la tipología de contrato, la informa-
ción de contacto, detalles del salario, asistencia, evaluación del rendimiento
y promoción de todos los empleados.
El módulo de recursos humanos puede estar integrado con el sistema de ges-

tión de conocimiento; así se optimiza el uso de las experiencias de los emplea-
dos.
Los subsistemas del módulo de recursos humanos son:
• gestión de personal
• gestión organizacional
• contabilidad de nominas
• gestión del tiempo y desarrollo personal
4.3.5. Ventas y distribución
Los ingresos de las ventas es el elemento vital de la organización.
El módulo gestiona la venta y la distribución de los productos o servicios que

produce la empresa.
Entre otros, implementa las funcionalidades siguientes:
• programación de pedidos
• envío y facturación
En el entorno de negocio actual, que se caracteriza por la creciente compe-

tencia y la reducción de los ciclos de ventas, las empresas cada vez están más
forzadas a optimizar sus procesos de ventas. Ya no es suficiente con ofrecer el
mejor producto o servicio; las empresas tienen que centrar sus esfuerzos en
mejorar la eficiencia de las ventas, los márgenes de beneficio y la atención
al servicio al cliente. Pues bien, todo eso se obtiene con las aplicaciones del
módulo de ventas.
Los módulos de ventas y distribución de varios vendedores de ERP ofrecen un

conjunto completo de módulos "best-of-breed" para la gestión de logística.
4.3.6. Marketing
El módulo de marketing permite a las organizaciones maximizar la eficiencia

de los recursos de marketing y capacita a los vendedores a adquirir y desarrollar
las relaciones con los clientes a largo plazo.
Los vendedores pueden analizar, planificar, ejecutar y medir todas las activi-
dades de marketing para obtener un éxito en la comercialización. Soporta los
procesos críticos de comercialización, como la gestión de recursos de marke-
ting, la gestión y segmentación de listas de clientes, la gestión de campañas,
el marketing por correo electrónico, la gestión de la promoción de comercio,
la gestión de clientes potenciales, el análisis de marketing y los estudios de
mercado basados en la web.
4.3.7. Gestión de materiales
El módulo de gestión de materiales ofrece mantener el almacén en el nivel

adecuado de existencias.
Entre otras aplicaciones, en el módulo se realiza:
• la identificación de los requisitos del inventario

• establecer objetivos, proporcionar técnicas de abastecimiento
• monitorizar el estado del inventario
• verificación de facturas
La integración del módulo de gestión de materiales con ventas, compras y

finanzas permite a los sistemas ERP generar informes de alertas desde el punto
de vista ejecutivo.
El módulo de gestión de materiales optimiza el proceso de compra conducido

por el proceso del flujo de trabajo y reduce los costes de adquisición y alma-
cenaje con el inventario preciso.
4.3.8. Mantenimiento de planta
Proporciona información para reducir el tiempo y los costes de los paros de la

planta de producción como consecuencia de los daños del sistema técnico, y
con ello se conocen sus puntos débiles con la suficiente antelación.
También permite definir una estrategia óptima de mantenimiento u optimizar

los riesgos. La mayoría de subsistemas del módulo son:
• el control de mantenimiento preventivo

• el seguimiento del equipo
• el seguimiento de los componentes
• el seguimiento de las reclamaciones
4.3.9. Gestión de calidad
La serie ISO 9000 y otros estándares internacionales definen las funciones y

los elementos del sistema de gestión de la calidad.
Las funciones internas del módulo de gestión de la calidad no interactúan

directamente con los datos o procesos de otros módulos. El módulo de gestión
de la calidad cumple las siguientes funciones:
• planificación
• inspección
• control de la calidad
4.4. Módulo sectorial o soluciones verticales
En general, si una aplicación puede ser usada por diferentes tipos de sectores
industriales, se llama solución�horizontal. Si la aplicación está diseñada por
un sector específico, entonces se llama solución�vertical por este tipo de sec-
tor.
Existen funcionalidades que son comunes e independientes del sector de ne-

gocio, como las financieras y la contabilidad. Otras son específicas del tipo
de negocio y hay que diseñar funcionalidades concretas, por ejemplo, las de
producción.
En los sistemas ERP existen soluciones diseñadas por determinados procesos Ejemplo
de negocio de un sector concreto, denominadas soluciones�verticales o ver-
Las necesidades de una empre-
siones�sectoriales. Actualmente, los ERP proveen a una amplia gama de sec- sa distribuidora son diferentes
tores, desde el sanitario hasta empresas de manufactura. de las de una empresa produc-
tora.
El sistema ERP se ha hecho popular en sectores no industriales como la uni-

versidad, la sanidad, la banca o la Administración pública, donde la eficiencia Nota
del back-office es importante, y también la eficacia del front-office. Los módulos Consultad glosario
de los vendedores de ERP enfocados a segmentos especializados del mercado
incorporan las mejores prácticas y los estándares de los procesos de negocio
para simplificar las implantaciones futuras.
En todo proceso de selección del ERP es fundamental analizar la existencia

de soluciones adaptadas al sector económico y a la actividad de la empresa
en concreto. Las soluciones verticales reducen el tiempo de implantación, al
estar configuradas previamente, a la hora de apoyar la actividad de la empresa,
adaptándose de una forma más definida y proporcionando prestaciones me-
jores a todas las áreas de negocio.
Oracle ofrece soluciones específicas para los siguientes sectores:
Tabla 2. Soluciones sectoriales de Oracle
Defensa y aeroespacial Servicios financieros Petróleo y gas
Automoción Atención sanitaria Servicios profesionales
Química Alta tecnología Sector público
Comunicaciones Fabricación industrial Sector minorista
Productos de consumo Seguros Viajes y transportes
Educación e investigación Medios y entretenimiento Servicios públicos
Ingeniería y construcción Recursos naturales Distribución mayorista

5. Ciclo de vida del sistema ERP
Como cualquier sistema de información, el ciclo de vida de los sistemas ERP

está dividido por una serie de fases por las cuales tiene que pasar un sistema
ERP dentro de una organización.
5.1. Fases del ciclo de vida
El ciclo de vida de los sistemas ERP se divide en las siguientes fases:
• Adopción
• Selección
• Implementación
• Puesta en marcha
El ciclo se inicia cuando una organización detecta que su sistema de informa-

ción ha quedado obsoleto y quiere optimizar el funcionamiento de sus proce-
sos relevantes, o cuando la organización quiere cambiar su estrategia de nego-
cio. Los directivos toman conciencia del problema y deciden analizar, evaluar,
seleccionar e implementar la opción del sistema de información más alineado
a sus necesidades para alcanzar los objetivos planteados.
Figura 10. El ciclo de vida de los sistemas ERP
5.2. Fase: adopción del sistema ERP
En la organización se ha detectado el problema y se evalúa rigurosamente la

solución más adecuada para las necesidades actuales existentes y las previstas
a corto y largo plazo.
En esta fase, los directivos de la organización se cuestionan la decisión de im-

plantar un sistema ERP o, si es más adecuado por motivos técnicos, económi-
cos o funcionales, la adquisición e implantación de otro tipo de sistema.
Las tareas y la documentación que se tendrá que realizar en esta fase son:
elaborar un análisis de los procesos, establecer los objetivos y los beneficios
que se quieren alcanzar, y analizar el impacto de la implantación en el negocio.
En general, las motivaciones para ir a un sistema ERP se pueden agrupar en

las siguientes categorías: tecnológica, proceso de negocio, estratégica y com-
petitiva.
1)�Razones�tecnológicas
• Diversidad�de�sistemas. La organización tiene una variedad de entornos Y2K

informáticos que limitan la capacidad de la empresa para integrar la infor-
En el año 2000, uno de los
mación de las diferentes unidades de negocio. motivos principales para im-
plantar un sistema ERP fue el
cambio de dígito (también co-
• Sistemas�actuales�de�baja�calidad. Los sistemas de información existentes nocido como Y2K).
son ineficientes o fallan a menudo.
• Integración�de�las�empresas�adquiridas. La adquisición de distintas em-

presas puede ser un motivo sustancial para ir a un sistema ERP, a la hora de
facilitar la integración de las empresas adquiridas. La coexistencia de los
diversos sistemas de información y los diferentes procesos dificulta la co-
municación entre las áreas de negocio y la explotación de la información.
2)�Razones�de�procesos�de�negocio
• Mejorar� la� eficiencia� de� la� organización. Se basa en mejorar aspectos

concretos de los procesos críticos de la organización: la mejora del proceso
de productividad, la reducción del tiempo del cierre financiero o la reduc-
ción del tiempo de realizar el proceso de inventario.
• Disminuir�costes. Reducción del número de almacenes y de las compras

de materia prima para reducir el inventario.
3)�Razones�de�estrategia
Enfocadas a obtener una mejora de la calidad en la organización o a diseñar

una estrategia de negocio orientada al cliente.
4)�Razones�de�competitividad
Las empresas de la competencia disponen de un sistema ERP, el cual les permite Ventaja competitiva
avanzar en el diseño de reglas para fidelizar y captar a nuevos clientes y a
Una ventaja competitiva es
obtener, con rapidez, informes para la dirección en la toma de decisiones; es cualquier característica de la
decir, las empresas de la competencia tienen ventaja competitiva. empresa que la diferencia del
resto de organizaciones y la
coloca en una posición relati-
vamente superior a la hora de
Además de definir una razón para adoptar un ERP, la mayoría de empresas competir.
usan un análisis de coste/beneficio para decidir si adoptan un sistema ERP u
otro tipo de sistema.
5.3. Fase: selección del sistema ERP
Una vez escogida la decisión de adoptar un ERP, el siguiente paso es seleccionar

el sistema ERP y los módulos que se implantarán.
La selección del sistema ERP es un proceso crítico con un alto impacto en la

organización. Equivocarse en los primeros pasos del proyecto, en una inco-
rrecta selección del sistema ERP, implica arrastrar y hacer crecer el problema
durante las fases posteriores, con una alta probabilidad de fracaso del proyecto
de implantación.
La fase de selección consiste en la evaluación, la selección y la adquisi-

ción del sistema ERP que mejor esté alineado a los requerimientos fun-
cionales de la organización, minimizando las necesidades de adaptación
y personalización.
En esta fase, el primer paso será:
1) hacer un análisis riguroso de la situación;
2) definir las funcionalidades que se quieren cubrir con el sistema ERP;
3) determinar cuáles son los procesos críticos y las áreas que están implicadas
en ellos.
En la realización de estas tareas, que afectan los sistemas y procesos que tiene
la empresa, tiene que participar las personas que conozcan el funcionamiento
global de la empresa.
Como parte de la selección del sistema ERP, las empresas han de decidir la po-
lítica�de�reingeniería. Probablemente, ninguno de los sistemas ERP candida-
tos nos proporcionará la cobertura de todos los requerimientos de la empre-
sa. La organización tendrá que escoger entre personalizar el sistema ERP, para
adaptarse a los procesos de la organización, o cambiar los procesos de negocio
al estándar que propone el sistema ERP. Muchas empresas utilizan la adopción
de un sistema ERP como una oportunidad para cambiar sus procesos de ne-
gocio básicos, haciendo una reingeniería de los mismos para coincidir con la
"mejor práctica" (best practice) de los procesos del sistema ERP. Todo tiene sus
ventajas y sus inconvenientes.
Dependiendo del tamaño de la empresa, los recursos económicos y el tamaño

del proyecto de implantación del ERP, la empresa puede externalizar el proceso
de evaluación y selección del sistema ERP en empresas consultoras especiali-
zadas. En la selección de la empresa de consultoría externa se analizan factores

como el precio, la formación y el mantenimiento de los servicios, y se negocia
el acuerdo contractual.
En la selección del ERP se analizará el mercado de los diferentes proveedores Criterios básicos
de sistemas ERP, en base a un conjunto de criterios que previamente se habrán
Los criterios básicos para eva-
definido, para ser capaces de obtener aquel o aquellos sistemas ERP que me- luar a los proveedores de siste-
jor se adapten tanto a las funcionalidades específicas como a los procesos de mas ERP se clasifican en: fun-
cionales, técnicos, económi-
negocio. cos, estratégicos y sobre el
proveedor.
5.4. Fase: implantación del sistema ERP
La implantación del sistema ERP es la personalización o parametriza-

ción y la adaptación del sistema ERP adquirido según las necesidades
de la organización.
La falta de experiencia en una costosa implantación del sistema ERP aconseja

contratar una empresa consultora externa con experiencia previa en proyectos
de implantaciones similares al nuestro. El equipo de consultoría proporciona-
rá las metodologías de implementación, el conocimiento y la formación. El
tiempo requerido para la implantación y puesta en marcha del sistema depen-
de del tipo de ERP, del número de módulos, del tamaño de la empresa y de
sus necesidades.
En la fase de selección se ha definido la política de reingeniería que aplicare- Ejemplo

mos (¿quién se adapta a quién?). En la fase de implantación, tendremos que
Con las tablas de configura-
encontrar un equilibrio entre la forma que se desea trabajar y la forma en que ción, una empresa puede se-
el sistema ERP permite trabajar. La configuración del sistema se realiza a través leccionar el tipo de contabili-
dad, o si quiere conocer los in-
de los módulos y las tablas de configuración. Se empieza por decidir qué mó- gresos de los productos por
unidades geográficas, por lí-
dulos se instalarán. Posteriormente, para cada módulo se modifica el sistema neas de productos o por cana-
les de distribución.
por medio de las tablas de configuración con el fin de obtener el mejor ajuste
posible con los procesos de negocio de la empresa. Las tablas de configuración
permiten a las empresas adaptar un aspecto particular del sistema con el modo
de hacer negocios. A pesar de los módulos y las tablas de configuración, el
sistema permite personalizarse hasta cierto punto.
Algunas de las tareas que se tienen que llevar a cabo en la fase de implantación
del ERP son:
• instalación del hardware

• instalación del software en entorno a pruebas
• reingeniería de procesos
• configuración del software (tablas, ficheros, interfaces, formularios e in-
formes para cada módulo)
• traspaso de datos
• diseño y ejecución de los juegos de pruebas

• elaboración de la documentación de los manuales de procedimientos
• formación de los usuarios finales
• puesta en marcha y seguimiento
La correcta implantación del sistema ERP es el reto principal. Los motivos de Los cambios empresariales
fracasos en la implantación son diversos, entre otros, el rechazo de los usuarios
Los cambios empresariales es-
al nuevo sistema o al cambio en la manera de trabajar. Como la implantación tán en la cultura de la organi-
de un sistema ERP supone un cambio en la filosofía empresarial, muchas ve- zación, en los procesos de ne-
gocio y en la disciplina de tra-
ces resulta conveniente engendrar el proyecto de implantación de un sistema bajo.
ERP dentro de un programa de gestión de cambio. De ahí que, cada vez más,
la implantación de un sistema ERP deje de ser una cuestión de sistemas de
información para convertirse en un aspecto de la estrategia de negocio o la
mejora de procesos.
Los dos principales (y contrapuestos) enfoques de implantación de sis-

temas ERP son: la implantación por fases o modular y la implantación
global o big bang.
1)�Implantación�modular�o�por�fases�o�"step�by�step" Fases
La implementación se realiza en fases y de forma progresiva. Los módulos
En una primera fase se pueden
son implantados uno a uno o por grupos de módulos. Son implementaciones implantar los módulos de fi-
secuenciales que consisten en el diseño, desarrollo, testing e instalación de los nanzas y compras, y en una se-
gunda, incluir los módulos de
diferentes módulos. En cada fase se han de integrar los nuevos módulos con gestión de materiales, produc-
ción y calidad.
el sistema existente. Minimiza los riesgos y el control del coste del proyecto,
pero aumenta el periodo de implantación del sistema ERP final.
2)�Implantación�global�o�"big�bang"
La implementación se realiza simultáneamente en todos los módulos, en un
solo lugar y a la misma vez. En este escenario, el sistema pasa de ser una versión
de prueba a ser el sistema actual utilizado. El big bang pide una gran cantidad
de testing antes de hacer el cambio de sistema heredado al nuevo.
Comparado con la implementación en fases, el big bang minimiza la duración

en el tiempo de la implantación, pero dificulta el control del coste económico
del proyecto.
El enfoque de implantación del big bang es un proceso de tres pasos:
• Primero, se seleccionan todos los procesos críticos y se implementan en

un entorno a prueba.
• Segundo, todos los módulos son testeados individualmente así como sus
integraciones con otros módulos. Los problemas detectados durante el tes-
ting proporcionan un feedback que será usado para desarrollar y finalizar

el módulo.
• Tercero y último, el sistema antiguo se retira y se instala el nuevo. Después

de la implantación siempre se tienen que hacer cambios o ajustes, pero
debido al amplio testing realizado se espera que las necesidades de estos
cambios sean mínimos.
5.5. Fase: puesta en marcha del sistema ERP
Finalizada la fase de implantación del sistema ERP, sigue un periodo de esta-

bilización. Se empieza a usar el nuevo sistema y los nuevos procesos. Se ob-
servan los primeros resultados del cambio y se detectan defectos de mal fun-
cionamiento que se tendrán que corregir. En este periodo de estabilización,
los usuarios todavía no están lo bastante familiarizados con los cambios, lo
cual puede suponer que, durante los primeros meses, no se obtenga el resul-
tado esperado. En el uso del sistema es importante que los usuarios reciban
formación y apoyo de la organización. Pasado el periodo de estabilización, los
problemas y las paradas tienen que ser mínimas.
La organización quiere conocer si la implantación ha sido un éxito,

comparar entre lo que se planificó y la realidad. Así, se hará una audi-
toría por parte de diferentes personas o por una empresa externa. En
la auditoría se comparará si el funcionamiento del sistema es el que se
acordó. Se evaluará la duración del proyecto, el coste y los beneficios
reales contrastándolos con los que se planificaron.
El sistema está implementado y se tiene que hacer el mantenimiento para ga-

rantizar su buen funcionamiento. Es necesario un mantenimiento en las in-
fraestructuras, en la instalación de las nuevas actualizaciones y en las mejoras
generales del sistema.
6. Proveedores de sistemas ERP
6.1. Modalidades de sistemas ERP
6.1.1. ERP propietario
Un software propietario requiere el pago de una licencia para poder ser usado.
En una implantación de ERP, el coste de las licencias puede representar el 50%
del coste total del proyecto; se tiene que pagar por el número de usuarios que
se usarán.
La principal ventaja de un software propietario es el control de la calidad. Las

empresas desarrolladoras de software propietario disponen de controles de ca-
lidad sobre el software desarrollado. El principal inconveniente es la depen-
dencia de los proveedores del software, al no poder disponer el cliente del có-
digo fuente.
6.1.2. ERP software libre
El significado de software libre o de fuente abierta (free software u open

source software) hace referencia a una serie de libertades que disfrutan los
usuarios de este tipo de software: libertad para ejecutar los programas
con cualquier propósito, en cualquier lugar y para siempre, libertad de
estudiar el funcionamiento de los programas (exige el acceso al código
fuente), libertad para redistribuir el programa y libertad para mejorar
los programas y distribuir versiones mejoradas.
(7)
Diferentes proyectos de gran magnitud de software libre7 son desarrollados Software libre no es lo mismo
que software gratuito.
por grandes compañías, que además de trabajar para mejorar constantemente
el código le dan garantía de continuidad. La diferencia de estas empresas con
las de software propietario más "tradicional" es su filosofía abierta y su modelo
de negocio orientado al servicio y no a la venta de licencias.
Generalmente, el software libre es gratuito porque no tiene costes de licencias

de uso (aunque las cuatro libertades mencionadas más arriba no prohíben co-
brar por licencias). La empresa cliente adquiere de forma gratuita los módulos
que necesita. Si el cliente dispone de recursos propios, el coste económico de
realizar la implementación y dar la formación a su personal es nulo. Si el clien-
te no dispone de recursos, entonces las empresas desarrolladoras de sistemas
de software libre disponen de una comunidad de socios que ofrecen servicios
de implantación, configuración y formación de usuarios para sus aplicaciones.

Asimismo, ofrecen cursos de formación para los nuevos socios o clientes que
desean implantar la solución de forma independiente.
Usando sistemas de código abierto no se está unido a la empresa desarrollado-

ra, pues al disponer del código fuente se puede escoger otra empresa que dé
el soporte técnico del sistema.
La principal ventaja de una implantación de ERP de software libre es la reduc-

ción de costes con respecto a las licencias de uso (aunque hay estudios que
avalan que este solo representa una parte del coste total de propiedad de un
programa, que incluye, entre otros, los costes de la implantación y de la for-
mación). El principal inconveniente es que muchos proyectos de software li-
bre no ofrecen todas las funcionalidades que propone el software propietario,
dado que están sin acabar.
Los principales sistemas ERP de software libre son Openbravo, OpenERP y

Adempiere.
6.2. Los principales proveedores de ERP propietario
Actualmente, los principales vendedores de ERP son: SAP, Oracle y Microsoft.
Aunque existen algunas diferencias en las estrategias de marketing y los pro-

ductos de estos vendedores, tienen algunas características comunes: una base
de datos relacional, una arquitectura cliente/servidor y varios módulos fun-
cionales.
Figura 11. Proveedores productos ERP para la pequeña y mediana empresa
Fuente: Gartner (2010). Cuadrante mágico ERP SME
6.2.1. SAP
(8)
SAP8 es un producto desarrollado y comercializado por la empresa alemana Systeme, Anwendungen und Pro-
dukte: sistemas, aplicaciones y pro-
SAP AG, fundada en 1972 por desarrolladores de aplicaciones de IBM. En sus ductos
orígenes, SAP AG desarrollaba aplicaciones para el mercado europeo. En las
últimas décadas se ha expandido lentamente y opera en todo el mundo, con-
virtiéndose en la empresa líder de los proveedores de sistema ERP.
En 1973 creó SAP R/1, formado para el sistema financiero y de gestión de ma-
teriales. En 1979 aparece SAP R/2 como la evolución de la anterior, añadiendo
una base de datos centralizada. En 1992, nace SAP R/3, con la incorporación
de la arquitectura cliente/servidor; eso supuso ser la líder del mercado a esca-
la mundial. En 1996, SAP R/3 se adapta a Internet, añade aplicaciones com-
plementarias, CRM y SCM, y empieza a desarrollar las soluciones sectoriales
específicas. En 1999 presenta mySAP, el sistema continúa evolucionado y me-
jorando, diversificándose en el mercado al ofrecer nuevos productos según el
tamaño de la empresa o el sector al que pertenece. En el 2002 presenta SAP
Business One.
En el 2004 comercializa SAP NetWeaber, que convierte cualquier programa

SAP en un programa Web-enabled, lo cual significa que se puede trabajar con
él mediante la web.
En el 2007, su principal producto, SAP R/3, pasa a llamarse SAP ERP. El sistema
usa la arquitectura cliente/servidor aplicada a varios niveles, permitiendo el
control de los módulos de interacción entre distintos clientes y servidores en
tiempo real. Está basado en la arquitectura en tres capas: base de datos, servi-
dor de aplicaciones y cliente. Se comercializan los sistemas: SAP Business Sui-
te, para grandes empresas; SAP Business All in One, Business One y Business
ByDesign, para pymes; y MySAP, para soluciones sectoriales.
SAP es el primer proveedor de software empresarial en el mundo.
6.2.2. Oracle
Esta empresa estadounidense fue fundada en 1977 por Larry Ellison para desa-
rrollar bases de datos y sistemas gestores. En 1983, se cambia el nombre de
la empresa por Oracle Corporation. Las bases de datos y los gestores creados
por Oracle evolucionan y obtienen un gran éxito. El ERP de Oracle, conoci-
do como Oracle Applications, proporciona aplicaciones para la grande y me-
diana empresa y soluciones específicas para los sectores industriales con las
soluciones sectoriales. Algunos de los productos que ofrece son: Oracle E-Bu-
siness Suite, PeopleSoft Enterprise, Siebel y JDEdwards Enterprise One. Todos
estos productos ofrecen aplicaciones CRM, SCM, e-business y la integración
de aplicaciones vía Internet.
Oracle pretende dominar el software de bases de datos para influenciar sobre

el mercado del ERP. La mayoría de desarrolladores de sistemas ERP usan la base
de datos de Oracle.
Desde el 2005 Oracle ha adquirido una serie de empresas, como PeopleSoft,

Siegel y Retek, para desbancar a SAP de su liderazgo en el mercado mundial.
Oracle es el segundo fabricante internacional de paquetes empresariales des-
pués de SAP.
6.2.3. Microsoft
Empresa norteamericana fundada en 1975 por Bill Gates y Paul Allen.
En el año 2001 creó una nueva línea de negocio, llamada Business, para desa-
rrollar sistemas de información empresarial. Desde el 2002, Microsoft adquie-
re diferentes empresas de vendedores de sistemas ERP como Great Plains, So-
lomon, Navision y Axapta. La combinación de los diferentes productos de las

empresas adquiridas permite a Microsoft crear el Microsoft Business Solutions
que, posteriormente, llamará Microsoft Dynamics.
El objetivo de Microsoft Dynamics es dar apoyo al área financiera, a la pro-

ducción, a la gestión de las relaciones con los clientes (CRM) y a la cadena
de suministros (SCM). Incluye el siguiente software: Microsoft Dynamics AX
(antes, Axapta), Microsoft Dynamics GP (antes, Great Plains), Microsoft Dy-
namics NAV (antes, Navision) y Microsoft Dynamics SL (antes, Solomon).
Actualmente, ofrece soluciones sectoriales y se han añadido aplicaciones CRM

(Microsoft Dynamics CRM).
El objetivo que persigue Microsoft, en el mercado de software ERP, es desbancar

del liderazgo a SAP, fin también perseguido por Oracle.
6.3. Los principales proveedores de ERP de software libre
6.3.1. Openbravo
Es la solución líder en software libre y en entorno web para la pequeña y me-

diana empresa.
Su sistema en entorno web de gestión integral de empresas (ERP) se utiliza

en cerca de cincuenta países. El crecimiento de Openbravo se origina por la
contribución de su comunidad internacional, compuesta de usuarios, partners
y desarrolladores en constante expansión. El modelo de negocio de la compa-
ñía, basado en el software libre comercial, elimina el coste de las licencias y
ofrece apoyo, servicios y mejoras de los productos mediante una suscripción
anual. Un creciente catálogo de soluciones y extensiones para su ERP, tanto
comerciales como gratuitas, se encuentran disponibles en su marketplace en
línea, Openbravo Exchange.
6.3.2. Adempiere
Adempiere es un proyecto guiado por la comunidad, la cual desarrolla y so-

porta una solución de código abierto para negocios del mismo nombre, ofre-
ciendo la funcionalidad de ERP, CRM y SCM.
El proyecto Adempiere fue creado en septiembre del 2006, después de las dife-
rencias que se tuvieron entre Compiere Inc., los desarrolladores de Compiere,
y la comunidad que se formó en torno al proyecto. La comunidad consideró
que Compiere Inc. había puesto especial énfasis en la naturaleza de código
abierto del proyecto en lugar de en la naturaleza comunitaria del proyecto.
Tras una intensa discusión, se decidió bifurcar el código de Compiere y dar
nacimiento al proyecto Adempiere. Al ser un proyecto basado en la comuni-
dad, todos tienen el derecho de emitir su opinión y, de hecho, es algo que se

promueve activamente. El hito del proyecto Adempiere es la creación de una
comunidad que desarrolle y dé apoyo a una solución de código abierto para
las organizaciones.
Las áreas de negocio que cubre el sistema Adempiere son: ERP, SCM, CRM,
finanzas, solución integrada de punto de ventas (TPV-POS) y tienda web in-
tegrada.
6.3.3. OpenERP
Actualmente, Openbravo ERP consta de dos versiones; una, Openbravo Com-

munity Edition (libre y gratuito) con soporte y funciones limitadas y otra,
Openbravo Network Edition (con elementos privativos y comerciales) que re-
quiere la compra de una licencia. El código de la versión libre se publicó en
abril del 2006.
Nace en el año 2000 con el nombre de TinyERP, por obra de Fabien Pinckaers.
En el 2004, esta compañía se posiciona como líder en software de gestión para
las ventas públicas en Bélgica. En el 2005 se crea la red de partners en Francia,
para expandirse más adelante por el resto del mundo.
En el 2008, la empresa pasa a llamarse OpenERP. En el 2009, se introducen

mejoras en el desarrollo colaborativo. Está orientado al uso en las pequeñas y
medianas empresas, aunque disponga de módulos más habituales en la gran
empresa, como gestión de proyectos o estadísticas.
El OpenERP permite trabajar remotamente mediante una interfaz web desde

cualquier equipo conectado a Internet. Está formado por los siguientes módu-
los: gestión de relaciones con el cliente (CRM), gestión de proyectos, gestión
de almacenes, gestión contable y financiera, gestión de compras, gestión de
ventas, recursos humanos, marketing, gestión del conocimiento y fabricación.
También dispone de soluciones verticales por sectores, como la sanidad, hoste-
lería, ingeniería civil, asociaciones, industria alimentaria y centros educativos.
6.4. Las soluciones SAP
6.4.1. SAP Business Suite
(9)
SAP Business Suite ofrece a la empresa la capacidad de realizar procesos esen- www.sap.com, fecha de consul-
ta: 14 de mayo del 2011.
ciales, específicos del sector y de apoyo empresarial con soluciones modulares
diseñadas para funcionar con otro software de SAP9 o de otros proveedores.
Las aplicaciones proporcionan las mejores prácticas sectoriales con aplicacio- Aplicaciones empresariales
nes específicas del sector: preparadas para servicios
Las aplicaciones están basadas

• SAP customer relationship management en una arquitectura abierta y
orientada a servicios (SOA) y
• SAP ERP (planificación de recursos empresariales) en la plataforma tecnológica
SAP NetWeaver.
• SAP product lifecycle management
• SAP supply chain management
• SAP supplier relationship management
Da apoyo a procesos empresariales globales en las áreas siguientes:
1)�Finanzas. Lleva a cabo, de forma eficiente y completa, la contabilidad fi-

nanciera y la gestión de informes, optimizando operaciones financieras y ges-
tionando pagos y cobros. Integra y da soporte a las funciones de gestión de
tesorería y capital.
2)�Fabricación. Coordina la fabricación global con la planificación y la eje-

cución locales. Gracias a la integración con diferentes sistemas de planta, se
obtiene una visibilidad para toda la empresa necesaria para optimizar activos
de fabricación distribuidos, integrar operaciones subcontratadas y fomentar la
fabricación optimizada.
3)�Aprovisionamiento. Optimiza y centraliza los procesos del pedido al co-

bro. Minimiza el riesgo reforzando el uso global de normativas en materia de
contratos y aumentado el ahorro gracias a una mayor visibilidad en las rela-
ciones con el proveedor y en el rendimiento.
4)� Marketing. Proporciona información de todas las interacciones con el

cliente. Esta información permite coordinar las actividades de ventas y mar-
keting, y conseguir retener de forma eficiente a los clientes adecuados para
desarrollar relaciones rentables a largo plazo.
5)�Ventas. Permite usar información relevante para centrar las iniciativas de

ventas en las oportunidades de cliente más rentables. Aumenta la eficacia de
los equipos de ventas, acelera los ciclos de ventas y obtiene un incremento en
los resultados finales con una mejor determinación de precios, una planifica-
ción más precisa de la demanda y con previsiones de ingresos.
6)�Servicio. Da una mejor atención al cliente, controlando de forma más es-

tricta el coste de la prestación de servicios. Permite aumentar la satisfacción
del cliente y su fidelidad resolviendo los problemas de forma rápida.
7)�Recursos�humanos. Gestiona de forma eficaz todos los aspectos del perso-

nal y controla los costes.
8)�Gestión�de�la�cadena�de�suministro. Permite percibir los cambios en el

suministro y las situaciones de la demanda en una red global.
6.4.2. SAP Business One
La aplicación SAP Business One está diseñada específicamente para la�peque-

ña�empresa. Incluye los procesos necesarios para gestionar toda la empresa,
desde ventas y las relaciones con los clientes hasta las finanzas y las operacio-
nes. Puede instalarse rápidamente (el tiempo de implantación habitual es de
dos a ocho semanas).
SAP Business One incluye:
1)�Gestión�financiera: para automatizar, integrar y gestionar todos los proce-

sos financieros y contables.
2)�Gestión�de�almacén�y�producción: para gestionar el inventario en varios

almacenes, hacer un seguimiento de los movimientos de stock y gestionar
las órdenes de fabricación que se basan en la planificación de necesidades de
material.
3)� Gestión� de� relaciones� con� el� cliente: para aumentar la rentabilidad del
cliente y la satisfacción con ventas efectivas, la gestión de oportunidades y el
servicio postventa.
4)�Compras�y�operaciones: para automatizar todo el proceso de aprovisiona-

miento, desde el pedido hasta el pago de la factura de proveedores.
5)�Gestión�de�informes: para actuar en función de la información instantánea

y completa que ofrecen los informes amplios y puntuales.
SAP Business One incluye las siguientes funcionalidades:
Tabla 3. Funcionalidades SAP Business One
Contabilidad • Libro general y captura en el diario

y finanzas • Contabilidad de costes
• Administración de presupuestos y proyectos
• Banca y estados de cuenta
• Procesamiento y reconciliación de pagos
• Estados financieros y reportes
• Impuestos por venta e impuesto al valor añadido
• Soporte de múltiples monedas
Ventas y • Administración de oportunidades y líneas

clientes • Administración de contacto y actividades de clientes y prospectos
• Cotización de ventas y órdenes
• Pronósticos de ventas
• Administración de relaciones con clientes basadas en Web
• Administración de contactos de servicio
• Captura y seguimiento de administración de llamadas de servicio
Compras y • Propuestas de compra

operaciones • Órdenes de compra y entrega
• Recepción y devolución de productos
• Facturas de cuentas para cobrar y notas de crédito
• Facturas de materiales
• Órdenes de producción
• Pronóstico de materiales
Inventario y • Administración y consulta de artículos

distribución • Recibo de stock, liberación de stock y transacciones de stock
• Transferencia de almacén y números de serie
• Reevaluación de inventario
• Catálogo de clientes y vendedores
• Lista de precios y precios especiales
• Recolectar y empaquetar
Reportes y ad- • Reportes basados el Microsoft Office Excel

ministración • Migración de datos, campos definidos para el usuario, interfaz de pro-
gramas de aplicación y SAP
• Business One Software Development Kit
• Contabilidad de nómina
• Directorio y administración de empleados y tiempo de los empleados
6.4.3. SAP Business All-in-One
Las soluciones SAP Business All-in-One están desarrolladas, específicamente,

para las empresas medianas que buscan soluciones sectoriales completas e in-
tegradas. Gestiona todos los aspectos, desde las finanzas, los recursos huma-
nos, el aprovisionamiento, el inventario, la fabricación, la logística, el desa-
rrollo de productos y los servicios corporativos, hasta la atención al cliente,
las ventas y el marketing.
La funcionalidad integrada de ERP y CRM permite optimizar y completar un

proceso de manera integral.
Ejemplo
Puede utilizar la funcionalidad CRM para crear una oportunidad y convertirla directa-
mente en una oferta y, a continuación, utilizar la funcionalidad ERP para convertirla en
un pedido de cliente completo, con producto, precio, factura y entrega.
SAP Business All-in-One ayuda a gestionar los procesos más importantes en

una solución integrada, proporcionando:
• Planificación�de�recursos�empresariales�(ERP): gestiona de manera eficaz

las finanzas, la contabilidad, los recursos humanos, las operaciones y los
servicios corporativos.
• Gestión� de� las� relaciones� con� los� clientes� (CRM): gestiona de manera
eficaz todos los aspectos de las relaciones con los clientes, desde el marke-
ting hasta las ventas y los servicios.
• Business�intelligence�(BI): obtiene información y mejorar la toma de de-

cisiones con herramientas para la generación de informes y análisis finan-
cieros y operativos.
• Mejores�prácticas: proporciona métodos probados para implantar las me-

jores prácticas en áreas y sectores funcionales clave.
• Funcionalidades�específicas�del�sector: solución adaptada al sector.
• Plataforma�tecnológica�SAP�NetWeaver: ampliación de la solución exis-

tente de manera rápida y rentable a medida que la empresa crece y las ne-
cesidades cambian.
El SAP Business All-in-One incluye:
1)�Contabilidad�y�finanzas: administra el libro general, los diarios, los presu-

puestos y las cuentas para cobrar y pagar.
2)�Administración�de�ventas�y�las�relaciones�con�los�clientes: administra
los contactos con los clientes para todos los empleados de la organización.
3)�Compras�y�operaciones: controla todo el proceso de compra y prevé todas

las operaciones para tener la producción al día.
4)�Inventario�y�distribución: administra las órdenes de ventas, controla el

inventario y las operaciones de almacén.
5)�Reportes�y�administración: proporciona los principales reportes que ayu-

dan a monitorizar el negocio.
6.5. Las soluciones OpenBravo
6.5.1. Openbravo 3
(10)
Openbravo 310 es la solución ERP líder mundial en software libre y entorno www.openbravo.com, fecha de
consulta: 14 de mayo del 2011.
web. Permite a las organizaciones de diferentes sectores económicos, como
distribución, minoristas, fabricación, servicios, ONG y Administración públi-
ca de todo el mundo, mejorar su rendimiento empresarial mediante una ma-
yor productividad y agilidad en el negocio. El ERP puede implantarse en tan
solo dos semanas en las pequeñas y medianas empresas, e ir incorporando
progresivamente más funcionalidades a medida que las necesidades del nego-
cio evolucionen.
Openbravo 3 ofrece una amplia cobertura funcional en todas las áreas princi-
pales de un sistema de gestión completo del negocio, como contabilidad, ven-
tas, aprovisionamiento, inventario, producción, gestión de proyectos y servi-
cios, incluyendo la integración con herramientas de BI y con la gestión de
punto de venta (TPV).
Openbravo 3 incluye las siguientes funcionalidades:
1)�Gestión�de�datos�maestros. Centralización de los datos en un único repo-

sitorio compartido. Se encarga de la correcta gestión de los datos maestros del
negocio, como pueden ser productos, clientes y proveedores, para garantizar
la coherencia y trazabilidad de los procesos.
2)�Gestión�del�aprovisionamiento. Permite tener el control de la cadena de

suministro garantizando la integración, el seguimiento y la coherencia del pro-
ceso. Minimiza los gastos de adquisición y maximiza la colaboración con ter-
ceros. Totalmente integrado con la gestión financiera y de almacén.
3)�Gestión�de�almacenes. Optimiza el inventario. Permite que las existencias

estén siempre al día y correctamente valoradas. Las capacidades para gestionar
los lotes de mercancías y la posibilidad de usar número de serie aseguran el
cumplimiento de los requisitos de trazabilidad impuestos en la mayoría de
industrias.
4)� Gestión� de� proyectos� y� servicios. Orientado a empresas cuya actividad

se basa en la entrega de proyectos o servicios. Permite gestionar, de manera
integrada con el resto de la aplicación, el presupuesto, las fases, los costes y
las compras asociados a cada proyecto individual. El componente de servicios
permite la definición de servicios y recursos y el control de todas las activida-
des, facturables o no, realizadas para un cliente externo o interno, así como
el monitoreo detallado de los gastos.
5)�Gestión�de�la�producción. Las funciones de producción y gestión de planta

permiten modelar la estructura productiva de cada organización (secciones,
centros de coste, máquinas y utillajes), así como de los datos relevantes para
la producción: planes de producción (secuencias de operaciones) y productos
involucrados en las mismas. La funcionalidad se orienta a cubrir las necesida-
des habituales de los entornos de producción discreta: planificación de la pro-
ducción y de los aprovisionamientos relacionados mediante MRP, creación de
órdenes de fabricación, partes de trabajo (notificación de tiempo y consumos),
cálculo de los costes de producción, notificación de incidencias de trabajo y
partes de mantenimiento.
6)�Gestión�comercial�y�CRM. La funcionalidad del área de gestión comercial

está expresamente diseñada con el objetivo de permitir la máxima flexibili-
dad y agilidad en la ejecución, aspectos determinantes en cualquier proceso
comercial. Es posible encadenar los documentos (pedido, albarán, factura) en

cualquier orden que la empresa precise, o incluso prescindir de alguno de ellos
si no es necesario.
7)�Gestión�financiera�y�contabilidad. Controla las finanzas a lo largo de todo

el ciclo de negocio. El área financiera actúa como acumulador de todos los
hechos relevantes que se van generando desde el resto de áreas de gestión.
8)�Business�intelligence. Las organizaciones empresariales manejan un gran

volumen de datos de la práctica de sus actividades empresariales. Eso no sig-
nifica necesariamente que dispongan de información útil para la gestión de
su negocio. El componente de business intelligence está integrado en el propio
sistema de gestión, y ayuda a realizar un seguimiento del estado del negocio,
proporcionando la información relevante para la toma de decisiones. Los cua-
dros de mandos predefinidos permiten verificar, mediante la monitorización
de una serie de indicadores clave, si la estrategia definida está siendo correc-
tamente implantada en la organización.
6.5.2. Openbravo POS
Openbravo POS (point of sale, 'punto de venta´) está integrado de forma com-
pleta y transparente con el Openbravo 3; puede ser utilizado de forma inde-
pendiente o con él en función de las necesidades del usuario. Garantiza el flu-
jo de información entre el punto de venta y el back-office, proporcionando a
las pequeñas y medianas empresas del sector Retail una solución de gestión
totalmente integrada, asequible y fácil de usar, a la vez que ágil y basada en
estándares.
Openbravo POS ofrece toda la gama de�funcionalidades�que�el�sector�mi-

norista�demanda: ventas, reembolsos, informes diarios, gestión de efectivo,
gestión de almacenes, etc.
1)�Gestión�de�datos�maestros: productos, categorías y subcategorías, imáge-

nes, impuestos, almacenes, áreas de restaurante y disposición de las mesas,
usuarios y roles, etc.
2)�Gestión�de�ventas,�reembolsos�y�efectivo: edición de recibos, búsqueda de

productos, gestión de impuestos, códigos de barras, descuentos, promociones,
pagos, etc.
3)�Gestión�de�almacenes: propiedades de productos, movimientos de produc-

tos, recuento de inventario, recibos de productos, etc.
4)�Informes�y�gráficos: elaboración de informes, filtrado, gráficos, etc.

5)�Módulo�para�restaurantes: gestión de reservas, áreas de restaurante perso-

nalizables, ocupación, etc.
Resumen
Los sistemas ERP han sido adoptados por muchos negocios en la última déca-
da. Estos sistemas han revolucionado la forma de hacer negocio mediante la
integración de los procesos de negocio, compartiendo los datos comunes y las
prácticas en toda la empresa, produciendo y accediendo a la información en
entornos de tiempo real.
Como resultado, los sistemas ERP han dado lugar a la mejora de la capacidad
de la toma de decisiones, lo cual se manifiesta en amplios indicadores, como
la disminución de inventarios o la aceleración del proceso de cierre financiero.
Las organizaciones se han dado cuenta de los importantes beneficios, tangibles

e intangibles, derivados de todo ello, como la reducción de los gastos generales
y administrativos, la mejora de márgenes, el crecimiento de los ingresos y el
aumento de la satisfacción de los clientes. Sin embargo, a pesar de estos bene-
ficios, muchas empresas han tenido serios problemas de implementación del
sistema ERP. Dichos problemas han hecho que muchas organizaciones aban-
donaran la iniciativa o implementaran el sistema con una capacidad reducida.
Las empresas han errado en la implantación del ERP cuando lo han visto co-
mo una forma mágica para ser competitivas y no como una herramienta que
depende de la forma en que se utilice. En efecto, la herramienta puede ayu-
dar a la empresa a ser más competitiva, pero también puede hacerla salir del
negocio. Es importante que todos los directivos y el personal de la empresa
sepan obtener el máximo rendimiento de un sistema ERP. No se tiene que ol-
vidar que la capacidad para obtener prestaciones máximas de un ERP depen-
derá siempre de los usuarios y no del propio ERP o del consultor externo que
ayude en su implantación.
La evolución del ERP está ligada a la innovación en las TIC y a las necesidades
de las empresas. Actualmente, los vendedores ofrecen mejoras en sus funcio-
nalidades y productos dirigidos al e-commerce, al back-office, en diseñar pro-
ductos para la pequeña y mediana empresa. El líder del mercado de ventas es
SAP; las empresas se asocian para innovar en nuevos productos para desban-
carla de su posición en el mercado. Otros proveedores de ERP se especializan
en las soluciones sectoriales, en productos para la pequeña y mediana empresa
o en la administración de la relación con el cliente (CRM).
Actividades
1. Definid con vuestras palabras qué es un sistema ERP (hemos visto diferentes definiciones
formales). Ahora, haced vuestra propia definición de un sistema ERP.
2. En la crisis económica y financiera actual, ¿creéis que las empresas invertirán en la adquisi-
ción o ampliación de sistemas ERP? ¿Cómo prevéis la evolución en estos próximos diez años?
3. En España, ¿en qué fase del ciclo de vida creéis que están los proyectos ERP?: ¿las empre-
sas están invirtiendo en adoptar, mejorar y mantener estos proyectos o no harán nada y lo
dejarán morir, haciendo aumentar los fracasos en las implantaciones ERP?
Glosario
arquitectura cliente/servidor f Es una configuración descentralizada basada en un ser-
vidor que ofrece servicios a un conjunto de clientes. La comunicación entre los clientes y el
servidor se realiza por red o por Internet. Este tipo de tecnología permite separar las tareas
de usuario de las lógicas de la aplicación y las de gestión de datos.
back-office m Es la parte de las empresas en la que tienen lugar las tareas destinadas a
gestionar la propia empresa y con las que el cliente no necesita contacto directo. El término
se construye a partir del concepto de que la oficina visible es el departamento de ventas y
clientes y en la trastienda es donde se fabrica, diseña y gestiona la actividad.
comercio electrónico (e-commerce) m Es la compra y venta de productos o de servicios

por Internet, usando como forma de pago medios electrónicos, tales como las tarjetas de
crédito.
comercio móvil (m-commerce) m Toma sus bases del comercio electrónico; las transac-
ciones son ejecutadas desde un móvil o dispositivo sin hilo móvil.
CRM f Herramienta de gestión de las relaciones con los clientes.
e-business m Transformación de los procesos de negocio mediante el uso de Internet.
ERP (enterprise resource planning) f Sistema de gestión de la información que se basa

en una solución completa que permite a las empresas gestionar su negocio.
front-office m Se refiere a los departamentos de una empresa que entran en contacto con
los clientes, incluyendo la comercialización, las ventas y los departamentos de servicio.
MRP f Material resource planning (planificación de pedidos de material).

Bibliografía
Libros
Davenport, T. H. (2000). Mission Critical: Realizing the Promise of Enterprise System. Harvard
Business Press.
Laudon, K. C.; Laudon, J. P. (2006). Management Information Systems: Managing the digital
firm. Pearson Prentice Hall.
Leon, A. (2007). Enterprise Resource Planning Systems. Tata McGraw-Hill Publishing Company
Limited.
Monk, E. F.; Wagner, B. J. (2008). Concepts in Enterprise Resource Planning Systems. Course
Cengage Learning.
Muñiz, L. (2004). ERP, Guía práctica para la selección e implantación. Edición Gestión 2000.
O'Leary, D. E. (2000). Enterprise Resource Planning Systems: Systems, Life Cycle, Electronic Com-
merce, and Risk. Cambridge University Press.
Olson, D. L.; Kesharwani, S. (2009). Enterprise Information Systems: Contemporary Trend

and Issues. World Scientific.
Sieber, S.; Valor, J.; Porta, V. (2006). Los sistemas de información en la empresa actual:
aspectos estratégicos y alternativas tácticas. McGraw-Hill.
Artículos
Beatty, C. B.; Williams, C. (2006). "ERP II: Best practices for successfully implementing
an ERP upgrade". Commun. ACM (vol. 49, núm. 3, pág. 105-109).
Esteves, J.; Pastor, J. A. (1999). "An ERP life-cycle-based research agenda". 1° International
Workshop on Enterprise Management Resource and Planning Systems (pág. 359-371). Venecia.
McGaughey, R. E.; Gunasekaran, A. (2007). "Enterprise resource Planning (ERP): Past,

Present and future". International Journal of Enterprise Information Systems(vol. 3, núm. 3, pág.
23-35).
Pairat, R.; Jungthirapanich, C. (2005). "A chronological review of ERP research: an

analysis of ERP inception, evolution, and direction". Engineering Management Conference,
2005. Proceedings. 2005 IEEE International (pág. 288-292).
Rashid, M. A.; Hossain, L.; Patrick, J. D. (2002). "The Evolution of ERP Systems: A His-
torical Perspective". Enterprise Resource Planning: Global opportunities. Idea Group Publishing.
Enlaces
Adempiere: www.adempiere.com
Microsoft: www.microsoft.com/dynamics
Openbravo: www.openbravo.com
Open ERP: www.openerp.com
Oracle: www.oracle.com
SAP: www.sap.com
Sistemas de
cooperación
empresarial
Humi Guill Fuster
PID_00174746
CC-BY-NC-ND • PID_00174746 Sistemas de cooperación empresarial
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. Gestión empresarial de proyectos (EPM)..................................... 7

1.1. Introducción ................................................................................ 7
1.2. Definición EPM ........................................................................... 8
1.3. Ciclo de vida de la gestión de proyectos .................................... 10
1.3.1. Establecer los criterios básicos del sistema EPM:
configuración general .................................................... 11
1.3.2. Creación y estimación de un proyecto ......................... 12
1.3.3. Planificación del proyecto ............................................. 13
1.3.4. Fase de evolución transaccional del proyecto ............... 14
1.3.5. Seguimiento del proyecto y de la cartera de
proyectos ........................................................................ 15
1.3.6. Optimización de la cartera de proyectos y análisis ........ 16
1.4. Relación del EPM con otros procesos ......................................... 16
2. Gestión de la cadena de suministro (SCM).................................. 18

2.1. Introducción ................................................................................ 18
2.1.1. La cadena de suministro ............................................... 19
2.2. Evolución de la gestión de la cadena de suministro ................... 20
2.3. Definición .................................................................................... 21
2.4. Características de una solución software SCM frente a una
solución ERP ................................................................................ 22
2.5. Características de una solución SCM .......................................... 23
2.6. Tendencias de futuro del SCM y ERP ......................................... 25
3. Gestión de la relación con el cliente (CRM)................................ 27

3.1. Introducción ................................................................................ 27
3.2. Definición .................................................................................... 28
3.3. Características de una solución CRM ......................................... 29
3.3.1. CRM operacional ........................................................... 29
3.3.2. CRM analítico ................................................................ 31
3.4. Proveedores de sistemas CRM ..................................................... 31
3.5. Implantación del CRM ............................................................... 32
4. Negocio electrónico (e-business)..................................................... 34

4.1. Introducción ................................................................................ 34
4.2. Conceptos e-business..................................................................... 34
5. Inteligencia del negocio (BI).......................................................... 36

5.1. Introducción ................................................................................ 36
5.2. Definición .................................................................................... 36
5.3. Elementos y características de una solución software BI ............ 37
5.4. Proveedores de sistemas de BI .................................................... 40
6. Gestión del conocimiento (KM)...................................................... 41

6.1. Introducción ................................................................................ 41
6.2. Definición .................................................................................... 41
6.3. Características de una solución KM ............................................ 41
6.4. Divergencia BI-KM ...................................................................... 43
7. Gestión documental.......................................................................... 44
7.1. Introducción ................................................................................ 44
7.2. Definición .................................................................................... 45
7.3. Características de una solución de gestión documental ............. 45
Resumen....................................................................................................... 47
Actividades.................................................................................................. 51
Glosario........................................................................................................ 52
Bibliografía................................................................................................. 53
CC-BY-NC-ND • PID_00174746 5 Sistemas de cooperación empresarial
Introducción
Este módulo didáctico tiene como objetivo estudiar otros sistemas avanzados
de información empresarial que han ido transformando y ampliando el núcleo
de los sistemas ERP hacia lo que algunos autores, e incluso los fabricantes, de-
nominaron ERP-II, término acuñado por la consultora Gartner�Group (2001,
febrero). "Taking the pulse of ERP". Modern Material Handling (pág. 44-51).
El núcleo del sistema ERP tradicional se complementa con soluciones de gran

nivel de especialización, tales como la gestión de la cadena de suministro
(SCM), la gestión de las relaciones con los clientes (CRM), la gestión empresa-
rial de proyectos (EPM) y, además, otros sistemas de valor añadido que perfec-
cionan la solución de negocio, tales como business intelligence (BI), gestión del
conocimiento (KM), e-business, gestión documental... El valor añadido para la
empresa de esta integración�tecnológica�y�gestión�colaborativa interorgani-
zacional incluye otras ventajas adicionales a las propias del ERP: se destaca el
incremento de la transparencia de la información, la optimización de recursos,
la automatización de los procesos operativos, la agilidad del proceso de toma
de decisiones y la reducción de los tiempos de respuesta.
Los sistemas que abordaremos en este módulo añaden, a los tradicionales siste-
mas ERP, optimización�interna y externa mediante un modelo colaborativo.
Las empresas, ejerciendo nuevas actitudes de supervivencia y adaptación ante

fenómenos como la globalización, la nueva economía y los negocios electró-
nicos, buscan la integración de sus departamentos y la integración entre em-
presas. Estos otros�sistemas que vamos a tratar en el módulo identifican una
tendencia de la transformación empresarial que, partiendo de la orientación
vertical de la empresa resuelta desde sistemas ERP tradicionales, optimiza las
funciones internas y externas de tal forma que la solución resultante incluye
funcionalidades interempresariales.
Por tanto, procede analizar y estudiar el conjunto de conceptos y caracterís-

ticas básicas de otros sistemas de información empresarial, todo ello después
de que el estudiante haya obtenido un conocimiento previo adecuado de los
sistemas ERP, sus funcionalidades y el marco de aplicación.
Trabajaremos con mayor profundidad los sistemas EPM, CRM y SCM y, a con-
tinuación, revisaremos en líneas generales el resto de sistemas que los pueden
complementar: e-business, BI, KM, gestión documental.
Objetivos
La finalidad de este módulo didáctico es dar a conocer el significado de los

conceptos sobre los que se han construido los sistemas de información em-
presarial avanzados SCM, EPM, CRM, y los sistemas BI, KM, e-business, gestión
documental que complementan las funciones de los primeros, y entender qué
es lo que resuelve cada uno de estos productos software y cómo pueden inter-
actuar entre ellos.
En las explicaciones se abordan los conceptos base de gestión de empresas

sobre los que ha partido el desarrollo de estas soluciones tecnológicas, y se
avanza hacia el estado actual de la tecnología ligada a los conceptos tratados.
En definitiva, al finalizar el estudio de este módulo, tenéis que:
1. Conocer las razones que han impulsado el desarrollo de los sistemas tra-
tados en el módulo.
2. Conocer las características de los distintos sistemas y su ámbito de aplica-

ción.
3. Obtener conclusiones sobre la aplicación de los sistemas tratados en los

entornos empresariales.
4. Identificar los factores críticos de éxito según el modelo de negocio que

cubren las soluciones tecnológicas que una empresa se plantee implantar.
1. Gestión empresarial de proyectos (EPM)
1.1. Introducción
En cualquier unidad funcional de una empresa surge la necesidad de gestio-

nar�proyectos; en toda organización van naciendo y terminando proyectos,
aunque no siempre las organizaciones los consideran como tales o los admi-
nistran como si lo fueran.
Por otro lado, dependiendo del objeto de negocio de la empresa, los propios
servicios y productos que se ofrecen a sus clientes necesitan ser estructurados
como proyectos.
La gestión�del�proyecto implica la coordinación de un conjunto de ac-

tividades, dentro de la organización, que permite obtener un conjunto
de productos y/o de prestaciones de servicios en unos plazos y condi-
ciones determinadas, utilizando los diferentes recursos internos de la
empresa.
La gestión del proyecto también supone la fabricación y entrega de los pro-

ductos físicos durante el transcurso del proyecto. Todo ello lleva a que la or-
ganización proporcione a sus clientes determinadas soluciones globales en un
contexto determinado.
Los métodos clásicos de gestión de proyectos han evolucionado desde la ges-

tión de flujos continuos hasta la gestión de proyectos con cambios disconti-
nuos, donde es necesario adaptar rápidamente todos los aspectos de la explo-
tación para mantener o desarrollar la competitividad.
(1)
EPM son las siglas de enterprise
1
El concepto EPM , como lo han llamado algunos fabricantes de softwa- project management.
re (de forma genérica se le conoce como solución de gestión empresarial

de proyectos), supone una estrategia de negocio para la empresa que lo
implanta; con ello se unifican los procesos, la organización y la tecnolo-
gía con el objeto de proporcionar una mejora en la gestión de la propia
compañía, centrándose en la gestión de proyectos desde la perspectiva
integral de la empresa.
La solución EPM concibe cada proyecto con los elementos básicos de la admi- Confusión con siglas EPM
nistración: control, recursos, presupuesto, organización de informes, etc.
Algunos fabricantes de softwa-
re utilizan EPM para la iden-
1.2. Definición EPM tificación de otros conceptos
muy diferentes al que estudia-
mos en este apartado; es im-
portante no confundir el con-
EPM es una solución�o�herramienta�de�gestión�de�proyectos. cepto EPM que nos ocupa, la
administración en gestión de
proyectos, con la gestión del
rendimiento empresarial (EPM,
enterprise performance manage-
EPM es un sistema de información de apoyo a la gestión de operaciones ment), utilizado por Oracle.
de envergadura y complejidad, de carácter no repetitivo y necesario para
acometer una obra de importancia en el contexto empresarial, sistema-
tizando las técnicas de gestión y las formas de organización adecuadas
para resolver operaciones complejas, que implican a varios conjuntos
de personas, máquinas, mercaderías, etc.
En esta definición, cabe destacar los siguientes aspectos:
1) Administra de forma inteligente el ciclo de vida completo de la inversión

y el proyecto, desde las decisiones estratégicas hasta la administración del tra-
bajo.
2) Incorpora una solución de gestión empresarial de proyectos, que es una

estrategia de negocio en sí misma.
3) Implica un proceso de transformación que supone cambios en los procesos,

la organización y la tecnología.
4) Mejora la gestión de proyectos internos y externos.
5) Toda la información que se gestiona mediante la herramienta es un activo

estratégico para la compañía; se crea una base sobre la que redefinir continua-
mente formas de mejorar la dirección y gestión de nuevos proyectos.
6) Proporciona un progreso sustancial en el nivel de calidad de los proyectos

y consigue los objetivos de resultado, coste y plazo de operación.
A partir de la solución informática de gestión de proyectos, podemos imple- Ejemplo

mentar proyectos de diferentes tipos atendiendo a la naturaleza del cambio
Una herramienta potente de-
que producen. bería permitir abordar proyec-
tos de construcción, investiga-
ción, ingeniería, informática,
En una organización, trabajarán contra la solución EPM distintos departamen- organización, desarrollo, co-
mercialización, servicios profe-
tos o áreas de la organización. En líneas generales, intervendrán: sionales, etc.
1)�Área�financiera (controler, administrativo y gestor de tesorería). Las gestio-

nes que realizará desde la solución son:
a) Gestión de clientes y proveedores

c) Gestión de impuestos
d) Contabilización
e) Reporting
2)�Gestores�operativos�del�proyecto (jefes de proyecto y miembros de equipo)

trabajando distintos aspectos:
a) Plan de proyecto, ejecución y monitorización: alcance, tiempo, coste y ries-

go
b) Relaciones entre los interesados
c) Realización de tareas
d) Documentación del proyecto
3)�Área�de�dirección�de�la�empresa (ejecutivos, responsables de área, director

técnico), donde se trabaja en la solución de aspectos como:
a) Gestión gerencial de la cartera

b) Apoyo a la toma de decisiones sobre la inversión en proyectos
c) Estrategia
d) Verificación de conformidad sobre la metodología, procedimientos inter-
nos...
4)�Área�comercial. El equipo comercial utilizará la herramienta para agilizar

la definición de proyectos durante el proceso de venta y permitir la realización
de un presupuesto acertado.
5)�Administradores�de�las�aplicaciones. La solución requiere tareas de admi-

nistración y mantenimiento similares a otras aplicaciones.
En la siguiente figura se representan las distintas áreas de la organización que

interactúan con el sistema EPM.
Figura 1. Áreas de la organización que interactúan con el EPM
1.3. Ciclo de vida de la gestión de proyectos
(2)
Para la gestión de proyectos se requiere adoptar una metodología de trabajo, IEEE Std 1490-2003 y también
como Norma ANSI.
dependiendo del sector al que pertenece la empresa. Por lo general, se tiende a
asumir la metodología desarrollada por el Project Manager Institute (PMI), que
PMBOK
se encuentra recopilada en la guía denominada PMBOK (A Guide to the Project
Management Body of Knowledge, actualizada cada cuatro años). Es un estándar Las empresas tienden a adap-
2 tar la metodología PMBOK u
reconocido internacionalmente que proporciona los fundamentos de la ges- otras específicas para gestionar
sus proyectos.
tión de proyectos que son aplicables a un amplio tipo de proyectos, incluyen-
do construcción, software, ingeniería, finanzas, administración y marketing.
Independientemente de la metodología que asuma la organización y que mar-

cará el modelo de operación, las soluciones EPM se pueden descomponer para
su análisis en distintos fragmentos de acuerdo al ciclo de vida del proyecto.
Podemos asociar dichos fragmentos de la solución a fases bien diferenciadas
del ciclo de un proyecto. En la figura siguiente representamos las fases y, a
continuación, se detallan las funcionalidades relacionadas con las cinco fases
genéricas.
Figura 2. Fases del ciclo de vida del EPM
El ciclo�de�vida�del�EPM se descompone en las siguientes fases:
• configuración general,
• creación y estimación de un proyecto,
• planificación del proyecto,
• evolución transaccional y
• seguimiento del proyecto de la cartera de proyectos.
1.3.1. Establecer los criterios básicos del sistema EPM:

configuración general
Cualquier solución software de gestión de proyectos requerirá la identi-

ficación inicial sobre el sistema de toda la información relativa al con-
junto de proyectos a gestionar en la empresa.
Para ello, el sistema proporcionará una estructura de formularios y un modelo

interno de datos para:
1) Identificar los aspectos generales en la gestión de proyectos de la empresa.
2) Establecer los calendarios genéricos que nos permitirán hacer las planifica-
ciones.
(3)
3) Identificar los recursos disponibles3 en la organización. Asociación de porcentajes de efi-
ciencia.
(4)
4) Identificar en el sistema los valores de coste4 de los servicios que realiza la Esta identificación podrá ser cal-
culada por el propio sistema a par-
empresa y los costes de los materiales utilizados. tir de los datos generados desde
otros módulos de la aplicación:
gestión de inventario, gestión de
5) Identificar los proyectos plantilla que puedan aportar agilidad en el mo- producción, gestión de recursos
humanos: nóminas.
mento de generación de proyectos concretos de ejecución.
6) Identificar los criterios de clasificación de los proyectos en la empresa.
1.3.2. Creación y estimación de un proyecto
Una vez tenemos el sistema configurado para permitir el uso de la so-

lución de forma apropiada, y según los requerimientos de la empresa,
será posible iniciar el uso del sistema. Para ello, dentro del ámbito de un
proyecto concreto, se inicia el ciclo de vida del proyecto identificando
los datos generales de cada uno de ellos.
Se detalla ahora la información necesaria para realizar la estimación del pro-

yecto:
1)�Presupuesto�del�proyecto
Realización de cálculos de importes según los conceptos a ofertar.
2)�Identificación�del�tipo�de�proyecto�atendiendo�a�sus�objetivos
Podría ser un proyecto externo o interno: inversión, coste, tiempo... En el caso
de un proyecto externo, existe una relación con un cliente que es la razón para
la que se ejecuta el proyecto, es decir, se trata de una operación comercial.
3)�Identificación�de�los�principios�contables�y�financieros�del�proyecto Proyectos internos

Una solución de gestión de proyectos va a permitir la gestión tanto de proyec-
Para proyectos internos, exis-
tos internos como externos. La lógica de negocio en uno u otro caso es dife- te la posibilidad de considerar
rente, y su reflejo sobre la contabilidad de la compañía puede representarse que los costes del proyecto se
reflejen en cuentas de pérdidas
de distintas formas según los criterios contables que se apliquen. La empresa y ganancias directamente o en
cuentas de saldo, con posterior
decide cómo y cuándo se consideran los costes en la cuenta de resultados. transferencia a las cuentas de
pérdidas y ganancias.
4)�El�tipo�de�proyecto
Atendiendo a las características de las condiciones de entrega de servicios y su

facturación. Por ejemplo, un proyecto podría responder a un contrato donde
los precios de venta están cerrados antes de iniciar el proyecto y comprome-
tidos de antemano, o por el contrario, el proyecto se factura al cliente según
evolucione el consumo de servicios y bienes durante su ejecución.
5)�Estimaciones�de�costes,�recursos�y�beneficios
6)�Evaluación�del�impacto�estratégico
7)�Evaluación�de�riesgos
8)�Identificación�de�las�condiciones�de�contratación�del�cliente�respecto
al�proyecto
Datos sobre la facturación y las condiciones financieras de uno o varios pro-

yectos que se administran conjuntamente.
9)�Identificación�de�los�datos�particulares�del�proyecto
a)� Subproyectos: las soluciones aportan una estructura jerárquica de repre-

sentación de proyectos, de forma que es posible organizar un proyecto en sub-
proyectos según proceda, permitiendo disponer de tantos niveles como sea
necesario, asegurando una gestión organizada del proyecto, según los elemen-
tos que requieran operaciones independientes, pero relacionadas a efectos de
análisis. La estructura jerárquica también será la base para realizar el análisis,
de forma que todos aquellos aspectos que requieran un análisis conjunto ha-
brán sido agrupados en subproyectos convenientemente.
b)� Actividades: creación de actividades específicas de detalle del proyecto.

Las actividades podrán planificarse en cuanto a horas necesarias, materiales y
gastos, y ejecutarse a posteriori también a partir de dicho desglose. Asimismo,
las actividades permitirán comparar, durante el ciclo de vida del proyecto, los
costes previstos con los costes realizados. La definición de actividades de un
proyecto podrá ser jerárquica, definiendo tantos niveles como sea necesario.
1.3.3. Planificación del proyecto
Una vez el proyecto se ha definido, es decir, se ha trasladado al sistema qué

es aquello que ha de ejecutarse, se sigue con la planificación; de esa forma se
responde a la pregunta ¿cómo�ha�de�realizarse�este�proyecto?
A continuación, se enumeran las acciones que abarca el proceso de planifica-

ción:
1) Programación asistida o manual del proyecto y reserva de capacidad de los

recursos y centros de trabajo según capacidad finita o ilimitada.
• La programación permite identificar la distribución en el tiempo de las

tareas a realizar, así como los recursos que intervienen en cada una de las
tareas.
• La programación puede ser propuesta por el sistema para su posterior acep-
tación.
• Existen distintos criterios de aplicación de la programación automática:
hacia delante o regresivo.
• La programación se apoya sobre herramientas gráficas como representa-

ciones de Gantt.
2) Previsiones de proyectos con objeto de identificar una distribución de re-

cursos eficiente y un control de gastos exhaustivo para conseguir un margen
razonable: tiempos, gastos, productos, facturaciones a cuenta.
3) Simulación financiera.
4) Conversión de previsiones de proyectos a contabilidad presupuestaria.
5) Previsión de cash-flow.
6) Previsión sobre el suministro de materiales de compra (forecasting).
7) Detalle de las actividades: duración, relación entre las actividades, prioridad

de actividades, recursos necesarios.
8) Definición del flujo de trabajo específico en la aprobación de consumos

de tiempos, artículos, gastos, ingresos relacionados..., según corresponda y de-
pendiendo de los responsables del proyecto y sus ejecutores.
1.3.4. Fase de evolución transaccional del proyecto
Una vez se ha establecido en el sistema la información base del proyec-

to, atendiendo al propio ciclo de vida de cada proyecto a resolver, se
ejecutarán las funciones que permitan identificar los aspectos transac-
cionales de los proyectos en los que la compañía esté trabajando.
Seguidamente, se detallan las acciones propias de la introducción de informa-

ción transaccional sobre el proyecto:
1) Imputación de los tiempos consumidos en los proyectos por los distintos

empleados en cada actividad.
• Este proceso, que refleja el trabajo realizado por los empleados, debe poder
realizarse desde entornos web.
• Estas imputaciones de tiempo se extenderán para vincular al proyecto los
precios de coste relacionados y los precios de venta.
2) Reservas de capacidad de ejecución.
3) Imputación de gastos durante la ejecución del proyecto.

4) Consumibles, equipos y materiales entregados al cliente.
5) Replanificaciones de centros de trabajo y recursos. Gráficos de Gantt.
6) Posibles ingresos relacionados con el proyecto.
7) Facturación de anticipos.
8) Facturas a cuenta.
9) Revisiones y ajustes sobre las estimaciones de proyectos en curso para ob-

tener información, en tiempo real, sobre la comparación entre lo previsto y lo
realizado en un punto de tiempo determinado; a su vez, se estimarían costes
futuros.
1.3.5. Seguimiento del proyecto y de la cartera de proyectos
En el transcurso del proyecto, la solución debe proporcionar informa-

ción detallada sobre su evolución para los responsables del mismo, y
también del conjunto de los proyectos en curso para la dirección de la
empresa.
El seguimiento del proyecto puede realizarse de forma paralela a la introduc-

ción de la información transaccional que se refleja en la fase de evolución.
Las fases de evolución y seguimiento se diferencian, fundamentalmen-

te, por:
• Evolución�del�proyecto: supone la generación de información en

el sistema al ritmo de ejecución del proyecto.
• Seguimiento: supone la consulta y explotación, en cualquier mo-

mento, de la información de la ejecución del proyecto; información
trasladada al sistema, en tiempo real según la evolución del proyec-
to.
Las funcionalidades disponibles para el seguimiento son:
1) Consultas sobre las transacciones del proyecto

2) Informes de previsión e ingresos
3) Informes y consultas para el control de la ejecución del proyecto
4) Integración con herramientas de escritorio externas: hojas de cálculo,
OLAP...
5) Pérdidas y ganancias
6) Trabajo en curso (WIP)

7) Asignaciones de nóminas
8) Consumo
9) Ratios de eficiencia de los empleados
1.3.6. Optimización de la cartera de proyectos y análisis
En cualquier momento del ciclo de vida de un proyecto y de la situación

de la cartera global de proyectos, la dirección de la empresa requiere
información global para el análisis y la toma de decisiones.
Algunos de los puntos siguientes se resolverán desde el propio EPM, pero en Ved también
la mayoría de casos son necesarias herramientas tecnológicas avanzadas que
En apartados posteriores del
explotarán la información generada desde el sistema EPM. presente módulo se tratan
también estas soluciones tec-
nológicas complementarias: BI,
1) Evaluación de riesgos KM, etc.
2) Evaluación del impacto estratégico

3) Estimaciones de beneficios
4) Priorizar factores impulsores del negocio
5) Mapas de inversión
6) Análisis hipotéticos
7) Elaboración de modelos de frontera eficiente
8) Análisis de la alineación empresarial
1.4. Relación del EPM con otros procesos
En líneas generales, la integración del EPM con el resto de funcionalidades de

un sistema ERP es imprescindible. El módulo de proyectos genera información
hacia otras áreas y también se produce el flujo contrario. A continuación, se
relacionan de forma genérica dichas relaciones.
1)�Gestión�de�inventario. Desde el EPM se generan transacciones de inventa-

rio que reflejan el consumo de artículos.
2)�Gestión�financiera. Desde el EPM se generan transacciones contables que

reflejan los flujos financieros vinculados al proyecto, así como las transaccio-
nes de clientes generadas para reflejar las previsiones de cobro como resultado
de la facturación de proyectos.
3)�Contabilidad�presupuestaria. Desde el EPM se generan presupuestos con-

tables en función de las estimaciones de proyectos.
4)�Gestión�de�la�producción. Desde el EPM se generan órdenes de fabricación

y se imputan los productos finalizados desde las órdenes de producción a un
proyecto.
5)�Gestión�de�compras. Desde el EPM se generan pedidos de compra.
6)�Gestión�de�ventas. Desde el EPM se gestiona la venta del proyecto.
7)�Gestión�de�activos�fijos. El EPM puede gestionar proyectos vinculados a

activos fijos de la compañía.
8)�Gestión�de�servicios. La gestión de servicios posventa y atención al cliente

o servicios de propio mantenimiento pueden vincularse a un proyecto gestio-
nado desde el EPM.
En la siguiente figura se reflejan las interacciones descritas con anterioridad

entre el EPM y el resto de áreas.
Figura 3. Integración del EPM y ERP

2. Gestión de la cadena de suministro (SCM)
2.1. Introducción
Las compañías están obligadas a buscar constantemente el mejor servicio a

sus clientes con el mínimo coste. Al mencionar "el�mejor�servicio�al�clien-
te" estamos incluyendo la necesidad de mejorar los productos ofrecidos a los
clientes y adecuarlos a sus necesidades reales. Por tanto, identificamos, para
poder conseguir mejorar el servicio, la necesidad de establecer estrategias de
gestión en la empresa que, abordando todos los eslabones del proceso interno,
permitan situar el producto adecuado en el mercado, en tiempo y forma, co-
mo resultado de una transformación, elaboración o realización de servicios a
partir de otros productos que se adquieren por la empresa mediante compra.
Considerando todos los elementos que intervienen en este escenario, y tra-

tándolos de forma integrada, las compañías obtienen ventajas competitivas.
Los elementos que intervienen en mayor o menor medida en el proceso de
mejora mencionado son:
1) los elementos físicos, tanto infraestructura como productos,

2) la tecnología,
3) los procesos de negocio,
4) las personas,
5) el diseño de la organización y
6) los mercados.
Una gestión óptima de las interrelaciones entre los elementos anteriores pro-
porciona ventajas�competitivas, reduciendo costes y favoreciendo los ingre-
sos de la compañía. Esta optimización se deberá sustentar por métodos y he-
rramientas tecnológicas que apoyarán la automatización y control de la pro-
pia estrategia de la compañía.
(5)
En este contexto, aparecen los sistemas SCM5 como un conjunto de métodos SCM son las siglas en inglés de
supply chain management.
y herramientas que facilitan gestionar los flujos físicos, administrativos y de
la información dentro y fuera de un ente económico.
En este apartado del módulo didáctico profundizaremos en este tipo de siste-

mas y clarificaremos los conceptos relacionados.
Suelen confundirse, tratarse indistintamente o de forma alterada, los términos

logística y SCM. A Lo largo de este apartado, es necesario clarificar ambos
conceptos y con ello avanzar hacia el entendimiento del concepto más amplio
SCM que nos ocupa.
La logística es parte de la gestión de la cadena de suministro. La misión funda-

mental de la logística empresarial es colocar los productos adecuados (bienes
y servicios) en el lugar adecuado, en el momento preciso y en las condiciones
deseadas, contribuyendo lo máximo posible a la rentabilidad de la organiza-
ción.
2.1.1. La cadena de suministro
Antes de entrar en más detalles sobre la gestión de la cadena de suministro y

los sistemas de información diseñados, definiremos qué es la cadena de sumi-
nistro y cuál es su funcionamiento.
La cadena de suministro es una serie de procesos de intercambio o flujo de

materiales y de información que se establece, tanto dentro de cada organiza-
ción o empresa como fuera de ella, con sus respectivos proveedores y clientes.
La fabricación del producto comienza con la compra de materias primas y se
transforma mediante los sistemas de producción hasta distribuirlos a los clien-
tes. También existe un flujo en dirección inversa, del comprador al vendedor.
Figura 4. La cadena de suministro tradicional
Podríamos definir la cadena de suministro como una red de organizaciones y

procesos de negocio para la adquisición de las materias primas, la transforma-
ción de estas materias en productos intermedios y finales, y la distribución de
los productos finales a los clientes.
Las principales conexiones de esta red son: proveedores, fabricantes, distribui-

dores, vendedores y clientes.
1)� Proveedores: están al inicio de la cadena de suministro. Es la parte del

suministro que responde a cómo y dónde se obtienen las materias primas para
la fabricación de los productos terminados.
2)�Producción: es la conversión de la materia prima en productos finales den-

tro de la empresa.
3)�Distribución: hay que hacer llegar los productos finales al consumidor a

través de la red de almacenes, distribuidores y comercios minoristas. En mu-
chas ocasiones, esta etapa se denomina logística.
4)�Clientes: el final de la cadena de suministro. El producto llega al consumi-

dor final.
Podemos concluir que la gestión de la cadena de suministro es compleja por

el elevado número de empresas que participan en ella. Una gestión�eficiente
implica integrar a proveedores, centros de producción, almacenes y detallistas.
2.2. Evolución de la gestión de la cadena de suministro
Para encuadrar el enfoque de los sistemas SCM y su origen, mencionaremos

que el concepto SCM aparece en los años setenta; en los años ochenta empieza
a tratarse incluso de forma académica.
Si consideramos que la logística es una parte de los sistemas SCM y revisamos

las tendencias logísticas de las últimas décadas, de forma paralela a la apari-
ción de los sistemas SCM, podemos contrastar que, a principios de los seten-
ta, la tendencia logística dominante era el just�in�case (JIC) o 'por si acaso',
donde lo mejor para la empresa era tener más de todo (stock). El inventario
elevado era la mejor manera de protegerse frente a la incertidumbre. Claro que
el problema emergente es que querer tener más de todo engendra más retraso
en todo (si se mantiene la capacidad de producción constante), por no hablar
de su elevado coste en inmovilizado financiero y el riesgo de convertirse en
productos obsoletos en los mercados actuales, donde predomina la volatilidad
de los productos a causa de la innovación continua, la emergencia de nuevos
diseños y el factor moda.
Más adelante, se desarrolló una nueva tendencia logística, just�in�time (JIT),

'justo a tiempo'. Esta tendencia implicaba reducir el inventario de materia pri-
ma, obra en curso y productos terminados al mínimo imprescindible (stock
cero, desperdicio cero). Si el just in case supone sobredimensionar las cosas, el
just in time implica austeridad.
La gestión�logística�adaptativa es la tendencia posterior al just in time cuyo

lema subyacente es imitar a los sistemas complejos adaptativos. El énfasis de
esta tendencia emergente es que el inventario se establece, dinámicamente,
donde y cuando sea necesario. En el enfoque de gestión de logística adaptativa,
lo prioritario es que, en tiempo real, el stock esté allí donde se necesite, cuando
se necesite y en la cantidad que se necesite para satisfacer la demanda.
La gestión logística adaptativa está alineada con la aparición de los sistemas

SCM, que permiten captar y separar la información donde y cuando se nece-
site y con una logística flexible para gestionar la incertidumbre. Es decir, los
sistemas SCM ponen el énfasis en la flexibilidad organizacional, siendo su in-
dicador clave la velocidad y calidad de respuesta.
La tecnología existente para dar respuesta a las necesidades logísticas, además,

debe permitir el acceso y el intercambio de información en tiempo real entre las
distintas unidades de negocio.
Los sistemas SCM orientan los sistemas de gestión logística de la empresa a

captar rápidamente las variaciones del entorno (mercado); deben ser capaces
de reconocer patrones de variación (demanda) y de proporcionar información
para que la empresa responda más rápidamente que la competencia, de tal
manera que una empresa que tenga implantado correctamente un SCM tendrá más
posibilidades de sobrevivir que las que no sean capaces de gestionar toda la
información a absorber y comprender, permitiendo así responder a las varia-
ciones del entorno.
2.3. Definición
(6)
SCM son las siglas en inglés de
Una solución o herramienta de gestión de la cadena de suministro supply chain management. Esta so-
lución informática es conocida en
(SCM6) es un sistema informático de apoyo a la gestión de la compañía español como solución para la ges-
tión de la cadena de suministro.
como parte integrante de la estrategia adoptada para la mejora de todos
los flujos físicos y administrativos que permiten planificar, implantar,
minimizar costes y controlar la entrega a los clientes de bienes y servi-
cios de calidad demandados por el mercado, a partir de productos ob-
tenidos de los proveedores de la compañía.
A partir de esta definición, cabe destacar que el SCM no es un sistema de in-

formación en sí mismo, sino un componente�de�un�modelo�de�negocio. La
aplicación informática SCM es la herramienta software que permite apoyar al
modelo de negocio adoptado por la compañía en el ámbito de la gestión de
la cadena de suministro. Las aplicaciones software SCM son imprescindibles
para implantar las estrategias de gestión de la cadena de suministro, pero la
estrategia requiere de otros elementos también imprescindibles: estructura de
la organización, infraestructura, procesos de negocio, acuerdos competitivos
con proveedores y clientes, etc.
Como hemos mencionado en la parte introductoria, la logística y la gestión

de�la�cadena�de�suministros están estrechamente relacionadas. Una vez de-
finido el sistema SCM, revisamos ambos conceptos y sus interrelaciones. Este
es el resumen:
• El término logística hace referencia a la gestión del flujo de productos

desde su origen hasta su destino.
• El término SCM alude a la gestión, en primer lugar, de las múltiples rela-

ciones de negocio entre la red de empresas externas que interactúan con la
organización, y, en segundo lugar, la gestión de todas las relaciones entre

las distintas áreas funcionales de la propia empresa.
2.4. Características de una solución software SCM frente a una

solución ERP
En el módulo anterior vimos que un sistema ERP se podía extender añadiendo

nuevas funcionalidades para convertirlo en un sistema de gestión de la cadena
de suministro (SCM). Pero también existen sistemas específicos, exclusivos,
independientes de los sistemas ERP, capaces de gestionar de forma global el
conjunto de operaciones mediante una única solución.
La frontera entre un sistema�ERP y un sistema�SCM es difícil de delimitar. A

continuación, vamos a clarificar las posibles diferencias entre ambos sistemas.
Diferencias entre software SCM y ERP
Software�ERP Software�SCM
Filosofía Los sistemas ERP tradicionales tratan la La filosofía de un software específi-

gestión de la cadena de suministro co- co SCM está basada en un mode-
mo un elemento modular y transaccio- lo de gestión transversal orientado
nal más del total de funciones de nego- a procesos horizontales e interde-
cio. Esta observación mantiene la habi- partamentales, según el cual todos
tual conceptualización de una empresa y cada uno de los procesos de ne-
basada en la gestión departamental. gocio operativos internos y exter-
nos de la empresa están implica-
dos en una cadena integral de de-
cisiones y acontecimientos secuen-
ciales que se realimentan entre sí.
Algoritmos Los sistemas ERP tradicionales están con- Las funcionalidades con las que
cebidos para realizar trabajos transaccio- cuenta un software SCM tienen
nales y sus motores internos se basan en como objetivo la realización de
algoritmos sencillos y repetitivos orienta- cálculos complejos de optimiza-
dos, básicamente, a la gestión relacional ción, por lo que utiliza algoritmos
de datos. muy elaborados con capacidad pa-
ra gestionar múltiples restricciones
en el tiempo.
Tablas Las aplicaciones software ERP, basándo- El software SCM trabaja con filoso-
se en su propia filosofía vertical, respec- fía orientada a los procesos com-
to al modelo de datos utilizado, manejan pletos; por ello gestiona tablas di-
tablas estáticas de datos y gestionan res- námicas y restricciones complejas
tricciones relacionales de forma modu- de forma integral.
lar.
Tiempo El software ERP está orientado hacia la El software SCM, por el contrario,
operación; su objetivo es resolver la pro- está centrado en la planificación a
blemática transaccional del día a día. medio y largo plazo y en la progra-
mación a corto plazo.
Interfaces El software ERP clásico se centra en faci- El software SCM cuenta con inter-
litar al usuario los trabajos de captura, faces sistema-usuario, intuitivas
gestión y consulta. y visuales, con los que el usuario
puede interactuar simulando dife-
rentes posibilidades de interven-
ción.
Diferencias entre software SCM y ERP
Software�ERP Software�SCM
Implantación El proceso de implantación de un soft- La implantación de una solución

ware ERP puede solaparse con la Reinge- SCM requiere haber finalizado la
niería de Procesos de la empresa. definición estratégica a adoptar en
la gestión de la cadena de suminis-
tro, asumiendo la filosofía de tra-
bajo y organización de un sistema
SCM.
2.5. Características de una solución SCM
La gestión de la cadena de suministro está compuesta por varios procesos y

subprocesos. Existen cinco procesos principales: control y estrategia, planifi-
cación, suministro, ejecución y entrega. Cada uno de ellos está formado por
varios subprocesos. En la figura 5 podemos observar la representación de las
distintas partes que conforman un sistema SCM.
Figura 5. Procesos de la gestión de la cadena de suministro (SCM)
La descripción de los procesos principales de la gestión de la cadena de sumi-

nistros es la siguiente:
1)�Control�y�estrategia. Proceso que permite analizar la información resultan-

te de las acciones realizadas en la cadena de suministro y prever la demanda
futura en base a la evolución del negocio.
2)�Planificación. Proceso que balancea la demanda y el suministro estable-

ciendo las reglas de negocio para obtener los mejores resultados.
3)�Suministro. Proceso para obtener los productos y servicios que responden

a la demanda actual o planificada.
4)�Ejecución. Proceso que transforma los productos de entrada en los produc-

tos terminados según la demanda actual y la planificada.
5)�Entrega. Proceso que suministra los productos terminados y servicios a los

clientes.
La figura que se muestra a continuación identifica los cinco procesos de ges-

tión realizados por cada una de las organizaciones que intervienen en la cade-
na de suministro. Cada una se relaciona con la siguiente entidad de la cadena
(por medio de la relación comercial de compra-venta), entregando los mate-
riales como proveedor a otra organización del eslabón.
Figura 6. Procesos de gestión de empresas en la cadena de suministro
Las aplicaciones del sistema SCM que dan soporte a los cuatro primeros proce-
sos (control, planificación, suministro y ejecución) proporcionan a la empresa:
• generar previsiones de demanda para un producto y para desarrollar planes

de abastecimiento y la fabricación de dicho producto;
• ayudar a tomar mejores decisiones operativas, tales como la determinación

de la cantidad de un producto específico para la fabricación en un período
de tiempo determinado, el establecimiento de los niveles de inventario de
materias primas, productos intermedios y productos terminados;
• determinar dónde almacenar los productos terminados, y la identificación Ejemplo

del transporte para la entrega del producto.
Si un cliente hace un pedido
más grande de lo normal, pue-
El sistema SCM proporciona los ajustes necesarios en los planes de producción de implicar un impacto gene-
ralizado en toda la cadena de
y distribución. La información acerca de los cambios es compartida entre los suministro. Tal vez sea nece-
sario solicitar a los proveedo-
distintos miembros de la cadena de suministro para que su trabajo se pueda res más materias primas o una
combinación diferente de es-
coordinar. Una de las funciones más importantes del sistema SCM es la pla- tas. La fabricación puede tener
nificación�de�la�demanda, que determina la cantidad de producto que una que alterar su programación
de trabajo. Asimismo, en las
empresa necesita producir para satisfacer todas las demandas de sus clientes. empresas de transporte puede
ser necesario reprogramar las
entregas.
El proceso de distribución es realizado por las aplicaciones del sistema SCM,
las cuales se encargan de:
• gestionar el flujo de productos a través de centros de distribución y alma-

cenes para asegurar que los productos se entreguen en los lugares adecua-
dos de la manera más eficiente;
• realizar el seguimiento del estado físico de las mercancías, la gestión de

los materiales, las operaciones de almacén y transporte, y la información
financiera entre todas las partes.
Podemos deducir que los sistemas de información SCM hacen más eficiente la
gestión de la cadena de suministro, proporcionando información para asistir
a las organizaciones a realizar el conjunto de procesos implicados, ayudando
a coordinar, programar y controlar la contratación, producción, gestión de
inventario y entrega de productos y servicios.
Beneficios de la implantación de un sistema SCM
Los principales beneficios de una implantación de un sistema SCM son:
• Mejora del servicio al cliente

• Reducción de las ventas perdidas
• Reducción de los costes de mantenimiento
• Reducción de la depreciación del inventario
• Reducción del coste de tratamiento de pedidos urgentes
• Reducción de coste por obsolescencia
2.6. Tendencias de futuro del SCM y ERP
El sistema ERP ha evolucionado reuniendo funcionalidades de otros software

que inicialmente no contenían. Bajo la marca de los principales ERP del mer-
cado, aparecen soluciones de múltiples funcionalidades y alcance tecnológico
para satisfacer los requerimientos del mercado.
El proveedor de soluciones SCM está tratando de expandir sus funcionalidades

al máximo para, de este modo, evitar ser absorbido completamente por los
principales proveedores de ERP.
Los principales proveedores de ERP han ido incorporando carencias funciona-

les de sus productos, poniendo algoritmos determinados de automatización
para resolver tareas desde el punto de vista de procesos SCM, tanto con desarro-
llo propio como con adquisiciones de otras compañías que poseían el softwa-
re o colaboraciones con proveedores SCM; de esta forma, las empresas que re-
querían soluciones completas han podido optar a soluciones integradas avan-
zadas.
Los principales proveedores de sistemas avanzados SCM no tienen demasiado

margen de maniobra; parece que su estrategia no es entrar en ámbitos ya re-
sueltos por los productos ERP, sino desarrollar funcionalidades cada vez más
complejas.
Los grandes proveedores de software ERP que continúan con su carrera de

ampliación funcional y tecnológica, probablemente, absorberán los sistemas
SCM avanzados en sus productos.
3. Gestión de la relación con el cliente (CRM)
3.1. Introducción
(7)
CRM7 es un término que sin duda está de moda. Actualmente, hay frecuentes CRM son las siglas en inglés de
customer relationship management.
conferencias, publicaciones, estudios y formaciones que tratan el tema desde
diferentes puntos de vista. La mayor parte de las empresas afirman que están
estudiando, trabajando o realizando su implementación en la compañía.
El término CRM se utiliza en el mundo empresarial y tecnológico tanto pa-

ra hacer referencia a una estrategia empresarial como para aludir al sistema
de información que permite tratar la información y realizar los procesos que
conllevan la estrategia empresarial. Dado que el tema que nos ocupa es tecno-
lógico, nos centraremos en los sistemas de información CRM, pero sin duda
es necesario en primera instancia partir y aclarar el concepto CRM, desde el
punto de vista de la estrategia empresarial, para luego abordar la definición y
las características de los sistemas de información CRM.
Uno de los objetivos de las empresas, en los últimos años, es que un cliente
perciba que es valorado de forma especial y tratado de forma individualizada
por parte de una empresa, así como poner a su disposición los productos y
servicios que cada uno de ellos requiere. Como respuesta a este objetivo in-
novador, nació, originalmente en el mundo tecnológico, el concepto de CRM
(customer relationship management). La razón de que los sistemas y el propio
concepto CRM se crearan desde el entorno tecnológico es evidente: surgió la
oportunidad de dar una respuesta mediante tecnología a los requerimientos de
las técnicas de marketing orientadas al cliente. Se necesitaba desarrollar herra-
mientas que posibilitaran ese nuevo tipo de interacción con los clientes, que
permitieran un aprendizaje constante de sus preferencias y comportamientos.
En este apartado definiremos y explicaremos las características de estos siste-

mas; siendo el término tan amplio, el alcance final de esta herramienta o me-
todología estará delimitado por la capacidad innovadora de las organizaciones
que las apliquen; a mayor innovación, mayor será la probabilidad de obtener
éxito.
3.2. Definición
Los sistemas� CRM aportan la tecnología para la implantación de un

modelo organizativo de gestión empresarial que integre las funciones
administrativas/financieras, logística, producción y gestión de los recur-
sos humanos, situando al cliente en la posición central, de forma que
los procesos de la empresa se orienten a él.
La Asociación Española de Marketing Relacional define el concepto CRM así:
"Conjunto de estrategias de negocio, marketing, comunicación e infraestructuras tecno-

lógicas, diseñadas con el objetivo de construir una relación duradera con los clientes,
identificando, comprendiendo y satisfaciendo sus necesidades".
Esta definición circunscribe el CRM como una actitud ante los clientes y ante
la propia organización para crear y añadir valor a la empresa y a sus clientes.
Consideramos que la esencia del CRM radica en una cultura de "centralización
en el cliente" por parte de toda la organización.
Vemos, por tanto, que CRM es un concepto que constituye la estrategia de ne-
gocio construida para mejorar el servicio de atención al cliente, cuyo objetivo
es aprender más sobre las necesidades y comportamientos de los clientes para
poder desarrollar fuertes relaciones de colaboración.
Según Philip Kotler, economista y especialista en marketing:
"CRM es un proceso de construcción y conservación de relaciones rentables con los clien-

tes, mediante la entrega de un valor superior y de una mayor satisfacción. Las empresas
modernas van más allá del diseño de estrategias para atraer a nuevos clientes y realizar
transacciones con ellos. Estas emplean la gestión de la relación con los clientes para con-
servar a los clientes que tienen y desarrollar relaciones rentables y duraderas con ellos".
Definición de Claudia Imhoff, presidenta y fundadora de la empresa Intelli-

gent Solutions, Inc.:
"CRM permite el alineamiento de la estrategia de negocios, la cultura corporativa y de la

organización, la información de los clientes y la tecnología que soporta la información
del negocio de tal forma que todas las interacciones con los clientes promuevan una
relación de mutuo beneficio entre cada uno de los clientes y de la organización".
Definición de CRM de Paul Greenberg, presidente de la empresa 56 Group LLC

y autor de varios libros relacionados con el CRM:
"CRM es una estrategia de negocios disciplinada para crear y sostener relaciones con
los clientes rentables y a largo plazo. Las iniciativas de CRM, para tener éxito, deben
comenzar por una filosofía y estrategia empresariales que centren todas las actividades de
la empresa en las necesidades del cliente. La tecnología de CRM es un catalizador crítico
de los procesos necesarios para convertir la estrategia en resultados contables".
Todos los autores coinciden en que el núcleo de la filosofía CRM es el cliente,

y por ello, las áreas de una organización más idóneas a la hora de poner en
marcha esta estrategia son los departamentos comerciales, áreas de marketing
y de atención al cliente, extendiéndose posteriormente, y por necesidades de
alineación, al resto de departamentos. Con todo ello se intenta fidelizar y for-
talecer la relación con el cliente.
El CRM es, claramente, una estrategia orientada a largo plazo que requiere in-
versiones tecnológicas y una adopción de estratégicas que den fruto cuando el
cliente acabe dándose cuenta de que realmente nuestra compañía le "entien-
de" y le satisface mejor que la competencia. En cierto sentido, se trata de una
redefinición de la compañía desde el punto de vista del cliente.
El CRM, por consiguiente, se modula como un concepto surgido a la luz de

los avances tecnológicos, consistente en un diseño del negocio en torno a las
necesidades y los deseos del cliente. El CRM combina un conjunto de meto-
dologías, software e infraestructuras de sistemas y comunicaciones. Los siste-
mas CRM buscan optimizar los ingresos y el beneficio de cara al cliente, así
como su satisfacción. La idea es conseguir que, gracias a esa mayor atención
y sensibilidad hacia las necesidades de los clientes, estos se conviertan en fie-
les de nuestra oferta y se sientan más satisfechos. De tal modo que prefieran
nuestros productos y servicios frente a otras opciones del mercado, dando con
todo ello un mayor margen de beneficio a nuestra empresa.
Realmente, partiendo de todas estas definiciones y observaciones sobre el

CRM, podemos deducir que ya lo aplica, en menor o mayor medida, toda or-
ganización que viva de mantener relaciones con los clientes.
3.3. Características de una solución CRM
Las funcionalidades principales que debe contener una solución CRM se cla-
sifican en operacionales y analíticas: las operacionales, desde la visión de
mejorar la operativa diaria, y las analíticas realizando un mejor análisis de los
datos disponibles.
3.3.1. CRM operacional
Es la parte más técnica. Abarca desde la identificación de clientes potenciales

hasta la obtención de una respuesta, e incluye el servicio proporcionado al
adquirir un producto.
1)� Automatización� de� la� fuerza� de� ventas. La automatización de algunas

tareas de la fuerza de ventas es el núcleo más importante de un sistema CRM.
Es utilizado, principalmente, por el departamento de ventas y los directivos
de las empresas para automatizar todo aquello relacionado con el proceso de
ventas.
Por lo general, realiza las siguientes actividades:
a) Organizar y proporcionar información del mercado y de la competencia a

los agentes de ventas.
b) Coordinar actividades de trabajo del equipo comercial.
c) Organizar y proporcionar información de los productos a los agentes: ca-
racterísticas, disponibilidades, precios...
d) Organizar y proporcionar la información de los clientes a los agentes de
ventas.
e) Proveedor al equipo comercial de informes actualizados del estado y posi-
ción de sus operaciones.
f) Permitir la evaluación del rendimiento de ofertas, campañas, productos,
zonas, agentes, etc.
g) Automatización de tareas de rutina.
2)�Automatización�de�marketing. La empresa podrá planificar, ejecutar y me-

jorar en tiempo real las actividades relacionadas con el marketing, realizando
campañas más efectivas a un coste menor.
Realiza las siguientes actividades:
a) Construcción y gestión de campañas de marketing

b) Medición de operaciones ganadas/perdidas
c) Oportunidades de venta
d) Información de la competencia
e) Distribución de publicaciones y folletos
3)�Help�desk�y�gestión�de�las�áreas�de�soporte. Gestión y solución de inci-

dencias: aplicaciones para prestar servicio técnico a los clientes a la hora de
resolver las dificultades con el funcionamiento del producto adquirido.
4)�Gestión�de�servicio�al�cliente. Gestiona las funciones del servicio al clien-

te de carácter más técnico, ya sea dentro o fuera de la propia empresa. Es la
función que más contacto tiene con el cliente.
5)�Call�center
6)�Gestión�de�incentivos
7)�Gestión�de�relaciones�con�socios
a) Gestión de contratos y niveles de servicio

b) Gestión de casos e interacciones
8)�Gestión�de�calidad
9)�Métricas�CRM. Es un conjunto de mediciones de variables de negocio tales

como satisfacción de clientes y tiempo de entrega.
3.3.2. CRM analítico
Analiza toda la información proporcionada por el CRM operacional para com-

prender mejor el comportamiento de los clientes. Permite diseñar estrategias
de marketing y predicción de ventas. Utiliza técnicas de minería de datos.
Además de las funciones de gestión, se exige la integración del sistema CRM

con diferentes tecnologías de comunicación para habilitar la coordinación de
los distintos canales de comunicación con el cliente: sistemas avanzados de te-
lefonía, correo electrónico, servicios web, Internet, sistemas de reconocimien-
to de voz, etc.
3.4. Proveedores de sistemas CRM
En el Cuadrante Mágico de Gartner, publicado en abril del 2010, vemos cómo

se sitúan en el mercado los proveedores de sistemas CRM para las interacciones
de los servicios al cliente.
Figura 7. Proveedores de sistemas CRM (Gartner, 2010)

El Cuadrante Mágico
Es una representación gráfica del mercado por un período específico de tiempo. Describe
los análisis de Gartner acerca de cómo ciertos fabricantes se miden con los criterios para
ese mercado, tal y como son definidos por el autor. Este no respalda a ningún fabricante,
producto o servicio descrito en el gráfico y no recomienda a los usuarios de tecnología
elegir solo a aquellos fabricantes situados en el cuadrante "Líderes". El Cuadrante Mágico
está desarrollado solamente como herramienta de investigación y no quiere decir que
sea una guía de acción específica. Gartner niega toda garantía, expresa o implícita, con
respecto a su investigación, incluyendo cualquier garantía de comercialización para un
propósito específico.
Otros recursos y sistemas relacionados con un sistema CRM complementan las

funciones propias del CRM y permiten agilidad. Algunos de estos recursos son
sistemas en sí mismos que se detallan en siguientes apartados de este módulo
didáctico, ya que no solo complementan a los sistemas CRM, sino a todos los
sistemas de gestión empresarial:
• Los sistemas que ya conocemos como ERP, EPM, SCM.
• Los sistemas que estudiaremos en los siguientes apartados del módulo:

– e-business: realización de transacciones de negocio de forma electróni-
ca
– BI: inteligencia de negocio
– KM: sistemas de gestión del conocimiento
– Gestión documental
3.5. Implantación del CRM
El concepto CRM es sencillo y sus objetivos fáciles de entender, pero su im-

plantación en una empresa es muy compleja, pues toda estrategia de implan-
tación de CRM debe basarse en un cambio radical de la orientación estratégica
de la compañía.
No se trata de implantar una nueva tecnología ni unas herramientas analíticas

determinadas, ni siquiera de crear un departamento de la empresa dedicado
a la relación con los clientes. El éxito de la implantación de una solución tec-
nológica CRM viene dado por la decisión acertada que se tenga al seleccionar
la herramienta y la empresa implantadora, pero la mayor parte del éxito o fra-
caso del proyecto vendrá de la capacidad de ajustar la cultura organizacional
a una nueva visión centrada en el cliente y al soporte que esta visión tenga
por parte de dirección de la empresa.
Implantar un sistema CRM concierne a todos los trabajadores de la compañía.

Todo el personal de la compañía debe ser una potencial fuente de entrada de
información procedente del cliente. Todo el mundo tiene que entender que el
activo más importante de la empresa es, precisamente, su base�de�clientes y
la información que sobre estos y sus necesidades es capaz de recopilar.
Existen dos principales�alternativas para implantar un sistema de gestión de

relaciones con el cliente:
1)� CRM� como� extensión� de� un� sistema� ERP. Como vimos en el módulo
anterior, a un sistema ERP podemos añadir funcionalidades para realizar las
funcionalidades de la gestión de las relaciones con el cliente.
2)�CRM�específico. Es la implantación de un sistema especializado y exclusivo

de CRM.
4. Negocio electrónico (e-business)
4.1. Introducción
La convergencia tecnológica de las últimas décadas ha permitido globalizar el

acceso a los recursos externos a la empresa y también ha favorecido el acce-
so de la empresa a los mercados. La evolución tecnológica ha propiciado la
transformación de los procesos clave de los negocios, facilitando las relacio-
nes entre las empresas. Con la aparición de nuevos entornos de negocios, las
empresas han sabido aprovechar las nuevas tecnologías para orientarse mejor
hacia su mercado.
El concepto de e-business es anterior a Internet, puesto que se implementaba

ya mediante otras soluciones tecnológicas hardware y software; en los años
setenta, empezaron a realizarse interacciones de operaciones bancarias entre
sistemas heterogéneos que permitían transferencias de datos "entendibles" por
aplicaciones diferentes y que se comunicaban directamente. Pero Internet es
la plataforma tecnológica con la que hace unos años se iniciaron, a gran es-
cala, las relaciones de la empresa con el exterior, lo cual ha ido ampliándose
desde la compraventa de productos con esta plataforma tecnológica hasta un
aprovechamiento mucho más extenso de la comodidad, disponibilidad, sim-
plicidad y alcance universal de Internet.
En este módulo didáctico tratamos el modelo e-business con objeto de hacer

constar que los sistemas de gestión empresarial tratados se extienden, necesa-
riamente, hacia el aprovechamiento de Internet y otras tecnologías, propor-
cionando un nuevo marco de interacción de la empresa con todos los elemen-
tos que participan en los procesos de negocio.
4.2. Conceptos e-business
El e-business (negocio electrónico) es un término general con el que se deno-

mina a la realización de procesos empresariales mediante medios electrónicos.
E-business es el modelo de negocio que implementa una organización,

integrando sus sistemas de información internos con los sistemas que
relacionan a la empresa con el mundo exterior, aprovechando las pla-
taformas tecnológicas, principalmente Internet, que permiten conecti-
vidad digital entre dicha organización y su entorno, según unos están-
dares de comunicación.
La plataforma tecnológica en la que se basa este modelo de negocio supone el

uso de sistemas informáticos en los extremos que intervienen en las relaciones
interempresa. Asimismo, los elementos tecnológicos que intervienen deben
ser interactivos y permitir gran cantidad e intensidad de transacciones.
Este modelo de negocio lleva a la mejora de las relaciones comerciales en-

tre empresas, componentes de la cadena de suministro, actuaciones de sopor-
te técnico, servicios posventa, educación, transacciones bancarias, comunica-
ción con empleados, relación con los administradores, etc. Por tanto, los pro-
pios sistemas de gestión empresarial implementados en la organización (ERP,
CRM, SCM, EPM) deben proporcionar posibilidades de comunicación por In-
ternet que habiliten a la organización para la aplicación de un modelo de ne-
gocio e-business como complemento a su actividad.
Las organizaciones realizan un proceso continuo de estudio de recursos y he-

rramientas de e-business, gestión del riesgo tecnológico y planificación de ac-
ciones concretas, al mismo tiempo que la tecnología continúa evolucionando.
Es por ello que es muy compleja la adecuación de las organizaciones al modelo
e-business, ya que el entorno es cambiante. La propia estrategia de la empre-
sa al respecto es variable, por cuanto las mejoras tecnológicas evolucionan a
mucha más velocidad que la velocidad a la que es posible su implantación en
las organizaciones.
El modelo e-business puede tener múltiples posibilidades. Cada empresa con-

creta definirá su propio modelo según sus necesidades, posibilidades y plan
de negocio. Con ello delimita dónde se encuentran los procesos clave de sus
sistemas de información, qué necesitan del soporte tecnológico para habilitar
correctamente las interacciones con el exterior, y así proporcionar a la plata-
forma ERP, SCM, CRM, EPM su extensión hacia el e-business.
5. Inteligencia del negocio (BI)
5.1. Introducción
(8)
El actual entorno de los negocios, de forma cada vez más eficiente, reclama BI son las siglas en inglés de bu-
8 siness intelligence.
tener información válida para la organización. BI identifica la inteligencia
del negocio, que se deriva de la correcta utilización de la información generada
Bill Gates
dentro y fuera de la empresa.
Bill Gates, cofundador de la
empresa de software Micro-
En este apartado trataremos de nuevo una extensión y un complemento de soft, aportó la frase "BI ayuda
a rastrear lo que en realidad
los sistemas operacionales de información de la empresa: los sistemas BI. funciona y lo que no" (Tupson
Technologies).
5.2. Definición
Se denomina business intelligence (inteligencia empresarial o inteligen-

cia de negocios) al conjunto de estrategias, procesos y herramientas tec-
nológicas orientadas a la creación�de�conocimiento como base para la
toma de decisiones en una organización y a la administración de dicho
conocimiento.
El conocimiento generado a partir de las estrategias y herramientas de BI debe

permitir acceso en tiempo real para su análisis. Dicho conocimiento cubre in-
formación sobre la situación real de la empresa, su funcionamiento y el ámbi-
to de la propia empresa; también proporciona información sobre predicciones
de acontecimientos futuros.
Estamos diferenciando tres elementos que intervienen en los sistemas de in-

teligencia del negocio: datos, información y conocimiento. Revisando rápida-
mente estos tres conceptos, se llega a la comprensión del objetivo del concep-
to BI:
1)�Datos. Los datos se corresponden con elementos primarios de información

que, por sí solos, son irrelevantes como apoyo a la toma de decisiones. Forman
un conjunto discreto de valores que no dicen nada sobre el porqué de las
cosas y no orientan la acción. Los datos pueden provenir de fuentes externas
o internas a la empresa, pudiendo ser de carácter objetivo o subjetivo, o de
tipo cualitativo o cuantitativo, etc.
2)�Información. La información se puede definir como un conjunto de datos

procesados y que tienen un significado (relevancia, propósito y contexto), y
que por lo tanto son de utilidad para quien debe tomar decisiones. Los datos
se pueden transformar en información añadiéndoles contextualización, cate-
gorización, cálculos, correcciones y acumulación.
3)�Conocimiento. Es el conjunto de información utilizada en el proceso de

la toma de decisiones. El conocimiento es una mezcla de experiencia, valo-
res, información y habilidades que sirve como marco para la incorporación de
nuevas experiencias e información, y es útil para la acción. Se origina y aplica
en la mente de los conocedores. En las organizaciones con frecuencia no solo
se encuentra dentro de documentos o almacenes de datos, sino también en
rutinas organizativas, procesos, prácticas y normas.
El conocimiento se deriva de la información, así como la información se deriva

de los datos. Para que la información se convierta en conocimiento es nece-
sario realizar acciones, como comparación�con�otros�elementos,�pronóstico
de� efectos� y� búsqueda� de� relaciones,� razonamientos� comunes� con� otros
portadores�de�conocimiento.
Los sistemas BI combinan necesariamente los siguientes componentes:
• grupos de trabajo (es decir, personas),

• procesos y
• tecnología.
5.3. Elementos y características de una solución software BI
Una solución BI combina distintos sistemas informáticos, que describimos en

líneas generales:
1)�Servidores�de�base�de�datos�relacionales. Las bases de datos relacionales

representan, conceptualmente, la realidad basada en la representación de esta
mediante su abstracción en entidades y relaciones. De esta forma intentamos
representar el mundo que nos rodea, los datos de nuestro problema median-
te una serie de entidades que representan objetos o conceptos, así como las
relaciones que se dan entre ellos, tales como su uso, composición, etc. El ERP
interactúa con la base de datos relacional completando todos los datos a partir
de los flujos de trabajo. Las bases de datos relacionales aportan el primer nivel
de obtención de datos a partir del cual podemos crear información y conoci-
miento mediante el resto de herramientas que vamos a ir revisando.
2)�Reporting. Los informes son usados para generar reportes estáticos altamen-
te personalizados destinados a ser distribuidos a muchos destinatarios. La ge-
neración de informes se reduce a la definición de vistas en la base de datos.
3)�OLTP�(on-line�transactional�processing). Es un tipo de proceso especial-

mente rápido en el que las solicitudes de los usuarios hacia el servidor de ba-
se de datos relacional son resueltas de inmediato; naturalmente, ello implica
la concurrencia de un mecanismo que permite el procesamiento de varias
transacciones a la vez.
4)�OLAP�(on-line�analytical�processing). Son herramientas que manejan inte-

rrogaciones complejas de bases de datos relacionales, proporcionando un ac-
ceso multidimensional a los datos; contienen capacidades elevadas de cálculo
y técnicas de indexación especializadas. Permiten a los usuarios fraccionar sus
datos planteando consultas sobre diferentes particularidades o dimensiones.
Utilizan un servidor intermedio para almacenar los datos multidimensionales
precalculados, de forma que la explotación sea rápida.
Su objetivo es dotar de capacidades analíticas a los administradores de nego-

cios.
Los sistemas OLAP tienen muchas ventajas que los hacen herramientas atrac-
tivas para BI, pero existen innegables inconvenientes. El interfaz de usuario es
considerablemente sencillo, pero ello supone más dificultad en la creación. La
definición de medidas, dimensiones y jerarquías, así como la creación del cu-
bo y la propia herramienta OLAP a utilizar, requieren conocer profundamente
los procesos y estructuras empresariales.
5)�Cuadro�de�mando�integral�o�estratégico�(balanced�scorecard). Este mo-

delo parte de que la estrategia de la empresa es el punto de referencia para todo
proceso de gestión interno. Partiendo de la estrategia, los diferentes niveles de
dirección y gestión de la organización disponen de una visión de la estrategia
de la empresa traducida en un conjunto de objetivos, iniciativas de actuación
e indicadores financieros y no financieros de evolución tangibles.
El cuadro de mando integral relaciona:
• Los indicadores externos para accionistas y clientes, y los indicadores in-

ternos de los procesos críticos (negocios, innovación, formación y creci-
miento).
• Los indicadores de resultados y los correspondientes a esfuerzos futuros.
• Medidas objetivas y cuantificables, y medidas subjetivas inductoras de re-
sultados.
Los objetivos estratégicos se asocian mediante relaciones causa-efecto y se or-

ganizan en cuatro áreas o perspectivas:
• financiera,
• cliente,
• procesos e
• innovación y formación.
El cuadro de mando integral es una herramienta que permite organizar los

objetivos de las diferentes áreas o unidades con la estrategia de la empresa y
seguir su evolución.
6)�Data�marts. Repositorios personalizados en función del análisis de datos

de interés para un grupo específico de trabajadores o área de la empresa.
7)�Data�mining�(minería�de�datos). Son herramientas de extracción de co-

nocimiento útil, a partir de la información contenida en las bases de datos de
cualquier empresa. El objetivo que se persigue es descubrir patrones ocultos,
tendencias y correlaciones, y presentar esta información de forma sencilla y
accesible a los usuarios finales, para solucionar, prever y simular problemas
del negocio. El data mining utiliza algoritmos de procesado de datos detallados
complejos para descubrir tendencias reveladoras dentro de la gran cantidad de
información que almacena la empresa. Estos algoritmos permiten encontrar
información clave sobre los hábitos de los clientes, hacer pronósticos sobre la
evolución de la empresa y del mercado, segmentar y clasificar clientes y aso-
ciar grupos y patrones; todo ello a partir de bases de datos relacionales, como
las que utilizan los sistemas OLTP, o bien a partir de las mismas bases de datos
utilizadas para BI.
Para realizar análisis y predicciones completos se adquieren recursos públicos

o privados, bases de datos externas, con datos legales, demográficos y geográ-
ficos.
8)�Data�warehouse. Es una gran colección de datos que recoge información de

múltiples sistemas fuentes o sistemas operacionales dispersos, y cuyo objetivo
se centra en la toma de decisiones, es decir, en el análisis de la información.
9)�Executive�information�systems�(EIS). Sistemas de información ejecutiva.
10)�Decision�support�systems�(DSS). Sistemas de apoyo a la toma de decisio-

nes.
5.4. Proveedores de sistemas de BI
Figura 8. Proveedores de la solución BI (Gartner, 2010)
A pesar de que los grandes proveedores acaparan en este cuadrante el 75%

del mercado, sigue habiendo mercado para los proveedores especializados en
BI, ya que ofrecen soluciones más innovadoras y consiguen una valoración
elevada por parte de sus clientes. Los grandes proveedores tienen pendiente la
problemática de integrar sus soluciones (fruto de múltiples adquisiciones), lo
que cuestiona seriamente su capacidad de ofrecer las soluciones que necesitan
las organizaciones actuales.
6. Gestión del conocimiento (KM)
6.1. Introducción
En el apartado anterior hemos tratado sobre los sistemas de inteligencia del

negocio (BI); ahora vamos a abordar los sistemas que permiten gestionar den-
tro de la organización correctamente el conocimiento que proporcionan di-
chas herramientas.
La organización requiere conocimiento tanto interno como externo, pero tam-

bién disponer de estrategias y herramientas que ayuden a determinar la vali-
dez del conocimiento, según el destinatario y sus funciones dentro de la or-
ganización.
6.2. Definición
La gestión del conocimiento (KM) es una disciplina que facilita la creación,

captura, organización, acceso y utilización del conocimiento corporativo.
(9)
KM son las siglas de knowledge
9
Un sistema de gestión del conocimiento (KM ) es el conjunto de políti- management.
cas, estructuras organizativas, procedimientos, aplicaciones y tecnolo-

gías que identifican, distribuyen y dan uso al conocimiento y al capital
intelectual, generado dentro y fuera de la organización. El KM mejora
la efectividad en la toma de decisiones.
M. Nüssbaum definió:
"La gestión del conocimiento es el proceso sistemático y explícito de capturar la expe-

riencia individual o colectiva de una organización, independiente del medio en el cual se
encuentra, de modo que se pueda distribuir o dejarlo accesible a todas aquellas personas
a las cuales le es útil".
La gestión del conocimiento es la estrategia formal y el conjunto de tecno-

logías diseñadas para administrar y potenciar los activos�intelectuales de la
compañía.
6.3. Características de una solución KM
Alguno de los elementos necesarios con que debería contar una solución de
gestión del conocimiento son:
1) Generación de almacenes de conocimiento sobre sistemas simples o com-

plejos:
• Bibliotecas digitales
• Bases de datos
• Sistemas expertos. Las bases de conocimiento están relacionadas con la
inteligencia artificial.
• Aplicaciones de trabajo colaborativo (groupware)
• Minería de datos (data mining)
• Árboles de conocimiento o gestión de competencias
• Sistemas de aprendizaje
• Sistemas de apoyo a la toma de decisiones
• Internet/intranet
• Bases documentales
• Software
2) Acceso rápido a esos almacenes, sea de manera pública o bien, mediante

restricciones departamentales.
3) Fomentar su difusión y enriquecimiento mediante la participación de todos

los implicados.
La función principal de un sistema de gestión de conocimiento es la genera-

ción de un repositorio de conocimiento de muy diversa índole (software, do-
cumentación, incidencias, propuestas, resultados del negocio, etc.). Destacan
su portabilidad y capacidad de reutilización, al constituirse como marco de
referencia para poder gestionar el conocimiento generado.
Cualquier sistema de gestión del conocimiento cuenta con dos ámbitos de

actuación diferentes:
1)�Desde�el�punto�de�vista�del�usuario�final. Consultando los datos incluidos

en el repositorio de conocimiento, reutilizándolos y generando propuestas o
sugerencias, o bien solicitando mayor información, lo que proporciona aún
mayor conocimiento.
2)�Desde�el�punto�de�vista�del�administrador�del�sistema. Se encargaría de
asegurar la recopilación necesaria del conocimiento desde las fuentes selec-
cionadas, estableciendo las reglas y habilitando los mecanismos de captura y
transmisión.
6.4. Divergencia BI-KM
Business intelligence (BI) se diferencia de la gestión del conocimiento (KM) en

que ofrece una aproximación más estructurada a la toma de decisiones, orien-
tada�a�problemas�determinados y dirigida a la integración y análisis de in-
formación de áreas de negocio concretas. La gestión del conocimiento está
orientada a contenidos y procesos.
La diferencia principal es que KM es una estrategia integral donde la tecnolo-

gía es realmente una herramienta supeditada a la estrategia y se exige la cola-
boración de personas e integración de distintas fuentes de información, mien-
tras que BI está en muchos aspectos fuertemente definida por la tecnología
disponible.
7. Gestión documental
7.1. Introducción
La necesidad de organizar, controlar y disponer de los documentos producidos

por las organizaciones ha sido una constante de la producción administrativa
de la empresa a lo largo de los años, y la gestión documental de apoyo ofimá-
tico cuenta con gran tradición y madurez. El avance de las TIC y la evolución
del concepto de gestión al servicio de las empresas y sus clientes hace que la
tecnología de gestión documental adquiera una mayor complejidad; en ella
interviene una serie de herramientas, aplicaciones y componentes tecnológi-
cos de cuya integración depende el éxito o el fracaso de la implantación.
Los documentos reúnen unas características que dificultan su gestión y deter-

minan el problema documental:
1) La información que contienen, en su gran mayoría, no está estructurada.
2) El soporte físico en el que se sustentan dificulta su flujo y acceso.
3) La conservación durante largos períodos de tiempo, en tanto que son prueba

de las actuaciones de las organizaciones.
4) La masa de documentos desorganizados, ya sea digitales o no, exige la de-

dicación de un gran número de horas de personal administrativo a su organi-
zación, conservación y localización.
La aplicación de la tecnología de gestión documental contribuye a la solución

de este problema, habiendo alcanzado en la actualidad un grado de madurez
que las convierte en indispensables de las organizaciones para resolver el pro-
blema documental.
En sus inicios, la gestión documental se concebía como una herramienta de

ayuda ofimática. Facilitaba la organización lógica de los documentos en un
sistema de información que permitía su control, al tiempo que, mediante su
digitalización, se podía sustituir el documento físico por su imagen electróni-
ca, con lo que se lograba reducir enormemente el espacio necesario para su
conservación en las propias oficinas.
Con el paso del tiempo, los sistemas de workflow y las herramientas de gestión
de contenidos supusieron una importante ayuda para la gestión administra-
tiva. Facilitaban enormemente la tramitación de los procesos al automatizar
las tareas propias del proceso administrativo, permitiendo la explotación de
la información residente en la organización, reportando un importante bene-

ficio al suponer un ahorro de costes, un mejor control y seguridad de los do-
cumentos y la optimización del conocimiento corporativo, y mejorando los
procesos internos.
A pesar de que hoy en día nadie duda de los beneficios que estas tecnologías
aportan, la realidad es que su nivel de implantación difiere todavía de ser el
que debiera corresponder a este tipo de soluciones.
7.2. Definición
Se entiende por sistema de gestión documental la estructura conceptual,

los procedimientos, las tecnologías y las prácticas usadas por una orga-
nización y otras entidades externas a la organización para lo siguiente:
administrar el flujo de documentos�digitales de todo tipo en la organi-
zación; evitar duplicidades de documentos y el manejo automático de
versiones de documentos; permitir la recuperación de información des-
de dichos documentos; determinar el tiempo que los documentos de-
ben almacenarse y asegurar la conservación indefinida de los documen-
tos más valiosos, aplicando sobre el sistema principios de racionaliza-
ción, control de la producción documental y compartición de recursos.
7.3. Características de una solución de gestión documental
Una aplicación de gestión documental está orientada a un contexto operacio-

nal que tenga relevancia para la organización, por ejemplo, la gestión docu-
mental podrá ser un elemento de los sistemas ERP, CRM, EPM, SCM.
Los sistemas de gestión documental permiten generar una estructura de docu-

mentos que reside en un repositorio documental centralizado y accesible para
todos los usuarios y según unas políticas de seguridad.
La estructura clásica de los sistemas de gestión documental incluye cinco ele-

mentos principales:
1) un modelo de registro estructurado en diferentes campos de tamaño varia-

ble,
2) la inversión de términos que conduce a la creación de un fichero invertido,
3) uno o más diccionarios que controlan la indexación (diccionario de pala-

bras vacías, de sinónimos, de palabras autorizadas, etc.),
4) un sistema de recuperación basado en el álgebra de Boole para realizar ope-

raciones lógicas con conjuntos de documentos, y
5) un sistema complementario de recuperación de cadenas de caracteres basa-

do en comparaciones, truncamientos, proximidad, etc.
En este sentido, un sistema documental clásico intenta facilitar elementos pa-

ra gestionar información no estructurada (es decir, sus atributos no son dedu-
cibles sin una operación compleja de análisis intelectual). No posee propieda-
des repetitivas, como un documento de oficina, sino que su estructura es in-
tensamente variable de un documento a otro. Para su recuperación no basta
con registrar datos como el autor, el destinatario y la fecha de creación. Debe
representarse también la información y el conocimiento que pueda contener
ese documento.
En cambio, los sistemas documentales proporcionan las herramientas para

ello:
• registros que admiten campos de gran extensión,

• recuperación del documento por cualquier palabra que forma parte de su
descripción,
• edición e impresión del fichero invertido y de los diversos diccionarios,
etc.
Sin estos elementos mínimos es�imposible controlar un fondo documental de

tipo cognitivo. En realidad, los usuarios de un sistema de información docu-
mental detectan una necesidad de información, expresada de forma borrosa,
que el sistema habrá de traducir a una expresión de búsqueda precisa mediante
términos de indización. El motor de recuperación del sistema deberá ejecutar
entonces una función de concordancia con el fin de determinar el conjunto
de documentos pertinentes a esa necesidad de información.
Los sistemas de gestión documental extienden sus procesos en Internet, es

decir, permiten que las personas externas a la organización, bien sean clientes,
proveedores, o socios, participen en los procesos a través de la Red. Podrán
ver una factura, consultar un albarán o hacer un pedido, lo que implica la
necesidad de extremar los requisitos de seguridad, la incorporación de la firma
electrónica y un marco legal que dé protección a esta nueva forma de entender
los procesos de negocio.
Tal como ocurre con el resto de sistemas estudiados, la definición de una me-
todología específica para la implantación de los sistemas de gestión documen-
tal, con la perspectiva del ciclo de vida completo de los procesos administra-
tivos, la priorización de los procesos a implementar y la definición de fases
del proceso de implantación son elementos fundamentales para la correcta
alineación de la solución de gestión documental en la empresa.
Resumen
Las organizaciones en la sociedad del conocimiento requieren de sistemas de

información eficientes e integrados y que permitan la gestión no solo de la
información, sino también del conocimiento, incorporando las mejores prác-
ticas para facilitar la toma de decisiones, la optimización de recursos y la alta
gestión de los recursos empresariales.
Para lograr esta meta, se utiliza una serie de tecnologías que permiten el logro
del mismo: ERP y su extensión a EPM, CRM, SCM, KM, BI...
Los propósitos y las características de los sistemas ERP y de los sistemas estu-
diados en este módulo se complementan y se distinguen. Mientras los prime-
ros suplantan a los sistemas legados creando una sola infraestructura de TIC,
los segundos crean comunidades de innovación, incluyendo a toda la comu-
nidad de la organización; los ERP mejoran la productividad organizacional por
medio de sistemas adecuados para compartir información; los sistemas EPM,
CRM, SCM, KM y BI mejoran la capacidad de innovación por medio de com-
partir y aplicar.
En un sistema complejo en el que convivan tanto sistemas ERP como sistemas

EPM, CRM y SCM, del mismo o de diferentes fabricantes, así como otras he-
rramientas KM, BI, gestión documental y modelos de negocio e-business, de-
berán existir necesariamente interrelaciones que habiliten la integración, lo
cual, cuando los sistemas provienen de diferentes fabricantes, puede llegar a
ser muy costoso.
Las empresas se enfrentan a una serie de problemas como consecuencia de su

interés por disponer de productos tecnológicos que cubran, de forma integra-
da, todas las funcionalidades requeridas. La evolución de las aplicaciones de
negocio y la terminología involucrada en esta evolución nos permite justificar
que, en materia de sistemas de gestión empresarial, la tendencia de futuro es
adaptar las soluciones tecnológicas a todas las necesidades. Por tanto, lo rele-
vante no es que ahora disponemos de múltiples tipos de sistemas de negocio
y que, además, mejorarán y se ampliarán con nuevos desarrollos, sino que las
organizaciones tiene un difícil reto para determinar cómo implementar, de
forma más eficiente, una solución empresarial que acelere el tiempo de res-
puesta y automatice al máximo los procesos internos y externos.
La evolución de las aplicaciones de negocio y la terminología involucrada en

esta evolución nos permite justificar que, en materia de sistemas de gestión
empresarial, la tendencia de futuro es adaptar las soluciones tecnológicas a
todas las necesidades. Por consiguiente, lo relevante no es que ahora dispone-
mos de múltiples tipos de sistemas de negocio y que además mejorarán y se
ampliarán con nuevos avances, sino que las organizaciones tienen un difícil
reto para determinar cómo implementar de forma más eficiente una solución
empresarial que acelere el tiempo de respuesta y automatice al máximo los
procesos internos y externos.
En definitiva, la capacidad para mejorar la eficacia en la gestión y el valor del

propio negocio convierten a los sistemas de información en una herramienta
estratégica de gestión que, por lo tanto, requiere de planificación a largo plazo
y alineamiento con la estrategia corporativa para mantener la ventaja compe-
titiva o la plena satisfacción de los usuarios y demás participantes en la red de
valor de la organización.
Para poder construir un sistema completo que abarque las soluciones tecno-
lógicas disponibles y alineadas con la organización y sus necesidades, es nece-
sario: partir de la implementación de los sistemas ERP operacionales para la
gestión del negocio; a continuación, solucionar sus extensiones EPM, CRM y
SCM según proceda y, con ello, evolucionar hacia las herramientas más avan-
zadas que requieren una base muy sólida de datos y procesos, como BI, KM y
gestión documental, aportando todas ellas de forma integrada las soluciones
del modelo e-business que se adopte.
Las organizaciones modernas se enfrentan al mercado en un escenario donde

las personas son los protagonistas del proceso. Se puede tener el sistema co-
rrecto y contar con tecnología avanzada, es posible estar realizando el proceso
correcto y hasta se puede tener el personal adecuadamente capacitado, pero
también se debe disponer del modelo de interrelaciones humanas adecuado
mediante el cual operan el producto, la tecnología, el proceso y las personas.
Además de los sistemas aquí tratados, existen otros sistemas y tecnologías que,
en este contexto de estudio, serían elementos propios de los sistemas tratados
ERP, SCM, CRM, EPM, BI, KM, e-business y gestión documental, pero que po-
drían trabajar con independencia o como complementarios a cualquier com-
binación de soluciones y, por tanto, resolverían parte de los objetivos globales
de los sistemas. Detallamos a continuación algunos de ellos:
• MIS: sistemas de información gerencial.

• DSS: sistema de soporte en el proceso de toma de decisiones.
• OCR: se usa para escanear y reconocer caracteres, e incluso códigos de
barras, en cualquier tipo de documento (albaranes, formularios, facturas,
etc.).
• EDI: intercambio electrónico de datos normalizado.
• BPM: business process management.
• CPM: corporate performance management.
En síntesis, los conceptos tratados cubren complejos sistemas tecnológicos y

avanzadas estrategias de negocio; la aplicación de estos conceptos en el mun-
do empresarial requiere inversiones muy elevadas. Tienen un elevado impacto
en la organización y se necesita personal interno cualificado con capacidad de

discernimiento y creatividad y grandes esfuerzos, por parte de las empresas, a
la hora de acometer actividades de reingeniería de procesos para integrar co-
rrectamente los procesos de negocio, con el agravante de que tanto las tecno-
logías como los negocios están en continua y rápida evolución. Por ello, las
empresas tienen un reto muy importante: la implementación de los sistemas
tecnológicos disponibles para la gestión empresarial.
Actividades
El objetivo es presentar un documento completo que muestre el desarrollo total de un caso.
Este puede ser tanto teórico como aplicado, pero siempre respetando los conceptos, teorías
y disciplinas relacionadas.
Los casos planteados podrán centrarse en el análisis de casos que han sido estudiados y so-
lucionados por equipos de especialistas, o casos centrados en generar propuestas de toma
de decisiones por parte del estudiante. Se pretende obtener conocimiento práctico, así como
aplicar los conceptos aprendidos en el módulo didáctico realizando el estudio de situaciones
que requieren la resolución de problemas; de esta manera, el estudiante se implica en el pro-
ceso de toma de decisiones.
Entendiendo el módulo didáctico como una serie de estrategias de negocio y tecnologías

unidas para satisfacer unos requerimientos de las organizaciones, se espera que, por medio
del estudio de estos casos, se analice cómo las empresas y organizaciones incorporan el uso
de las nuevas tecnologías y sistemas operacionales a sus procesos de negocio, englobando
cualquier actividad tradicional.
Entre posibles casos, y a modo de ejemplo, se puede trabajar en estos temas:
• Análisis de la implantación de un proyecto CRM + e-business

• Propuesta de implantación de un proyecto de gestión documental integrado con EPM
Glosario
estrategia f Una estrategia se vincula, en términos empresariales, al trazado de un plan de
acción a los fines de alcanzar determinados objetivos corporativos o financieros.
call center m Es una unidad funcional dentro de la empresa (o bien una empresa en sí
misma) diseñada para manejar llamadas telefónicas entrantes y salientes desde y hacia sus
clientes, con el propósito de dar soporte a las operaciones cotidianas de la organización.
capital intelectual m Aquel conjunto de activos intangibles que suponen la generación

de una mayor valoración de la empresa. Está constituido por el capital humano (informa-
ción sobre el empleado, sus aptitudes, habilidades, capacidad de aprendizaje, etc.), el capital
estructural (información sobre la cultura de la organización, características, estructura y filo-
sofía de trabajo) y por el capital relacional (relativo a los contactos con entornos externos
a la organización).
ciclo de vida de un proyecto m Distintas etapas que atraviesan los proyectos desde su
aparición hasta su finalización.
forecasting m Pronosticar, prever.
groupware m Conjunto de programas informáticos colaborativos. Uso de métodos y he-

rramientas de software que permiten que los usuarios realicen trabajos colectivos a través
de redes.
help desk m Conjunto de recursos técnicos y humanos que dan soporte a diferentes niveles
de usuarios de la propia empresa o de los clientes a los que se les da servicio.
productividad f Incremento o decremento del rendimiento a partir de la variación de

cualquiera de los factores que intervienen en un proceso de producción o en las etapas de
la cadena de suministro.
reingeniería de procesos f Reconsideración, reestructuración y racionalización de las es-

tructuras de negocio, procesos, métodos de trabajo, gestión de sistemas y relaciones externas.
workflow m Automatización de un proceso o serie de procesos por medio del encadena-

miento de las tareas y actividades.
Bibliografía
Cohen Karen, D.; Asín Lares, E. (2005). Sistemas de Información para los Negocios. Mc-
Graw-Hill.
Dick Lee (2001). Self-Guided CRM (Customer Relationship Management). Spiral Bound.
Draeger, E. (2000). Project Management with SAP(R) R/3. Addison-Wesley, Pearson Education.
Dyche, J. (2002). The CRM Handbook: A Business Guide to Customer Relationship Management.
Addison-Wesley.
Gómez Vieites, A.; Suárez Rey, C. (2006). Sistemas de Información: herramientas prácticas
para la gestión empresarial. Alfa Omega Ra-ma.
Gray, C. F.; Larson, E. W. (2000). Project Management. The Managerial Process. McGraw-Hill.
Huidoro Moya, J. M.; Roldán Martínez, D. (2005). La tecnología e-business. Thomson.
Kaplan, R. S.; Norton, D. P. (1997). El Cuadro de Mando Integral. The Balanced Scorecard.
Barcelona: Ediciones Gestión 2000.
Kimball, R.; Ross, M. (2009). The Data Warehouse Toolkit. Wiley.
Kleijnen, J. P.; Simts, M. T. (2003). Perfomance metrics in supply chain management. En:
Journal of the operational research society.
Lee, D. Self-Guided CRM (Customer Relationship Management). Spiral-bound.
McLeod, R. (2000). Sistemas de Información Gerencial (7.ª ed.). Hispanoamericana.
O'Brien, J. A.; Marakas George, M. (2008). Sistemas de Información Gerencial. Mc-

Graw-Hill.
Papazoglou, M. P.; Ribbers, P. (2006). e-business Organizational and Technical Foundations.

Willey.
Caja de
herramientas
para tu proyecto y
presentación
PID_00270735
Emma Gorgori Bonet
Tiempo mínimo de dedicación recomendado: 2 horas

© FUOC • PID_00270735 Caja de herramientas para tu proyecto y presentación
Emma Gorgori Bonet
Licenciada en Administración y Di-

rección de Empresas y diplomada en
Ciencias Empresariales (especialidad
finanzas) por la Universidad Rovira i
Virgili (URV). Durante más de quin-
ce años trabajó en el sector privado,
ejerciendo como consultora senior
analista en business intelligence y co-
mo responsable de tesorería. Desde
2011 es responsable de la Unidad
de Proyectos Europeos de la Dipu-
tación de Tarragona. Compagina su
actividad profesional con la de do-
cencia en la Universitat Oberta de
Catalunya (UOC) y en la URV.
El encargo y la creación de este recurso de aprendizaje UOC han sido coordinados

por el profesor: Josep Cobarsí Morales (2020)
Primera edición: febrero 2020

© Emma Gorgori Bonet
Todos los derechos reservados
© de esta edición, FUOC, 2020
Av. Tibidabo, 39-43, 08035 Barcelona
Realización editorial: FUOC
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea este eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares de los derechos.
© FUOC • PID_00270735 Caja de herramientas para tu proyecto y presentación
Índice
Introducción............................................................................................... 5
1. Conceptualización de la presentación.......................................... 7
1.1. Preguntas clave ............................................................................ 7
1.2. Herramientas para esta fase ........................................................ 7
1.3. Resultados .................................................................................... 7
2. Estructura y organización de la presentación........................... 9

2.1. Preguntas clave ............................................................................ 10
2.3. Resultados .................................................................................... 11
3. Diseño de la presentación................................................................ 12
3.2. Herramientas UOC para grabar vídeo y audio ........................... 14
3.3. Resultados .................................................................................... 15
4. Exposición y grabación de la presentación................................ 16

4.2. Recomendaciones ........................................................................ 16
4.3. Conclusión final .......................................................................... 17
Bibliografía................................................................................................. 19
© FUOC • PID_00270735 5 Caja de herramientas para tu proyecto y presentación
Introducción
La exposición no es solo un medio funcional de comunicar, sino que contri-

buye a informar, ilustrar, facilitar la decisión y fomentar el debate y aspectos
como entusiasmar, persuadir, cuestionar y motivar.
Este documento nace con la voluntad de proveer una referencia a modo de ca-
ja�de�herramientas que permita a los estudiantes de la asignatura Integración
de sistemas de información (ISI) conocer y valorar diferentes opciones dispo-
nibles para presentar los contenidos de las presentaciones gráficas, de la mejor
manera posible, de acuerdo con las nuevas tendencias y modelos disponibles
en el mercado y en el entorno UOC, completando así la propia experiencia y
las técnicas para preparar presentaciones.
A la vez, la caja de herramientas que os presentamos pretende facilitar las ta-

reas de ordenación y presentación de los materiales, favoreciendo que los es-
tudiantes hagan su aportación de valor con una presentación gráfica sencilla
pero llena de contenido.
1. Conceptualización de la presentación
Esta es la etapa inicial y a la que dedicaremos un tiempo considerable. El foco

de esta primera fase de trabajo se centra en recopilar todo aquello que pensa-
mos que necesitaremos para nuestra presentación de acuerdo con el objetivo
global que pretendemos alcanzar.
1.1. Preguntas clave
Para centrar bien el trabajo en esta fase, formularemos las preguntas siguientes:
• ¿Cuál es el objetivo de la presentación?

• ¿A quién nos dirigimos? ¿Cuál es la audiencia?
• ¿De cuánto tiempo dispongo? ¿Cuál es la duración deseada?
• ¿Qué recursos necesito?
En definitiva, ¿cuál es el�mensaje que queréis transmitir a vuestra audiencia

una vez finalizada la presentación?
Podemos pensar en cuáles son las tres cosas que querríais que recorda-
ran cuando finalice la exposición. Cómo podemos hacer que sea intere-
sante.
1.2. Herramientas para esta fase
• Libreta con notas.

• Gestores de notas: Evernote dispone de un plan gratuito y otros de pago
con más funcionalidades.
1.3. Resultados
En esta etapa obtendremos un primer borrador con las ideas principales y se-
cundarias (alcance), las tareas que hay que llevar a cabo y los plazos de ejecu-
ción (tiempo), además de la relación de los recursos necesarios, materiales hu-
manos, económicos y de información (coste). También podemos determinar
riesgos y dependencias. En definitiva, podríamos decir que determinamos el
triángulo�de�la�gestión�de�proyectos.
Figura 1. Triángulo de la gestión de proyectos
Fuente: elaboración propia.

2. Estructura y organización de la presentación
Esta etapa se inicia con la visualización mental de nuestra presentación ideal.

Cualquier construcción, antes de pasar al plano físico, primero pasa por un
plano mental.
En primer lugar, reuniremos todas las ideas que tengamos sobre el tema, de
manera exhaustiva y amplia y que hayamos elaborado en la fase anterior.
A continuación, debemos organizar y estructurar toda esta información de

manera lógica, por ejemplo, de acuerdo con las respuestas que hemos obtenido
de las preguntas formuladas en la fase anterior. Después podemos trabajar el
contenido y el continente a la vez, utilizando un esquema lineal, formando
una estructura dividida en diferentes partes, por ejemplo:
• Introducción.
• Mensaje.
• Evidencia.
• Conclusiones/Cierre.
En la introducción, la apertura es el momento más crítico porque hay que

llamar la atención, crear confianza e invitar a continuar. En este punto, se
introducen los contenidos y se presenta el tema principal.
A continuación, se plantea el mensaje principal, se concentra la atención de

la audiencia haciendo una declaración de intenciones y se argumenta el tema
principal.
El uso de las evidencias es una técnica para «convencer» sobre el mensaje o

idea principal y se puede realizar con ejemplos, datos estadísticos, demostra-
ciones, relatos de experiencias propias o conocidas, testimonios, analogías u
otros tipos de informaciones.
En el cierre o conclusiones, hay que provocar una impresión positiva y de im-

pacto, relacionándolo con la apertura. Se pueden utilizar repeticiones, recapi-
tulaciones, pasos siguientes, acciones previstas, beneficios esperados e, inclu-
so, proponer un desafío o expresar una premonición.
En esta etapa también redactaremos el guion y las notas complementa-

rias, y visualizaremos cómo irán fluyendo los contenidos a lo largo de
la presentación.
2.1. Preguntas clave
Para centrar bien el trabajo en esta fase, formularemos las preguntas siguientes:
• ¿Cuántas diapositivas/páginas tendremos?
• ¿Cuántas subdivisiones haremos en cada apartado?
• ¿Qué contenido, tiempo, detalle y dimensión dispondremos para cada una

de ellas?
• ¿Qué medios audiovisuales/recursos técnicos utilizaremos: vídeos, enlaces,

audios, fotos, casos reales, frases, etc.?
• ¿Cómo presentaremos la información estadística y los datos: gráfico de

barras, línea, circulares, histogramas, mapas, pictogramas, etc.?
Guy Kawasaki, ejecutivo de marketing en Silicon Valley, dice que las presen-
taciones con PowerPoint deben seguir la regla del 10/20/30 y propone que la
presentación no tenga más de 10 diapositivas y 10 ideas principales, que no
dure más de 20 minutos y que la letra no sea menor de 30 puntos.
Sin embargo, hay otros métodos o estilos de presentaciones, basados en la sim-

plicidad, las frases cortas y los aspectos visuales, como por ejemplo el método
Takahashi y el método Lessig. Otros serían el método Godin, que se centran
en el diseño, o el método Monta, que se centra en preguntas y respuestas a
todos los elementos visuales.
Si no se quiere utilizar ningún método, una estimación típica es dedicar entre

1 y 2 minutos a cada diapositiva.
Recordad que las personas solo podemos tener atención plena en una
cosa durante 10 minutos seguidos.
• Papel DIN A3 para dibujar tu presentación.

• Herramienta de mapa mental: Freemind, MindMeister, XMind.
2.3. Resultados
En esta etapa se creará una primera estructura de la presentación, obtendre-

mos el continente o los apartados determinados de la presentación, a falta de
desarrollar los contenidos, que se finalizarán en la fase siguiente. También de-
terminaremos aquí los medios y recursos técnicos que debemos utilizar.
3. Diseño de la presentación
Es la fase que consiste en obtener una versión final de todo el material audio-
visual y contenido que hemos recabado en la fase anterior. Este material ha de
encajar en la estructura previamente determinada, buscando un diseño atrac-
tivo y ameno.
Hay que tener en cuenta los aspectos referentes al impacto que queremos
causar a la hora de diseñar una presentación, y pensar en primer lugar qué
queremos transmitir y destacarlo a nuestra audiencia, especialmente si es un
tema muy técnico o con una determinada complejidad.
Las presentaciones tienen un cierto arte de captación y convencimiento de

la idea que queremos transmitir, dado que la capacidad de atención de la au-
diencia es limitada. Hoy, el exceso de información hace que seamos mucho
más selectivos a la hora de valorar una presentación y los aspectos innovado-
res. El factor sorpresa y los principios psicológicos nos pueden ayudar a hacer
una presentación más efectiva.
En esta fase se eligen los medios�audiovisuales, en el supuesto de que estos

no vengan predeterminados por la propia PEC, además de otros aspectos que
también hay que tener presentes: aspectos� gráficos� y� de� texto, el tipo de
fuente para el texto, la medida de la letra, el tipo de marcadores (bullets), los
colores de la presentación, gráficos, tablas, etc.
Es importante que haya consistencia a lo largo de todo el texto o presentación:
• Emplear la misma medida y tipo de letra en cada título y dentro de ca-

da apartado, salvo que haya una razón justificada para lo contrario, por
ejemplo una cita textual.
• Emplear el mismo margen y espaciado interlineal a lo largo del texto.
• Emplear los mismos marcadores (viñetas o números) en los diferentes

apartados.
• La posición de la sangría y los tabuladores deben ser consistentes en cada

nivel.
• Los gráficos, tablas, figuras, etc., tienen que llevar título. Si se da el caso,
pueden llevar pie o leyenda y hay que citar la fuente de la que provienen,
si no es de elaboración propia. Se recomienda numerar cada elemento en
el texto para facilitar su localización.
También es importante considerar los aspectos�más�emocionales, como por

ejemplo comunicar de manera empática, evitando tanto términos coloquiales
como argot técnico. Es recomendable añadir un pie de página o un glosario de
términos como parte del documento, especialmente si hay abreviaturas, siglas
o símbolos.
Y también lo es la parte�visual, huyendo si es posible de las plantillas e imáge-

nes prediseñadas de los programas de presentación que veremos a continua-
ción, y procurando hacer nuestras propias plantillas.
La imagen y las fotografías son un recurso muy poderoso, que hay que relacio-
nar con el contenido, y de este modo puede sustituir una gran parte de texto,
provocando, incluso, emociones y facilitando una comprensión mucho más
rápida y de impacto, generar expectativas y causar el interés de la audiencia.
En cuanto a los medios�audiovisuales, son un aspecto muy importante, dado

que su elección y puesta en práctica puede aumentar el impacto, ayudar a
la explicación de conceptos difíciles, captar la atención de la audiencia y, en
definitiva, incrementar las posibilidades de éxito del tema elegido.
Hay que conocer las ventajas y los inconvenientes de los diferentes me-
dios de presentación antes de hacer la elección.
En el apartado siguiente relacionaremos, a título de ejemplo, algunos de los

medios audiovisuales genéricos que están disponibles en el mercado para la
realización de presentaciones y, en concreto, profundizaremos en los que la
UOC pone a disposición de su comunidad para este fin.
• Powerpoint Online (Microsoft) versión gratuita dentro de One Drive.

• Keynote (Apple).
• Prezi.
• Google Slides.
• Canva.
• Sway.
• VideoScribe.
• Knovio, orientada a presentaciones en vídeo.
• Emaze.
En cuanto a incrustar imágenes en la presentación, a continuación podemos

encontrar una relación de bancos�de�imágenes donde encontrar recursos vi-
suales:
• Freeimages.
• morgueFile.
• IStock Photo.
• shutterstock.
3.2. Herramientas UOC para grabar vídeo y audio
A continuación encontraréis algunas herramientas de la UOC que permiten

grabar audios y vídeos y colgarlos en el aula:
• Present@: permite grabar y colgar fácilmente vídeos breves. Podréis usarla

para grabar vuestros vídeos o para ver videotutoriales, explicaciones de
conceptos clave o aclaraciones de dudas por parte del profesor colaborador.
Se utiliza a menudo para presentar los trabajos finales.
Encontraréis el tutorial que os indica los pasos que hay que seguir en el
enlace siguiente: http://blogs1.uoc.es/aules/files/2015/06/TutorialPresen-
ta-cat_CA.pdf.
• Langblog: es un blog de entradas de audio y de vídeo que permite grabar

y colgar fácilmente archivos de voz y vídeos personales.
Permite bajar de manera automática todas las grabaciones que se vayan
publicando, de manera que se puedan exportar a un dispositivo móvil y
escucharlos sin estar conectados a internet.
Se utiliza mucho en las asignaturas de idiomas, dado que permite practicar
la expresión oral y hacer comentarios de los audios y vídeos publicados.
Encontraréis el tutorial que os indica los pasos que hay que seguir en el en-
lace siguiente: http://blogs1.uoc.es/langbloghelp/files/2013/01/interven-
ci%C3%B3_video_LANGblog_ESP.pdf.
• VideoPAC: permite enviar las actividades (PEC) en formato de vídeo o

audio individualmente al aula.
Encontraréis el tutorial en pdf sobre cómo grabar un vídeo con
esta herramienta en el enlace siguiente: http://aula.blogs.uoc.edu/fi-
les/2013/07/Com-enregistrar-un-v%C3%ADdeo.pdf.
• Videoflow: es la aplicación que permite insertar grafismos y editar los ví-

deos. Para acceder a ella, es necesario que os den acceso al grupo de trabajo
del campus.
Encontraréis el tutorial en pdf y en vídeo para usar esta aplicación de
inserción de grafismos UOC en los vídeos en el enlace siguiente: http://
videoedu.blogs.uoc.edu/2013/02/12/video-flow/.
La UOC dispone de un espacio donde podéis aprender a crear los vídeos do-
centes y que detalla los aspectos en cuanto al material audiovisual producido
desde la UOC, derechos de autor y derechos de imagen que necesitáis tener
presentes.
A continuación encontraréis un cuadro resumen que indica las opciones más

básicas que permite cada herramienta que hemos indicado:
Herramienta Diapositivas Audio Vídeo
Powerpoint Sí Se puede incrustar Se puede incrustar
Keynote Sí No No
Prezi* Sí Sí Sí
Google slides Sí Sí Sí
Canva Sí Se puede incrustar Se puede incrustar
Sway Sí Se puede incrustar Se puede incrustar
VideoScribe Sí Sí Sí
Knovio Sí Sí Sí
Emaze Sí Sí Sí
Present@ No Sí Sí
Langblog No Sí Sí
VideoPAC No Sí Sí
Videoflow No Sí Sí
* Versión de pago.
Fuente: elaboración propia.
Hay que revisar o leer en voz alta el texto final con objeto de corregir la
sintaxis, la tipografía y las posibles frases que no se acaben de entender.
3.3. Resultados
En esta etapa obtendremos los contenidos estructurados, redactados y forma-

teados dentro de la estructura propuesta en la fase anterior, y también el medio
o medios que vehicularán la puesta en escena de la presentación.
4. Exposición y grabación de la presentación
Esta etapa tiene lugar cuando el usuario presenta el resultado del trabajo ela-
borado en la fase de diseño a una audiencia determinada mediante la secuen-
cia de formatos multimedia, que pueden ser imágenes, vídeo, audio, texto, etc.
Así pues, la exposición puede combinar la presentación con una voz en audio
o un texto explicativo que amplía los contenidos expuestos.
• Storytelling.
• Preguntas.
• Metáforas.
• Analogías.
• Fragmentos de películas.
• Cuentos.
• Vídeos.
• Música.
• Humor.
• Misterio.
• Ejemplos.
• Datos estadísticos y cuadros comparativos.
• Citas.
• Attrezzo, objetos, dibujo en directo cuando estamos ante una audiencia de
forma presencial.
4.2. Recomendaciones
En esta fase hay que tener presente los aspectos siguientes:
• Demostrar seguridad con los contenidos y materiales, incluso los que co-
nozcamos poco.
• Presentar el material escrito de modo que sea atractivo.
• Encontrar maneras para que sea innovador, superando las barreras de la

presentación en el formato elegido. Hay que demostrar seguridad, pasión
y entusiasmo respecto a aquello que queremos transmitir.
Los objetivo finales deben ser:
• Convencer.
• Ser influyentes.
• Comunicar.
• Liderar promoviendo la acción.
Según Dale Carnegie, la manera más efectiva de conmover a un auditorio no

es de manera casual sino por medio de lo que denominó la «fórmula mágica».
Las claves para una fórmula mágica efectiva en términos de la distribu-

ción de tiempo en una presentación son las siguientes:
• Evidencia: 90 %
• Acción: 5 %
• Recomendación/beneficio: 5 %
4.3. Conclusión final
• Identificad a la audiencia y adaptad el lenguaje técnico.

• Determinad qué queréis comunicar, intención y propósito.
• Estructurad la información que debéis transmitir.
• Utilizad recursos audiovisuales que aporten claridad y comprensión.
• Cuidad tanto los contenidos como los formatos.
• Innovad.
Bibliografía
Atkinson, C. (2007). Beyond Bullet Points. Washington: Microsoft.
Alvárez Marañon, G. (2012). El arte de presentar. Barcelona: Gestión 2000.
Beneito Montagut, R. (2005). Presentación de documentos y elaboración de presentaciones.

Barcelona: UOC.
Manchester Open Learning (1995). Cómo hacer presentaciones eficaces. Barcelona: Gestión
2000.
Webgrafía
https://www.elartedepresentar.com/
https://www.presentationzen.com/
http://www.presentable.es/consejos-practicos/20-1-recursos-que-puedes-utilizar-en-tus-
presentaciones/
https://hellocreatividad.com/como-hacer-presentaciones-efectivas/
https://visme.co/blog/programas-para-hacer-presentaciones/
http://www.cronomaquia.com/el-gestor-de-tareas-y-pendientes-perfecto/
https://www.ub.edu/cub/criteri.php?id=270
Tecnologías de
la información
y procesos de
negocio
José Ramón Rodríguez
Ignacio Lamarca
PID_00198546
CC-BY-NC-ND • PID_00198546 Tecnologías de la información y procesos de negocio
La revisión de este material docente ha sido coordinada

por el profesor: José Ramón Rodríguez (2012)
CC-BY-NC-ND • PID_00198546 Tecnologías de la información y procesos de negocio
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 6
1. La gestión de la empresa por procesos......................................... 7
2. Reingeniería de procesos.................................................................. 10
2.1. Selección de los procesos de reingeniería ................................... 11
2.2. Identificación de los facilitadores del cambio (o "palancas") ...... 12
2.3. Desarrollo de una nueva visión de los procesos ......................... 13
2.4. Valoración de los procesos actuales ............................................ 14
2.5. Diseño y prototipo de nuevos procesos ..................................... 14
2.6. Conclusiones ............................................................................... 14
3. Los sistemas de información de las empresas............................ 16

3.1. Los sistemas de gestión de procesos internos (ERP) ................... 20
4. Los sistemas de empresa basados en la colaboración en

Internet................................................................................................. 25
4.1. Los sistemas de gestión de clientes: CRM ................................... 27
4.1.1. Ventajas de un sistema CRM ......................................... 28
4.1.2. Procesos de gestión ........................................................ 30
4.2. Los sistemas de gestión de la cadena de suministro (SCM) ........ 33
4.3. Sistemas de comercio electrónico ............................................... 37
4.3.1. Tipos de comercio electrónico ....................................... 38
4.3.2. Procesos de comercio electrónico .................................. 39
4.3.3. Factores de éxito en el comercio electrónico ................. 41
Resumen....................................................................................................... 43
Bibliografía................................................................................................. 45
CC-BY-NC-ND • PID_00198546 5 Tecnologías de la información y procesos de negocio
Introducción
En los módulos anteriores hemos examinado la relación entre la estrategia

de empresa y los sistemas y tecnologías de la información. Tradicionalmente
los SI/TI soportan y automatizan las transacciones de la empresa, pero en la
actualidad, además, pueden ayudar a transformar los procesos internos del
negocio (la cadena de valor) y las relaciones con clientes, proveedores y socios
(la cadena de valor extendida), para obtener ventajas sobre los competidores.
La reingeniería representa la introducción de cambios radicales en los proce-

sos de la cadena de valor (en cada proceso y en la relación entre unos y otros)
mediante la aplicación de herramientas de organización y/o de tecnología. Es-
to se puede hacer mediante un ejercicio artesanal y ad hoc de análisis e iden-
tificación de mejoras o mediante la utilización de soluciones disponibles en
el mercado que supuestamente contienen en su interior una "enciclopedia"
de mejores prácticas empresariales. Seguidamente hay que adaptar la organi-
zación a estas maneras de hacer. Es el mundo de los ERP (modelos de infor-
mación integrales que intentan presentar soluciones completas para toda la
cadena de valor de uno o varios sectores industriales) y el de las soluciones
específicas para determinados procesos de negocio: soluciones para la cadena
de aprovisionamientos (SCM), la gestión de relaciones con los clientes (CRM),
los recursos humanos, la gestión económico-financiera, etc.
La aparición y utilización intensiva de Internet en las relaciones de negocio (el

mundo del negocio electrónico o e-business) ha representado oportunidades
adicionales y disruptivas para transformar los procesos internos y la relación
con terceros.
En este módulo presentaremos los conceptos básicos de la gestión por procesos

y la reingeniería, y también las aplicaciones disponibles de gestión de los dife-
rentes procesos de la cadena de valor, incluidos los sistemas de empresa o ERP.
En el módulo siguiente presentaremos el enfoque y las soluciones para la ges-

tión de la información y el conocimiento interno y externo de la empresa,
cuya importancia estratégica ha ido creciendo a largo de los últimos años.
El objetivo de este módulo no es describir las diferentes soluciones existentes

de soporte a los procesos de negocio, que ya se examinan en otras asignaturas
de diferentes programas, sino más bien reflexionar sobre su valor estratégico
y transformacional para los negocios y las organizaciones de todo tipo.
Objetivos
El objetivo de este módulo es entender la visión de la empresa por procesos y el

concepto de reingeniería como base para el desarrollo de los nuevos sistemas
de información empresarial, y mostrar cómo estas aplicaciones actúan en la
gestión de los procesos y en la gestión de las relaciones de la empresa con
clientes y proveedores.
Para lograr esta finalidad, los estudiantes deberán lograr los objetivos que de-
tallamos a continuación:
1. Entender qué es un proceso y su contexto en la cadena de valor. Analizar

cuáles son las principales técnicas que permiten rediseñar y mejorar los
procesos empresariales.
2. Entender cuál ha sido la aportación de los sistemas de empresa (entre otros,

el ERP) y las oportunidades y retos de instalar un sistema de esta natura-
leza.
3. Entender cómo la aparición de la conectividad y las nuevas tecnologías

ha afectado a la manera de hacer negocio de las empresas. Comprender
cómo estas gestionan los procesos internos, cómo se relacionan con sus
clientes, cómo manejan la cadena de suministro y la producción con los
aliados y proveedores.
1. La gestión de la empresa por procesos
Desde la década de los ochenta, la aparición del concepto de cadena�de�valor

(Porter, 1985) ha facilitado el desarrollo de nuevas prácticas de mejora radical
de los procesos de negocio en las empresas. La cadena de valor, tal como hemos
visto en el módulo "Tecnologías de la información y estrategia de empresa"
de esta asignatura, está constituida por procesos múltiples que, integrados,
conforman la creación de riqueza en las empresas. Las empresas aprovechan
las tecnologías de la información para transformar la cadena de valor y obtener
ventajas significativas (de coste, de calidad, de rapidez de entrega, etc.) sobre
los competidores:
Figura 1. La cadena de valor

Orientación
La aportación de la tecnología
como soporte y transforma-
ción de los procesos en el por-
tafolio de IT (podéis ver la ma-
triz de McFarlan) se debe es-
tudiar en el módulo "Decisio-
nes estratégicas en sistemas y
tecnologías de la información"
y el concepto de la cadena de
valor y procesos de negocio,
tal como fueron teorizados por
Porter (capítulo 2), en el mó-
dulo "Tecnologías de la infor-
mación y estrategia de empre-
Fuente: M. Porter (1985) sa".
Un proceso es un conjunto de actividades que permiten transformar

un conjunto de inputs en resultados útiles para la organización y para
sus clientes.
Ejemplo
Un proceso puede ser la cadena de montaje de las piezas de un automóvil, la preparación

de una hamburguesa en una cadena de comida rápida, la fermentación de una cerveza,
etc. El conjunto de procesos de la organización podemos denominarlo sistema�operativo
o sistema�de�operaciones
Andreu, Ricart y Valor (2000).
Los procesos, como implican secuencias de actividades, tienen asociados el

consumo de recursos y dedicaciones y representan, por tanto, un coste para la
organización, el cual repercute en el coste del producto o productos acabados
de la empresa. Como muestra, y siguiendo el ejemplo anterior, la preparación
de una hamburguesa tiene el coste de la materia prima, el coste asociado a la
elaboración, etc.
Asimismo, los procesos tienen "propietarios" que responden de aquellos y de

sus resultados y también "clientes", internos o externos, ante los cuales han
de responder. Por ejemplo, en una cadena de montaje de un automóvil, el
responsable del proceso de pintura es un cliente del acabado de chapa anterior
y, por su parte, dispone de clientes en los pasos posteriores de la cadena.
La gestión�de�procesos tiene que ver en definitiva con todos estos as-

pectos y se puede definir como el conjunto de medios por los cuales la
gente, los recursos, los equipos, los procedimientos, los métodos y las
herramientas se integran para producir un resultado final.
La tabla siguiente recoge las diferencias que la gestión por procesos ha apor-
tado a la gestión empresarial (Edwards y Ward, 1998). Ya se ve que la gestión
por procesos no es exclusivamente una herramienta de gestión de costes (los
sistemas ABC, activity based costing) o de mejora continua de la calidad (los
sistemas TQM, total quality management), sino que también supone un cambio
en la manera de hacer de las empresas y en su cultura interna: sustituir una
visión de la empresa ligada a unidades funcionales y de producto, aisladas e
independientes, por un sistema integrado de operaciones que tienen un clien-
te y del cual se obtiene un valor (margen). En definitiva, una nueva cultura
de empresa:
Tabla 1. Comparación entre pensamiento tradicional y pensamiento orientado a procesos
Orientación�tradicional Aspecto Orientación�a�procesos
Interno Enfoque de negocio Cliente
Jerárquica Organización Matricial
Difuso Contacto con cliente Punto único
Control Papel del directivo Facilitador
Stocks intermedios Trabajo en curso Justo a tiempo
Funcional Medida del rendimiento Cliente
Eficiencia interna Información y sistemas Eficiencia externa
Fuente: Edwards y Ward (1998)
Todos los procesos y actividades de la cadena de valor, primarios o secunda-

rios, generan información. Por definición, los sistemas�de�información ac-
túan sobre toda la cadena de valor, soportando las operaciones contenidas en
cada proceso, y permiten relacionar y coordinar unos procesos con los otros.
Por ejemplo, la información de las reclamaciones hechas por los clientes pue-
de ser muy interesante para el diseño y la fabricación de mejores productos
industriales.
Actualmente no se puede pensar en la gestión de la empresa por proce-

sos, o en ejercicios de mejora o reingeniería, sin el papel facilitador y
transformador de los sistemas de información.
Como veremos más adelante, los sistemas de información de la empresa (ERP,

CRM y otros) facilitan la introducción de la gestión por procesos y de ejercicios
de reingeniería y transformación empresarial de diferente alcance, tanto en la
cadena de valor interna como en la relación de la empresa con clientes, socios
y proveedores en la cadena de valor extendida. Asimismo, la relación entre los
diferentes agentes en un mundo hiperconectado está dando lugar a modelos
de negocio completamente nuevos.
2. Reingeniería de procesos
La reingeniería de una empresa es un concepto fundamentalmente ligado al

cambio radical de los procesos de negocio de una compañía.
Tal como la definieron Hammer y Champy (1993), la reingeniería de

procesos es el "replanteamiento fundamental y el rediseño radical de los
procesos de negocio para lograr mejoras sustanciales en los indicadores
críticos de resultados, como por ejemplo el coste, la calidad, el servicio
y la rapidez".
Normalmente, las organizaciones están estructuradas en departamentos estan-

cos, unidades funcionales o unidades de producto en las que no hay una res-
ponsabilidad directa o única sobre procesos en los que participan diferentes
departamentos. Por ejemplo, situaciones habituales pueden ser sobreproducir
un producto porque no se dispone de una información ajustada de mercado,
diseñar un producto poco adaptado a las necesidades del cliente, o tener rup-
turas de stock porque no se dispone de información ajustada de pedidos.
Según lo que hemos visto en el módulo "Tecnologías de la información y es- Ved también
trategia de empresa", cada proceso de la cadena de valor, en especial los que
Podéis ver el epígrafe "El core
denominábamos de core business, involucran diferentes departamentos y, por business de la empresa", en el
tanto, una parte del éxito está en la coordinación entre ellos. subapartado "La cadena de va-
lor".
En un ejercicio de reingeniería empresarial, los vínculos entre los pro-

cesos se rediseñan hasta reconfigurar la cadena de valor de la empresa,
lo que da lugar a ventajas competitivas sostenibles.
La reingeniería se diferencia de las técnicas de mejora incremental en el hecho

de que, mientras que estas se centran en procesos muy concretos y detallados
de la operación (subprocesos, actividades, trámites, etc.) y, por tanto, los be-
neficios de la mejora son limitados (y de bajo riesgo), la reingeniería se centra
en los procesos más amplios de la organización, actuando con un principio de
cambio radical que requiere una dimensión crítica necesaria para conseguir el
efecto deseado (tabla 2). Como se muestra en la tabla, el principal facilitador
de un ejercicio de reingeniería son las tecnologías de la información (Daven-
port, 1993).
En la práctica, y en la mayoría de las empresas, los ejercicios de transformación Nota

radical son puntuales y obedecen a momentos críticos del negocio, mientras
Popularmente, los ejercicios
que los ejercicios de mejora son continuos y deben estar imbuidos en la cultura de reingeniería han sido aso-
interna. La generalización de determinadas aplicaciones empresariales (ERP y ciados con las operaciones de
reducción radical de recursos
aplicaciones estándar de negocio electrónico) ha extendido rápidamente las (reestructuraciones, desmante-
lamiento de empresas) propios
ventajas de la reingeniería de procesos de una organización a la otra y, hasta del inicio de los noventa, pe-
ro esta acepción no tiene nada
cierto punto, ha eliminado las ventajas obtenidas por los primeros actores. que ver con el concepto técni-
co de reingeniería.
Tabla 2. Diferencias entre reingeniería de procesos y mejora incremental
Reingeniería Mejora incremental
Nivel�de�cambio Radical Incremental
Punto�de�inicio Tabula rasa Proceso existente
Participación De arriba abajo De abajo arriba
Alcance�típico Amplio, interfuncional Ajustado, dentro de funciones
Riesgo Alto Moderado
Posibilitador�principal Tecnologías de la información Control estadístico
Tipo�de�cambio Cultural y estructural Cultural
Fuente: Davenport (1993)
Los proyectos de reingeniería incorporan normalmente cinco etapas de trabajo

que veremos en detalle en los apartados siguientes:
Figura 2. Etapas de la reingeniería de procesos
Fuente: Elaboración propia
2.1. Selección de los procesos de reingeniería
La reingeniería se debe iniciar con la correcta identificación y selección de los

procesos involucrados en el ejercicio. Esto prevé las actividades siguientes:
• La enumeración,�identificación�y�mapeo de los principales macroproce-

sos de la compañía, no más de diez o veinte en un proceso de reingenie-
ría: el número de procesos ha de estar relacionado con la capacidad de
gestionar la interdependencia de estos y con la capacidad de gestionar un
alcance manejable.
• La definición�de�los�límites�y�las�fronteras de los procesos, una vez que

los procesos han sido identificados a alto nivel. Este es un trabajo explora-
torio e iterativo, y no exento de arbitrariedad. Por ello hay que considerar
un conjunto de preguntas seleccionadas del tipo: ¿cuándo el propietario

del proceso se siente preocupado y cuándo deja de estarlo?, ¿cuándo se
inician los subprocesos relacionados?, ¿está el proceso integrado dentro
de un proceso más amplio?, ¿se pueden conseguir otros resultados combi-
nando los procesos o subprocesos de una manera diferente?
• La selección y priorización de los procesos, una vez que los procesos han
sido identificados y definidos con propiedad. El esfuerzo de actuación so-
bre los procesos debe estar directamente relacionado con las capacidades
y los recursos de la organización. Algunas grandes organizaciones, como
IBM o GE, han actuado en proyectos de reingeniería con múltiples proce-
sos a la vez, pero la mayoría de las empresas no dispone ni de la coordi-
nación ni de los recursos materiales y humanos, ni del presupuesto ni del
tiempo para actuar con un alcance tan amplio.
Por ello la mayoría de las empresas seleccionan un conjunto mínimo de pro-

cesos en los que actuar, según los criterios estratégicos que tengan. Una buena
guía de criterios para la selección puede ser la importancia del proceso para
la consecución de los objetivos de negocio, la situación del proceso en la ac-
tualidad, la cultura y liderazgo asociado, el coste incurrido y la manejabilidad
del alcance.
Reingeniería de un hospital
Muchos hospitales han abordado procesos radicales de reingeniería importantes pero se-
lectivos en los últimos años: la centralización de los servicios de admisión y gestión de
pacientes, la eliminación de los almacenes periféricos de farmacia o material sanitario y
circuitos paralelos de gestión de suministros, la creación de servicios de urgencias exter-
nos al propio hospital para gestionar patologías no críticas, etc.
2.2. Identificación de los facilitadores del cambio (o "palancas")
Una vez que el proceso ha sido seleccionado para reingeniería, un equipo de

diseño puede orientar el modo como una nueva estructuración de las activi-
dades y de los recursos que las soportan puede facilitar el cambio. Esto implica
las siguientes acciones:
• Valorar�el�papel�de�las�tecnologías de la información en la reingeniería,

que no solo posibilita la implantación de los nuevos procesos, sino que
incluso es un elemento directo impulsor y condicionante de su transfor-
mación. Por ello, la información debe ser considerada antes, durante y
después del proceso de reingeniería. Hablaremos de ello en los próximos
apartados.
• Valorar� el� impacto� que� los� cambios� pueden� tener� en� las� estructuras
organizativas, por ejemplo, mediante el trabajo interfuncional (como en
el diseño de un nuevo automóvil), la adquisición de nuevas habilidades
(como las habilidades de atención al público), o la definición de puestos
de trabajo nuevos (como, por ejemplo, para la atención telefónica), puede

ser una aportación para la transformación de los procesos empresariales.
Reingeniería de un hospital: papel de la tecnología
En el caso del hospital que comentábamos antes, por ejemplo, la creación de un servicio
central de admisión requiere disponer de un aplicación que gestione todos los recursos
del hospital (camas, consultas, salas de operaciones, agenda de los médicos, etc.) y de un
departamento autorizado, muy tecnificado y con capacidad de decisión (normalmente
dependiente de la gerencia del hospital o de la dirección médica) que decidan las políticas
adecuadas.
2.3. Desarrollo de una nueva visión de los procesos
El núcleo central de la reingeniería es el diseño de los nuevos procesos empre-

sariales. Para crear la nueva visión de los procesos de la compañía es necesario
tener en cuenta:
• La referencia�a�la�estrategia�y�objetivos�de�negocio�más�generales de
la compañía, con los que el nuevo proceso tiene que estar alineado. Por
ejemplo, si el objetivo de una compañía hotelera es posicionarse en el
mercado urbano, construir sistemas de acceso directo para el comprador
de estos servicios.
• La colaboración�con�clientes�y�proveedores en la formulación de proce-

sos que mejoren los resultados de las relaciones entre empresas.
• La revisión� de� las� mejores� prácticas� y� experiencias de éxito de otras

empresas en el proceso.
• La formulación� de� objetivos� de� negocio� claros� para� el� proceso. Por
ejemplo, reducir el tiempo de puesta en el mercado en un 50% en un año,
reducir el coste de producción en un 15% en cinco meses, etc.
• La descripción�básica�de�los�atributos o características básicas del nuevo

proceso.
Reingeniería de un hospital: visión, objetivos, indicadores
En el caso del hospital, los objetivos de negocio tienen que ver, en primer lugar, con
mejorar la eficiencia en la utilización de los recursos, elevar la equidad de acceso (todos
los pacientes son iguales o diferentes según su patología pero no según su capacidad de
influencia) o eliminar bolsas de fraude. El modelo de gestión de camas se copió en un
primer momento de la gestión de los hoteles, aunque en la actualidad es mucho más
sofisticado. Los indicadores de éxito son la ocupación (porcentaje de camas ocupadas
sobre el total), la rotación (número de pacientes por recurso disponible), etc.
2.4. Valoración de los procesos actuales
A diferencia de los procesos de mejora continua, que parten del estudio de-
tallado del proceso actual para introducir mejoras, la reingeniería analiza la
situación actual de los procesos una vez que ya se ha visto cuál debería ser su
nueva realidad. Esto supone:
• Analizar�y�valorar�el�proceso�actual, incluyendo las actividades, los res-

ponsables, los participantes y los resultados, comparándolos con los nue-
vos objetivos definidos.
• Identificar�problemas existentes en la actualidad.
• Introducir en algunos casos mejoras a corto plazo.
Reingeniería de un hospital: iniciativas de mejora y transformación
Siguiendo con el ejemplo del hospital, algunas experiencias de mejora pueden consistir
en la gestión centralizada de los recursos (por ejemplo, gestionando por separado los
recursos más escasos y sofisticados, como los anestesistas o estableciendo una gestión
centralizada de camas que permita trabajar sobre cada patología para ver la posibilidad
de reducir cuantitativamente la estancia sin riesgos para el paciente). O bien, en el es-
tablecimiento de un sistema de alta anticipada (el médico da al paciente el alta el día
anterior con efectos al día siguiente, para que se pueda liberar la cama a primera hora),
o de un sistema de realización de análisis previos a una intervención el día antes y por
procedimiento ambulatorio que no requiere estancia, etc.
2.5. Diseño y prototipo de nuevos procesos
La última etapa de la reingeniería de procesos consiste en sintetizar toda la

información anterior, definir con más detalle las actividades y construir los
nuevos procesos. Esto implica:
• Valorar alternativas de diseño y definir la secuencia de actividades de los

nuevos procesos.
• Valorar las estructuras organizativas y de sistemas de información necesa-

rios de acuerdo con la nueva configuración de los procesos.
• Planificar e implementar la migración de la organización hacia los nuevos

procesos establecidos.
2.6. Conclusiones
El modelo y el método presentados deben permitir comprender las bases con-

ceptuales y metodológicas de cualquier proceso de reingeniería empresarial.
Estos principios también están imbuidos en los sistemas de información de
empresa (ERP, etc.) y en soluciones de nicho, pero muy pocas empresas los
abordan en toda su dimensión y radicalidad.
Nota
En los procesos de reingeniería importa más la visión del proceso en su
integridad que el análisis del proceso actual. El análisis actual permite Quizá el único enfoque radi-
cal de reingeniería es el que
mostrar el gap (la diferencia) o las oportunidades de cambio. empiezan a permitir los siste-
mas de gestión por procesos
(BPM, o business process mana-
gement), que introduciremos
En la práctica, la implantación de determinadas soluciones tecnológicas per- en el módulo siguiente.
mite ejercicios más rápidos de reingeniería "limitada", basados en las caracte-

rísticas de los productos, el uso de "buenas prácticas" de la industria, las habi-
lidades del implantador y del usuario y la continuidad (la "mejora continua")
en el tiempo.
Dos visiones diferentes de la reingeniería
Los dos libros de Thomas Davenport (1993 y 2000) pueden marcar precisamente la evo-
lución desde un concepto amplio de innovación o reingeniería basada en los procesos hasta
otro más práctico de reingeniería facilitada o limitada por los sistemas de información de em-
presa. La evolución entre uno y otro la marca probablemente la explosión en el mercado
a finales de los años noventa del siglo pasado de los ERP y otros sistemas de información
de empresa.
3. Los sistemas de información de las empresas
En este apartado y los siguientes recordaremos los aspectos más importantes Información adicional
de los sistemas de información de empresa, que ya habéis visto en otras asig-
Para una introducción a los
naturas, y nos pararemos especialmente en las implicaciones estratégicas que diferentes sistemas de infor-
la adopción de este tipo de sistemas tiene para los negocios, para la dirección mación de empresa, sus ca-
racterísticas funcionales y
de sistemas de información y para la interacción entre los dos. técnicas, los productos prin-
cipales del mercado y el ciclo
completo de implantación,
recomendamos los materiales
Los sistemas de información de empresa (SIE) son paquetes estándar de la asignatura Fundamentos
de sistemas de información.
que, en principio, cubren los procesos de trabajo habituales de cualquier También podéis ver A. Gó-
empresa en casi cualquier sector industrial, que se pueden adaptar (con- mez Vieites y C. Suárez Rey
(2006).
figurar) a las peculiaridades de cada negocio u organización concreta
mediante un menú de opciones (supuestamente de "buenas prácticas")
y que comparten una base de datos común para toda la empresa y pa-
ra las diferentes aplicaciones o módulos del sistema. También permiten
su integración con otras aplicaciones departamentales o el desarrollo a
medida de algunas funcionalidades que puedan no estar incorporadas
en el paquete.
La figura siguiente muestra de manera resumida el catálogo típico de los pro-

ductos que incluyen estos sistemas en la actualidad, pero la evolución es muy
rápida y da lugar continuamente a productos nuevos. Sistemas ERP clásicos
incorporan capacidades y módulos de otros sistemas y, al revés, surgen pro-
ductos de nicho que ocupan posiciones dominantes dentro de los ERP u otros
sistemas tradicionales:
Fuente: elaboración propia a partir de O'Brien y Marakas (2006)

El trabajo colaborativo en Internet, las arquitecturas basadas en servicios web,

las nuevas plataformas de aplicaciones en la nube, la externalización de pro-
cesos completos del negocio o el alquiler de espacio y servicios por uso están
modificando también el panorama de los sistemas de empresa. Actualmente,
la gestión de ventas y clientes también incluye las plataformas de comercio
electrónico. Las relaciones con socios permiten el intercambio de cualquier
tipo de datos sobre plataformas sencillas (los datos del padrón con los de Ha-
cienda, por ejemplo), o sistemas más complejos (como los que integran la
atención primaria con los hospitales o los programas de fidelización de las
empresas de ocio). Toda la parte de la izquierda de la imagen (la información y
los servicios para directivos y empleados) es un espacio tan enorme y variado
que lo veremos en el módulo siguiente, sobre la gestión de la información y
el conocimiento.
En los últimos años también han surgido suites generales o sectoriales o pro-
ductos adaptados a las necesidades de la pequeña y mediana empresa que cu-
bren la mayor parte de la funcionalidad necesaria para la gestión empresarial.
La figura siguiente muestra las características o los criterios de diseño de los

sistemas de información de empresa: la modularidad funcional, la arquitectura
cliente-servidor, la facilidad de uso, la adaptación y evolución, la posibilidad
de configuración y adaptación, etc.
Fuente: elaboración propia a partir de Kirchmer (1999)

Probablemente, el aspecto más importante de todos los sistemas de empresa

modernos es su grado elevado de integración: todos los procesos, funciones,
departamentos y empresas que utilizan el mismo software comparten los mis-
mos datos y utilizan la misma estructura de datos. El dato es único y se intro-
duce una sola vez.
Sin embargo, si nos alejamos un poco, lo que es realmente importante de la

adopción de un sistema de empresa, frente al trabajo tradicional de desarrollo
a medida, es que la empresa está dejando en manos de un fabricante externo y
de un implantador que también suele ser externo la provisión de los sistemas
que son críticos para cumplir su misión. Esto tiene consecuencias estratégicas
y operativas de importancia enorme y para siempre, tanto para el negocio
como para la informática. La empresa necesita, para las cosas buenas y para las
malas, adaptarse a las capacidades del paquete y abandonar una parte de sus
prácticas de trabajo anteriores y dependerá para siempre, excepto en casos muy
limitados de abandono, de la evolución funcional y técnica que introduzca el
fabricante del software.
Aspectos estratégicos de la adopción de sistemas de información de

Referencia bibliográfica
empresa
• Un sistema de información de empresa (SIE) es una "forma de vida" (en palabras de Revisión del libro de Daven-
Davenport) para el negocio y para las TI. Es una decisión estratégica de gran impacto port (2000) publicada en el
y para siempre, que modifica radicalmente la manera de trabajar de la organización y blog de los Estudios de Infor-
la arquitectura, la organización y la gestión de sus sistemas en sentido amplio (datos, mática de la UOC.
procesos e infraestructura). La decisión de adoptar o no un SIE, con qué alcance y Los análisis más recientes
velocidad, con qué tipo de implantación, con qué productos y socios, con qué lide- (por ejemplo, Gartner Re-
razgos y equipos, etc. no puede ser una decisión técnica derivada de la obsolescencia search, 2010) corroboran am-
de una aplicación u otra o la respuesta a la presión de un departamento o unidad de pliamente las previsiones de
negocio, a la moda del momento o a la presión comercial de los vendedores. Tam- Davenport.
bién, y por la misma razón, son decisiones que no acaban nunca.
• Los SIE tienen el potencial de transformar la organización internamente y su manera

de relacionarse con clientes, proveedores y socios. La universalidad y la integración
de la información, la verdadera conectividad y transparencia entre las secciones or-
ganizativas, la oportunidad de orientarnos al cliente y de trabajar por procesos, de
conocer la realidad (y la misma realidad para todos) y de tomar decisiones en tiempo
real, de allanar e integrar estructuras, etc. son oportunidades, quizá la primera opor-
tunidad, contenidas en el ERP o el resto de los sistemas de empresa.
• Paradójicamente, para tener éxito la empresa necesita adaptarse al máximo a las ca-
pacidades (y limitaciones) que le imponen los paquetes. En realidad, el ERP propone
un conjunto de buenas prácticas (good enough) a las que conviene adaptarse, para
limitar los cambios y los desarrollos a medida y los costes de mantenimiento y evo-
lución futuros. Esto reduce las especialidades o las maneras de hacer de cada uno y
también, a veces, la diferenciación o la ventaja competitiva de alguno.
• Un gran número de proyectos de implantación de sistemas de empresa fracasan en

tiempo, coste, calidad, rendimiento o uso efectivo por la organización, principalmen-
te por decisiones equivocadas en el momento de la adopción, por el enfoque de im-
plantación y extensión, por la falta de comprensión y colaboración de directivos y
usuarios o de los departamentos de sistemas, que han vivido muchas veces el ERP
como una amenaza para su estatus y, principalmente, por un patrocinio deficiente,
liderazgo y organización del proyecto.
• Todavía ahora, la mayoría de los proyectos no han conseguido los beneficios de ne-
gocio y poner en valor la inversión y el esfuerzo que han hecho. La mayoría de los
proyectos de éxito han triunfado en la automatización de las operaciones y proba-
blemente en la integración de la información, pero han fracasado en los intentos de
reingeniería, en la transformación organizativa y en la aportación de conocimiento
y resultados para el negocio, que fueron las promesas de los fabricantes, los implan-
tadores y los patrocinadores internos. Y tampoco han resultado más económicos.
Desde el punto de vista de la función informática y su organización, las con-

secuencias también son importantes. Cambian, en todo o en parte, los roles
de informáticos y usuarios, sus perfiles y capacidades profesionales, y también
el tipo de relación con el proveedor, tanto con el fabricante como con el im-
plantador:
• El poder comercial de un grupo pequeño de fabricantes (su capacidad para Ejemplo

definir funcionalidades, el tiempo de puesta en el mercado, los precios y
AUSAPE, la asociación de usua-
a veces la arquitectura entera) es enorme y solo puede ser contrarrestado rios de SAP en España, tiene
con estrategias más colectivas de asociación de empresas usuarias. grupos sectoriales y funciona-
les.
• El poder y la influencia de directivos y usuarios también es más grande

y normalmente se relacionan directamente con los vendedores y los im-
plantadores, tanto durante la compra como durante la ejecución del pro-
yecto.
• Efectivamente, aparece una tercera figura (el implantador) que se relacio-

na directamente con el usuario final para configurar o parametrizar el pro-
ducto y que acaba disponiendo del saber hacer (know-how) de los procesos
de trabajo y de las soluciones adoptadas en cada caso.
• El papel de los departamentos de informática, si no actúan inteligente-

mente o no disponen de la complicidad de los directivos y usuarios, se
puede ver marginado al de proveedor de la infraestructura. Sin embargo,
al mismo tiempo, después de la implantación se deberán hacer cargo de
la evolución de los paquetes o volverla a dejar en manos de proveedores
externos.
Por ello resulta muy importante entender el ciclo completo de adopción de Ved también
este tipo de sistemas para tomar las buenas decisiones durante la implantación,
Hemos desarrollado más ex-
pero sobre todo, antes y después, decisiones compartidas entre la dirección de tensamente estos conceptos
sistemas y los líderes de negocio. en el módulo "Implantación
de sistemas de información de
empresa", elaborado por José
Ramón Rodríguez y José María
En los apartados siguientes, presentaremos de manera resumida las caracterís- Joana, dentro de la asignatura
Fundamentos de sistemas de in-
ticas principales de cada tipo genérico de sistemas de empresa y su uso estra- formación.
tégico para el negocio. En el módulo siguiente, mostraremos por separado las
soluciones de inteligencia de negocio y gestión del conocimiento interno y
externo de la empresa por la importancia que tiene y el crecimiento que ha
experimentado a lo largo de los últimos años.
3.1. Los sistemas de gestión de procesos internos (ERP)
ERP son las siglas de enterprise resource planning (sistemas para la planificación
de recursos de la empresa) y, como indica su nombre, al principio eran sistemas
de planificación y control de producción. De hecho, los ERP son una evolución
de los antiguos sistemas MRP, de planificación de materiales en las cadenas
de producción. Sin embargo, hoy los ERP de diferente tamaño y ambición
líderes en el mercado (Oracle, SAP, Microsoft) y otros más pequeños, basados
en software propietario o en software de código abierto, aspiran a proporcionar
una gestión integral de los procesos empresariales.
La figura siguiente muestra la estructura típica de un sistema ERP, que, como se

puede ver, responde bastante a las funciones de la empresa. De hecho, a pesar
de que su vocación y su promesa es estructurar las empresas a lo largo de los
procesos de negocio y romper las secciones funcionales, la estructura modular
de los ERP responde básicamente a la organización funcional de las empresas:
Estructura del sistema ERP
Las ventajas y las características genéricas suelen ser las que se han presentado
en la introducción de este apartado: modularidad, facilidad de uso, arquitec-
turas cliente-servidor, parametrización o configuración a partir de un reperto-
rio de "buenas prácticas" y, sobre todo, integración de datos y, en cierta medi-
da, de procesos:
• Los datos son consistentes, completos y comunes.
• La estructura y el formato de los datos también son comunes.
• Todas las aplicaciones o módulos utilizan los mismos datos, que se intro-
ducen una sola vez.
• Permite controlar la actividad de los diferentes departamentos en tiempo

real y también de la empresa en conjunto.
• La visión global que proporcionan permite reducir los costes de coordina-

ción entre departamentos, delegaciones o filiales, al reducir los tiempos
del ciclo de producción y servicio al cliente u operaciones administrativas,
como la facturación, los cobros o el volumen del inventario.
• La información es, o debería ser, más rápida de elaborar y se debería pro-

porcionar a los cuadros intermedios y a la dirección, para la toma de de-
cisiones.
• Se facilita la homogeneización de los procesos de trabajo entre diferentes

usuarios o partes de la empresa y, eventualmente, las operaciones de me-
jora y reingeniería.
Como se puede ver en la figura, entre el conjunto de funciones o procesos que

cubre el ERP hay algunos que son típicamente de soporte (la administración
de recursos humanos, la contabilidad o la administración comercial o de com-
pras, etc.), en los que se pueden producir especialidades propias de cada em-
presa, pero que rara vez son la fuente de ventajas competitivas. Sin embargo,
la diferenciación de otros procesos, como los de producción, marketing, pro-
yectos o algunos procesos avanzados (la gestión de las carreras profesionales,
o cierta clase de procesos de compras, etc.), es justamente la fuente de ventajas
competitivas para muchas empresas.
Desde un punto de vista estratégico, a menudo muchas empresas utilizan ERP

en los proyectos de reorganización interna (por ejemplo, para centralizar cierta
clase de departamentos, filiales, unidades o procesos) y también para acelerar
las operaciones de fusiones y adquisiciones entre empresas.
La implantación del ERP de Cisco

Uno de los ejemplos más clásicos de implantación de un ERP corporativo es el caso de
Oracle en Cisco a mediados de los noventa. Tenéis una descripción de es-
te proceso en:
De este ejemplo, que podéis consultar en la bibliografía en diferentes formatos, se pueden L.�Applegate;�R.�Austin;�W.
extraer algunas lecciones, aunque, como ya hemos dicho, cada enfoque de implantación McFarlan (2003). Corpora-
en cada compañía es diferente y, desde entonces, empresas y organizaciones de todo tipo te information strategy and
han abordado estos procesos de modos muy diferentes. management (6.ª ed., pág.
601-616). Nueva York: Mc-
En el caso de Cisco, las razones principales para evolucionar desde sistemas desarrollados Graw Hill-Irwin.
a medida a una solución ERP eran dos:
• Las aplicaciones heredadas (legacy) no podían dar respuesta al crecimiento acelerado

y a la expansión internacional de la compañía.
• Los sistemas a medida presentaban continuamente problemas y caídas, hasta que se

produjo una crisis brutal a comienzos de 1994, que paralizó la compañía durante dos
días y corrompió la base de datos central.
Es importante señalar que Cisco era, y continúa siendo, una organización muy centrali-
zada y disciplinada, de liderazgos fuertes y con una aspiración de homogeneizar al má-
ximo los procesos a lo largo de la empresa. A pesar de la inmadurez de los productos en
aquella época, la implantación del ERP aparecía como una oportunidad para solucionar
todos aquellos problemas a la vez y hacerlo de manera rápida, muy rápida.
Desde el inicio, el cambio de los sistemas se vivió como una iniciativa liderada, o al menos
coliderada, desde el negocio, y no como una iniciativa exclusiva de TI. Todo el comité
de dirección de la compañía asumía el patrocinio del proyecto y se seleccionaron cien de
los empleados más brillantes de todos los departamentos para dedicarlos al proyecto a
tiempo completo. El implantador (KPMG) y el fabricante (Oracle) también estaban muy
comprometidos, para ellos era una oportunidad única para perfeccionar el producto y el
enfoque de implantación en un entorno real y una referencia de gran prestigio.
El factor tiempo era clave: el plan inicial quería implantar todo el sistema en siete meses.
Y el coste era de 15 millones de dólares, la inversión más importante de cualquier tipo
hecha por Cisco en su historia. Los equipos propios (todos los participantes) y externos
tenían incentivos económicos para conseguir el objetivo y los riesgos eran compartidos.
El análisis del proceso de implantación revela algunos factores clave de éxito y algunos
riesgos que no se cubrieron adecuadamente.
Factores�de�éxito
• Un enfoque y una estrategia de implantación muy claros: hacerlo todo, hacerlo rá-
pidamente, seguir el estándar y ponerlo en marcha a la vez en toda la compañía (se
denomina big bang).
• El sistema de dirección del proyecto, basado en un comité fuerte, una oficina de pro-
yecto y una serie de líneas de trabajo por módulos, lideradas cada una por un respon-
sable de negocio y un responsable de TI, y con equipos combinados de consultores
de negocio, expertos de los procesos de la misma compañía (usuarios clave) y con-
sultores y personal de TI.
• Un proceso muy rápido para establecer los requisitos, basado en talleres de trabajo
en profundidad dirigidos a entender las opciones del paquete y las necesidades de
configuración. En este proceso se descartaban los desarrollos a medida, y la oficina
de proyecto y el comité de dirección establecían rápidamente el camino que seguir.
• La presentación temprana de prototipos para cada línea de trabajo (track) o módulo,

para identificar rápidamente los errores o limitaciones de funcionalidad, ergonomía
de uso, etc.
• La creación de un gran equipo de intervención rápida para la resolución de errores

e incidencias y el soporte a los usuarios durante los primeros dos meses de puesta
en marcha.
Sin embargo, no todo salió bien ni salió rápidamente ni salió a la primera. Durante las
primeras semanas de puesta en marcha, el sistema caía cada día y las incidencias y las
quejas de los usuarios eran más y más graves que las que los implantadores podían so-
lucionar. Entre los fallos que se reconocen en el análisis del caso, los más importantes
fueron los siguientes:
Factores�de�riesgo�o�causas�de�errores
• Escasez de pruebas (testing) o pruebas inadecuadas. En realidad, nunca hubo una es-
trategia clara de pruebas.
• Gaps (agujeros) de funcionalidad. La sujeción estricta al estándar dejaba de atender

procesos y maneras de trabajar de la compañía. La rapidez y el coste se pusieron por
encima de la cobertura de la funcionalidad y de un diálogo mejor con los usuarios.
• Todo quiere decir muchas cosas y nada. De hecho, el alcance nunca se definió con
claridad y cambiaba continuamente.
• En lugar de trabajar con una versión del producto conocida y probada, Cisco y Oracle
decidieron trabajar con una nueva versión, que produjo muchos problemas funcio-
nales y técnicos en el proceso de configuración e integración.
A pesar de todo, y dentro de este tipo de cultura y organización empresarial, la implan-

tación de Oracle en Cisco se considera un éxito. La desviación fue solo de dos meses (esto
es, una duración total de nueve meses) y de 0 dólares, puesto que las desviaciones las
asumían los proveedores como parte de su riesgo. También es cierto que, después de la
fase de estabilización, se entró en un proceso de postimplantación, con ajustes y mejoras
(incluidos desarrollos a medida), a lo largo de aproximadamente dos años hasta que el

sistema respondió a las necesidades y la funcionalidad requeridas.
Desde la implantación pionera del ERP de Oracle en Cisco, la experiencia que

han ganado las compañías, hecha de algunos éxitos y muchos fracasos, la for-
mación de los consultores e implantadores y la reflexión de la literatura aca-
démica y profesional, ha permitido ver con más claridad los factores de éxito
y los errores más frecuentes de una implantación de un paquete ERP en el
mundo actual. Un artículo reciente publicado en la revista CIO revisaba los
más importantes.
Errores más frecuentes en la implantación de ERP y cómo se pueden evitar
• Planificación�pobre. Es importante tener una visión inicial lo más detallada posible

de los procesos de negocio que debe cubrir el ERP y del esfuerzo requerido en la
implantación. Para obtener esta visión habría que contar con todas las partes y todos
los departamentos interesados o afectados por la implantación.
• Selección�inadecuada�del�paquete. Una buena implantación es un proceso en el

que la empresa se adapta al paquete y el paquete, a la empresa. Pero esto no puede ser
a cualquier coste. Se ha de analizar bien la funcionalidad y las referencias dentro del
sector que pueden ofrecer los diferentes fabricantes, visitar las empresas y obtener in-
formación de primera mano. Lo mismo se puede decir de los implantadores, que vie-
nen de la mano del fabricante y que tendrán un papel clave durante la implantación.
• No�entender�o�usar�muchas�de�las�funcionalidades. Según fuentes independientes,

casi la mitad de las implantaciones no usan casi la mitad de las funcionalidades. Con
una inversión tan grande y una promesa tan tentadora, se debe realizar el primero
de todos los beneficios, que no es otro que su uso por la organización.
• No�asignar�el�tiempo�y�los�recursos�adecuados,�en�cantidad�y�calidad. La planifi-
cación ha de incluir una buena esponsorización directiva, un jefe de proyecto expe-
rimentado, un coordinador interno de todos los recursos de los diferentes departa-
mentos y una estimación del tiempo y coste que se deberá dedicar. Una buena regla
es multiplicar por dos la previsión inicial.
• No� asignar� prioridades. Un ERP es un proyecto muy ambicioso que ha de cubrir

muchas tareas en muchos lugares diferentes. La empresa debe decidir pronto, y revi-
sar de manera ordenada y frecuente, cuál es la funcionalidad básica, cuáles son las
prioridades y qué cosas pueden esperar.
• No� invertir� en� gestión� del� cambio� y� formación. La gestión del cambio es todo
aquello que ha de pasar dentro de la empresa para que el proyecto sea un éxito: cam-
bios en la organización, los roles y las responsabilidades; cambios en los procesos de
trabajo y las tareas individuales; cambios en la comunicación y la cultura organiza-
tiva. Este esfuerzo normalmente se infravalora y puede llegar a representar entre un
20 y un 50% del coste total.
• No�tener�datos�precisos�y�bien�definidos. Un ERP es tan bueno como lo sean sus

datos, que han de estar bien definidos y querer decir lo mismo para todo el mundo.
En algunas implantaciones, se designa un especialista, arquitecto o gestor de datos
para esta tarea, que incluye también el proceso de migración de los datos de las apli-
caciones legacy a las nuevas.
• Suponer�que�el�ERP�lo�hará�todo�y�lo�hará�desde�el�primer�día. Tanto la práctica

profesional como la investigación coinciden en que el ERP debe soportar los procesos
básicos de la cadena de valor, seguir los costes y obtener los indicadores principales
para la gestión. Después, queda mucho trabajo. Cada vez se le da más importancia
al proceso de postimplantación, que, con el uso efectivo por la organización, ha de
permitir el "ajuste final" del producto a las necesidades de la empresa.
• No�programar�la�desaparición�de�las�aplicaciones�legacy. El ERP está pensado pa-

ra sustituir, no para complementar ni amalgamar las aplicaciones antiguas. Muchos
procesos de integración con las aplicaciones actuales que se hacen durante la implan-
tación del ERP esconden la supervivencia de los sistemas tal como funcionaban antes
y anulan el potencial de cambio y ahorro del ERP.
• Desestimar�la�inversión�en�pruebas,�tanto�las�unitarias,�como�las�de�integración
y,�especialmente,�las�de�usuario. Pero, sobre todo, lo que sucede a menudo es que
no se hacen pruebas de carga en un entorno operativo real. Hacerlo es caro, pero
ahorra muchos sustos.
• Ligarse�demasiado�al�fabricante�y�al�consultor�de�implantación. Cuando sucede

esto, después la organización no tiene autonomía para gestionar el mantenimiento
de las aplicaciones o buscar el apoyo de terceros, que puede resultar mucho más eco-
nómico que el de los fabricantes e implantadores iniciales.
• No�tener�una�estrategia�de�mantenimiento. Esto puede suponer que la inversión

asociada deje obsoleta la inversión en un plazo corto y, al contrario, puede implicar
un gasto excesivo si se hace todo lo que el fabricante pide o promete con cada cambio
de versión.
Adaptado de: Jennifer Lonnor Schiff (2012, marzo). "13 Common ERP mistakes and how
to avoid making them". www.cio.com.
Como hemos indicado más arriba, actualmente los ERP se han extendido de Ejemplo
modo que permiten la colaboración con otras empresas a lo largo de la cadena
Los sistemas CRM cubren o
de valor "extensa", algunos módulos han adquirido "vida propia" y han pasado pueden cubrir muchos pro-
a cubrir funcionalidades de otros sistemas o se produce un encabalgamiento cesos del área de marketing
y ventas. Los sistemas SCM
entre las funcionalidades del ERP y las que ofrecen otros productos. pueden cubrir la gestión de
compras. Y los nuevos ERP son
suites de soluciones que tam-
bién pueden cubrir el CRM o
Algunos productos estándar no han sido capaces de cubrir bien desde el inicio el SCM.
funciones empresariales complejas, sobre todo en algunos sectores, lo cual ha
dado lugar a la aparición de productos específicos de nicho. Es el caso de los
sistemas de gestión presupuestaria, los de gestión de tesorería o los de gestión
de proyectos (EPM o enterprise project management).
4. Los sistemas de empresa basados en la colaboración

en Internet
El universo de los sistemas de empresa y sus ventajas potenciales de reingenie-

ría o transformación empresarial se han multiplicado con la extensión de las
infraestructuras de red, privadas o públicas, en definitiva, Internet. Si en los
comienzos de Internet se habla del e-business o comercio electrónico, hoy se
puede decir que "todo el business es e-business", y al revés.
Iniciativas de negocio electrónico en General Electric
"Todo lo que he aprendido de Internet mejora nuestras fortalezas, y se trata solo del
principio", manifestaba su CEO Jeff Immelt en el año 2001 después de ser elegido. Su
predecesor, Jack Welch, había actuado potenciando el efecto que las nuevas tecnologías
podían tener sobre el ahorro de costes y la productividad de la compañía, que calculaba
en diez millones de dólares, promoviendo proyectos de externalización de procesos de
personal y de administración, y de automatización de las transacciones con proveedores y
clientes. Ahora el reto de Jack Immelt ha sido utilizar las nuevas tecnologías para generar
nuevos ingresos y transformar una empresa intensiva en capital en una intensiva en
información.
Por ejemplo, algunos de los proyectos llevados a cabo en la división médica son la moni-
torización remota de equipos o la información de productividad de los hospitales com-
parada con otros centros. En la división energética, el diseño de una planta se puede ha-
cer en cuestión de días. En la división de equipos domésticos, GE puede hacer la distri-
bución directa de los productos que ofrece liberando las cadenas de distribución de gran
consumo del stock en almacén.
Según los analistas, en el futuro GE será valorada por la capacidad de mejorar los ahorros
de coste de sus clientes.
En realidad, como ya hemos visto en el módulo "Tecnologías de la información

y estrategia de empresa", Internet modifica la estructura de la cadena de valor,
proporcionando nuevas oportunidades (y también riesgos) estratégicas.
La figura siguiente muestra algunos ejemplos de utilización de Internet en la

cadena de valor de una compañía según la representación clásica de Michael
Porter. Internet proporciona una síntesis y una multiplicación de las capacida-
des de proceso y comunicación que añade (o puede añadir) valor a cada parte
del ciclo de negocio:
• Reduciendo costes individuales de cada proceso y de integración entre pro-

cesos diferentes, con tecnologías más baratas de desarrollar, operar y man-
tener.
• Generando eficiencia, al disponer de más información sobre el negocio,

interna y externamente, o poder acceder a ella más rápidamente.
• Generando nuevos ingresos, mediante más eficacia en la gestión de recur-

sos y más facilidad de acceso a clientes actuales y nuevos.
Figura 6. Ejemplos de utilización de tecnologías Internet en la cadena de valor de una compañía
Si volvemos al diagrama de la arquitectura de sistemas de empresa que hemos

presentado en el capítulo anterior, en realidad Internet amplía o multiplica la
facilidad de hacer negocios con proveedores, socios y clientes, y también las
relaciones internas de trabajo:
Arquitectura de los sistemas de empresa
Se podría decir que el ERP nos permite "poner orden en casa"; nos prepara para
establecer relaciones colaborativas con otras, mediante las tecnologías web.
Veamos justamente un resumen de la evolución del caso de Cisco, que hemos
utilizado como ejemplo en el apartado anterior.
Arquitectura de sistemas en Cisco: ERP y tecnología web
Para Guido Jouret, responsable europeo de Cisco, Internet no es el negocio de Cisco sino
la manera de hacer negocio de Cisco. En el año 1993, Cisco disponía de un departamento
de SI y TI tradicional (se consideraba un centro de costes), con múltiples aplicaciones
informáticas de orientación departamental de baja escalabilidad ante el crecimiento que
estaba experimentando la compañía. En el año 1994, un error en la base de control de
datos causó la parada de la compañía durante dos días y esto provocó la decisión defini-
tiva de implantar un ERP corporativo. Se optó por un sistema integrado que reemplazara
totalmente los sistemas existentes. El nuevo ERP debía implementarse de una sola vez y,
para reducir el tiempo de implantación, Cisco asumió que el ERP no fuera excesivamen-
te customizado para aplicaciones específicas. Al ser una empresa joven, esperaba que la
plantilla asumiera la nueva manera de trabajar.
Para Cisco, disponer del ERP representó un punto de partida muy importante para desa-
rrollar las aplicaciones estratégicas en la Red. Con una inversión importante, Cisco po-
sibilitó la configuración web de todas sus aplicaciones. Ha proveído una intranet que
permite la toma de decisiones con datos fiables y rápidoas, la gestión del conocimiento
de los trabajadores, la comunicación y la formación en línea de los empleados; ha dis-
puesto la mejora del servicio al cliente y la reducción de tiempo de entrega mediante la
gestión de la venta, de la integración del cliente a la red de información de Cisco a lo
largo de la cadena logística, y del servicio posventa por el canal Internet (92% del total
de ingresos), y ha hecho que sea posible la gestión de toda la cadena de suministro por
medio de su extranet.
Mediante esta estrategia, Cisco ha focalizado el diseño de los productos y la gestión de

clientes, se ha liberado de los procesos de producción, que le hacen sus proveedores en
red y ha concentrado sus activos estratégicos en la gestión de la información .
Al mismo tiempo, el desarrollo de Internet y sus nuevos estándares abiertos

de código y comunicación (XML, J2EE, servicios web) ha aumentado el des-
pliegue de soluciones a medida, hasta el punto de que muchos ERP ya pro-
porcionan módulos que el cliente ha creado libremente, a partir de plantillas
preestablecidas, que se pueden desarrollar por separado y que son más fáciles
de integrar en el caso de migraciones o cambios de versión futuros.
4.1. Los sistemas de gestión de clientes: CRM
Si en el caso del ERP el componente estratégico es más limitado y tiene que

ver principalmente con la automatización, la normalización y la integración
de datos y procesos, en el caso de los sistemas CRM, aunque también hay un
componente operativo, no estamos hablando solo de un producto que puede
sustituir mejor o peor los procedimientos de trabajo actuales y proporcionar
una información administrativa mejor, sino de una estrategia empresarial de
mayor alcance.
Las empresas compiten en mercados cada vez más complejos y competitivos,

con un número más alto de productos y servicios, con más consumidores
reales o potenciales, mejor informados y preparados, y con un número de in-
teracciones más elevado mediante un número más elevado de profesionales
y canales de contacto.
Incrementar los ingresos, al mismo tiempo que se reducen los costes de vender,
aumentar la efectividad de la fuerza de ventas y la coordinación interna y
mejorar los servicios de preventa y posventa para mantener clientes más fieles
es un reto común de la mayoría de las empresas.
Notas
• Como media es seis veces más caro vender a un nuevo cliente que a un cliente actual.
• Un cliente insatisfecho explicará su experiencia, como media, a entre ocho y diez

personas.
• Las posibilidades de vender un producto a un cliente actual son del 50%, mientras
que las de venderlo a un cliente nuevo son del 15%.
• Solo un 5% de los clientes insatisfechos se quejan.
• El 70% de los clientes que se quejan y reciben una satisfacción rápida continuarán
comprando a la compañía.
(elaboración propia a partir de O'Brien y Marakas, 2006)
La gestión�de�las�relaciones�con�los�clientes�(CRM) es una estrategia

empresarial que consiste en un cambio técnico, organizativo y de pro-
cesos para gestionar mejor las operaciones centrándose en la conducta
del cliente.
En el nivel operativo, el CRM implica la adquisición y el despliegue de conoci-

mientos sobre los clientes y la aplicación de esta información en varios puntos
de manera transversal, lo que da lugar al aumento de ingresos y a eficiencias
operativas.
Fundamentalmente, intenta responder al abanico de preguntas siguiente:
• ¿Qué requieren los segmentos de clientes de una empresa para cubrir sus
necesidades?
• ¿Qué valor aportan los socios de los canales de venta al valor final del
producto?
• ¿Cómo se debería posicionar una compañía en un canal de venta para

adquirir ventajas competitivas en el mercado?
• ¿Cómo se pueden construir relaciones estables con los clientes mediante

la gestión de los canales de contacto y la información que se recoge?
• ¿Cómo se puede mejorar la efectividad y reducir los costes en el contacto

con el cliente?
• ¿Qué canales de contacto son útiles para cada proceso de la gestión de

clientes?
4.1.1. Ventajas de un sistema CRM
En la figura siguiente se resumen algunas de las ventajas�de�un�modelo�CRM:

Figura 8. Ventajas del modelo CRM
El modelo CRM se basa en cinco�grandes�principios�empresariales:
• El conocimiento�de�la�conducta�del�cliente y la contribución en benefi-

cios asociada con esta. Por ejemplo, la identificación de qué segmentos de
clientes son rentables a corto, medio y largo plazo para la compañía y la
realización de tareas de fidelización y trato diferenciado, como las tarjetas
oro de cliente.
• La identificación�de�los�canales de ventas, marketing y servicios que pre-

fieren los clientes y la empresa. Por ejemplo, la selección del canal telefóni-
co para ciertos segmentos de población o el presencial para otros sectores.
• La gestión�proactiva�de�las�interacciones�personalizadas con el clien-

te para el servicio diferenciado, venta ampliada y venta cruzada indepen-
dientemente del canal. Por ejemplo, la extensión de productos de seguros
a un cliente bancario.
• La información�compartida del cliente y las interacciones generales den-

tro y entre las operaciones de ventas, marketing y servicios. Por ejemplo,
el trato diferenciado posventa.
• La reducción� de� los� costes� generales de ventas y servicio en todos los

canales. Por ejemplo, utilizando canales más efectivos para ciertos trámites
en un municipio.
4.1.2. Procesos de gestión
Partiendo de los principios y objetivos expuestos, se han desarrollado solucio-

nes CRM basadas en herramientas y sistemas de información que les dan so-
porte. Operativamente, la construcción de un proyecto CRM consiste en los
pasos que describimos a continuación:
• Capturar� y� consolidar� la� información� de� clientes. Por ejemplo, reco-

giendo la información de todas las transacciones del cliente sea cual sea
el canal de contacto.
• Construir�perfiles�de�clientes. Por ejemplo, analizando el potencial eco-

nómico del cliente, sus preferencias e intereses, cómo desea ser atendido,
etc.
• Extender�el�acceso�a�la�información clave de los clientes en todos los

canales y puntos de contacto. Por ejemplo, disponiendo de la misma in-
formación en todos los puntos de venta o de servicio.
• Definir�criterios�de�acceso�a�la�información de los clientes, teniendo en

cuenta el canal y el punto de contacto. Por ejemplo, qué información debe
disponer de un canal presencial y cuál de un canal telefónico.
• Refinar�los�procesos�de�gestión�de�las�relaciones con los clientes en to-

dos los puntos de contacto después de considerar el perfil del cliente. Por
ejemplo, la atención en un hotel de una cadena hotelera de acuerdo con
el perfil corporativo completo del cliente.
• Integrar� la� solución� de� marketing (análisis, segmentación, gestión de

campañas y personalización) con las soluciones de gestión de interaccio-
nes. Por ejemplo, combinando las acciones de marketing con campañas
dirigidas por medio de diferentes canales de contacto.
• Preparar�toda�la�organización para la implantación del nuevo modelo

de relación con los clientes. Por ejemplo, mediante la formación adecuada
a base de vender.
Figura 9. Ciclo operativo CRM
Una solución CRM se basa en un módulo�operativo y un módulo�analítico.
El módulo�operativo gestiona los puntos de contacto con el cliente: los cana-

les de venta, marketing y servicios y, partiendo de la información de clientes
recogida en el módulo analítico, gestiona nuevas interacciones con el cliente
(se corresponde con lo que se denomina CRM colaborativo).
El módulo�analítico (la trastienda o black office de las operaciones) gestiona

la recogida y el análisis de la información de clientes obtenida en los contac-
tos y operaciones con estos y permite obtener conclusiones de interés para la
relación futura con ellos.
El CRM de Mitsubishi Motor Sales

El caso de la implantación de un sistema de gestión de las relaciones con el cliente en
esta empresa es muy diferente del enfoque de implantación del ERP de Cisco que hemos Podéis consultar el caso en
presentado en el apartado anterior, y muestra, a nuestro entender, a la vez los aspectos O'Brien y Marakas (pág. 249).
estratégicos que hay detrás de la decisión de adoptar un sistema de empresa, un enfoque
de selección de los productos muy diferente y también un proceso de implantación di-
ferente. Al mismo tiempo, este tipo de implantación ha sido bastante frecuente en los
últimos años, en cuanto a la implantación de sistemas CRM.
Mitsubishi, como la mayoría de las organizaciones de ventas de coches, era y es una

empresa típicamente comercial. Alguien fabrica en algún lugar del mundo y un conjunto
de concesionarios y talleres asegura el proceso de venta, la financiación, el servicio de
posventa y atención al cliente, y las reparaciones y los recambios. Pues bien, a finales
de los noventa, la empresa tenía dieciocho números de teléfono diferentes de atención
al cliente, todos gratuitos, para atender las incidencias, las consultas y las reclamaciones
de los clientes por las causas más variadas. A menudo, el cliente no llamaba al lugar
adecuado y el empleado lo debía derivar a un número diferente, a veces equivocado.
La organización del servicio estaba estructurada según la organización interna de la casa,

no de acuerdo con los problemas y las necesidades de los clientes, y además era extraor-
dinariamente ineficiente y cara. La empresa, como otras muchas, decidió "orientarse al

cliente" e imaginó que disponer de un solo centro de contactos la ayudaría a conocer
mejor a los clientes, a facilitarles su relación con la compañía y a ofrecer un servicio más
rápido, consistente, de calidad y, eventualmente, más barato.
El enfoque de selección de productos y servicios y de su implantación debía ser relativa-

mente "lento" y por fases, puesto que representaba cambios en la organización, la incor-
poración de proveedores externos de una función muy íntima y clave para la empresa, y
no se podía permitir fallos o errores importantes y continuados en el servicio.
De este modo, en lugar de comprar un solo sistema integrado, la empresa decidió una
estrategia de productos best of breed (es decir, el módulo más adecuado para cada función
con independencia del fabricante) y asumir la integración. También aceptó la implanta-
ción por fases, de modo que solo se evolucionaba hacia la fase siguiente cuando el siste-
ma estaba muy probado y resultaba satisfactorio.
En primer lugar (junio de 1999), se implantó el sistema de gestión de llamadas de Siebel

(pero solo este módulo, en lugar de todo el suite de Siebel), creando un centro de llama-
das único. El problema más grave, como suele pasar, fue unificar las diferentes bases de
contactos (o sea, la migración de datos), puesto que integrarlas y sanearlas mantuvo pa-
ralizado el proyecto casi un año y medio.
En enero del 2001, se adquirió una centralita inteligente de Avaya, capaz de redirigir las
llamadas al agente más adecuado en cada caso, y se contrató Sitel como proveedor ex-
terno de los servicios de atención de llamadas más sencillas o de primer nivel. Esto repre-
sentó un gran trabajo de reorganización y formación tanto del centro de atención tele-
fónica o call-center como de la propia organización de Mitsubishi. En el proceso también
se adquirió el sistema de Smart Scripts de Siebel, un sistema que permite al agente seguir
un protocolo de atención estricta y, en caso de duda o incidencia, recurrir a un soporte
manual (un supervisor o agente más experimentado o el propio back-office corporativo).
Al mismo tiempo, el sistema de registro y la base de datos se había depurado, de modo
que cualquier agente podía conocer el historial del cliente, evitar preguntas innecesarias
y actuar en consecuencia.
Para garantizar la calidad del servicio y recoger información sobre las llamadas e inciden-
cias, en mayo del 2001 se instalaron diferentes sistemas de nicho para prever la cobertura
del servicio en diferentes horarios y para poder grabar y escuchar las llamadas.
Más adelante, se implantaron los sistemas de análisis estadístico e "inteligencia" para

conocer mejor las necesidades de diferentes perfiles de clientes y establecer las mejoras
tanto en el servicio al cliente como en el resto de la organización.
Como resultado de la implantación de estos sistemas, el nuevo centro de atención tele-

fónica era capaz de atender casi un 40% más de volumen de llamadas, a un coste por
llamada de un tercio del inicial. La satisfacción del cliente subió en un 8% y la inversión
se recuperó en dieciocho meses.
Actualmente, los centros de atención telefónica han evolucionado a centros de

atención multicanal o contact-centers, centros de contacto capaces de manejar
cualquier clase de contacto del cliente con la empresa por medio de cualquier
tipo de canal, sobre todo de los canales electrónicos (correo, redes sociales,
aplicaciones multimedia, etc.), y de hacerlo no solo reactivamente (atendien-
do las consultas y las peticiones), sino también proactivamente (estableciendo
ofertas individuales o campañas según el perfil psicográfico y sociográfico de
los clientes, y sus hábitos de compra).
Asimismo, el entorno de relaciones con los clientes ha evolucionado mediante

la creación de plataformas de venta en línea o de comercio electrónico, que
veremos más adelante.
Nuevas tendencias en el mundo CRM
La revista CIO publicaba en febrero del 2012 un resumen interesante sobre las tendencias
que destacan actualmente en el entorno de las soluciones CRM; en especial, la integración
de la información de las redes sociales y de los móviles y smartphones.
• Continuará la tendencia de compra de productos basados en la nube y pagados por

servicios. Esto ha supuesto, por ejemplo, el éxito de la plataforma Salesforce.com.
• Los usuarios, tanto internos como externos, cada vez dan más importancia a la utili-
dad y la interfaz de usuario, la posibilidad de configurarlo a su medida y que sea trans-
portable en diferentes dispositivos, particularmente móviles y tabletas inteligentes.
• El CRM puede ser el lugar donde confluyan datos o soluciones que ahora se están
tratando de manera fragmentada y dispersa, como la procedente de las redes sociales
o de los sensores de la "Internet de las cosas". La información de los clientes e intere-
sados en nuestra empresa ha de estar toda en el mismo lugar y el lugar más maduro
es posiblemente el CRM.
• El CRM está cada vez más integrado con otras aplicaciones, como el ERP o los sistemas
de gestión del punto de venta, incluyendo la venta en línea. La información comercial
y financiera deben estar fuertemente integradas.
• Emergen con fuerza las soluciones CRM basadas en software libre. Son más flexibles,
económicas y fáciles de customizar y cambiar.
• El CRM cada vez será más social y deberá aportar más rápidamente datos de las ten-
dencias emergentes y, a veces, de nicho entre clientes actuales y potenciales.
• El CRM se está moviendo rápidamente hacia los dispositivos móviles.
• El CRM está haciendo realidad el viejo sueño de una reingeniería completa de la em-
presa, incluyendo el diseño de los productos, basada en los deseos y las experiencias
de los clientes, por ejemplo, a través del crowdsourcing.
Jennifer Lonnor Schiff (2012, febrero). "Eight CRM trends you need to watch".
www.cio.com.
4.2. Los sistemas de gestión de la cadena de suministro (SCM)
(1)
Históricamente, el concepto de gestión de la cadena de suministros1 se relaciona En inglés, supply chain manage-
ment (SCM).
con la logística y los procedimientos administrativos asociados. Es decir, se
trata de aligerar el flujo de materiales físicos, de documentación administrativa
(pedidos, albaranes y facturas) y de información (inventarios, rutas y fechas
de entrega) a lo largo de la cadena de valor extendida.
Figura 10. La cadena de suministro tradicional
Los sistemas de producción y entrega justo a tiempo (just in time) y la externa- Referencia bibliográfica
lización de un gran número de procesos de fabricación han transformado el
Para elaborar este capítulo,
corazón del negocio de muchos fabricantes (que se han convertido en gestores hemos utilizado una parte
de marca y organizaciones de diseño, marketing y ventas) y han diversifica- de los materiales del módulo
"Sistemas de cooperación em-
do el número y la tipología de los agentes que intervienen en el proceso de presarial", elaborados por Hu-
mi Guill, para la asignatura
producción y entrega de productos acabados en su punto de venta. La figura
Fundamentos de sistemas de in-
siguiente muestra los procesos de gestión de empresas participantes en la ca- formación.
dena de suministros moderna:
Figura 11. Procesos de gestión de empresas en la cadena de suministros
Veamos algunos ejemplos en diferentes sectores industriales.
Ejemplos de gestión de la cadena de suministro
Para Rover, el lanzamiento del modelo Freelander, primer producto después de la adqui-
sición de la compañía por BMW, fue revolucionario, puesto que redujo el tiempo de
desarrollo desde el concepto hasta el lanzamiento al mercado de sesenta a treinta meses;
redujo el tiempo de puesta en producción de sesenta a veintiocho semanas; redujo el
tiempo de entrega de cuatro a dos semanas, y redujo los niveles de inventario de veinte
a dos días. El secreto fue el trabajo en red de un equipo multidisciplinario que trabajó
en paralelo en un proceso iterativo y de aprendizaje conjunto. El vehículo fue dividido
en diez secciones y diez equipos de trabajo formados por diseñadores e ingenieros de
producción.
La compañía Alcoa, líder mundial de costes en el sector del aluminio, redujo, en el año
2000, inventarios por valor de más de 250 millones de dólares y mejoró las ventas por
1.000 millones de dólares. El secreto fue la implantación de una solución de negocio
electrónico que le permitió gestionar la producción en tiempo real, basándose en la in-
formación de demandas reales accesibles por extranet e Internet corporativas, y permitió
la toma de decisiones en la cadena de producción de una manera ágil mediante la Red.
La compañía Cisco, de la que hemos hablado en apartados anteriores, dispone de trein-

ta y seis plantas de facturación, pero solo dos son de su propiedad. El resto pertenecen
a compañías de la red colaborativa, como por ejemplo Jabil Circuit y Solectron. Randy
Pond, vicepresidente de Operaciones, afirma que se trata de una "producción virtual, he-
cha posible por un conjunto de herramientas y procesos que permiten gestionar una em-
presa extendida de la que no se dispone pero funciona como si se dispusiera. Se obtienen
datos reales en tiempo real de manera que mis socios y colaboradores saben cómo va el
negocio en cada momento del día".
Una solución para la gestión de una cadena de suministro es organizar

los procesos de negocio, la información y los acuerdos con proveedores,
distribuidores y clientes a lo largo de la cadena de valor extendida de
manera que permita planificar, implantar, minimizar costes y controlar
la entrega a los clientes de bienes y servicios de calidad, coordinando la
actividad de múltiples agentes.
Un SCM, al igual que un CRM, no es simplemente una solución informática,

sino una estrategia empresarial, un modelo de negocio en el que cada agente
establece su participación y apropiación de valor, basada en lo que considera
que son sus competencias y habilidades más propias.
Core competence
El concepto de core competence (competencia central de una organización) se debe origi-

nariamente a C. K. Prahalad y Gary Hamel. Según su visión, una core competence sería
un factor específico de cada empresa que la hace ser como es y que el mercado la per-
ciba de una determinada manera. Una core competence debería ser difícil de imitar para
los competidores, podría ser reutilizable en nuevos productos y mercados (incluye una
cierta adaptación dinámica) y debería proporcionar a los clientes un beneficio único y
especial. Prahalad y Hamel estudiaron con detalle el caso de las empresas de Walt Disney
y descubrieron las competencias exclusivas en la gestión de la experiencia de cliente y
en la gestión de los recursos humanos, principalmente.
Pero es también una solución informática, normalmente empaquetada, o con

muchos componentes empaquetados. Los módulos o componentes típicos de
una solución SCM se muestran en la figura siguiente:
Figura 12. Procesos de gestión de un sistema SCM
• La�planificación�estratégica, que comprende la planificación de colabo-

radores y socios, la manera de ir al mercado y los acuerdos de colaboración.
• El�análisis�y�la�previsión�de�la�demanda, que comprende el análisis del

mercado, conversaciones con clientes y elaboración de previsiones de ven-
ta.
• El�diseño�y�la�planificación�de�la�cadena�de�suministro, que incluye la

planificación y la localización de las plantas de producción y distribución,
la planificación logística, la selección de proveedores y el establecimiento
de los procesos de gestión y soporte y los sistemas de información.
• El� desarrollo� del� producto� y� la� planificación� de� la� producción, que
implica la colaboración en el diseño (si procede), la formulación de las
hojas de materiales y la planificación y colaboración en el suministro: qué
tiene que estar dónde y cuándo.
• La� gestión� de� la� producción o, en muchos casos, el ensamblaje de los

materiales, que implica la manufactura, el control de calidad, los cambios
en la ingeniería, el empaquetado y la preparación para la distribución.
• La�ejecución�propiamente�dicha�del�aprovisionamiento, que implica la

generación y la recogida de pedidos, y su seguimiento, recepción, gestión
y distribución a almacenes intermedios o a su punto final de venta.
Todos estos procesos aportan información muy valiosa sobre el mercado, los La función de IT como un
clientes y los socios, tanto desde el punto de vista operativo (seguimiento de SCM
las entregas, gestión de las excepciones, servicio al cliente, etc.) como desde A medida que los departamen-
el punto de vista estratégico, para reformular la cadena de suministros, revisar tos internos de IT se van re-
duciendo y se transforman en
los acuerdos con proveedores, etc. gestión de proveedores exter-
nos, deben adoptar enfoques
y soluciones parecidas a las
que usan los departamentos
Los beneficios principales que supone la implantación de sistemas SCM son de operaciones. En ocasiones,
los siguientes: los dos departamentos llegan a
fusionarse.
Sobre este tema podéis con-
• Mejora del servicio al cliente final, al reducirse los tiempos de entrega. sultar: Zohar�Glad (2011,
diciembre). "The CIO as
Supply Chain Manager".
www.cio.com.
• Seguimiento del estado del pedido en cualquier momento del proceso.
• Reducción de ventas y pedidos perdidos.
• Reducción de los costes de almacenamiento.
• Reducción de los costes de transporte.
• Reducción de los costes de depreciación y mantenimiento del inventario.
• Reducción del coste de tratamiento y flexibilidad para la atención de pe-

didos urgentes.
• Reducción de los costes físicos, administrativos y económicos de coordi-

nación entre los diferentes participantes en la cadena de suministros.
• Reducción de los costes por obsolescencia.
• Establecimiento de un lenguaje común entre los miembros de la cadena

de suministro.
• Obtención de una inteligencia comercial y logística para analizar tenden-

cias y hacer previsiones.
Los sistemas SCM hacen más eficiente la gestión de la cadena de sumi-

nistros, dentro y fuera de la empresa, porque proporcionan información
puntual y de calidad que permite a los agentes llevar a cabo el conjun-
to de procesos de gestión de manera más ligera y sencilla, y también
porque ayudan a coordinar, programar y controlar la contratación, la
producción, la gestión de los inventarios, los almacenes y los centros
de distribución y, además, porque facilitan la entrega en tiempo y la
calidad de productos y servicios.
4.3. Sistemas de comercio electrónico
Probablemente el comercio electrónico representa la máxima expresión de la

transformación de los sistemas de empresa y de la relación entre las empresas
y los clientes, los proveedores y los socios mediante el uso colaborativo de
Internet y otras tecnologías.
En la versión más inmediata y popular, el comercio electrónico (e-commerce)

parece que se reduce a comprar y vender por Internet. En realidad, es una cosa
bastante más complicada, como veremos en este apartado, que envuelve y
transforma una gran cantidad de procesos de negocio, cuando no implica un
cambio completo o la creación de un nuevo modelo de negocio. Podríamos
decir que el comercio electrónico es una transformación estratégica y operativa
de la manera de hacer negocios.
El comercio electrónico incluye el proceso (completo y en la Red) de
desarrollar, poner en el mercado, vender, entregar y pagar por cualquier En este capítulo seguimos es-
pecialmente el capítulo 9 del
clase de producto o servicio, en un mercado global e interrelacionado de libro de O'Brien y Marakas
(2006).
clientes mediante la colaboración y el soporte de una red de proveedores
y socios de negocio también global.
En su evolución, el comercio electrónico ha pasado primero de la publicación

de páginas corporativas y catálogos de productos a la interacción con el clien-
te por medio de la web para consultas o quejas, o para hacer campañas per-
sonalizadas de marketing, en un segundo estadio. A continuación, ha evolu-
cionado hasta llegar a poder cerrar transacciones en la web. Y finalmente ya
permite la integración de toda la cadena de suministros como la forma más
evolucionada de los sistemas SCM y, a la vez, la forma más evolucionada de
la gestión de relaciones con los clientes (CRM), que hemos estudiado en los
apartados anteriores.
Los buscadores y las redes sociales, así como la masificación de nuevos dispo-
sitivos de acceso y conexión a la Red, permiten multiplicar estas interacciones.
Los anuncios y las ventas en la Red empiezan a ser una fuente fundamental
de ingresos para un cierto tipo de compañías.
Algunos ejemplos
• Grandes marcas o centros comerciales (desde Mango a Macy's) ofrecen sus catálogos
y permiten la compra en línea.
• Algunas tiendas en línea, como Amazon, que hemos estudiado en el módulo anterior,
han canibalizado la venta en el mundo físico no solamente de libros, sino cada vez
de más tipos de artículos.
• eBay es una gran plataforma de compra y venta en Internet entre los propios consu-
midores.
• Dell solo vende sus productos en la web y permite la configuración personalizada.
• Algunos gobiernos permiten hacer casi cualquier tipo de gestión administrativa por
Internet, o incluso lo hacen obligatorio para empresas de cierto tamaño (como la
relación de las empresas con la Seguridad Social o la Agencia Tributaria en España).
• La fuente principal de ingresos de Google es la inserción de anuncios personalizados,

localizados o para un determinado tipo de perfil, a partir de la información que dis-
pone de los usuarios.
4.3.1. Tipos de comercio electrónico
A partir de los ejemplos anteriores, podemos identificar al menos cuatro cate-

gorías de comercio electrónico:
(2)
• Empresa-consumidor2. En la versión más evolucionada, se trata de mer- En inglés, business to consumer
(B2C).
cados o tiendas en línea, que ofrecen o pueden ofrecer todo el ciclo de rela-
ción con el cliente hasta el cierre de la venta y la entrega de los productos.
(3)
• Empresa-empresa3. Se puede llevar a cabo mediante redes públicas (Inter- En inglés, business to business
(B2B).
net) o, más a menudo, mediante extranets de empresa, y no incluye sola-
mente la realización de ventas y compras, sino toda la gestión de la cadena
de suministros (SCM). Según hemos visto, debe disponer de un lenguaje
estándar de intercambio de datos (EDI u otros). Actualmente, el B2B tam-
bién incluye, por ejemplo, la realización de subastas.
(4)
• Consumidor-consumidor4. El ejemplo por excelencia es eBay, la platafor- En inglés, consumer to consumer
(C2C).
ma de compraventas y subastas por Internet.
(5)
En inglés, e-government.
• 5
Administración�electrónica . Representa todo lo anterior en el mundo
de las relaciones entre las administraciones públicas y los ciudadanos y las
empresas. En su versión más evolucionada, puede incluir la realización de Lectura sugerida

consultas y el voto electrónico.
Para una introducción y apli-
cación práctica de adminis-
tración electrónica, que no
se suele ver en los manuales,
4.3.2. Procesos de comercio electrónico podéis consultar el caso del
Ayuntamiento de Barcelona
en Rodríguez (2006).
La figura siguiente muestra las categorías y los procesos principales de la arqui-
tectura de un sistema de comercio electrónico, en su expresión más completa:
Figura 13. Arquitectura de los procesos de comercio electrónico
• Control�de�accesos�y�seguridad. Vital en cualquier sistema de comercio

electrónico (e-commerce). Incluye la autenticación del usuario, los permi-
sos de acceso autorizados para cada usuario, la encriptación de las comu-
nicaciones, los certificados y las firmas digitales, y todo tipo de medidas
de seguridad tanto físicas como lógicas.
• Establecimiento�de�perfiles�y�personalización. En los portales avanza-

dos, el sistema recoge las características y el comportamiento del usuario
(de manera voluntaria o involuntaria) y construye perfiles individuales o
de grupo sobre sus preferencias. Esto permite ofrecer una interfaz indivi-
dualizada del contenido de la web y proporcionar recomendaciones de
compra y anuncios personalizados. El marketing y las ventas en la web
difieren en muchos aspectos de lo que sucede en el mundo que no está
conectado (fuera de línea u offline). El consumidor es más volátil y el cie-
rre de la compra (el proceso de "conversión digital") y la obtención de la
lealtad son clave.
• Gestión�de�la�búsqueda. El usuario ha de ser capaz de encontrar rápida- Ejemplo

mente lo que busca y se debe tener en cuenta que cada uno busca de una
Visitad la web de Ikea.
manera diferente (por productos, por categorías, por parámetros, en len-
guaje natural, etc.), por lo que se le deben ofrecer diferentes métodos de
búsqueda. Si no lo encuentra, cambiará rápidamente de plataforma. Ade-
más de softwares específicos, actualmente muchas webs de comercio elec-
trónico utilizan máquinas de búsqueda estandarizadas, como la de Goo-
gle. Otras webs ofrecen un servicio de ayuda automática o semiautomática
por medio de un "avatar" personalizado.
• Gestión�de�contenidos�y�catálogos. En realidad, son dos cosas diferentes

pero relacionadas. De hecho, muchas compañías usan sistemas separados
para cada cosa. La gestión de contenidos permite producir, publicar, actua-
lizar y archivar datos, texto y ficheros multimedia de cualquier tipo y que
el usuario y la compañía los puedan recuperar con facilidad. El catálogo de
productos ha de ser capaz de almacenar y publicar catálogos multimedia
de multitud de productos, que a veces pertenecen a múltiples proveedo-
res, como en el caso de Amazon. Una funcionalidad adicional puede ser la
posibilidad de configurar a medida el producto que quiere el consumidor,
como en las webs de Apple o Dell.
• Gestión�de�procesos�y�flujos�de�información (se suele denominar ciclo de Click & mortar

trabajo o workflow). Normalmente, cualquier transacción electrónica cons-
Clics y ladrillos es la expresión
ta de una serie de pasos tanto desde el punto de vista del consumidor (bús- coloquial dentro del mundo
queda, selección, configuración, registro o confirmación de datos, orden del comercio electrónico para
referirse a esta combinación.
de pago, etc.) como desde el punto de vista del proveedor (confirmación
de existencias, envío, confirmación de entrega, facturación, cobro, etc.).
Estos procesos han de ser muy ágiles y, a la vez, seguros y de confianza.
Además, deben asociar el mundo digital con el físico (los productos están
almacenados en alguna parte que alguien entrega en otra parte, en un
tiempo y con una calidad previsibles). De hecho, a toda esta lista tendría-
mos que añadir siempre y no olvidar nunca todos los procesos que se pro-
ducen en el interior de cada organización, las capacidades de integración
"hacia atrás" que básicamente proporciona, o debería proporcionar, el ERP.
• Notificación� de� acontecimientos. Como también pasaba con los siste-

mas de gestión de clientes o los de la gestión de la cadena de suministros,
con los que el comercio electrónico está estrechamente relacionado, cada
momento en el ciclo de compra o venta se considera un acontecimiento
que se ha notificar a todas las partes interesadas. Tiene que ver con la ges-
tión de la incertidumbre, pero también es una forma de control interno y
externo de calidad. La notificación de acontecimientos incluye la confir-
mación de un pedido, la confirmación del pago, la información de salida
del producto del almacén y la previsión de entrega o la comunicación de
que el producto no está disponible, se retrasa o se ha intentado entregar
sin éxito.
• Colaboración�y�acuerdos�entre�proveedores�y�socios. Como sucedía en

el SCM, para que todo esto funcione, hay un back office de arreglos, nego-
ciaciones, acuerdos de nivel de servicio, mediación, estándares de inter-
cambio de comunicación, etc. entre multitud de socios. Actualmente, es-
to puede incluir también en algunos casos comunidades de intereses en-
tre los propios consumidores, como los negocios tipo Groupon. Hay un
software que facilita la automatización y el seguimiento de estos acuerdos,
pero aquí las habilidades estratégicas y tácticas para llegar a esta clase de
acuerdos son lo más importante.
• Gestión�de�pagos�y�otros�procesos�de�gestión�financiera. Aquí inclui-

mos, para simplificar, elementos muy diferentes. La relación más obvia es
que el pago que hace el consumidor de un producto o servicio por medio
de la web suele suponer el cierre de la transacción. Esto incluye el proceso
de reserva (el carro de la compra), el sistema seguro de pagos y la compro-
bación de que el pago se ha llevado a cabo.
Sin embargo, en las transacciones entre las compañías y los socios de ne-
gocio los procesos y los sistemas son más complejos e incluyen los siste-
mas electrónicos de transferencia de fondo y toda clase de transacciones
financieras.
4.3.3. Factores de éxito en el comercio electrónico
La complejidad organizativa, procedimental, de los sistemas y de su integra- Ved también

ción, además de los objetivos de negocio que se quieren conseguir, hace que
En la asignatura Gestión avan-
los proyectos y los servicios de comercio electrónico sean, quizá, de los más zada de proyectos podéis en-
complejos que se pueden llegar a imaginar. El éxito se puede medir de muchas contrar un caso completamen-
te desarrollado de construc-
maneras, pero al final del día, consiste en obtener más clientes, más ventas ción de una plataforma de co-
mercio electrónico, basado en
y márgenes más amplios por cliente y operar más rápido y a costes más redu- un proyecto y una compañía
reales.
cidos.
A continuación presentamos un resumen de estos factores de éxito:
• Selección�y�valor. Catálogo atractivo, precios competitivos, garantías de

satisfacción, responsabilidad y soporte posventa.
• Funcionamiento�y�servicio. Navegación, búsqueda y operación fáciles y

rápidas, y entrega rápida y segura de los productos en su punto de entrega.
• Apariencia (look & feel). Entorno amable, sencillo y atractivo; catálogos

multimedia; funcionalidades y funcionamiento intuitivo y comprensible.
• Anuncios�y�ofertas. Promociones, descuentos, agregación de productos,

tanto en la web como en campañas personalizadas. Anuncios de afiliados.
• Atención� personal. Servicio posventa impecable, resolución rápida de

consultas e incidencias; sentimiento de que el cliente es lo más importante.
• Gestión�de�comunidades. Gestión de los acuerdos y comunidades de in-

tereses de clientes, proveedores y socios, por múltiples vías.
• Integración�de�lo�físico�y�lo�virtual. Las plataformas deben asegurar la

integración del servicio virtual con el servicio físico y la integración de sus
procesos y sistemas en el back office (ERP, etc.).
• Acceso�multicanal�y�multiplataforma. Las nuevas aplicaciones y dispo-

sitivos (redes sociales, teléfonos inteligentes, tabletas) son una nueva for-
ma de acceso y una fuente de negocio.
• Seguridad� y� confianza. Seguridad de la información del consumidor y

de sus transacciones, de la información sobre los productos ofrecidos y
capacidad de cumplir las promesas de entrega y servicio.
Hemos presentado sucintamente las características más comunes de los siste-

mas de comercio electrónico, pero, como hemos dicho, las diferentes catego-
rías y variantes ofrecen funcionalidades y procesos propios (cómo debe ser una
tienda en línea, qué es un mercado electrónico, cómo son las aplicaciones de
empresa a empresa o las de la administración, cómo se han de gestionar los
canales y qué retos plantean para el negocio y su relación con los distribuido-
res, etc.), que exceden las pretensiones de este módulo.
Resumen
Las empresas aprovechan las tecnologías de la información para soportar

transacciones y mejorar los procesos de trabajo, la relación entre los diferentes
procesos internos y las relaciones con clientes, proveedores y socios. La visión
de la empresa por procesos se contrapone a la concepción tradicional de la
empresa organizada en funciones, departamentos o grupos de trabajo.
Las empresas mejoran sus procesos de manera constante y gradual y aplican

la tecnología a la mecanización de las operaciones. Pero a veces, las empre-
sas aplican cambios más radicales y reconfiguran los procesos y las relaciones
internas y externas mediante la tecnología. Estas operaciones se denominan
reingeniería de procesos.
En los últimos veinte años, han aparecido productos informáticos que contie-
nen en su diseño un catálogo de buenas prácticas para los diferentes procesos
típicos de la cadena de valor (las compras, la producción, las ventas, las finan-
zas, los recursos humanos, etc.). Son productos como los ERP, CRM, SCM, etc.
La implantación de estos productos estándar permite potencialmente hacer
un ejercicio de reingeniería de los procesos de la empresa, globalmente o en
cada ámbito.
Normalmente la implantación de sistemas ERP (multiproceso) o de sistemas

estándar de cada proceso de la cadena de valor se utiliza para mejorar la gestión
interna, reduciendo costes o tiempos de entrega. Aun así, en los últimos años
las tecnologías de Internet han actuado también sobre la relación con terceros,
en la cadena de valor extendida.
La adopción de este tipo de productos tiene el potencial de modificar radical-

mente la manera de trabajar y competir, pero para tener éxito requiere una
estrategia y una planificación muy cuidadosas, una inversión adecuada, asig-
nación de recursos y mantenimiento en el tiempo.
Bibliografía
Andreu, R.; Ricart; J. E.; Valor, J. (1996). Estrategia y sistemas de información (2.ª edición).
Madrid: McGraw-Hill.
Davenport, T. (2000). "Enterprise Systems and Process Change: Still no Quick Fix". Maste-
ring Information Management. Londres: Financial Times Prentice Hall.
Davenport, T. (2000). Mission critical. Realizing the promise of information systems. Boston:
Harvard Business School Press.
Davenport, T. (1993). Reengineering Work through Information Technology. Boston (MA, EE.
UU.): Harvard Business School Press.
Edwards, C.; Ward, J.; Bytheway, A. (1998). The Essence of Information Systems. Londres:
Prentice Hall.
Gómez Vieites, A.; Suárez Rey, C. (2006). Sistemas de información: herramientas para la
gestión empresarial. Madrid: Editorial Ra-Ma.
Hagel, J.; Seely, J. (2001). "Your Next IT Strategy". Harvard Business Review. Boston (MA,
EE. UU.).
Hagel, J. (2002). Out of the Box. Boston (MA, EE. UU.): Harvard Business School Press.
Hagel, J.; Seely J. (2002). "Orchestating Bussiness Processes". Harvard Business Review. Bos-
ton (MA, EE. UU.).
Hammer, M.; Champy, J. (1993). Reengineering the Corporation. Nueva York: Harper Busi-
ness.
Porter, M. (1985). Competitive Advantage. Nueva York (NJ, EE. UU.): The Free Press.
Rodríguez, J. R. (2011-2012). Posts en el blog "iNFormáTICa++" <http://

informatica.blogs.uoc.edu/author/jose-ramon/>.
Sieber, S.; Valor, J.; Porta, V. (2006). Los sistemas de información en la empresa actual.
Madrid: McGraw-Hill.
Vollman, T.; Cordon, C. (2000). "Building a Smarter Supply Chain". Mastering Information
Management. Londres: Financial Times Prentice Hall.

Teoria Unificada

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Teoria Unificada

Cargado por

Copyright:

Formatos disponibles

Implantación

1. Características de los sistemas de información de empresa.... 9

2. Fases del ciclo de vida de implantación...................................... 14

3. Fase 1. Adopción del sistema: la decisión de adquirir un

4. Fase 2. Selección de la solución estándar.................................... 25

5. Fase 3. Implantación de la solución............................................. 33

6. Fase 4. Puesta en marcha................................................................. 44

7. Gestión del cambio............................................................................ 46

En los módulos anteriores hemos examinado la estructura, el catálogo de so-

En la actualidad, los SIE cubren la mayor parte de los procesos de negocio de

En este módulo mostramos que la adopción de un SIE, un paquete estándar

Aun más que en otros ámbitos de la gestión y producción de sistemas de infor-

El objetivo de este módulo es familiarizar al estudiante con los procesos de

Aunque se proporciona una guía metodológica general para abordar un pro-

Más concretamente, estos objetivos son:

1) Conocer las características propias de diseño y construcción de los sistemas

• La adopción, es decir, cómo se toma o se debe tomar la decisión de adquirir

3) Entender los dos procesos de "acompañamiento", que se consideran clave

• La gestión�del�cambio, o sea, los aspectos de organización, procesos de

implantación de un SIE. Se analizará, en particular, la estructura de orga-

1. Características de los sistemas de información de

Según hemos visto en la introducción y los primeros módulos de la asignatura, SIE

Podéis ver: A.�Gómez�Viei-

1)�Los�ERP (enterprise resource planning o sistemas de gestión de recursos) clási-

2)�Los�sistemas�de�relación�con�los�proveedores, o sistemas de gestión de la

4)�Los�nuevos�sistemas�que�comienzan�a�llamarse�PRM (partnership relations-

5)�El�conjunto�de�sistemas�de�relaciones�con�los�directivos�y�empleados, Ved también

En este apartado, profundizaremos en las características funcionales de los sis-

Estas características principales, o criterios de diseño, son las siguientes:

1) El software se organiza por procesos�de�trabajo, es decir, cada aplicación o Proceso

3) Probablemente, el aspecto más importante de los modernos sistemas de Workflow

5) El sistema estándar proporciona un menú de opciones funcionales supues-

6) Una consecuencia de mayor calado de esta filosofía es la estandarización

La figura�2 contiene un resumen esquemático de todas estas características.

Figura 2. Arquitectura actual de los sistemas de información de empresa

1.1. Consecuencias para la gestión

Este conjunto de diferencias (también similitudes) tiene consecuencias sobre

1) La relación con el fabricante es completamente distinta que con un pro- Ejemplo

2) El poder de directivos y usuarios finales es también mayor y, frecuentemen-

3) Aparece una tercera figura, el consultor o implantador, que tiene un papel

4) En consecuencia, el papel de los departamentos de informática y sus profe- Intervención de los

6) Al mismo tiempo, la adquisición e implantación de ERP, para funciones o

2. Fases del ciclo de vida de implantación

En los apartados siguientes, profundizaremos en el desarrollo metodológico

La clasificación de estas fases varía entre autores y también en la práctica pro-

El propio enfoque de la implantación (más amplio o más restringido, más rá-

Finalmente, la metodología o metodologías de gestión de proyecto que utilice

Con estas limitaciones, hemos adoptado una clasificación bastante ecléctica

1) Fase 1, o de adopción. Es la fase en que directivos, usuarios y técnicos se

2) Fase 2, o de selección. Una vez tomada la decisión de adoptar un sistema

3) Fase 3, o de implantación del sistema, consistente en la personalización

4) Fase 4, de puesta�en�marcha, que incluye el arranque y la estabilización del

5) La gestión� del� cambio, es decir, todos los procesos de adaptación de la

6) La gestión�de�proyecto, o sea, el conjunto de procesos y habilidades para

Una representación gráfica de este ciclo se muestra en la figura siguiente:

Figura 3. El ciclo de vida de la implantación de un sistema de empresa

• El mantenimiento, sea de corrección de defectos (correctivo), como de

• La evolución, que incluye la extensión de la funcionalidad y la instala-

• La migración a una nueva versión más completa o actualizada técnica o

• La adquisición e implantación de nuevos módulos para cubrir nuevas

3. Fase 1. Adopción del sistema: la decisión de adquirir

Los sistemas de información de empresa proporcionan una infraestructura in-

Reingeniería de procesos y sistemas de información de empresa