Sieber Valor Porta - Los Sistemas de Inf

La empresa virtual i
LOS SISTEMAS
DE INFORMACIÓN
EN LA EMPRESA ACTUAL
Aspectos estratégicos y alternativas tácticas
000 - VALOR - Los sistemas de información en 1la empresa actual.pmd 24/11/2005, 13:14
ii La empresa virtual
La empresa virtual iii
LOS SISTEMAS
DE INFORMACIÓN
Microsoft Excel
EN LA EMPRESA
®
ACTUAL
2002
Aspectos estratégicos y alternativas tácticas
sin problemas
Sandra Sieber
Josep Valor
Valentín Porta
MADRID • BOGOTÁ • BUENOS AIRES • CARACAS • GUATEMALA • LISBOA

MÉXICO • NUEVA YORK • PANAMÁ • SAN JUAN • SANTIAGO • SÃO PAULO
AUCKLAND • HAMBURGO • LONDRES • MILÁN • MONTREAL • NUEVA DELHI
PARÍS • SAN FRANCISCO • SIDNEY • SINGAPUR • ST. LOUIS • TOKIO • TORONTO
iv La empresa virtual
La información contenida en este libro procede de una obra original entregada por el autor.
No obstante, McGraw-Hill/Interamericana de España no garantiza la exactitud o perfección
de la información publicada. Tampoco asume ningún tipo de garantía sobre los contenidos
y las opiniones vertidas en dichos textos.
Este trabajo se publica con el reconocimiento expreso de que se está proporcionando una
información, pero no tratando de prestar ningún tipo de servicio profesional o técnico.
Los procedimientos y la información que se presentan en este libro tienen sólo la intención
de servir como guía general.
McGraw-Hill ha solicitado los permisos oportunos para la realización y el desarrollo

de esta obra.
LOS SISTEMAS DE INFORMACIÓN EN LA EMPRESA ACTUAL
No está permitida la reproducción total o parcial de este libro, ni su tratamiento

informático, ni la transmisión de ninguna forma o por cualquier medio, ya sea electrónico,
mecánico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito
de los titulares del Copyright.
McGraw-Hill / Interamericana
de España S. A. U.
DERECHOS RESERVADOS © 2006, respecto a la primera edición en español, por
McGRAW-HILL/INTERAMERICANA DE ESPAÑA, S. A. U.
Edificio Valrealty, 1ª planta
Basauri, 17
28023 Aravaca (Madrid)
http://www.mcgraw-hill.es
profesional@mcgraw-hill.com
Copyright © 2006 por Sandra Sieber, Josep Valor, Valentín Porta
ISBN: 84-481-4006-0
Depósito legal:
Diseño de cubierta: Luis Sanz Cantero

Compuesto en: GAAP Editorial, S. L.
Impreso en:
IMPRESO EN ESPAÑA - PRINTED IN SPAIN
La empresa virtual v
Contenido
Prólogo .......................................................................................................... vii
Capítulo 1. Introducción .............................................................................. 1
Capítulo 2. Conceptos básicos de sistemas y tecnologías

de la información .................................................................................... 7
Capítulo 3. Compitiendo con los sistemas de información ....................... 31
Capítulo 4. Sistemas para la gestión integrada de los recursos

de la empresa ........................................................................................... 57
Capítulo 5. Sistemas de información para la gestión de la cadena

de suministro ........................................................................................... 81
Capítulo 6. Sistemas para la gestión de las relaciones con los clientes .... 95
Capítulo 7. La externalización de los servicios de TIC

y el Business Process Outsourcing (BPO) ............................................. 115
Capítulo 8. La toma de decisiones de inversión en tecnologías

de la información y comunicaciones ...................................................... 149
Capítulo 9. Medición y control de costes ................................................... 173
Capítulo 10. Gestión de proyectos de tecnologías de la información

y comunicaciones .................................................................................... 195
Capítulo 11. Gobierno del departamento de tecnologías

de la información y comunicaciones ...................................................... 209
Epílogo .......................................................................................................... 229
Glosario básico de términos de las tecnologías de la información

y de la comunicación ............................................................................... 233
vi La empresa virtual
La empresa virtual vii
Prólogo
Los Sistemas de Información (SI), de la mano de las Tecnologías de la Informa-

ción y las Comunicaciones (TIC) han recorrido un largo camino juntos desde la
aparición de los primeros ordenadores y sus iniciales aplicaciones, concebidas
sobre todo para mejorar la eficiencia de procesos administrativos muy básicos,
utilizados en las empresas casi “por obligación”. Muy pocos de ellos, conse-
cuentemente, proporcionaron lo que actualmente denominaríamos “ventajas
competitivas”.
La situación hoy es muy distinta. Superado lo que se vino en llamar la “para-
doja de la productividad”, que ponía en duda la contribución de las TIC vía SI a
la productividad de la economía en general, hemos aprendido que no todos los SI
son iguales, y que las aportaciones claramente positivas de unos pueden discernir-
se de otras hasta contraproducentes, aunque la tecnología básica utilizada en su
implantación y funcionamiento sea exactamente la misma.
Este libro constituye un completo repaso de cómo los SI, aun basados en
enfoques de carácter genérico e incluso implantados a través de soluciones con-
sideradas “estándar” en el mercado, pueden, al final, acompañar, enriquecer, y
en ocasiones incluso determinar, el potencial competitivo y estratégico de una
empresa. Desde esta perspectiva, que incluye de manera fundamental la consi-
deración de encaje del SI con el planteamiento de negocio y la idea de un ade-
cuado desarrollo de capacidades en los procesos de implantación, adaptando así
una tecnología de uso general a la idiosincrasia de cada organización, el libro
constituye una aportación poco común a la vez que valiosa para quienes deseen
aproximarse a estos temas con rigor y pragmatismo, evitando al mismo tiempo
enzarzarse demasiado en detalles de carácter tecnológico.
Los autores han hecho un magnífico trabajo de síntesis, poniendo los SI, las
TIC y la estrategia de negocio en un marco que facilita la toma de decisiones,
con las reflexiones oportunas acerca de los criterios y las responsabilidades ne-
cesarios en el entorno organizativo. Incluso lo que ellos llaman “tácticas” cons-
tituye un complemento muy adecuado para concretar, a lo que contribuyen tam-
bién los numerosos ejemplos y casos prácticos que salpican el texto.
En definitiva, un libro que no dudo constituirá un hito en el campo de los SI,
y que mantendrá su frescor durante tiempo, aun tratándose de un terreno en
constante evolución. Porque se centra en lo fundamental, y lo fundamental per-
siste.
R. Andreu
vii
viii La empresa virtual
Introducción 1
1
Introducción
Tomar decisiones sobre las Tecnologías de la Información y las Comunicaciones

(TIC) con conocimiento de causa y pleno convencimiento de lo que se está hacien-
do sigue siendo, a día de hoy, una asignatura pendiente para muchos gestores de
empresa. No son pocas las organizaciones que delegan en los responsables funcio-
nales a cargo de «Informática» –normalmente en dependencia del director del
área administrativo-financiera– decisiones tan importantes como qué plataforma
tecnológica utilizar, qué sistemas informáticos implantar o, incluso, qué cantidad
invertir en TIC durante el próximo ejercicio. En consecuencia, pocos directores
generales están realmente convencidos de que su empresa esté gastando en TIC las
cantidades adecuadas. ¿Estamos sacando el provecho que deberíamos del nivel
actual de inversión? ¿Podríamos hacer lo mismo con menos? ¿O, por el contrario,
no invertimos lo suficiente y estamos socavando nuestra competitividad futura?
Este libro pretende ayudar a responder a estas y otras preguntas similares que, sin
duda, están ahora mismo en la mente de muchos directivos.
Resulta sorprendente que, tras casi cuarenta años de uso de ordenadores en
las empresas, sus responsables sigan haciéndose este tipo de preguntas básicas.
Una perspectiva histórica de la «Informática» ayuda a comprenderlo. Cuando se
introdujeron las primeras tecnologías de la información en la empresa, allá por
los años sesenta, se pretendían solucionar problemas sencillos pero repetitivos,
muy a menudo relacionados con la facturación y la contabilidad. Por aquel en-
tonces el conocimiento de las interioridades tecnológicas de una determinada
herramienta informática era vital si se pretendía sacarle el máximo rendimiento
a un coste asequible. Visto así, es natural que los responsables del funciona-
miento de la tecnología dependieran de la dirección administrativa-financiera,
su principal usuario. Era la época en la que los programas se desarrollaban bajo
restricciones tecnológicas como tener que minimizar el uso de la memoria del
ordenador, la capacidad de proceso o el espacio en los discos. En otras palabras,
para gestionar la informática había que ser un excelente técnico. Hoy en día,
estas cuestiones ya no quitan el sueño a ningún desarrollador de aplicaciones de
gestión. Baste decir, para dar una idea de cómo han evolucionado las capacida-
1
2 Los sistemas de información en la empresa actual
des de los ordenadores, que un teléfono móvil GSM como el que llevan hoy la
mayoría de adolescentes procesa más información por segundo que podía proce-
sar la NASA en julio de 1969, cuando mandó a sus astronautas a la luna.
Hasta el final de la década de los setenta la repercusión de la informática en
la estrategia de la empresa fue mínima: simplemente ayudaba a reducir los cos-
tes de proceso de información en funciones de soporte. Aunque en términos
relativos la tecnología era mucho más cara que ahora, en aquellos días era fácil
justificar las inversiones y demostrar su rentabilidad. Para llevar a cabo un aná-
lisis coste/beneficio relativamente adecuado, bastaba con valorar las compras de
tecnología, añadirle el mantenimiento y el coste del personal informático aso-
ciado, y compararlo con el ahorro conseguido en tiempo y en mano de obra
administrativa.
Era lógico, pues, que la alta dirección de la empresa tratara desde una cierta
distancia las decisiones en informática y las inversiones relacionadas.
Cuando la tecnología empezó a usarse para resolver otros problemas más com-
plejos planteados por las empresas, tales como los relacionados con sistemas de
producción y de almacenaje, o con la gestión de clientes y proveedores, se desa-
rrollaron unos sistemas de información y de control de gestión que pronto se con-
virtieron en el sistema nervioso de la empresa. Con este tipo de sistemas de infor-
mación, justificar las inversiones con simples análisis coste/beneficio empezó a
hacerse complicado. ¿Cómo medir, por ejemplo, el beneficio de disponer de infor-
mación instantánea sobre el estado de los inventarios en los almacenes de una
empresa de gran consumo? ¿O cómo saber qué cantidad adicional habría que pa-
gar por información actualizada al segundo, en lugar de tenerla en diferido una
hora (o incluso 24) más tarde? La justificación de inversiones es pues una de las
tareas más complejas que debe afrontar la dirección de la empresa.
Y la decisión sobre inversiones en TIC es de la alta dirección de la empresa
debido a su enorme impacto en la manera de funcionar y competir de la empresa
del siglo XXI. Esta relevancia se ha documentado en suficientes foros como para
que no sea necesario enfatizarlo más aquí. Baste con especular qué les pasaría a
las empresas de hoy si la tecnología dejara de funcionar. No sólo escasearía la
información de gestión, sino que ni siquiera podría sacarse dinero de un cajero,
hacer reservas o viajar en un avión. Es muy probable, incluso, que el restaurante
de la esquina no pudiera servir comidas, y que si lo hiciera, no pudiera aceptar
tarjetas de débito. Si las TIC son tan importantes para cualquier empresa, ¿pue-
den sus máximos responsables estar ausentes en las decisiones que al respecto
toman sus ejecutivos, tal como hacían en los años setenta?
Las decisiones sobre tecnología de una empresa presentan un factor de com-
plejidad adicional que viene dado por la interacción entre los sistemas de infor-
mación y los demás sistemas de la organización: sistemas de control, de com-
pensación e incentivos, de planificación y, por supuesto, los relacionados con la
propia estructura organizativa de la empresa. Las modificaciones en los siste-
mas de información deben respetar el equilibrio del resto de sistemas, si lo que
se espera es que unos y otros funcionen de la forma adecuada. Por lo general,
esto significa que los sistemas de información nunca deben concebirse de forma
aislada y que es esencial plantear la implantación de las TIC desde un enfoque
global, que contemple desde cómo hay que controlar y compensar a los emplea-
dos hasta cómo planificar y organizar el proceso de adopción. Cambiando los
flujos y repositorios de información se cambia una de las dimensiones más im-
Introducción 3
portantes del diseño organizativo, lo que impide a la alta dirección de la empresa

sustraerse de las decisiones sobre las TIC.
CONTENIDO DEL LIBRO

Este libro repasa los conceptos necesarios para que un alto ejecutivo pueda gestio-
nar los recursos TIC con la misma soltura y conocimiento de causa con que
–presumiblemente– gestiona las demás áreas de la empresa. No es un libro téc-
nico; de hecho, parte de la idea de que no es necesario ningún conocimiento
tecnológico complejo para ser coherente en las decisiones sobre tecnología y la
gestión de la empresa. El capítulo que sigue a esta introducción presenta los
conceptos técnicos que la alta dirección necesita conocer, suficientes siempre y
cuando el producto final o servicio que ofrece la empresa no esté basado en gran
medida en las TIC; obviamente, el directivo de una empresa cuya actividad prin-
cipal sean las propias Tecnologías de la Información y las Comunicaciones pre-
cisaría de una ampliación de estos conceptos. Además, al final de la obra, se
incluye un glosario con los términos más comúnmente utilizados en el ámbito
de la tecnología y los sistemas de información.
Incluyendo esta introducción, el libro está dividido en doce capítulos, que
pueden leerse de forma independiente en función del interés del lector, de su
previo conocimiento de los temas tratados, o de la asignación requerida si el uso
de la obra es como libro de texto en un curso sobre sistemas de información.
El Capítulo 2 describe la historia y los conceptos básicos en el uso de las TIC
en la empresa. Con el fin de evitar demasiados tecnicismos y de facilitar su
comprensión, se han tratado de explicar los términos tecnológicos de la forma
más sencilla posible. Aún así, puede consultarse el glosario al final de la obra
para una información más detallada. El lector que tenga un mínimo conocimien-
to de las funcionalidades y la estructura de las Tecnologías de la Información y
las Comunicaciones puede obviar este capítulo.
El tercer capítulo se centra en las decisiones que podríamos definir como bási-
cas en la implantación de las TIC, como por ejemplo la planificación de los siste-
mas de información y el posicionamiento de este departamento dentro de la es-
tructura de la empresa. En primer lugar, se aborda la necesidad de «alinear»
los sistemas, o lo que es lo mismo, de tomar decisiones TIC que sean coherentes
con la estrategia de la empresa. En segundo lugar, se discuten aspectos relacio-
nados con la intervención de las capacidades TIC en la definición de la estrate-
gia competitiva de la empresa. Las dificultades específicas a la implantación de
grandes sistemas y cómo conseguir que los usuarios los empleen según lo pre-
visto también son objeto de estudio en este capítulo.
Los Capítulos 4, 5 y 6 exploran, respectivamente, los sistemas de empresa de
mayor relevancia: gestión integrada de los recursos de la empresa (o ERP, Enter-
prise Resource Planning), gestión de la cadena de suministro (o SCM, Supply
Chain Management) y gestión de las relaciones con los clientes (o CRM, Custo-
mer Relationship Management). Partiendo de la idea de que la información ac-
tualizada, consistente y compartida por toda la empresa es una fuente de ventaja
competitiva, se exploran las ventajas que pueden conseguirse mejorando tres
aspectos clave en los sistemas de gestión: las operaciones internas y su gestión
(ERP), la cadena de suministros (SCM) –con sus derivaciones hacia las relacio-
nes entre empresas, representadas por los sistemas Business to Business o B2B, y
la gestión de las relaciones con los clientes (CRM).
La subcontratación (outsourcing) de la gestión de las TIC se analiza en el
Capítulo 7, con un repaso de las ventajas y los inconvenientes de la provisión
por la propia empresa respecto a la subcontratación a terceros, ya sea parcial o
completa. Este mismo capítulo explora también la subcontratación de procesos
de negocio enteros, conocida como BPO o Business Process Outsourcing.
El Capítulo 8 estudia las decisiones de inversión en tecnología de la informa-
ción. Las estrategias de TIC tienen efectos de largo alcance en todas las dimensio-
nes de la empresa y, aún así, muchas veces se toman considerando aspectos pura-
mente económicos, de corto plazo, y sin la aquiescencia de la alta dirección. Se
exploran las razones por las que esto ocurre en la práctica y se proponen una serie
de medidas pensadas para evitar los errores más comunes. Además, se hace refe-
rencia a los sistemas de código abierto en general y al sistema Linux en particular.
Los Capítulos 9, 10 y 11 están dedicados a la gestión y control de la función
de TI en la empresa. El Capítulo 9 trata la medición de los costes incurridos,
tanto los directamente relacionados con en el departamento TIC como los que
puedan quedar «ocultos» en otras áreas funcionales. La gestión, propiamente
dicha, de proyectos de desarrollo TIC y otros aspectos más específicos a la fun-
ción de este departamento son analizados en el Capítulo 10. Cierra este bloque
el Capítulo 11, que pretende ofrecer una visión global del departamento de TI
poniendo especial énfasis en la gestión de sus recursos humanos y en los perfiles
profesionales y carreras de los técnicos del departamento.
El libro concluye con un epílogo y un glosario de términos relacionados con
las TIC.
¿A QUIÉN VA DIRIGIDO ESTE LIBRO?

Esta obra combina el rigor académico con la experiencia práctica, en un texto
claro y fácil de entender para los profesionales de la gestión no especialistas en
tecnologías de la información. No se pretende elaborar un texto académico, si
bien puede ser utilizado en asignaturas de Sistemas de Información en los últi-
mos cursos de ingenierías de organización o en postgrados de escuelas de nego-
cios. Con lecturas selectivas, se puede usar para apoyar la docencia en cursos
dirigidos a ejecutivos que deseen adquirir o ampliar conocimientos sobre los
fundamentos de los Sistemas de Información, su impacto en los demás sistemas
de la empresa, y la gestión de este recurso, cada vez más complejo e importante
para la estrategia empresarial. Igualmente, los ejecutivos con distintos ámbitos
de responsabilidad (tecnológica o no –por ejemplo control de gestión o planifi-
cación) pueden encontrar en los distintos capítulos del libro criterios para apo-
yar la toma de decisiones sobre aspectos específicos relacionados con las TIC o
para desarrollar instrumentos para la gestión y control de las mismas. A tal fin y
para ilustrar las teorías descritas, se han incluido una serie de casos reales de
empresas.
Por todo ello, esta obra puede ser de interés para todo lector interesado en:
z Gestionar el recurso TIC desde el punto de vista de la dirección de la

empresa.
Introducción 5
z Conocer un marco conceptual integrador de todos los aspectos que un di-

rectivo debe conocer en relación a las TIC.
z Obtener un enfoque eminentemente práctico sin descuidar el rigor acadé-
mico.
z Buscar apoyo en casos prácticos de éxito, y en la experiencia como con-
sultores y docentes de los autores.
AGRADECIMIENTOS
Una obra como ésta no es únicamente fruto del esfuerzo de sus autores. Los estu-
diantes y directivos de los programas máster y de perfeccionamiento directivo del
IESE que han seguido los cursos de Sistemas de Información impartidos por San-
dra Sieber y Josep Valor y los clientes de CRM Concord (hoy integrado en Mercer
Management Consulting) que de forma anónima o explícita han contribuido ex-
poniendo sus problemas y dejándose estudiar como casos-ejemplo, han sido fun-
damentales a lo largo de todo el proceso. Una mención muy especial merece nues-
tro colega del IESE Rafael Andreu, con el que hemos pasado muchas horas
debatiendo temas de Sistemas de Información, y cuya visión nos ha acompañado
al escribir esta obra. Asimismo agradecemos la ayuda que nos han brindado en la
preparación del material y en parte de la redacción Eduardo Soler, Susanna Arasa
y Tomás Crespo, del IESE; Marta Comín, Gemma Golobardes, Marisol Pérez y
Gemma Tonijuan, del e-business Center PwC&IESE; y Patricia Martín y Enrique
Vigneron, de CRM Concord. Ha sido de vital importancia la ayuda de Isabel Gar-
cía en todos los temas logísticos y administrativos. Nuestros inmediatos superio-
res, Jordi Canals, Director General del IESE, y José Miguel Argüelles, Director
General de CRM Concord, nos han proporcionado el tiempo y los recursos nece-
sarios para llevar a cabo este trabajo. Finalmente, esta obra no hubiera sido posible
sin el apoyo de nuestros cónyuges Jaume Català, Montse Soler y Adela Martín,
que han aguantado pacientemente nuestras ausencias –presenciales y mentales–
mientras nos dedicábamos a este empeño.
Conceptos básicos de sistemas y tecnologías de la información 7
2
Conceptos básicos
de sistemas y tecnologías
de la información
Antes de entrar en el estudio de los sistemas y las tecnologías de la información en

sí mismos es necesario dejar bien claro lo que actualmente se entiende como infor-
mación y –lo que puede ser todavía más importante– la diferencia entre datos,
información y conocimiento. Son muchos los responsables de Tecnologías de In-
formación y Comunicación (TIC) que desconocen cómo tratar estos conceptos y
qué abarca cada uno de ellos. Toda información procede de algún dato anterior.
Sin embargo, no todos los datos son información. Es más, se pueden tener muchos
datos y mucha información y, aún así, no haber acumulado ningún conocimiento.
En efecto, los datos no son más que elementos de tipo numérico, alfanuméri-
co, imágenes o sonidos que permiten describir ciertos eventos, actividades o tran-
sacciones. Se trata de elementos que pueden estar almacenados e incluso clasifica-
dos, pero no organizados para dar respuesta a cuestiones específicas o a significados
concretos.
La información proviene de la ordenación de los datos de forma que éstos
tengan un significado concreto para el que los recibe e incluso un valor determi-
nado. De esta forma, el destinatario puede analizar dicho significado y obtener
conclusiones. Mientras que los datos en sí no son nada, sí lo es la información
que se pueda obtener de ellos. Las decisiones que se toman habitualmente en las
empresas provienen de información recabada a partir de datos, previamente cla-
sificados y presentados adecuadamente para facilitar el proceso.
Sin embargo, estar informados no es suficiente para tomar decisiones acerta-
das. Cualquier decisión requiere también de la experiencia, historia profesional
y personal de quien la toma, así como de sus propios elementos de juicio y de
evaluación de la información. La información evaluada por una persona dentro
de un contexto se convierte en conocimiento. Los sistemas de información, vis-
tos desde esta perspectiva, pueden mejorar el desarrollo de una base de conoci-
miento si ponen al alcance de los agentes de decisión información relevante. De
hecho, en entornos cambiantes una buena base de conocimiento constituye a
menudo una fuente fundamental de ventaja competitiva, y en estas situaciones
los sistemas de información pueden resultar esenciales.
7
¿QUÉ ES UN SISTEMA DE INFORMACIÓN? 1

Previo al análisis de los aspectos más importantes de planificación, diseño, im-
plantación y gestión de los Sistemas de Información (SI), es conveniente intro-
ducir brevemente algunos conceptos básicos para aclarar qué se entiende por el
sistema de información de una empresa.
La visión más intuitiva del SI de una empresa se obtiene simplemente obser-
vando cómo fluye la información dentro de la misma y entre ella y su entorno.
Algunos flujos de información son claramente observables porque se corres-
ponden con flujos físicos. Imaginemos, por ejemplo, el pedido de un cliente que
llega a una empresa; alguien del departamento de ventas lo registra y envía una
copia al almacén para que pueda ser servido (probablemente después de com-
probar que el cliente en cuestión tenga crédito); en el almacén se comprueba que
exista stock disponible y, en caso afirmativo, se asigna al pedido, se adjunta el
albarán correspondiente y se remite una copia a facturación, donde se prepara la
factura de acuerdo con las condiciones pactadas con el cliente.
Este trasiego de información, presente en cualquier empresa comercial, es
necesario para coordinar acciones de carácter operativo e imprescindible para el
funcionamiento de cualquier organización. Habitualmente a estas tareas se las
califica como procesos transaccionales. Normalmente estos procesos –que in-
volucran a clientes, proveedores y otros miembros del entorno de la empresa–
registran las transacciones con el doble objetivo de coordinar acciones y dispo-
ner de una base de información en la que apoyar la toma de decisiones en la
actividad empresarial en general.
Pero la necesidad de acceder a información no sólo está presente en la toma
de decisiones más o menos rutinarias y operacionales como las descritas. Acce-
der a información relevante es imprescindible para el desempeño de todas las
funciones y procesos de negocio de una empresa. Desde la planificación y defi-
nición de sus objetivos hasta el control de la consecución de los mismos, pasan-
do por el diseño y puesta en práctica de acciones encaminadas a conseguirlos.
Por tanto, se puede definir el SI de una empresa como un sistema más dentro
de los sistemas de gestión de la misma, encargado de coordinar los flujos y
registros de información necesarios para llevar a cabo las funciones de una em-
presa determinada de acuerdo con su planteamiento o estrategia de negocio.
Desde un punto de vista general, dichas funciones dan lugar a actividades de
planificación, diseño y ejecución de acciones para conseguir objetivos y activi-
dades de control. Además, mucha información relevante para estas actividades
puede obtenerse del registro de transacciones de actividades operativas básicas.
Puesto que las distintas actividades de soporte se complementan y apoyan entre
sí, se puede afirmar que el SI interacciona con todas las actividades de la empre-
sa. De hecho, como el SI es el encargado de recopilar la información que gene-
ran las distintas actividades y de distribuirla hacia otras áreas para posibilitar
una buena toma de decisiones, tiene claramente una función coordinadora.
En definitiva, el SI tiene que ser concebido como parte integrante de la infra-
estructura de la empresa, ya que la información que maneja, aunque generada o
1
Esta sección se basa en sus definiciones y conceptos básicos en el trabajo de Andreu R., Ricart
J. E. y Valor J. en Estrategia y Sistemas de Información; McGraw-Hill (1996).
utilizada por actividades concretas, no pertenece a ninguna en particular sino a la

empresa considerada globalmente.
En un tono más formal, el SI es «el conjunto formal de procesos que, operan-
do sobre una colección de datos estructurada de acuerdo con las necesidades de
una empresa, recopila, elabora y distribuye (parte de) la información necesaria
para la operación de dicha empresa y para las actividades de dirección y control
correspondientes, apoyando al menos en parte, la toma de decisiones necesaria
para desempeñar las funciones y procesos de negocio de la empresa de acuerdo
con su estrategia» (Andreu, Ricart y Valor, 1996).
Esta definición se centra fundamentalmente en el para qué del SI, más que en
el cómo o en el qué. Las empresas necesitan que determinada información fluya
para coordinar sus acciones operativas, y que otra información llegue a tiempo y
organizada adecuadamente para que los responsables tomen sus decisiones con el
máximo conocimiento de causa y para que quienes coordinan las distintas activi-
dades puedan hacerlo en cuanto se detecte la primera desviación relevante entre lo
previsto y lo real. Y todo ello, para llevar a cabo las funciones y procesos de
negocio que la empresa les ha encomendado de manera coherente con los objeti-
vos de la misma. En ocasiones la propia estrategia de negocio de una empresa
puede contar con el SI como parte activa de la misma. Dicho de otro modo, el SI
también puede utilizarse para la obtención de ventajas competitivas.
En conclusión, la planificación, el diseño y la implementación del SI en una
organización deben tener en cuenta su estrecha relación con los demás sistemas
que coniguran la infraestructura de la empresa que, a su vez, deben asegurar
la coherencia del SI resultante con la estrategia competitiva de la empresa. En
estos procesos la dirección debe involucrarse y jugar un papel esencial, del mis-
mo modo en que se involucra, por ejemplo, en el diseño del sistema de control o
en el de planificación.
Todo esto tiene una serie de implicaciones para la dirección, resumidas en el
Cuadro 2.1.
Características de un sistema de información eficaz
z La estructura y funciones del SI de una empresa deben ser coheren-

tes con su estrategia en cada momento.
z La planificación y el diseño de un SI deben servir a los objetivos estra-
tégicos de la empresa, por lo que tienen que ser consensuados entre
los expertos de SI y el resto de la organización.
z El SI se tiene que planificar, diseñar e implantar de forma que guarde
un equilibrio con el resto de sistemas integrantes de la infraestructura
organizativa.
z El SI tiene que gestionarse desde una perspectiva amplia, contando
con la implicación y el compromiso de la alta dirección de la empresa.
Cuadro 2.1. Características de un sistema de información eficaz.

(Fuente: Adaptado de Andreu, Ricart y Valor, 1996.)
TECNOLOGÍA Y SISTEMAS DE INFORMACIÓN

Hoy en día no se puede hablar de sistema de información sin pensar inmediatamente
en tecnología. Sin embargo, es importante tener en cuenta que, aunque hablemos de
tecnología, la necesidad inicial se plantea en términos de Sistema de Información
(SI). Esto no significa que la tecnología sea irrelevante, ni mucho menos, pero sí
puede decirse que su influencia en la implementación, diseño y planificación de los
SI de las empresas es meramente coyuntural. En otras palabras, sin una buena concep-
ción de la necesidad inicial en términos de SI muy difícilmente pueden lograrse im-
plantaciones efectivas y adecuadas al negocio, por muy buena tecnología que se em-
plee. En cambio, se pueden obtener SI contando con una buena concepción inicial,
aunque se implanten con tecnología básica y estándar.
Por TIC se entiende informática y afines, es decir, necesidades de hardware,
software y telecomunicaciones de una empresa. El punto de contacto inicial
entre estas tecnologías y los SI es obvio, ya que las TIC proporcionan soluciones
claras a determinados problemas que presenta la implementación de todo SI:
almacenamiento de datos y posterior acceso según pautas difíciles de anticipar,
tratamiento de datos rápido y sin errores, comunicaciones automáticas, etc.
Cabe tener en cuenta que las características de la tecnología pueden llevar a
reconsiderar el funcionamiento de los SI, ya que al adoptar una determinada
solución de TIC pueden darse dos circunstancias. Por un lado, las TIC pueden
aportar mejores maneras de hacer las cosas. Existe un sinfín de casos en los que
las TIC han permitido hacer las cosas de forma más eficaz y barata. Tomemos,
por ejemplo, los tiempos medios necesarios requeridos para transacciones de
pedido, entrega, facturación y pago, que se han acortado drásticamente, como se
muestra en la Figura 2.1.
Pero por otro lado, la implantación de una determinada solución tecnológica
también puede forzar a que algunas actividades se hagan peor, debido a la rigi-
dez que puede llegar a imponer. Por eso resulta imprescindible conocer clara-
mente las posibilidades de la tecnología en términos de lo que puede aportar a
nuestro SI. Este conocimiento debe estar presente en las empresas desde la pers-
pectiva de SI, que en definitiva es una perspectiva de empresa.
COMPONENTES DE LA TECNOLOGÍA:
HARDWARE, SOFTWARE Y TECNOLOGÍAS DE REDES
Un SI típico se apoya en tres componentes: el hardware, constituido por todas
aquellas partes que se pueden tocar físicamente, el software (los programas), y
las tecnologías de redes, necesarias para conectar diferentes máquinas.
Existen diferentes tipos de arquitecturas de sistemas, dependiendo de las nece-
sidades de las empresas y del momento histórico en el que se introdujeron las
tecnologías de información. Así, en los años setenta IBM popularizó la arquitectu-
ra mainframe, cuya filosofía básica consiste en disponer de un gran ordenador
central (mainframe) que sirve a cientos o miles de usuarios conectados a él vía una
pantalla tonta (dumb terminal) que se utiliza para entrar o cambiar datos y acceder
a información en el mainframe. Un mainframe típico tiene hoy en día el tamaño de
un coche utilitario pequeño, aunque en los setenta uno de potencia equivalente
podía llegar a ocupar varias habitaciones y necesitaba de una instalación de enfria-
020 - VALOR - Los sistemas de información en 10

la empresa actual.pmd 24/11/2005, 13:14
1960 2000
Pedido 4-7 días Mismo día
Entrega 14-21 días Siguiente día
Facturación 4-7 días Mismo día
Pago 45-60 días 45-60 días
Figura 2.1. Tiempos de procesamiento de transacciones, 1960 y 2000.

(Fuente: Pillen/Associates, Inc., 2002.)
miento de agua para su refrigeración. Los mainframes satisfacen las necesidades de

procesamiento de información de grandes corporaciones y sus precios pueden llegar
a alcanzar varios millones de euros. Sin embargo, en la actualidad muy pocas orga-
nizaciones utilizan exclusivamente este tipo de arquitectura basada en un único or-
denador central. A partir de mediados de los años ochenta, aproximadamente, se fue
extendiendo el uso de terminales inteligentes en forma de PC de sobremesa o portá-
tiles, que además de teclado y pantalla, incorporan elevadas capacidades de proceso
y almacenaje, de modo que los usuarios pueden procesar información localmente,
de forma descentralizada y autónoma respecto al mainframe u ordenador central. La
aparición de los PC ha dado lugar a nuevas coniguraciones de red, también denomi-
nadas «arquitecturas». Una arquitectura especialmente popular en pequeñas organi-
zaciones es la denominada de entorno PC, en la que todo el hardware de la empresa
está compuesto por PC conectados en red, con alguno de ellos dedicado a tarea de
almacenamiento de datos.
Sin embargo, actualmente la arquitectura que predomina en la gran mayoría
de organizaciones es el entorno distribuido, en el que el procesamiento de infor-
mación se reparte entre dos o más máquinas. Éstas pueden ser mainframes, po-
tentes servidores tipo PC o bien otros tipos de máquinas desarrolladas en las
últimas décadas, como las cada vez más populares midrange, con capacidades
de procesamiento y almacenamiento superiores a las de los PC pero inferiores a
las de un mainframe. Dentro del entorno distribuido, destaca la arquitectura de
cliente-servidor, en la que varios ordenadores comparten recursos y se comuni-
can con muchos otros ordenadores vía redes locales. En esta configuración los
ordenadores se dividen en dos grandes categorías: clientes y servidores. Un cliente
es un ordenador tipo PC conectado a una red que almacena una serie de recursos
compartidos. El servidor es la máquina conectada a esa misma red que provee a
los clientes de los servicios en red. Ejemplos típicos son servidores de bases de
datos, provistos de gran capacidad de almacenamiento, los servidores de correo
electrónico o los servidores de comunicación, que facilitan las conexiones a
otras redes. Así se optimiza el uso de los recursos, ya que se consigue que má-
quinas diferentes trabajen simultáneamente, cada una de ellas haciendo funcio-
nes específicas. Además, resultan muy flexibles y permiten abarcar tanto las
necesidades de empresas pequeñas como las de grandes corporaciones.

Tipos de hardware
Del apartado anterior se deduce que se debe distinguir entre diferentes catego-
rías de hardware. Ya hemos hablado de las diferencias entre ordenadores cliente
–típicamente PC o portátiles–, y de los de uso compartido –mainframe, midran-
ge o servidores–. Además, está el denominado hardware de periféricos, que eng-
loba impresoras, plotters o escáneres. Finalmente existe otra familia de hard-
ware, necesaria para la infraestructura de redes, formada por hubs o routers
(encaminadores) que se dedican exclusivamente a interconectar diferentes má-
quinas entre sí. La sección siguiente, dedicada a los sistemas de comunicación,
explica con algo más de detalle el funcionamiento de este tipo de hardware espe-
cializado.
Desde la aparición de los primeros ordenadores, hace ya más de cincuenta años,
el ritmo de innovación en el campo del hardware ha sido espectacular. El ejemplo
más conocido de innovación tecnológica es el de los microprocesadores de Intel.
En 1965 George Moore, uno de los fundadores de la empresa, publicó un artículo
en el que afirmaba que cada dos años podría fabricar circuitos integrados del doble
de potencia sin aumentar el coste2. Esta sentencia, denominada Ley de Moore, se
ha cumplido hasta nuestros días, tal como muestra la Figu-
ra 2.2. De hecho, ha sido parte importante del auge de los sistemas de informa-
ción en la segunda parte del siglo XX.
Sirva como ilustración la siguiente analogía: suponiendo que la aviación co-
mercial hubiera avanzado al mismo ritmo que los microchips, tendríamos que
un vuelo Nueva York-Madrid que en 1978 costaba unos 900$ y tardaba 9 horas
hoy costaría sólo 1 centimo y duraría 0,25 segundos.
Las innovaciones en el campo del procesamiento de datos han ido acompa-
ñadas de otras tantas innovaciones en el campo del almacenamiento y de la
comunicación. Así, si en los años cincuenta una empresa podía tener capacidad
para almacenar 10Kb3 de datos (véase Figura 2.3) comparando el disco de 10Kb
con el de 181Gb), en 1997 ordenadores típicos de sobremesa llegaban a 1Gb, y
en 2005 cualquier persona puede tener fácilmente más de 100Gb para el almace-
namiento de datos. En el campo de los servidores la evolución ha sido parecida,
y en 2004 la empresa Sun Microsystems, líder del mercado, ofrecía capacidades
de hasta 147.5Tb con su sistema StorEdge 9980.
En el campo de las comunicaciones, el cable telefónico habitual (un par de
hilos de cobre) soportaba velocidades hasta 56.6 kb/s4, capacidad que se vio
incrementada por sucesivas innovaciones en los protocolos de comunicación hasta
llegar a los 128kb/s del RDSI o a los 9Mb/s del ADSL. Además, el desarrollo de
otros tipos de redes de comunicación como el cable coaxial y la fibra óptica ha
permitido llegar a anchos de banda aún superiores, tal como se muestra en el
cuadro de la Figura 2.4.
2
La frase exacta de Moore fue expresada en términos de doblar el número de transistores por
unidad de superficie, que de hecho equivale a doblar la potencia.
3
Véase el glosario al final de esta obra para las definiciones exactas de las capacidades de medi-
da de almacenaje. Kb (kilo byte, 1032 bytes), Mb (mega byte, 1032 Kb), Gb (giga byte, 1032 Mb) y
Tb (tera byte, 1032 Gb).
4
kb/s son kilo-bits por segundo, o 1.024 unidades básicas de información (0 o 1) por segundo.
Véase el glosario al final de la obra para una definición más exacta.

Intel
Itanium II
Intel
Itanium
1.000.000.000
Intel
Pentium IV
Intel
100.000.000 Pentium III
Intel
Pentium II
Intel
Nº de transistores
10.000.000 Pentium
Intel
486TM
Intel
1.000.000 386TM
286
100.000 8086
8080
8008
10.000
4004
1.000
1971 1972 1974 1978 1982 1985 1989 1993 1997 1999 2000 2002 2003
Figura 2.2. La "Ley de Moore" en acción.

(Fuente: Elaboración propia a partir de datos encontrados
en la página web de Intel: http://www.intel.com.)
“Disco” de 10K, 1953 Disco de 1G (1.000.000 K), 1997
2G 0,5G
Memorias permanentes, 2003 Disco de 181G, 2001
Figura 2.3. Discos de diferentes épocas y capacidades.

(Fuente: Elaboración propia.)

Ancho de banda
Tipo de medio de comunicación
(velocidad de transmisión)
56,9 kbps con módem tradicional

Cable telefónico
hasta 9 Mbps con tecnología ADSL
Cable coaxial Hasta 200 Mbps
Cable de fibra óptica De 100 Mbps a 2 Gbps
Radio (broadcast) Hasta 2 Mbps
Radio (microondas) 45 Mbps
9.600 bps con GSM

Radio (telefonía móvil) Hasta 171,2 kbps con GPRS
Hasta 2 Gbps con UMTS
Satélite Hasta 100 Mbps
Infrarrojos 1 a 4 Mbps
Bluetooth Hasta 2,1 Mbps
(Nota: velocidades conocidas en marzo de 2005, evoluciones de la tecnología

sin duda incrementarán las velocidades en algunos medios.)
Figura 2.4. Velocidades de transmisión de datos en diferentes medios.
Tipos de software
El software, o programas, son el conjunto de instrucciones que ejecutadas por los

ordenadores, definen nuestra experiencia de uso. Hay que distinguir entre soft-
ware de sistemas y software de aplicación.
El software de sistemas se refiere principalmente a los sistemas operativos,
que son los que controlan el hardware y posibilitan el uso de los programas.
Todos los ordenadores tienen un sistema operativo. En el caso de los ordenado-
res de sobremesa, los sistemas operativos más comunes son los de las familias
Windows, Macintosh y UNIX. Los sistemas XP (Windows), Mac OS X (el últi-
mo sistema operativo desarrollado por Macintosh) y el software libre Linux (Unix)
son los más populares de cada familia. Existen cientos de otros sistemas opera-
tivos desarrollados para aplicaciones específicas, especialmente diseñados para
mainframes, robótica, aplicaciones concretas de producción o sistemas de con-
trol en tiempo real, por ejemplo.
Pero, ¿qué hace exactamente un sistema operativo? Explicado de forma sim-
ple, gestionar los recursos de hardware y software de un equipo (el procesador,
la memoria, el espacio de disco, las impresoras y demás periféricos, etc.). Esta
labor es importante, ya que típicamente varios programas, y probablemente el
propio usuario entrando información con el teclado, compiten por la atención de
la CPU (Central Processing Unit o unidad central de procesamiento) pidiendo

memoria, espacio de almacenamiento y ancho de banda tanto de entrada como de

salida. El sistema operativo permite, por ejemplo, que se pueda tener en marcha
simultáneamente un procesador de texto y una hoja de cálculo, que se puedan
entrar datos utilizando indistintamente el teclado o el ratón, imprimir los resulta-
dos en impresoras diferentes o enviarlos por e-mail a otros usuarios. Al hacer todo
esto, el sistema operativo es quien mantiene el orden y asegura que cada aplica-
ción recibe la atención adecuada sin dejar sin recursos (o «colgada») a ninguna
otra. En resumen, gestiona la capacidad limitada del sistema para mayor beneficio
de todos los usuarios y aplicaciones.
Cabe distinguir también entre los sistemas operativos que gestionan múlti-
ples tareas de un único usuario de PC u ordenador portátil y aquellos que se
encargan de múltiples tareas y múltiples usuarios de un servidor o mainframe.
Estos últimos no sólo se encargan de las tareas ya descritas, sino también de
asegurar que los requerimientos de los distintos usuarios sean satisfechos de
forma equilibrada. Esto significa que los programas que se ejecuten en una má-
quina con múltiples usuarios tengan recursos suficientes y separados, de modo
que un problema de un usuario no afecte a la comunidad entera.
Una segunda familia la forma el llamado software de aplicación, que suele
comercializarse en forma de paquete cerrado y listo para utilizar. Ejemplos típi-
cos en el PC son los paquetes Microsoft Office (que engloba distintos programas
de ofimática) o Photoshop (con distintas aplicaciones para el tratamiento de
imágenes). Existen también otras aplicaciones para servidores y mainframes,
más sofisticadas, que requieren algún tipo de personalización, como SAP, People-
Soft o Siebel. Finalmente, algunas aplicaciones son creadas por las propias em-
presas o por proveedores externos especializados en satisfacer necesidades con-
cretas que ningún paquete estándar cubre satisfactoriamente.
El software constituye en la actualidad una parte creciente del coste típico de
un departamento TIC, tal como muestra en la Figura 2.5.
Redes y telecomunicaciones
El tercer elemento necesario para cualquier sistema de información son las re-
des de comunicación y las telecomunicaciones que hacen posible el intercambio
de datos entre diferentes ordenadores, su almacenamiento en unidades centrales,
la comunicación instantánea entre trabajadores que están a miles de kilómetros
de distancia o el trabajo conjunto de varios usuarios en un único archivo.
Las tecnologías de redes constituyen un elemento esencial en casi cualquier
empresa, aunque a menudo las utilizamos sin ser conscientes de ello. El ejemplo
de red más conocido es la Internet pública, que une a millones de ordenadores
dispersos en todo el mundo y permite que amigos, empleados, clientes o provee-
dores intercambien datos de toda índole. Sin embargo, a nivel empresarial redes
más pequeñas son fundamentales para el buen funcionamiento del día a día. Mu-
chos grandes almacenes, por ejemplo, cuentan con ordenadores especializados
que registran las transacciones en cada punto de venta y remiten la información
recogida a la central para que sea utilizada en la gestión de las existencias.
Las redes pueden clasificarse en dos grandes grupos. Las denominadas LAN
(Local Area Network o red de área local, RAL) conectan equipos que están rela-
tivamente cerca unos de otros, normalmente dentro de un mismo edificio. Las

Presupuesto en TIC por categoría (%) 2002 2003
Hardware 23,4 24,4
Software 19,1 18,9
Servicios externos 12,9 13,0
Telecomunicaciones 14,6 14,1
Dirección, Gestión y Administración 23,2 21,9
Almacenes 3,3 3,6
Planta física y otros 3,5 4,1
Figura 2.5. Categorías de gastos de TIC en las empresas.

(Fuente: Gartner, 2003, IT Spending and Staffing Survey among 400 UD
Companies.)
WAN (Wide Area Networks o redes de alcance intermedio), en cambio, conectan a

equipos que pueden estar a muchos kilómetros de distancia. Normalmente las LAN
son más rápidas y fiables, aunque sucesivas innovaciones tecnológicas en el área
de la comunicación han ido menguando las diferencias entre LAN y WAN. La
introducción de cables de fibra óptica ha permitido conectar equipos que están a
varios kilómetros mediante tecnologías LAN, al tiempo que ha servido también
para mejorar la rapidez y fiabilidad de las redes WAN.
La tecnología más extendida para redes LAN es Ethernet, un protocolo de
comunicación desarrollado y probado por primera vez en 1973 por Bob Metcal-
fe en el Xerox Corporation Palo Alto Research Center, PARC. Existen otras tec-
nologías alternativas de redes locales como las de token ring o las redes ATM
(Asynchronous Transfer Mode), aunque Ethernet es la tecnología más amplia-
mente utilizada en la actualidad. Sin ánimo de entrar en demasiados tecnicis-
mos, cabe destacar que cualquier LAN suele contar con una pieza de hardware
fundamental para aumentar el uso eficiente de una red: el intercambiador (switch)
que se encarga de poner orden entre los miles o millones de mensajes que se
envían cribándolos y dirigiéndolos a segmentos concretos de la red local.
Una LAN se puede conectar con otras redes públicas mediante una salida
(network gateway). Para ello se requiere de otra pieza de hardware: el router o
«encaminador», un ordenador especializado en gestionar el intercambio de da-
tos entre redes. El router cumple dos tareas: primero, asegura que la informa-
ción no va a sitios innecesarios –algo esencial para evitar la congestión de re-
des–, y segundo, verifica que la información enviada llegue a su destino previsto.
Al hablar de redes, no podemos ignorar aquella tecnología que ha creado la
red más grande del mundo: Internet. Internet es, como su propio nombre indica,
una red de redes interconectadas para formar una sola entidad. Ello es posible
gracias a la existencia de una serie de políticas y protocolos que definen cómo
usamos e interactuamos con Internet. También puede utilizarse a nivel local,
creando las denominadas intranets.
Es importante entender que existe una jerarquía de redes. Así, por ejemplo,
un particular que tiene un ordenador en su casa forma parte de la red gracias a

que puede conectarse a ella, mediante el hilo telefónico y a través de un módem,

a un proveedor se servicio de Internet o ISP (Internet Service Provider). En cam-
bio, en el trabajo uno suele formar parte de una LAN, que puede estar conectada
a Internet mediante un ISP normalmente mediante una línea dedicada (véase
Figura 2.6)
En Internet, docenas de ISP se conectan a los denominados puntos de acceso
a red (Network Access Points, NAP) formando redes, típicamente regionales.
Estas redes, a su vez, están interconectadas mediante conexiones de alta veloci-
dad, los denominados backbones formados por cables de fibra óptica. El conjun-
to forma Internet, y mediante la ayuda de los routers millones de mensajes via-
jan a través de las distintas redes, cruzando medio mundo en cuestión de fracciones
de segundo, y llegan a su destino.
Pero… ¿cómo funciona Internet?
El buen funcionamiento de Internet sería impensable de no ser por una serie de

protocolos y políticas generalmente establecidas que garantizan una buena co-
municación entre máquinas. Las personas nos podemos comunicar unas con otras
de forma espontánea, mientras que las máquinas –dada su nula inteligencia–,
requieren el uso de protocolos previamente establecidos para poder comunicarse
con éxito. Por ello, cuando hablamos de protocolos nos referimos a una serie de
procedimientos que siguen los programas de comunicación y que regulan el
tráfico de comunicaciones entre el emisor y el receptor.
El órgano coordinador de la implantación de estas políticas y protocolos es la
Internet Society (ISOC), una organización sin ánimo de lucro creada en 1992. Su
misión consiste en «asegurar el desarrollo, la evolución y un uso abierto de Inter-
net para beneficio de todas las personas en todo el mundo». A mediados de 2004
Internet
Backbone
T3
Línea
Servidor
dedicada
T1
ISP
Router
Línea telefónica con módem
RDSI (Red Digital Servicios Integrados)
ADSL (Asymmetric Digital Subscriber Line)
LAN
Figura 2.6. La Internet como red de redes.


contaba entre sus miembros a más de 150 organizaciones y 16000 individuos de

más de 180 países.5
Gran parte del éxito de Internet se explica por el desarrollo, a mediados de los
años 70, de un protocolo de red adoptado como estándar de comunicación entre
máquinas por el Departamento de Defensa de Estados Unidos. Así, el protocolo
TCP/IP se difundió rápidamente posibilitando la comunicación masiva de máqui-
nas dispersas en todo el mundo. En realidad, se trataba de dos protocolos: el TCP
(Transfer Control Protocol), que permite establecer conexiones entre ordenado-
res; y el IP (Internet Protocol), que se encarga del transporte de la información a
través de la red hasta llegar a su destino. Aunque el usuario final normalmente no
es consciente de la existencia de estos protocolos (o sólo cuando ¨no funciona
Internet¨), creemos que entender su funcionamiento es esencial.
El protocolo IP es el lenguaje que usan los ordenadores para comunicarse en
Internet, mediante el uso de una aplicación, como puede ser un navegador. Ade-
más, el IP proporciona a cada máquina conectada un número único identificati-
vo, que típicamente tiene un aspecto como: 172.58.61.1296. Existen más de cua-
tro mil millones de direcciones IP7, que se utilizan también para crear distintas
categorías en función del tamaño y las necesidades de organizaciones, gobiernos
u otras entidades.
De este modo, para localizar un ordenador de una red determinada, hace
falta conocer su dirección IP. Cuando Internet era pequeño se solía introducir
directamente el número de IP en el navegador para establecer la conexión. Este
sistema, sin embargo, resultó demasiado farragoso cuando más y más sistemas
se conectaron a Internet, por lo que en 1983 la Universidad de Wisconsin creó un
sistema, el Domain Name System (DNS) que automáticamente corresponde cada
dirección IP con un nombre propio en forma de texto. De este modo, uno sólo
tiene que recordar el nombre de un cierto dominio, como por ejemplo
www.intermonoxfam.org, en lugar de su número IP. De hecho, cada vez que uno
introduce el nombre de un dominio, el navegador contacta con un servidor DNS
para que le traduzca ese nombre (entendible para humanos) en una dirección IP
(entendible para máquinas).
El servidor DNS, ante un requerimiento así, puede llevar a cabo cuatro ac-
ciones diferentes:
z Contestar con la dirección IP porque sabe cuál es.

z Contactar a otro servidor DNS para que averigüe la dirección IP del do-
minio solicitado, que él desconoce. (Puede tener que hacer esto más de
una vez.)
z Contestar que no conoce esa dirección IP, pero facilitando la IP de otro
servidor DNS que tenga más información (servidores DNS especializa-
dos en dominios concretos).
5
Para más información se puede consultar su página web en http://www.isoc.org/.
6
Los cuatro números de una dirección IP se denominan también octetos. Esto se debe a que,
cuando están expresados en lenguaje binario cada uno de ellos tiene ocho posiciones, con lo que el
número mayor en cada posición es 2 a la potencia de 8, es decir, 256 (0-255).
7
Combinando los cuatro octetos se obtienen 4 veces 256 o 4.294.967.296 valores únicos. De
hecho, algunas direcciones son de uso restringido, como el 0.0.0.0 para la red por defecto. De todos
modos, en 2004 se estaba agotando el número de IP disponibles, por lo que se estaba introduciendo
el IPv6, con más de un trillón de combinaciones posibles.

z Devolver un mensaje de error porque el nombre de dominio requerido, sim-

plemente, es inválido o no existe.
Obviamente, para que Internet funcione de esta manera es esencial que exis-
ta un cierto nivel de redundancia, de tal modo que cuando un servidor DNS no
esté conectado o presente cualquier problema, existan otros que puedan llevar a
cabo su trabajo. También es deseable que las respuestas sean rápidas, porque así
cada vez que un servidor DNS resuelve un requerimiento puede guardar la direc-
ción IP que recibe (caching). De esta manera, la próxima vez podrá resolver una
petición más rápidamente y evitando la creación de tráfico innecesario. A pesar
de ser completamente invisibles a un navegador común, los servidores DNS ges-
tionan billones de peticiones cada día y son una pieza esencial para el buen
funcionamiento de Internet.
Los DNS son sólo una parte de los servidores que integran Internet. De he-
cho, todas las máquinas conectadas funcionan como servidores o como clientes.
Todos los servidores proveen servicios a otras máquinas, llamadas clientes, que
se conectan a ellos para obtener sus servicios. Existen diferentes clases de servi-
dores, como por ejemplo servidores web, de ficheros, o de correo electrónico.
El cliente, pues, se conecta a un determinado servicio y accede a él utilizan-
do un protocolo particular específico de ese servicio, que describe cómo se van
a entender el servidor y el cliente. Por ejemplo, todos los servidores de correo
electrónico utilizan el protocolo SMTP (Simple Mail Transfer Protocol), mien-
tras que los servidores web utilizan el protocolo HTTP (Hypertext Transfer Pro-
tocol). Por ello, cuando uno se conecta a una página web utilizando un navega-
dor, indica primero el tipo de protocolo a utilizar, después el dominio y finalmente
la página concreta a servir (como por ejemplo, http://www.iese.edu/faculty, para
acceder al servidor de páginas web del IESE, pidiendo la página referente al
profesorado). La Figura 2.7 muestra, a modo de ejemplo, los protocolos más
comunes para los diferentes servicios de Internet.
Según las convenciones generalmente aceptadas de funcionamiento, la direc-
ción completa se denomina URL (Uniform Resource Locator) y es todo lo que se
necesita saber para acceder a un determinado servicio en la Red, ya que especifica
tanto el tipo de protocolo a utilizar como la dirección IP o el nombre del dominio
al que se quiere acceder.
Sirvan como ejemplo las siguientes direcciones:
ftp://nombredominio/fichero.exe
http://nombredominio/index.htm
En la primera se estaría accediendo a un fichero ejecutable utilizando el

protocolo FTP de transferencia de archivos, mientras que en la segunda se esta-
ría accediendo a una página web mediante un protocolo HTTP.
La conmutación de paquetes como base de Internet
Una tecnología de comunicación, inicialmente concebida para datos, que ha

revolucionado la manera en que las máquinas pueden hablarse entre sí es la
tecnología de «conmutación de paquetes».

Servicio Protocolo Funcionalidad
Visualización de páginas escritas

Navegación en la Web HTTP
en hipertexto
Correo electrónico POP 3, IMAP, SMTP Enviar y recibir correo
Descargar archivos desde

Transferencia de archivos FTP servidores remotos o colocarlos
en ellos
Chat IRC (Internet Relay Chat) Charla en tiempo real
Conexión a equipos Acceso a la línea de comandos

Telnet
remotos de equipos remotos
Figura 2.7. Internet, algunos servicios típicos y sus protocolos.

Históricamente las comunicaciones se habían establecido usando una línea que

unía, sin solución de continuidad, dos máquinas que necesitaban pasarse informa-
ción. Este tipo de conexiones son seguras, pero obligan a usar mucha capacidad
«de red» porque hace falta una línea dedicada a cada par de máquinas mientras
dura la transferencia.
La conmutación de paquetes (packet switching) ha permitido incrementar
de manera espectacular la capacidad real de las redes y obtener mayores velo-
cidades de transmisión. Esta tecnología divide los mensajes en una serie de
paquetes –cada uno de los cuales contiene la dirección de destino y las instruc-
ciones de control, además de los propios datos que se incluyen en el mensaje–
, que son transmitidos a través de distintas rutas según el tráfico de cada mo-
mento. Cada uno de estos paquetes viaja de forma independiente a través de la
red y cuando llegan a su destino se agrupan de nuevo en el mensaje original. El
tamaño de dichos paquetes puede variar entre 64 y 4.096 bytes. El packet swit-
ching hace posible un mayor aprovechamiento de los recursos y resulta simple
y poco costoso cuando soporta a un número elevado de usuarios porque, al
entrecruzar paquetes de diferentes usuarios en la misma línea, permite com-
partir las mismas facilidades de transmisión. Entre sus principales inconve-
nientes cabe destacar la dificultad de transmitir datos de calidad a tiempo real
(por ejemplo, en conversaciones telefónicas o videoconferencias), pues la crea-
ción de los paquetes y su posterior reagrupamiento en el destino, además del
hecho de que los paquetes se pueden «adelantar» al usar diferentes caminos,
requiere de un cierto tiempo.
CLASIFICACIÓN Y TIPOS DE SISTEMAS DE INFORMACIÓN

Hoy en día, pocas son las empresas que no disponen de algún sistema de informa-
ción, por sencillo que sea. Los enormes montones de hojas, que tiempos atrás re-

sumían la contabilidad de una organización, han sido sustituidos por avanzadísi-

mos programas informáticos capaces de realizar cálculos precisos y de mostrar los
resultados de manera clara y útil. De manera semejante, aunque a un nivel ligera-
mente superior, encontramos en muchas empresas sistemas capaces de mantener
relaciones directas e instantáneas con sus proveedores y clientes que intercambian
flujos de información acerca de sus productos. Es el caso, por ejemplo, de los
proveedores de grandes supermercados que, automáticamente, reciben una señal
cuando un producto está a punto de agotarse y se requiere que sea repuesto en el
menor tiempo posible.
En el entorno extremadamente competitivo en el que nos encontramos, peque-
ñas, medianas y grandes empresas necesitan sistemas de información para hacer
frente a las presiones de sus rivales más directos, e incluso para permanecer en la
posición que ocupan. Estos sistemas, no obstante, pueden variar de muy simples a
muy complejos, y su clasificación depende de factores muy diversos. Eso sí, todos
ellos tienen en común los elementos que se han descrito en el punto anterior:
hardware, software, datos, telecomunicaciones y, por supuesto, personas.
Turban, McLean y Wetherbe, en su libro Information Techonolgy for Manage-
ment, proponen cuatro clasificaciones de sistemas de información: (1) según la
estructura organizacional de la empresa, (2) según sus áreas funcionales, (3) según
el soporte que puedan dar y, finalmente, (4) según la propia arquitectura del siste-
ma. Sin embargo, este tipo de clasificaciones se superponen entre sí cuando se
consideran desde una perspectiva de gestión, por lo que trataremos de describir
los sistemas desde el punto de vista del soporte que ofrecen a la empresa.
Ofimática (Office Information Systems - OIS)
Son los sistemas utilizados prácticamente en todas las organizaciones para la rea-
lización de tareas y el procesamiento de información a través de documentos de
texto, hojas de cálculo, presentaciones, etc. No sólo podemos encontrarlos en
empresas, sino también en un elevado número de hogares –especialmente en aque-
llos en los que viven jóvenes que los utilizan como herramienta de soporte para sus
estudios. Estos sistemas resultan muy eficaces a la hora de realizar cálculos, escri-
tos o documentos que deben guardarse para hacer uso de ellos más adelante.
Su rápida evolución y su cada vez más accesible precio han convertido a
estos sistemas en una herramienta universal y común en todas las empresas.
Algunos programas que incluyen los OIS, son:
z Hojas de cálculo.
z Sistemas de procesamiento de texto e imágenes.
z Programas para la realización de presentaciones.
z Bases de datos personales.
z Sistemas para tomar notas.
Sistemas de comunicación personal
En los últimos años, los avances en las TIC han permitido a un buen número de
empresas la posibilidad de realizar tareas conjuntas entre personas ubicadas en

lugares completamente diferentes y muy distantes entre sí. Ello ha sido posible gra-
cias al desarrollo de toda una serie de aplicaciones que están modificando sustan-
cialmente la forma de trabajar de las personas. Desde el envío de información a
través de un e-mail hasta las conversaciones en grupo a través de «chats» o videocon-
ferencias, estos nuevos canales han revolucionado el mundo de la comunicación
empresarial en todos los sentidos.
Correo electrónico (Electronic mail)
Es, todavía, uno de los servicios que ofrece Internet más usados tanto a nivel de
empresa como individualmente. Hace posible la comunicación entre personas
ubicadas en diferentes lugares y con diferentes sistemas de información8. Ade-
más del propio contenido del mensaje pueden añadirse al cuerpo del mensaje
muchos otros datos adjuntos, como documentos, imágenes o música.
Mensajería instantánea
Es uno de los grandes sistemas de comunicación instantánea utilizados en todo

el mundo, aunque su aplicación en el mundo empresarial es más bien escasa.
Permite el envío de mensajes de texto, documentos o imágenes de forma instan-
tánea entre uno o más usuarios conectados al servicio. Cuando se inicia la co-
nexión, el sistema informa de los contactos que están conectados y de los que se
van conectando o desconectado durante el período en que se esté en línea. El
sistema permite, además, mantener conversaciones telefónicas entre dos usua-
rios conectados (si se dispone de altavoces, micrófono y tarjeta de sonido) e
incluso videoconferencia si se dispone, además, de una cámara conectada al
ordenador (webcam).
ICQ fue uno de los servicios pioneros en el campo de mensajería instantánea
en Internet. En la actualidad, los servicios más utilizados son el MSN Messen-
ger de Microsoft y el Yahoo! Messenger. Hasta ahora, el principal y práctica-
mente único inconveniente de este sistema es la necesidad de que todos los usua-
rios con los que se desee mantener comunicación pertenezcan al mismo servicio
de mensajería, aunque están apareciendo aplicaciones marco que permiten la
mensajería a través de diferentes herramientas.
El chat es otro servicio de mensajería instantánea en el que usuarios de dis-
tintos lugares se conectan para establecer conversaciones a tiempo real con otros,
normalmente desconocidos, acerca de temas concretos o simplemente para pa-
sar un rato charlando. Existen millones de «salas de chat» en Internet, en las que
diversas personas intercambian opiniones sobre algún tema de interés común o
simplemente mantienen una conversación.
8
Los protocolos estándar en los que se basan los clientes de correo electrónico que encontramos
en los PC para acceder a los servidores en los que se almacenan los mensajes y en los que el usuario
tiene una cuenta abierta son el Post Office Protocol (POP) y el Internet Message Access Protocol
(IMAP). En la actualidad, muchos servidores de correo poseen un programa de interfaz, denominado
Web Mail, que permite a los clientes acceder a su correo mediante un simple navegador, sin progra-
mas de correo dedicados.

Peer-to-Peer (P2P) file sharing
Aunque no se trata estrictamente de un servicio de mensajería instantánea como

los anteriores, estos sistemas permiten el intercambio de ficheros entre sus dife-
rentes usuarios. Uno de los servicios más extendidos actualmente es el que per-
mite compartir cualquier archivo, aunque los formatos de intercambio más habi-
tuales son los ficheros de música o vídeo. El sistema busca el recurso deseado
entre los usuarios conectados y ofrece un listado de aquellos disponibles que
incluye el tamaño, del archivo, el tiempo de descarga en función del ancho de
banda de ambos contactos y otra información de interés acerca del proceso. Una
vez que el fichero se ha descargado, éste puede ser descargado a su vez por otro
usuario que lo desee.
La aparición de redes P2P está teniendo un fuerte impacto en algunos secto-
res, especialmente en el de distribución de la música, que desde la aparición,
éxito y posterior cierre de Napster ha visto cómo el uso de plataformas P2P no
ha dejado de crecer, con un volumen estimado de datos intercambiados de 30
millones de canciones por día a mediados de 2005.
Teleconferencia
Especialmente en aquellas empresas con establecimientos repartidos en diferen-

tes puntos geográficos, las reuniones suponen un gasto considerable en despla-
zamientos y transportes, así como un riesgo debido a la imposibilidad de asis-
tencia de alguno de los miembros convocados. La teleconferencia se ha convertido
en los últimos años en uno de los avances más significativos en las tecnologías
de la información y las telecomunicaciones.
Por teleconferencia se entiende cualquier sistema que permita la realización
de reuniones entre personas que se encuentran en distintos lugares físicos. En
este sentido, podríamos incluir el teléfono tradicional o el ordenador, gracias a
la solución de mensajería instantánea que hemos visto en los párrafos anteriores.
No obstante, al hablar de teleconferencia, pretendemos introducir componentes
más modernos que incluyan tanto audio como vídeo.
Dentro de este tipo de sistemas, la audioconferencia y la videoconferencia
son los más populares actualmente. El primero de ellos hace posible mantener
conversaciones telefónicas con más de dos personas a la vez, mientras que el
segundo incluye, además, la posibilidad de verse a través de pantallas de televi-
sión. Además de para mantener reuniones en distintas oficinas, la videoconfe-
rencia se utiliza en universidades para impartir clases a distancia. En este y otros
ámbitos, también resulta muy útil la posibilidad de presentar documentos gráfi-
cos en distintos lugares al mismo tiempo (conferencia audiográfica).
Sistemas transaccionales
Este tipo de sistemas, de carácter básico y operativo, son los que conocemos como
sistemas de procesamiento de transacciones (Transaction Processing Systems,
TPS). Se trata de sistemas informáticos que ejecutan y memorizan aquellas tran-
sacciones diarias y rutinarias pero esenciales para el correcto funcionamiento de la

empresa. A diferencia de otros sistemas que trataremos más adelante, los TPS son
utilizados por responsables de niveles más operacionales que estratégicos o direc-
tivos.
Podríamos calificar estos sistemas como la columna vertebral de los demás
sistemas de información de las empresas, puesto que proporcionan cantidades
importantes de información necesaria para otros sistemas más complejos. Su
objetivo principal es proporcionar la información que necesita cualquier empre-
sa para funcionar correctamente e incluso aquella más esencial para sistemas de
carácter más táctico o que ayuda al establecimiento de nuevas ventajas competi-
tivas. Este tipo de sistemas son los más expuestos a los procesos de reingeniería
necesarios para su constante adaptación a los cambios del entorno, aunque tam-
bién son los que más beneficios tangibles cosechan.
Características de los TPS
z Tratan información de manera rutinaria (diaria, semanal, etc...).

z Realizan operaciones poco complejas que simplemente requieren pro-
gramas matemáticos y/o estadísticos.
z Suelen tratar con enormes cantidades de datos, habitualmente de
carácter histórico. Por este motivo requieren, en primer lugar, una po-
tente base de datos para poder almacenarlos y, en segundo lugar,
gran velocidad de los procesadores para poder tratarlos con rapidez.
z Pueden resultar críticos para el funcionamiento de la empresa. Erro-
res en alguno de estos sistemas causarían graves consecuencias para
la organización.
z En general, los datos suelen proceder del interior de la empresa.
Encontramos este tipo de sistemas prácticamente en todas las áreas funciona-

les de las empresas, ya que son los que recogen los datos «en origen» y, en general,
los que reflejan fidedignamente el desarrollo de las operaciones más elementales
de la empresa.
Es importante tener en cuenta que estos sistemas, aún siendo relativamente
sencillos y pareciendo poco críticos para la empresa, son imprescindibles para
su funcionamiento. Un mínimo error podría dar lugar a importantes consecuen-
cias para las empresas. ¿Podemos imaginar qué ocurriría, por ejemplo, con una
compañía aérea si se quedase por un tiempo sin su sistema central de reservas?
Los sistemas transaccionales más modernos se venden ya de forma integra-
da, y aunque requieren un esfuerzo de adaptación nada despreciable, éste sue-
le ser menor que el que haría falta para desarrollar los programas uno a uno de
forma coherente y rigurosa. Entre estos paquetes destacan los ERP (Enterprise
Resource Planning) de seguimiento de las funciones básicas de la empresa, y
los CRM (Customer Relationsip Management) de relación con los consumido-
res; ambos serán objeto de estudio específico más adelante (véanse los Capítu-
los del 4 al 6).

Sistemas de información gerencial

(Management Information Systems, MIS)
La evolución de los ordenadores en los años sesenta hizo que sus capacidades y
características mejoraran al tiempo que su precio, paradójicamente, disminuía. Esto
favoreció el desarrollo de sistemas mucho más complejos, capaces de dar soporte a
los directivos a la hora de tomar decisiones repetitivas en las diferentes áreas funcio-
nales de la empresa. Los sistemas de información gerenciales (Management In-
formation Systems, MIS), en efecto, apoyan las funciones de planificación, control
y la toma de decisiones gracias a la realización de informes periódicos y rutinarios
como, por ejemplo, comparativas entre ingresos y gastos reales en relación al presu-
puesto inicial o a lo largo de períodos consecutivos. En términos generales, podemos
decir que un MIS resume y presenta las operaciones básicas de una empresa gracias
a los datos aportados por los sistemas de procesamiento de transacciones (TPS).
De hecho, estos sistemas surgieron como respuesta a las deficiencias de los ante-
riores TPS, que sólo realizaban tareas de procesamiento de transacciones y aportaban
poca información para la gestión de las diferentes áreas funcionales de la empresa.
Las funciones principales de un MIS son las de recopilar y resumir los datos
aportados por los TPS, para controlar y dirigir la organización y también para
que los empleados dispongan de un feedback acerca de aspectos fácilmente me-
dibles de su trabajo. Estos sistemas son de especial utilidad para aquellos direc-
tivos de nivel medio que desean información semanal, mensual o anual acerca
de cuestiones que ya conocen con antelación.
En muchas ocasiones, estos sistemas también son utilizados como herramienta
de planificación y control. Por encima de todo, no obstante, se presentan como
buenos sistemas de medida del rendimiento de una organización. El hecho de que
todo el mundo conozca cómo se mide este rendimiento puede ayudar a una mejor
toma de decisiones y a un incremento de la motivación por parte de los empleados,
quienes tenderán a hacer lo posible para mejorar en aquello que les corresponde.
Características de los MIS
z Se basan en datos actuales, habitualmente aportados por sistemas

de procesamiento de transacciones, TPS.
z No suelen ser muy flexibles.
z Tienen poca capacidad de análisis. Dejan en manos de los responsa-
bles directos cualquier interpretación de los datos que aportan.
z Dan soporte a decisiones estructuradas de directivos de nivel medio
mediante el análisis de datos internos (pocas veces son de carácter
externo), pasados o presentes.
Sistemas de soporte a la toma de decisiones

(Decision Support Systems, DSS)
Son muchas las decisiones que se toman día a día en todas las empresas. Tal y
como su nombre indica, estos sistemas han sido expresamente diseñados para

hacer frente a este proceso de toma de decisiones. Aunque pueda parecerlo, no se

trata de «simples» programas implementados para ofrecer la mejor solución de un
determinado problema (sería el caso de algoritmos de optimización), sino que los
DSS mantienen un contacto directo con el usuario y, mediante la utilización de
modelos previamente creados y complejas bases de datos (internas y externas),
pretenden aportar la información justa para dar solución a los diversos problemas
que se le planteen. Su principal objetivo es hacer frente a decisiones complejas y
que no suelen ser habituales (no son típicas del día a día).
Pongamos el caso, por ejemplo, de una empresa que desee lanzar un nuevo
producto al mercado. Un sistema de soporte a la toma de decisiones contiene
modelos que relacionan todos los factores que pueden influir en una decisión de
este tipo: las empresas que disponen de productos similares, sus precios, los
posibles clientes, la materia prima o, incluso, una predicción de las ventas en los
próximos años. Aunque la decisión final siempre la debe tomar uno o varios
responsables, estos sistemas constituyen un buen soporte a la hora de decidir.
Otro gran campo de aplicación de un sistema de estas características es la eva-
luación del riesgo de efectuar o no una determinada acción.
Características de los DSS
Las características más comunes de un DSS son:
z Que proporciona información de forma muy flexible sin prácticamente

presencia de operadores/programadores especializados que desarro-
llen pequeños programas para los usuarios.
z Fácil de utilizar por los diferentes usuarios y en multitud de situacio-
nes diversas.
z Utiliza sofisticadas herramientas de modelización y análisis de datos
que permiten hacer frente a la toma de decisiones en los distintos
niveles del proceso.
z Puede ofrecer soporte a decisiones tanto secuenciales como inde-
pendientes y permite cambios en las condiciones iniciales.
z Da soporte a decisiones que no se pueden predecir con antelación.
Sistemas de soporte a la toma de decisiones en grupo

(Group Decision Support Systems, GDSS)
En la empresa moderna es frecuente que decisiones importantes deban consen-

suarse entre un grupo de personas reunidas para tal efecto. Cuando este tipo de
decisiones en grupo se apoyan en soportes electrónicos, hablamos de sistemas
de soporte a la toma de decisiones en grupo.
Los DGSS ayudan a los expertos a encontrar una solución a problemas no
estructurados o semi-estructurados y suelen ser relativamente fáciles de usar por
personas poco familiarizadas con este tipo de sistemas, y estar diseñados tanto
para afrontar un único tipo de problema como varios de diferentes categorías.

Además, fomentan la aparición de ideas y disponen de mecanismos disuasorios

ante comportamientos destructivos por parte de uno o varios de los componentes
del grupo, posibles en este tipo de reuniones.
Al igual que los DSS, el principal objetivo que persiguen estos sistemas es
ofrecer apoyo en la toma de decisiones, especialmente en aquellas que exigen el
consenso de un grupo de personas implicadas. Entre sus características, destaca
la de proporcionar una extensa cantidad de información de la empresa, tanto
interna como externa.
Sistemas de información para ejecutivos

(Executive Information Systems, EIS)
Aunque son muchos los directivos que los utilizan, son los responsables de de-
partamento los usuarios habituales de sistemas DSS. Por su naturaleza, la infor-
mación que aportan está dispuesta para facilitar el proceso de toma de decisio-
nes frente a problemas concretos, pero no para obtener una valoración global del
funcionamiento de la empresa.
En cambio, los sistemas de información para ejecutivos (Executive Infor-
mation Systems, EIS) o sistemas de soporte a ejecutivos (Executive Support
Systems) ofrecen apoyo directo y específico a directivos o ejecutivos, gracias al
procesamiento de gran variedad de información, tanto interna como externa,
convenientemente resumida y especialmente presentada. Con un sistema EIS es
posible analizar el rendimiento de la empresa con datos reales, determinar su
situación en el sector y compararla con la de la competencia o fijar direcciones
estratégicas para el futuro. Este sistema, con un formato sencillo y útil, está
especialmente pensado para ser utilizado por directivos con poca disponibilidad
de tiempo o experiencia con ordenadores. Además, permite a los ejecutivos en-
contrar la información o los aspectos estratégicos que más les interesan y explo-
rar sus raíces para encontrar resultados todavía más precisos. Una respuesta gené-
rica a la pregunta sobre qué datos deben contener los EIS, sería: «todo lo que
pueda resultar interesante para los ejecutivos».
Antes de la llegada de los sistemas EIS, era común encontrarse con ejecuti-
vos analizando cientos y cientos de informes cada mes (o incluso semana), habi-
tualmente con el mismo esquema y formato. Poco a poco, los analistas encontra-
ron herramientas para resumir esa gran cantidad de datos de forma que los ejecutivos
pudieran seleccionar la información más relevante y ampliar la que más les intere-
sase. Actualmente los EIS incluyen todo tipo de herramientas de análisis, así como
infinidad de modelos de representación de datos online que permiten a los ejecuti-
vos y a sus subordinados visualizar idénticos datos simultáneamente.
Este tipo de sistemas jerarquizan la información, mediante sumarios o resú-
menes muy esquemáticos, para ofrecer un mayor desglose a medida que el usua-
rio requiere ampliar la información. Esta técnica, denominada de perforación o
drill down, evita el problema de tratar con gran multitud de datos que, a menu-
do, «distraen» o dificultan la atención sobre los que realmente interesa conocer.
Los EIS utilizan herramientas de análisis y modelización de datos que pro-
porcionan los resultados en formatos conocidos como, por ejemplo, hojas de
cálculo, lo que hace facilitar su uso por parte de los directivos que tienen que
manejarlos.

El objetivo principal de los EIS es el de facilitar el estudio de la organización

desde un punto de vista directivo, que incluye todos sus procesos y su interac-
ción con el entorno competitivo. Directivos bien informados pueden realizar
mejores preguntas y tomar mejores decisiones. Por otro lado, estos sistemas
permiten obtener información de manera rápida y, lo que es más importante,
pueden adaptarse a los continuos cambios que puedan surgir en el día a día;
cambios que impedirían a los sistemas tradicionales ofrecer información al deta-
lle, como no fuera recurriendo a otros métodos de búsqueda. En ocasiones, cuando
se consigue recopilar toda la información necesaria para generar un determina-
do informe, los aspectos estratégicos que perseguía el director han cambiado y
dicho informe queda obsoleto. Esto se puede evitar gracias a la flexibilidad y
rapidez que caracteriza a los EIS.
Las principales bazas de un sistema EIS son el gran contenido de informa-
ción que ofrece y la posibilidad de representarla gráficamente en una pantalla.
En el caso de una gran multinacional, por ejemplo, un EIS podría mostrarnos en
pantalla un mapa geográfico con los países en los que tiene representación y las
ventas que han tenido lugar en cada uno de ellos durante un período determina-
do. Si en algún país, además, hubiera más de una sede, tendríamos también la
opción de acceder a cada una de ellas para obtener información más detallada.
En ocasiones, estos sistemas pueden estar conectados con servicios de informa-
ción online y con el correo electrónico.
Otra característica destacable es la posibilidad de realizar estudios de merca-
do de manera sencilla. Cuando se desea analizar la situación de una empresa, es
necesario situarla en el sector en el que opera y comparar sus resultados con los
de las empresas de la competencia. Es habitual que estos estudios se lleven a
cabo con alguno de los diversos modelos de predicción que incluyen los EIS.
La información que aportan estos sistemas no sólo es útil para directivos y
altos ejecutivos, sino también para responsables de menor nivel. Por este moti-
vo, el concepto Executive Information Systems ha caído en desuso y este tipo de
sistemas se integran ahora en los llamados sistemas expertos o de inteligencia
de negocio, que se discuten a en el apartado siguiente.
Características de los EIS
Estos sistemas se distinguen de otros más tradicionales en los siguien-

tes puntos:
z Están especialmente adaptados para atender las necesidades de los

ejecutivos.
z Aportan numerosos datos, tanto internos como externos.
z Son muy fáciles de utilizar (simples «clicks» de ratón o pantallas tácti-
les). Los ejecutivos no requieren experiencia ni asistencia para traba-
jar con ellos.
z Presentan la información de manera gráfica.
z Disponen de herramientas de análisis.

Sistemas expertos (Expert Systems)
Muchas empresas requieren en ocasiones de la opinión de un especialista o exper-

to para solucionar ciertos problemas o para tomar decisiones comprometidas y, en
ocasiones, arriesgadas. Estos especialistas suelen tener experiencia y un elevado
conocimiento del problema en cada área concreta, y saben lo que puede suponer
para la empresa el que no se solucione. Nuevas estrategias de marketing, la com-
pra de equipamiento necesario o la posibilidad de entrar en un nuevo mercado son
algunos ejemplos de situaciones en las que las empresas pueden verse en la nece-
sidad de buscar el consejo de un experto.
En general, hablamos de sistemas expertos para referirnos a aquellos siste-
mas de información que utilizan reglas y otras representaciones del conocimien-
to para facilitar el trabajo de profesionales en situaciones puntuales pero com-
plejas, a las que difícilmente podrían enfrentarse personas no expertas. Dan soporte
a profesionales dedicados al diseño, diagnóstico y/o evaluación de problemas
complejos que requieren un grado de conocimiento por encima del habitual.
Turban, Mclean y Wetherbe, describen el funcionamiento de este tipo de siste-
mas del siguiente modo: «La habilidad (conocimiento) se transfiere del experto
al ordenador. Este conocimiento se almacena en el ordenador. Los usuarios pue-
den pedir consejo al ordenador acerca de una cuestión específica. El ordenador
realizará las transacciones necesarias y llegará a una conclusión. Por último,
igual que un experto, informa a los no expertos y, si se considera necesario,
explica la lógica que se esconde detrás del consejo».
Un sistema experto, una vez introducidos los datos, nos devolvería el conjun-
to de soluciones a nuestro alcance considerando una serie de condiciones y res-
tricciones impuestas anteriormente.
Desde una perspectiva empresarial, estos sistemas se desarrollaron con el
propósito de mejorar el rendimiento de aquellas personas con poca experiencia
en tareas similares, de mantener el nivel de los ya expertos o, simplemente, para
profundizar en aspectos concretos de tareas realizadas por el personal de la em-
presa. Al mismo tiempo, los sistemas expertos pueden resultar un buen sistema
de soporte a la toma de ciertas decisiones.
Se pueden incluir dentro de esta categoría aquellos sistemas que, de forma
explícita, representan el conocimiento para ser aplicado automáticamente. Son
los denominados sistemas basados en el conocimiento y suelen ser utilizados
por los sistemas expertos para representar el conocimiento a través de fórmulas
del estilo si-entonces: si se cumplen ciertas condiciones, entonces deben llevar-
se a cabo determinados procedimientos.
Es importante no olvidar que estos sistemas, en ningún caso, pueden sustituir
a un experto humano. Obviamente, no disponen de sentido común y no son
capaces de ver la lógica de ciertos procesos como podemos hacerlo las personas,
más aún personas expertas. Además, mientras que un sistema informático se
basa en reglas difícilmente modificables, una persona puede adaptarse a la situa-
ción concreta cuando lo crea oportuno, independientemente de las condiciones
previstas en un principio.
Es evidente, entonces, que este tipo de sistemas requieren total interacción
con el usuario, que es quien da las órdenes e introduce los datos que el sistema
necesita para buscar la solución óptima a un determinado problema. En este sen-
tido, son muchos los sistemas expertos que, hoy en día, permiten «conversar»

con el ordenador directamente gracias a sofisticados programas de reconocimiento

de voz.
IMPLICACIONES PARA LA DIRECCIÓN

Si bien la tecnología en sí no ha de ser un campo en el que los altos directivos sean
consumados expertos, es esencial que pueda existir un diálogo entre estos y los
responsables directos de las TIC. Para ello, ambas partes deben realizar un esfuer-
zo para entenderse. Los directivos deben conocer unos mínimos conceptos tecno-
lógicos y ser conscientes de por dónde avanzan las TIC y de sus posibilidades, y
los responsables de las TIC han de ser sensibles a las necesidades del negocio y a
los condicionantes competitivos.
Este capítulo ha presentado los conceptos tecnológicos básicos que a la fe-
cha de publicación de esta obra los autores de la misma creen que son necesarios
para que este diálogo exista. Evidentemente, esta es sólo la mitad de la ecua-
ción. Lo directivos responsables de las tecnologías de la información deben es-
tar completamente al día de los procesos de negocio de la empresa, de su manera
de competir, y de sus objetivos estratégicos. Como se verá en los capítulos si-
guientes, la gestión adecuada de las TIC requiere de una serie de decisiones que
no se podrán tomar de forma adecuada sin esta simbiosis constante de conoci-
mientos.

Compitiendo con los sistemas de información 31
3
Compitiendo
con los sistemas
de información1
Tradicionalmente, la planificación y, en cierto modo todas las dimensiones de

la gestión del departamento de Informática, se hacía a partir de una estrategia
de empresa clara y definida. La función de los sistemas de información era
ayudar en la implantación de dicha estrategia y, en muchos casos, la alta direc-
ción se contentaba si la informática no era un freno a las decisiones de planifi-
cación. De este modo, el rol del departamento de Sistemas de Información (SI)
estaba subordinado a la estrategia general de la empresa, y tanto su posición
en la estructura de la empresa como sus relaciones con otros departamentos
funcionales respondían a unas necesidades estratégicas bien establecidas. Esta
dependencia de las decisiones de SI de las de negocio ha sido crucial para que
los departamentos de sistemas desarrollen un sentido de utilidad para el nego-
cio, y se consideren a sí mismos esenciales para la implantación de las estrate-
gias competitivas.
Sin embargo, en la actualidad las empresas están inmersas en un entorno en
constante cambio y sujetas a altos niveles de incertidumbre que dificultan el
establecimiento de estrategias competitivas estables. Y la estabilidad en el tiem-
po es esencial para que funcione este paradigma en el que la planificación de
sistemas sigue a la planificación estratégica.
En este entorno cambiante, las empresas se centran en el desarrollo de capa-
cidades distintivas que les ayudan a competir de forma flexible, y evidentemente
los sistemas de información forman parte de estas capacidades. Esta situación
conlleva que las empresas aspiren a saber gestionar de forma avanzada y flexible
los sistemas y tecnologías de la información. Pero esto no es tarea fácil: las
capacidades basadas en sistemas suelen tener unas características, en particular
su inherente inercia y rigidez, que deben gestionarse cuidadosamente.
1
Este capítulo resume de forma sucinta los conceptos y metodología de la obra Estrategia y
Sistemas de Información de Andreu R., Ricart J. E. y Valor J., McGraw-Hill, (1996). El lector intere-
sado en profundizar más en la planificación de sistemas de información puede referirse a ella.
31

La estrategia tecnológica y de sistemas tiene que mirar necesariamente al

largo plazo, con un plan de desarrollo e implantaciones definido, ya que la infra-
estructura, una vez desplegada, es difícil de cambiar. Los costes de cambio no
son sólo monetarios: un cambio de sistemas acostumbra a llevar consigo modifi-
caciones en los procesos y las maneras de hacer de la empresa.
Por todo ello, es necesario estudiar detenidamente las características de las
capacidades basadas en SI, teniendo en cuenta no sólo su relación con otras
capacidades sino su carácter de largo plazo, responsable de unas fuertes rigide-
ces una vez implantados dichos sistemas.
LA TOMA DE DECISIONES DE SISTEMAS

DE INFORMACIÓN EN LA EMPRESA
Los departamentos de Informática entran en las grandes empresas durante la
década de los sesenta. En aquella época, empresas como Ford, General Electric
y las administraciones públicas empiezan a incorporar ordenadores para auto-
matizar algunos de sus procesos de transacciones básicas, principalmente en las
áreas de contabilidad y administración. La utilización de las Tecnologías de
Información y Comunicación (TIC) ofrecen una mayor eficiencia y precisión,
además de una reducción de los costes. Por aquel entonces, las empresas suelen
trabajar sin un sistema formal de planificación de SI: el departamento de Infor-
mática se limita a establecer un orden a las demandas de desarrollo de aplicacio-
nes informáticas que recibe de las diferentes partes de la organización.
Dado que el objetivo primordial del departamento de Informática en esta
situación es la reducción de costes, un simple –y normalmente bastante obvio–
análisis coste-beneficio en términos estrictamente monetarios suele garantizar
la correcta priorización de proyectos. En consecuencia, no acostumbran a pre-
sentarse incompatibilidades o incoherencias con la estrategia global de la em-
presa. Debido a que el departamento de Administración y Finanzas sigue siendo
su primer y todavía principal cliente, Informática suele depender de éste en el
organigrama funcional.
Sin embargo, a medida que las funciones de Informática superan la simple
automatización de transacciones, y empiezan a referirse a complejos procesos
de negocio que involucran a toda la empresa, este departamento comienza a
implicarse en la consecución de la estrategia de negocio.
En esta situación, y como consecuencia de la evolución histórica, la direc-
ción del departamento de Informática suele carecer de la visión y los mecanis-
mos de comunicación con otros departamentos necesarios para tomar decisiones
desde un punto de vista global. Sin una comunicación fluida y con una visión
parcial del posicionamiento de la empresa, las decisiones de planificación de
sistemas y la asignación de recursos suelen basarse en (1) la facilidad de implan-
tación; (2) el atractivo de la tecnología para el departamento de Informática; (3)
el poder de la unidad funcional solicitante y (4) el coste del desarrollo a realizar.
Muchas veces, esto ha desencadenado la aparición de SI con multitud de aplica-
ciones transaccionales disjuntas.
Aunque esta situación es claramente indeseable, es al mismo tiempo relati-
vamente difícil de detectar y solucionar, ya que la creciente importancia del
departamento de Informática –basada en sus exitosas implantaciones de desa-

rrollos pasados– hasta este momento, se ha traducido en la aparición de peticio-

nes más complejas. De este modo se da lugar a un nuevo status quo, en el que el
departamento de Informática tiene más poder, pero no necesariamente la visión
de negocio necesaria para llevar a cabo su función de manera satisfactoria.
Por ello, para funcionar adecuadamente en este nuevo entorno son necesarias
dos condiciones que afectan a la empresa en su conjunto. Primero, el director
del departamento de Informática debe desarrollar nuevas capacidades directivas
que le proporcionen suficiente visión de la estrategia de la empresa. En segundo
lugar, los directores funcionales necesitan capacidades y conocimientos sobre
las TIC que les permitan entender su impacto e implicaciones en sus respectivas
áreas de negocio. Además, es necesario un replanteamiento de la posición de
Informática dentro de la organización y, muy probablemente que este departa-
mento abandone el paraguas del departamento de Administración y Finanzas.
Una vez llegado a una situación en la que las decisiones de tecnología afec-
tan directamente a las diferentes direcciones funcionales y la alta dirección, es
inevitable que los respectivos responsables se quieran involucrar en la toma de
decisiones de tecnología. La situación más común en este estadio es que la alta
dirección intervenga en la selección de algunos proyectos a implantar. Sin em-
bargo, esta forma de proceder acarrea una serie de consecuencias poco desea-
bles. En primer lugar, la creciente complejidad de las TIC dificulta, desde un
punto de vista puramente técnico, el análisis de las implicaciones futuras que
conlleva la decisión. No hay que olvidar que, en muchas ocasiones, la alta direc-
ción carece del conocimiento mínimo necesario para evaluar de forma correcta
las alternativas disponibles en el mercado, mientras que el departamento de In-
formática desconoce las dimensiones importantes desde un punto de vista de
negocio.
Segundo, la intervención directa de la alta dirección en decisiones que en
principio corresponden al responsable de Sistemas de Información diluye la es-
tructura de responsabilidad y puede provocar confusiones sobre la paternidad
final de las decisiones.
Por ello, es necesario definir un procedimiento formal de planificación de SI.
De esta forma, mediante la comunicación directa entre los planes de la compa-
ñía y los planes de SI se puede garantizar la coherencia con la estrategia global
de la empresa, atendiendo adecuadamente las necesidades de información de las
diferentes unidades funcionales. Con un procedimiento formal, el plan de SI
contiene los proyectos explícitos a desarrollar y define las prioridades de la em-
presa para la asignación de recursos de las TIC de forma clara e inequívoca.
TIC: ¿ALINEACIÓN CON LA ESTRATEGIA

O AVANCE EN PARALELO?
Existen dos formas diferenciadas de formulación de planes de sistemas. La prime-
ra consiste en definir el plan de SI a partir de la estrategia corporativa y las necesi-
dades concretas de cada unidad de negocio, tal como muestra la Figura 3.1.
Esta forma responde a una metodología pasiva o de alineamiento del plan
de SI con la estrategia de la empresa. Resulta especialmente adecuada cuando,
si bien las TIC constituyen un soporte importante para la estrategia de negocio,
no son en sí mismas una fuente de ventaja competitiva ni tienen el potencial de

Estrategia/
Necesidades corporativas
Estrategia/
Necesidades de cada
unidad de negocio
Plan de TI/SI
Figura 3.1. Formulación coherente de los planes de SI con los planes

estratégicos de la compañía.
(Fuente: Andreu, Ricart y Valor, 1996.)
convertirse en una pieza fundamental de la estrategia competitiva a medio plazo.

Una metodología pasiva es un instrumento esencial para las empresas que no
disponen de un mínimo sistema de información organizado y cuya Informática
está desagregada, normalmente fruto de un crecimiento orgánico no planificado
que intenta solucionar los problemas de negocio conforme aparecen.
Una segunda manera de formulación de planes de SI consiste en su concepción
en paralelo con la estrategia de negocio. Esta metodología activa, que se muestra
en la Figura 3.2, se basa en la idea de que cada vez más las empresas pueden
obtener ventajas competitivas sostenibles mediante la incorporación de las TIC en
sus planeamientos estratégicos y que no es posible concebir un planteamiento de
negocio moderno sin considerar las posibilidades de estas tecnologías.
Muchas de las empresas de Internet, tanto las de éxito como las que han
fracasado, han considerado la tecnología como parte intrínseca de su negocio y,
en muchas ocasiones, sus novedosos planteamientos han causado cambios pro-
fundos en sectores existentes. Esto ha obligado a las empresas preexistentes a
reaccionar, llevando al sector a nuevos equilibrios competitivos. Un ejemplo
claro y archiconocido es la entrada de Amazon.com en el sector de la venta
detallista de libros. La idea del fundador de Amazon.com de vender libros a
distancia aprovechando las posibilidades de Internet, no sólo cambió la estructu-
ra de costes de su negocio respecto al de un librero tradicional, sino que introdu-
jo la creencia de que había que ofrecer al potencial comprador la información
necesaria para tomar adecuadamente una decisión de compra. Su planteamiento
inicial requería contar con una tecnología adecuada que pusiera al alcance del
internauta toda la información necesaria de forma fácil y efectiva (lo que los
anglosajones denominan proporcionar un look and feel adecuado). Pero también

TI/SI
Estrategia/
Necesidades
corporativas
TI/SI
Estrategia/
Necesidades de las
unidades de negocio
Figura 3.2. Formulación de planes de SI conjuntamente

con los planes estratégicos de la compañía.
requería de una estructura de costes bajos, fundamentalmente basada en TIC que

le permitiera operar con márgenes positivos.
De forma similar, la empresa española líder en procesos de selección online,
Infojobs, no podía concebir su negocio sin tener en cuenta las posibilidades
tecnológicas a las que podía acceder. Así, no sólo acertó en la creación de una
plataforma central que casa ofertas y demandas de trabajo, sino que desarrolló
una sede web de fácil uso, con entrada estándar de CV, un procedimiento senci-
llo de alta de ofertas de trabajo y un buen motor de aparejamiento de CV y
ofertas. Todo ello sin descuidar el modelo de ingresos y costes, lo que le ha
permitido operar con beneficios desde su primer año de existencia.
Sin embargo, si bien la formulación conjunta del plan de SI con el plan estra-
tégico no suele presentar mayores problemas en las empresas de nueva creación,
sí puede resultar de extrema dificultad en empresas ya establecidas, especial-
mente si en el pasado el papel de la tecnología ha sido limitado o nulo. En estas
situaciones, la cultura de la empresa suele ser poco sensible hacia el potencial de
las TIC. Por consiguiente, será muy difícil convencer de la idoneidad de una
metodología activa de planificación de sistemas tanto a la alta dirección como a
las direcciones funcionales. Como casi siempre, tiene que existir un convenci-
miento real de las posibilidades de las TIC. Ello requiere de experiencias exito-

sas reales que contribuyan a la construcción de un clima favorable hacia la tec-

nología, y en especial hacia las TIC, ya que en la gran mayoría de empresas
suelen existir evidencias de fracasos rotundos y por tanto unas potentes barreras
implícitas a derribar. Por tanto, incluso en situaciones donde resulta idónea una
metodología activa de planificación de SI, es muy recomendable empezar con
una metodología pasiva, hasta llegar a una madurez organizativa que implique
un compromiso suficiente de toda la organización hacia el uso de TIC.
No cabe duda de que la existencia de un procedimiento formal de planifica-
ción de SI es de importancia vital para la empresa en condiciones en las que las
TIC afectan el funcionamiento normal del negocio.
Tanto la metodología pasiva de alineamiento como la metodología activa
de planificación en paralelo son tan sólo dos propuestas de cómo estructurar el
proceso de formulación, y el lector no debe interpretar que son los únicos
válidos. Sin embargo, pueden servir para ilustrar qué dimensiones cabe tener
en cuenta, por lo que a continuación se describen en detalle ambas metodolo-
gías.
METODOLOGÍA PASIVA: PLANIFICACIÓN DE LAS TIC

BASADA EN EL ALINEAMIENTO CON LA ESTRATEGIA
DE NEGOCIO2
Cualquier planificación tiene que estar delimitada en su alcance y tiempo. Un
buen plan de sistemas incluye los proyectos a desarrollar en los próximos 3 a 5
años, así como una lista de actividades de la empresa donde las TIC pueden
utilizarse como herramienta de soporte para aumentar su eficiencia (Andreu,
Ricart y Valor, 1996). Asimismo, es importante especificar el punto de partida
del plan, es decir, la situación actual de los sistemas de información en la empre-
sa. Y no sólo desde el punto de vista técnico, sino teniendo en cuenta la utilidad
de los sistemas en servicio para el negocio.
El procedimiento aquí descrito de manera esquemática representa una posi-
ble forma de elaboración del plan de sistemas, pero en ningún caso es una expli-
cación exhaustiva de esta metodología.
Un plan de sistemas adecuado debe servir como referente para decidir la
inversión en proyectos. Estas decisiones deben ser coherentes con las necesida-
des estratégicas de la empresa, ya que en la mayoría de las ocasiones no existen
recursos suficientes (monetarios, humanos o de tiempo).
Esta fijación de prioridades suele ser especialmente compleja para proyectos
de implantación de infraestructura, ya que, aunque normalmente están separa-
dos del negocio, suelen crear dependencias tecnológicas con un impacto a largo
plazo en la empresa. El Capítulo 8 ofrece una guía específicamente pensada
para tomar este tipo de decisiones sobre tecnología; en este capítulo nos dedica-
remos a los SI pertenecientes a las familias descritas en el capítulo anterior.
La especificación de un plan de sistemas a cinco años no debe realizarse de
forma homogénea en cuanto al detalle. La descripción de los proyectos a desa-
2
Esta sección describe de forma somera el procedimiento. Remitimos al lector interesado en
una descripción más detallada al libro Estrategia y Sistemas de Información de R. Andreu, J. E.
Ricart y J. Valor (1996).

rrollar durante el primer año del plan deben contener de forma detallada toda la
información necesaria para poder evaluarlos en términos de los recursos necesa-
rios para su desarrollo, mientras que para los proyectos posteriores una aproxi-
mación suele ser suficiente. Además de un calendario detallado, es necesario
establecer los mecanismos adecuados de evaluación y garantizar la existencia de
los procedimientos de control necesarios para llevar a cabo un correcto segui-
miento del plan.
Un buen plan de sistemas no es necesariamente muy tecnológico. Al contra-
rio, debe desarrollarse primordialmente desde una perspectiva de negocio, inte-
grando las necesidades de información emanadas del cruce de las directrices
estratégicas de la empresa con las funciones y procesos de negocio de las distin-
tas unidades organizativas. La dimensión tecnológica se desarrolla una vez se
dispone de las necesidades de información y proceso de la empresa. Por consi-
guiente, la responsabilidad del desarrollo del plan recae fundamentalmente en la
dirección de la empresa, con la participación de la dirección del departamento
de sistemas. Como detallaremos más adelante, ello tiene una serie de implica-
ciones sobre la estructura de responsabilidad de los proyectos de sistemas, ya
que requerirá la implicación y co-responsabilidad de los diferentes directores
funcionales.
Finalmente, el procedimiento de alineamiento del plan de tecnología con la
estrategia de negocio precisa de la participación activa de toda una serie de
agentes de la empresa.
Personas y grupos de trabajo involucrados

en el proceso de planificación
Un plan de sistemas que abarque toda la empresa y siente las bases de las inver-
siones de tecnología en los próximos años ha de involucrar en cierto grado a los
máximos responsables de la organización. La filosofía de la metodología que
aquí se esboza es que toda la organización debe sentir como propio el plan de
sistemas que acabe llevándose a la práctica. Ello implica que el peso del trabajo
de análisis lo lleve personal propio, no necesariamente del departamento de sis-
temas, sino de las áreas funcionales asignadas de forma temporal, pero explícita,
a la elaboración del Plan de Sistemas
El procedimiento propuesto organiza al personal implicado en el proyecto en
tres grupos de trabajo: (1) el comité de tecnologías y sistemas de información;
(2) el equipo de trabajo; y (3) el grupo base. Estos se interrelacionan tal como
está descrito en la Figura 3.3.
El Comité de tecnología y sistemas de información es el órgano con res-
ponsabilidad última sobre el sistema de información diseñado. Debe supervisar
las etapas de la planificación; proporcionar los criterios estratégicos, de fija-
ción de prioridades y asignación de recursos; aprobar el plan de tecnología y
sistemas de información desarrollado; y asegurar el compromiso de la organi-
zación con el plan. Está formado por el máximo responsable de la empresa, los
directores de las distintas áreas funcionales y el director de SI. En muchas orga-
nizaciones coincide con el comité ejecutivo o de dirección de la empresa, con
la adición del responsable de sistemas de información en caso de no formar
parte del mismo.

Comité de
tecnologías y
sistemas de Director
información general
Otros Subdirector a
subdirectores cargo de SI
Director
de SI/TI Grupo base
(con
consultores
externos)
Equipo Director
de trabajo operativo
Personal de departamentos
usuarios asignado Personal de SI asignado
al proyecto al proyecto
Otro personal de departamentos Otro personal de SI

usuarios
Figura 3.3. Relación entre los grupos de trabajo que intervienen

en el proceso de planificación.
La función principal del equipo de trabajo –el personal de sistemas y de los

departamentos usuarios que forman parte del proceso de planificación– es iden-
tificar y documentar las necesidades de información y de proceso de las diferen-
tes funciones, calificándolas según las prioridades estratégicas de la empresa
(establecias previamente por el comité de tecnología). El equipo está formal-
mente dirigido por el director de sistemas, aunque el trabajo diario de dirección
suele asumirlo un director operativo de proyecto.
Finalmente, el grupo base está constituido por todo el personal del departa-
mento de Sistemas con responsabilidad directa sobre el proceso de planifica-
ción, así como por el posible personal externo experto que se haya decidido
contratar. Normalmente, ello incluye al director del departamento de SI, al di-
rector operativo del proyecto de planificación y al responsable del personal ex-
terno contratado. Las grandes organizaciones, con proyectos de planificación de
gran envergadura, pueden requerir la división del proyecto en partes, por lo que
el grupo base incluiría a los directores operativos de cada división.
Principales fases del proyecto de planificación
El proyecto de planificación puede dividirse en cuatro fases principales: (1)

constitución del equipo y generación de compromiso; (2) descripción de la si-

tuación actual y de las necesidades de información; (3) elaboración del plan de

sistemas; y (4) programación de actividades.
Fase 1: Constitución del equipo y generación de compromiso
En la primera fase, se constituyen y presentan formalmente en la organización

cada uno de los grupos de trabajo. Esta presentación formal, liderada por el
máximo responsable de la empresa, no debe subestimarse. Dado que la descrip-
ción de la situación actual y la elaboración del plan requiere la colaboración
activa de los departamentos y áreas funcionales de la empresa, es de vital impor-
tancia que la dirección general muestre claramente su compromiso con la obten-
ción de un plan de sistemas, convenciendo a sus colaboradores más directos de
la necesidad de participación activa en el proyecto para llegar a buen puerto.
Fase 2: Descripción de la situación actual

y de las necesidades de información
La segunda fase consiste en «peinar» completamente la empresa con dos objeti-

vos. El primero es diagnosticar el estado de los sistemas de la empresa, tanto
desde el punto de vista tecnológico como del servicio que prestan a las diferen-
tes funciones. En segundo lugar, documentar las necesidades de información de
las diferentes funciones no cubiertas (o cubiertas de forma deficiente) por los
sistemas en operación. Las necesidades de información de la empresa constitu-
yen la base de la siguiente fase. Esta etapa debe comenzar por la identificación
de los procesos de negocio fundamentales, para entrar posteriormente en cada
área de negocio. Esta distinción es importante, ya que en empresas muy compar-
timentadas, el punto de vista de los responsables de unidad operativa influye
mucho en los entrevistadores, por lo que un enfoque en áreas funcionales puede
eliminar la visión transversal.
Las necesidades de información (por ejemplo las ventas a un cliente) se pue-
den clasificar tanto desde el punto de vista de la función de negocio (las necesita
el departamento de marketing, por ejemplo) como de la acción estratégica que
apoyan, ya que toda necesidad de información debe responder a una necesidad
de negocio, y ésta debe estar supeditada a una necesidad estratégica. Una visión
esquemática de esta dependencia dual se presenta en la matriz de la Figura 3.4,
donde las filas representan los procesos o áreas funcionales, y las columnas las
necesidades estratégicas. Una celda de la matriz es una necesidad de informa-
ción, que pertenece a un proceso y responde a una determinada decisión o posi-
cionamiento estratégico.
Fase 3: Elaboración del plan de tecnologías y de sistemas
En una tercera fase se aborda la elaboración del plan de tecnologías y de siste-

mas (plan TIC), que consiste en la planificación propiamente dicha. Un equipo
de SI, bajo la coordinación del director de sistemas, señala las necesidades de
información no cubiertas a partir de las necesidades de información ya identi-

ficadas. De este modo se pueden proponer nuevas pautas de actuación, mostrando

su incidencia en las líneas estratégicas de la empresa, así como su impacto en las
distintas funciones de negocio. De esta forma, el plan TIC marca la política gene-
ral y establece las prioridades de implantación. El comité TIC, último responsable
del Plan, es el encargado de aprobar éste (véase la parte b de la Figura 3.4).
Fase 4: Programación de actividades
En la última fase se establece, bajo la responsabilidad de la dirección del departa-

mento TIC, el plan informático, formado por el plan de hardware y software de
base y los proyectos a desarrollar, de carácter más tecnológico (véase la parte c de
la Figura 3.4). Este plan, establecido normalmente para un año aunque revisable
trimestralmente, define las necesidades internas del departamento TIC para poder
llevar a cabo satisfactoriamente tanto los proyectos a desarrollar como el plan de
hardware y software de base, es decir, las inversiones especificas en soluciones
tecnológicas concretas.
Resumiendo, en este apartado se han descrito las características principales
de una metodología de planificación de SI en la que éstos apoyan la estrategia de
la empresa, que se supone desarrollada y completamente especificada de ante-
mano. Este tipo de metodología pertenece a la familia de las denominadas pasi-
vas o «de alineamiento», en clara referencia a alinear los sistemas de informa-
ción con la estrategia de la empresa.
Estrategia de negocio
Aprobado por el
comité TIC
Acciones estratégicas a b
Plan de
tecnologías y de
sistemas
Funciones y procesos
de negocio
Necesidades c
de información Plan de hardware Proyectos a
y software básico desarrollar
Ciclo de feedback
Fase (a): Identificación de necesidades y priorización de acciones

Fase (b): Establecimiento del plan TIC
Fase (c): Definición del plan informático
Figura 3.4. Esquema del procedimiento de alineación

estrategia-sistemas de información.

Esta metodología, si bien es esencial para que los sistemas no frenen las inten-
ciones competitivas de la empresa, presenta una limitación fundamental: no inte-
gra en el diseño de la estrategia las posibilidades que las TIC ofrecen. Por ello, en
general, las metodologías pasivas resultan insuficientes para las empresas que usan
información para competir. Este inconveniente se puede solventar aplicando una
metodología activa de planificación.
¿CÓMO OBTENER VENTAJAS COMPETITIVAS

CON SISTEMAS DE INFORMACIÓN?
Desde mediados de los noventa se está hablando con cierta insistencia de la
relación entre tecnologías de la información y posicionamiento competitivo de
la empresa. Igual que nadie duda de la necesidad de información precisa para
tomar decisiones adecuadas, pocos ejecutivos discutirían el papel esencial que
las capacidades para gestionar TIC tienen en las decisiones estratégicas. Dicho
de otro modo, es imposible pensar en la estrategia competitiva de una empresa
sin considerar las posibilidades de las TIC y las habilidades necesarias para apro-
vecharlas. El reto para los directivos es cómo integrar estas posibilidades y capa-
cidades en el pensamiento estratégico de la empresa, y cómo desarrollar otras
habilidades que en el futuro permitan competir de forma más efectiva. El objeti-
vo de este capítulo es ayudar en esta tarea, para lo que se presentan algunos
principios básicos.
El objetivo principal de estos principios es incluir en la planificación estraté-
gica el potencial competitivo que puede alcanzarse a través de las TIC, e inte-
grar en la estrategia de negocio las tecnologías o sistemas que puedan contribuir
a crear ventajas competitivas.
La evolución de la relación de las TIC con la estrategia empresarial está
relacionada con la propia evolución de los procesos de formulación de estrategia
competitiva. No es de extrañar, pues, que la metodología aquí propuesta se fun-
damente más en la denominada «gestión estratégica» que en la «planificación»
de los años noventa.
Decisiones de TIC: de la planificación por presupuestos

a la gestión estratégica
Desde una perspectiva histórica, los precursores de la planificación son los pro-
cedimientos de control financiero presupuestario, en boga en los años cincuenta.
Estos procedimientos utilizaban un horizonte corto con el fin de controlar la
tesorería, y su punto de vista era fundamentalmente interno y de control. Su
análogo en las decisiones de TIC (una incipiente informática por aquel enton-
ces) es la utilización de la tecnología en procesos transaccionales sencillos y
repetitivos. Ambas situaciones se caracterizan por su énfasis en el corto plazo,
limitándose a actividades definidas y estructuradas. En aquellos momentos no se
podía hablar de desencaje entre estrategia e informática, dado que el soporte de
esa última a la primera era mínimo.
En los años sesenta se desarrolla el concepto de planificación a largo plazo,
incorporando la perspectiva externa. Se trata de un proceso todavía pobre en

diagnósticos y fundamentalmente continuista en sus recomendaciones. Pretende

determinar la diferencia entre realidad y expectativas para identificar proyectos
encaminados a disminuir esa distancia. Paralelamente, proliferan las aplicacio-
nes y los sistemas de soporte a la gestión que llevan a Informática a establecer
sistemas de control que asignen prioridades y ordenen los procesos de decisión
en término de sistemas. Esta fase, básicamente reactiva a los requerimientos de
los diferentes usuarios, consigue alinear en cierto modo las decisiones de tecno-
logía con los objetivos de la empresa. Sin embargo, carece de un claro diagnós-
tico, visión de conjunto y elección de sistemas apropiados también para las ne-
cesidades futuras de la empresa. En esta época se generan la mayoría de sistemas
de información desagregados que todavía hoy permanecen en algunas empresas:
múltiples bases de datos con la misma información, a menudo inconsistentes,
con distintos responsables y usadas para fines distintos.
Las décadas de los setenta y ochenta se caracterizan por la proliferación de
métodos de planificación estratégica. Aparecen varias metodologías y herramien-
tas cuyo objetivo es ampliar la visión estratégica de los empresarios. El análisis
resulta mucho más prospectivo y, aunque los consultores expertos son los verda-
deros motores del cambio, la implicación de los altos directivos en el proceso es
esencial. Sin embargo, todavía falta integración; sólo existe una visión parcial
de una realidad muy compleja. La definición de negocios es poco sistemática, lo
mismo que el entronque entre estrategia y organización. De hecho, se considera
que la organización sigue a la estrategia. Entre las herramientas que se utilizan
destacan las distintas matrices de cartera de negocios, la curva de la experiencia,
el ciclo de vida del producto, el concepto de creación de valor, etc. Su uso se
generaliza y cada consultora desarrolla su propia metodología. Desde este posi-
cionamiento, más bien financiero y con énfasis en la selección de la cartera de
negocios, se evoluciona hacia un planteamiento de estrategia a nivel de unidad
de negocio. Aunque se desarrollan nuevos elementos metodológicos con dicho
punto de vista, el conjunto es todavía imparcial e incompleto. Sin embargo, va
calando en las empresas un proceso de aprendizaje organizativo en planificación
estratégica, con lo que el papel de los consultores es cada vez más de soporte.
Los directivos de línea son cada vez más activos y las metodologías integran los
elementos utilizados en etapas anteriores, formalizando el proceso. Finalmente,
en los ochenta aparecen los procesos formales de planificación estratégica, que
analizan tanto aspectos internos como el entorno de las empresas a partir de
escenarios. Se trata de procesos prospectivos que se integran con la organización
y sus sistemas de control y presupuestos. Además utilizan horizontes suficiente-
mente largos y elaboran planes de acción concretos a corto plazo. En el terreno
de las TIC se alcanza la llamada etapa de la coordinación y empieza a eviden-
ciarse la necesidad de vincular estrategia de negocio a las oportunidades de la
tecnología. Aparece el llamado enfoque clásico de la estrategia de SI: el plan de
TIC sigue a la estrategia de negocio y es una estricta consecuencia de la misma,
jugando exclusivamente un papel de soporte. Esta etapa es necesaria para que la
empresa adquiera un aprendizaje organizativo, y su papel es paralelo a que la
planificación estratégica jugaba en los años setenta. Esta etapa se apoya en pro-
cedimientos de planificación pasivos, como la metodología pasiva descrita en el
apartado anterior.
Es en esta época cuando se popularizan los conceptos de MIS (Management
Information Systems) y DSS (Decision Support Systems), introducidos en el ca-

pítulo anterior, que se encaminan fundamentalmente a proporcionar a la dirección

de la empresa, y a los decisores en general, la información adecuada para apoyar-
los en sus decisiones.
Una de las claves de la planificación estratégica en esta etapa es la definición
de los negocios en los que compite la empresa, buscando las combinaciones
producto/mercado más uniformes posible y creando diferentes unidades de ne-
gocio. Estas unidades debían primero competir con sus negocios «hermanos»
por los recursos corporativos, para poder salir al mercado a enfrentarse efectiva-
mente con sus competidores reales. En este contexto, los departamentos de In-
formática formaron parte de las diferentes unidades de negocio dando lugar a
sistemas que, con más o menos fortuna, apoyaban las diferentes estrategias. Sin
embargo, carecían de la visión global de empresa. Desde un punto de vista de
toma de decisiones de Tecnologías y Sistemas de Información es una etapa rela-
tivamente tranquila, ya que la popularización de la planificación estratégica en
las unidades de negocio proporciona el contexto adecuado para añadir el recurso
TIC en el ciclo de planificación. De este modo, los planes estratégicos a cinco
años revisados anualmente son un marco adecuado para encajar en los mismos
los Planes de Sistemas.
En los noventa aparece el concepto «recurso estratégico» y se populariza la
visión de la empresa basada en recursos. La estrategia deja de ser una colección
más o menos disjunta de estrategias de unidades de negocio que reaccionan a
elementos externos, y se convierte en una serie de decisiones de inversión en
recursos para desarrollar capacidades que proporcionen una ventaja sostenible3.
Esta nueva manera de formular estrategia de empresa tuvo un efecto inme-
diato en los departamentos de Informática, que de hecho muchas veces se pasa-
ron a denominar departamento de Sistemas o departamento de Tecnologías de la
Información y Comunicación (departamento TIC4): competir con recursos pro-
pició que las empresas desarrollaran planes de tecnología encaminados a crear
y mantener capacidades más o menos diferenciales. Los planes de TIC incluían
inversiones que potencialmente permitirían a la empresa competir a través de
varias de sus unidades de negocio.
El nuevo siglo ha traído una serie de cambios geopolíticos que obligan a las
empresas a cambiar de estrategia a unos ritmos inusitados. La globalización de
la economía; la creciente deslocalización de los recursos productivos; la popula-
rización de la subcontratación masiva de todo tipo de procesos (Business Pro-
cess Outsourcing, BPO); los movimientos migratorios; y el avance imparable de
las tecnologías entre otros, fuerzan a las empresas a ser capaces de variar su
orientación estratégica si no quieren competir en inferioridad de condiciones.
Esta flexibilidad está normalmente reñida con los departamentos TIC. Los
sistemas tardan tiempo en desarrollarse e implantarse y, en general, una vez en
operación generan una rigidez inapropiada a los tiempos actuales. Para solven-
tar este inconveniente es necesario que los conceptos de TIC se integren en el
pensamiento estratégico al máximo nivel de la empresa, en su dirección estraté-
3
Véase M. Peteraf (1993), «The Cornerstones of Competitive Advantage: A Resource-Based
View», Strategic Management Journal, 14: 179-191, o P. Ghemawat (1991), Commitment: The
Dynamic of Strategy, New York: The Free Press.
4
En adelante, utilizaremos la denominación departamento TIC para referirnos al departamento
con responsabilidad sobre las TIC entendido como un recurso estratégico.

gica. Si bien las inversiones en tecnologías de la información generan rigidez e

impiden según qué acciones estratégicas, no lo hacen en mayor medida que
inversiones comparables de capital en activos fijos o en formación, por ejemplo.
El problema es que, en muchas empresas, las TIC siguen siendo reactivas a las
estrategias de negocio que se determinan por procedimientos completamente
ajenos a las posibilidades, positivas y negativas, de la tecnología. El resto del
capítulo expone las características básicas que debe seguir el sistema de toma de
decisiones estratégicas de la empresa integrando de manera sistemática las TIC.
Los sistemas de información como elemento

de la dirección estratégica
La dirección estratégica representa la forma más avanzada y coherente del pen-

samiento estratégico. No solamente intenta extender la visión estratégica a lo
largo de todas las unidades operativas y funcionales de la empresa, sino que
incluye también todo sistema administrativo y reconoce el papel central de los
individuos y grupos en la organización y de la cultura restante. El objetivo últi-
mo de la dirección estratégica es el desarrollo de los valores corporativos, las
capacidades directivas, las responsabilidades organizativas, las capacidades dis-
tintivas y los sistemas administrativos que enlazan la toma de decisiones opera-
tivas con las estratégicas a todos los niveles de la jerarquía y a través de todas las
líneas de autoridad de negocios y funciones en la empresa. Al llegar a esta etapa
se elimina el conflicto entre largo y corto plazo, y las decisiones operativas y
estratégicas se acoplan definiendo las tareas directivas a todos los niveles. En
pocas palabras, toda la organización está impregnada de pensamiento estratégi-
co y se mueve de forma coherente. El elemento catalizador de todo proceso son
los valores corporativos y la cultura empresarial.
El desarrollo de la dirección estratégica precisa que todos los sistemas estén
integrados en la estructura organizativa, que esta integración tenga lugar a nivel
operativo y estratégico y que la infraestructura directiva sea congruente con la
cultura organizativa. Cuando se produce esta integración, dado que los SI for-
man parte de la infraestructura de empresa, la integración entre la estrategia de
negocio y de TIC se da de forma natural, sin necesidad de ningún proceso formal
para su identificación e integración. El objetivo final de la utilización de este
tipo de metodología es facilitar tal integración y que la cultura organizativa de
cada empresa se desarrolle coherentemente con ella.
Cuando las empresas alcanzan el estadio de la dirección estratégica, pueden
usar las oportunidades que le brindan las TIC para la mejora de sus procesos. No
obstante, muchas veces –en particular cuando los competidores tienen estructu-
ras de costes marcadamente inferiores– no es suficiente mejorar la eficiencia de
manera incremental, sino que la empresa necesita dar saltos cuánticos. En estos
casos la organización debe examinar de manera sistemática las hipótesis que
sustentan los procesos de negocio.
La aparición de nuevas tecnologías –que permiten realizar tareas radical-
mente diferentes a la habitual o incluso suprimirlas completamente– hace que
sea posible, y seguramente esencial, un replanteamiento radical de la manera de
hacer «de siempre». Muchas empresas, tanto si están involucradas en un proceso
formal de planificación como si han alcanzado el estadio de dirección estratégi-

ca, necesitan un mecanismo de seguimiento de la evolución de la tecnología. Y es

que las TIC avanzan a una velocidad tal que hace imposible seguirlas si la empresa
no dedica esfuerzos formales a ello.
Uno de los errores que se observan en muchas empresas es que los responsa-
bles de las TIC quedan anclados en las tecnologías que conocen y no toman
decisiones en base a todas las posibilidades disponibles. Una dimensión esencial
de una propuesta que se apalanque en las posibilidades de la tecnología requiere
conocer por dónde camina la tecnología relevante para la empresa.
La empresa puede desechar el uso de una nueva tecnología de la informa-
ción, pero siempre tras considerar su posibilidad, nunca porque desconocía su
existencia o sus capacidades. Utilizar una tecnología sólo porque existe es igual
de pernicioso; de hecho, muchos de los errores cometidos durante la llamada
«fiebre de Internet» pueden buscarse en el uso de la tecnología «per se», sin una
imbricación clara con el modelo de negocio.
VENTAJAS ESTRATÉGICAS DE LOS SI Y LAS TIC:

EL CONCEPTO DE ITSGA
La integración del diseño de la estrategia de TIC con el del negocio puede
articularse con la ayuda de un concepto que denominamos «Acciones estratégi-
cas genéricas de tecnologías de la información», que se ha venido usando bajo
el acrónimo inglés ITSGA (Information Technology Strategic Generic Action).
Dicho concepto trata de transmitir la idea de acciones estándar, cuya aplicación
genera ventajas competitivas sostenibles. Aunque «estándar» y «estratégico»
puedan parecer términos incompatibles, y hasta contradictorios, en este contex-
to no lo son.
Se entiende por ITSGA acciones que las empresas llevan a cabo para obtener
ventajas competitivas de la mano de las TIC y que pueden generalizarse e imi-
tarse en otros contextos; de aquí que el concepto de genérico no sea peyorativo,
sino que entraña aplicabilidad. Los ejemplos siguientes ilustran algunas de estas
acciones.
Las ITSGA pretenden proporcionar a los responsables de la formulación de
la estrategia unas líneas de actuación basadas en las posibilidades de las TIC.
Son elementos genéricos que, combinados adecuadamente con el resto de capa-
cidades de la empresa, permiten generar una ventaja competitiva, al menos tem-
poralmente. Después de presentar varias ITSGA a modo de ejemplo, se presen-
tará un esquema de metodología que las incorpora en el proceso de gestión
estratégica de la empresa para que ésta pueda incorporar en la misma las posibi-
lidades que ofrecen las TIC.
Es posible identificar varias ITSGA sólo repasando la abundante literatura
que describe cómo determinadas empresas han conseguido ventajas competiti-
vas basadas en los sistemas de información y las tecnología asociadas. La iden-
tificación de las ITSGA procede, pues, del análisis de ejemplos concretos. En
esta sección se presentan tan sólo un conjunto representativo. En general, sin
embargo, cada empresa debería llevar a cabo su propio esfuerzo para analizar
los ejemplos que considere más adecuados (más característicos de su sector, por
ejemplo) y clasificarlos de manera que puedan aprovecharse, razonando por ana-
logía, como se sugiere más adelante.

Son muchos los ejemplos de ventajas competitivas alcanzadas a través de un

uso inteligente de los SI y de las TIC que se han documentado en varias publica-
ciones, tanto especializadas como de divulgación, durante los últimos años. Con
frecuencia lo que pretenden dichos ejemplos es despertar el interés del lector en
el tema, y por ello acostumbran a ser incluso espectaculares. Dado que el propó-
sito de este apartado es ligeramente distinto, no todos los ejemplos resultan sor-
prendentes. Sin embargo, por un lado permiten ver la amplitud de aplicaciones
estratégicas de las TIC y, por otro, ofrecen una base para la clasificación de las
mismas.
Muchas entidades financieras en nuestro país ofrecen las denominadas «cuen-
tas familiares». Detrás de dichas cuentas no hay más que una cuenta tradicional,
por ejemplo de ahorro, a la que se añade un servicio: un resumen periódico de
los movimientos, ordenados por concepto (ingresos, gastos de alquiler, gas, elec-
tricidad, teléfono, colegios, etc.). El resultado equivale a una «cuenta de resulta-
dos» del titular para un período determinado. Por supuesto, el valor para el cliente
de este servicio adicional aumenta en función del porcentaje de las transaccio-
nes que realice a través de la entidad; en caso de realizarlas todas sobre esa
cuenta, el resumen periódico le proporciona un análisis exhaustivo de sus ingre-
sos y gastos. Para la entidad financiera, la elaboración de dichos informes es
relativamente fácil: las transacciones deben registrarse en cualquier caso y orde-
narlas por conceptos periódicamente es un subproducto de su sistema de infor-
mación que precisa solamente de datos fiables acerca del «tipo» de cada transac-
ción. Por esta razón, la ventaja sobre los rivales por ofrecer este servicio añadido
ha durado poco: ahora todas las entidades ofrecen un producto similar.
Pero hoy en día, aportar esta cuenta de resultados se debe entender de otro
modo: es algo necesario para competir. Se ha convertido en una práctica están-
dar en el sector, de modo que no ofrecerlo constituye una desventaja y, por tanto,
sigue contando en el planteamiento estratégico de las empresas del sector.
¿Qué se ha hecho en este caso con el SI?
Puede conceptualizarse de varias maneras. Puede decirse, por ejemplo, que se

ha aumentado el contenido de información del producto, diferenciándolo así
de los de la competencia. O que se trabaja para el cliente, que se ahorra la
elaboración del resumen a mano. O que, de hecho, se ha creado un nuevo pro-
ducto, integrado por la cuenta tradicional y del servicio periódico de la elabora-
ción del informe. Puede también decirse que aunque una cuenta de ahorro no se
distingue de otra, el informe sí, y por tanto se ha personalizado el producto,
incluyendo en el mismo datos de interés para el cliente en particular. El ejemplo
de la cuenta familiar es seguramente irrelevante para la mayoría de empresas,
pero la ITSGA trabajar para el cliente, disminuyendo sus costes mediante una
operación sin coste para la entidad sí puede serlo, ya que tiende a aumentar la
calidad percibida del servicio y a aumentar las barreras de cambio del cliente.
Otro ejemplo del sector financiero que se cita a menudo es la instalación de
cajeros automáticos (ATM). Aunque ahora es un producto indispensable para el
sector, sigue proporcionando diferenciación a las entidades más agresivas, que
destacan este aspecto cuando transmiten su imagen de empresa. ¿Qué consiguen
los cajeros automáticos? Puede también conceptualizarse de más de una mane-

ra. Para empezar, una red de cajeros constituye un nuevo canal de distribución
para ciertos productos, que puede incluso utilizarse para distribuir otros pro-
ductos o servicios (por ejemplo, algunas entidades financieras están distribu-
yendo seguros, reservas de viajes y entradas a espectáculos). Puede verse tam-
bién como una manera de lograr que el cliente trabaje para nosotros, ya que
teclea las transacciones él mismo en vez de hacerlo un empleado de la entidad
financiera. En esta situación, el cliente acepta como mejora de servicio una ac-
tividad que reduce sustancialmente los costes del proveedor.
El ejemplo actual de paso de ventaja competitiva a necesidad estratégica son
las sugerencias personalizadas de Amazon.com. Esta gran tienda online fue la
primera empresa de venta por Internet que usó el historial de compras de sus
clientes para encontrar patrones de comportamiento. Así, cuando un cliente se
identifica, se compara su patrón de compra con el de otras personas que hayan
comprado libros similares, se buscan las diferencias, y se le presenta al navegan-
te una lista de sugerencias bajo el epígrafe «Otros clientes que han comprado lo
mismo que usted también ha comprado…» o «Pensamos que pueden ser de su
interés…»
Esta ventaja diferencial de Amazon.com se ha convertido en un estándar de la
venta por Internet. Evidentemente, las empresas con mayor número de clientes
podrán afinar mucho más con sus sugerencias que el resto. Desde un punto de
vista conceptual, esta acción de comunicarse con el cliente de forma personali-
zada es usar información sobre el cliente para construir un mensaje único,
posibilidad facilitada en gran manera por Internet, pero que está al alcance de
las empresas que se comunican sistemáticamente con sus clientes.
Después de la liberalización del sector de líneas aéreas en Estados Unidos,
varias empresas que no disponían de sistemas de reservas pasaron por enormes
dificultades. Un caso muy conocido es el de Frontier Airlines, que durante los
años de mercado regulado decidió no desarrollar su propio sistema de reservas.
En 1978, se vio obligado a subcontratar, los servicios de reservas a un competi-
dor, una iniciativa que acabó con la desaparición de Frontier. Para Frontier la
desventaja derivada de no disponer de sistema de reservas propio fue, pues, de-
cisiva. Por el contrario, las aerolíneas United Arlines desarrollaron un sistema
de reservas que le permitió controlar el canal de distribución de sus productos
e imponerlo a sus clientes, los agentes de viajes. Este control absoluto del canal
de distribución llevó a United a dominar a sus competidores, que se vieron obli-
gados a subcontratar el canal a su competidor. Frontier se sintió tan agredida que
interpuso un recurso en el Congreso de Estados Unidos, aunque, visto el resulta-
do final, de poco le sirvió.
Una vez dominado el canal de distribución a través de los SI, es posible
utilizar el canal para otros propósitos. United lo utilizó para enviar mensajes a
sus clientes, como también podía haber distribuido otros productos o servicios,
como seguros de viaje.
Federal Express es un ejemplo de compañía que, acoplando actividades de la
cadena de valor y basándose en su sistema transaccional, obtiene tales venta-
jas competitivas que incluso establece nuevas prácticas en el sector. A finales de
los años ochenta, Federal construyó un sistema global de seguimiento que le
permitía saber en cada momento la posición de sus envíos. Cada paquete estaba
identificado inequívocamente con un código de barras: cuando éste cambiaba de
manos, la lectura de la etiqueta comunicaba su situación a un único ordenador

central. Cada camión –de hecho, cada empleado de recogida y entrega– estaba
comunicado vía radio con el ordenador central, de manera que un envío que
pasaba a manos de Federal quedaba instantáneamente registrado y se le asigna-
ba una ruta hasta su destino. El operario conocía cualquier modificación de la
ruta gracias al escáner del código de barras, y de este modo podía redirigir el
paquete adecuadamente. Este sistema fue extraordinariamente novedoso en su
momento, y proporcionó a Federal Express una enorme ventaja competitiva al
redefinir el estándar operativo del sector. Hoy en día, todas las empresas de
transporte urgente de carácter global han invertido enormes sumas para disponer
de sistemas comparables, pero Federal Express, con su fiabilidad inigualable,
consiguió una posición de liderazgo que todavía hoy conserva.
Las relaciones entre los sistemas de información y la estructura organizati-
va las ejemplifica la compañía Mrs. Fields Cookies. En 1977, la señora Debbie
Fields tenía una única tienda de galletas localizada a las afueras de San Fran-
cisco. En 1992, ella y su marido habían pasado a ser los propietarios y dirigir
una cadena de 400 tiendas, pero además lo habían conseguido manteniendo
una estructura de solamente 130 personas. Con este mismo personal controla-
ban también 380 tiendas adicionales en régimen de franquicia. Para ello, Mrs.
Fields Cookies construyó un sistema de comunicación/información por el que
el ordenador central de la empresa –en realidad un potente miniordenador–
contacta varias veces al día con un ordenador personal localizado en cada una
de sus tiendas. El ordenador personal controla la actividad de la tienda, inclu-
yendo las ventas horarias y la producción. El ordenador sugiere al director de
la tienda cuántas galletas de cada clase debe hornear y le advierte si está lejos
del objetivo de ventas. Debbie había establecido para su primera tienda objeti-
vos de venta horarios que, en su opinión, debían adoptar el resto de tiendas:
era la única manera de que las galletas estuviesen siempre recién hechas y
calientes. Existe además un sistema de correo electrónico y de correo de voz
que permite a todos los empleados comunicarse directamente con Debbie, quien
se compromete a responder personalmente los mensajes en menos de 48 horas.
¿Qué están haciendo los Fields?: funcionar con una estructura organizativa
esencialmente plana, sin jerarquía. Han acercado extraordinariamente los
niveles de gestión y la operativa de la tienda, dándose cuenta de que cuando la
estructura se usa solamente para transmitir y elaborar información es innece-
saria.
Categorías de ITSGA
Como se acaba de ver, pueden conseguirse ventajas estratégicas gracias a las

nuevas tecnologías atacando distintos puntos de las relaciones de las empresas
con sus clientes o proveedores; del diseño de nuevos productos; o de la ejecu-
ción de actividades internas, etc. Estas ITSGA, que hacen referencia tanto a las
relaciones de la empresa con su entorno como a las actividades internas de la
cadena de valor, son conceptualmente importantes en el diseño de procedimien-
tos de análisis pensados para identificar oportunidades estratégicas basadas en
las TIC. A continuación se resumen las ITSGA identificadas en los ejemplos
anteriores, clasificadas por conceptos. La lista incluye también algunas ITSGA
que son sólo las recíprocas de las ya identificadas.

ITSGA relacionadas con producto
z Incrementar el contenido de información del producto.

z Personalizar el producto.
z Crear nuevos productos (por ejemplo, a partir de datos de ventas de otros
productos).
z Combinar productos.
ITSGA relacionadas con clientes
z Trabajar para el cliente.

z Conseguir que el cliente trabaje para la empresa.
z Seleccionar clientes potenciales para determinados productos.
z Incrementar los costes de cambio de proveedor por parte de los clientes.
z Facilitar a los clientes acceso a nuestro sistema de transacciones.
z Acceder al sistema de transacciones de los clientes.
z Estandarizar las relaciones con los clientes (EDI o XML).
z Fomentar la creación de un mercado electrónico.
z Defenderse de la aparición de un mercado electrónico.
ITSGA relacionadas con canales de distribución
z Controlar el canal de distribución.

z Desarrollar nuevos canales de distribución.
z Utilizar canales existentes para otros propósitos (distribuir otros produc-
tos, etc.).
ITSGA relacionadas con proveedores
z Incrementar la efectividad de las relaciones con proveedores.

z Facilitar a los proveedores acceso al sistema de transacciones de la em-
presa.
z Conseguir que el proveedor trabaje para la empresa.
z Acceder al sistema de transacciones de los proveedores.
z Estandarizar las relaciones con los proveedores (vía EDI o XML).
z Fomentar la aparición de un mercado electrónico.
ITSGA relacionadas con actividades de la cadena de valor

(de reingeniería o innovación de procesos)
z Incrementar eficiencia de actividades.

z Acoplar actividades.
z Reestructurar la cadena de valor, explotando vínculos e interrelaciones.
z Encadenar procesos, aumentando el contenido del trabajo de las perso-
nas.

z Combinar el trabajo que produce la información con su entrada en el siste-

ma y su posible elaboración. Recoger la información una sola vez, dónde
se produzca.
z Tratar recursos dispersos geográficamente como si estuvieran en el mis-
mo lugar.
z Descentralizar decisiones tanto como sea posible, proporcionando ayuda
al decisor, y estableciendo los sistemas de control adecuados.
z Colapsar el tiempo necesario para producir y recopilar información.
ITSGA de carácter general
z Establecer nuevas prácticas (¿estándar?) en el sector, llegando a cambiar

su estructura a favor de la empresa.
z Considerar los sistemas transaccionales como fuentes de ventajas compe-
titivas.
z Considerar operar con una estructura prácticamente plana, sin escalones
jerárquicos.
Estas acciones no son las únicas ni las más importantes para todas las situa-
ciones. Sin embargo, resultan útiles para apoyar el proceso de generación de
ideas estratégicas basadas en las TIC. A pesar de que, en general, las ITSGA
presentadas lo han sido como acciones positivas (esto es, como fuentes de ven-
tajas), pueden también jugar un papel más defensivo. En ese caso, se trata de
acciones necesarias para contrarrestar movimientos de los competidores, para
adaptarse a nuevas estructuras emergentes en el sector, etc. Las ITSGA de este
tipo pueden dar lugar a acciones estratégicas basadas en las TIC tan importantes
como las deducidas de ITSGA más positivas.
ESTRUCTURA BÁSICA DE UNA METODOLOGÍA

DE PLANIFICACIÓN CONJUNTA ESTRATEGIA
DE EMPRESA - TIC5
La Figura 3.5 presenta los bloques básicos de la metodología propuesta, que
básicamente consiste en añadir el componente de TIC en el pensamiento estraté-
gico de la empresa. El impacto de este componente se produce en tres estadios:
z Análisis detallado de las posibilidades de la tecnología existentes y acce-

sibles.
z Examen exhaustivo de la tecnología y el conocimiento relacionado dis-
ponible en la organización.
z Contraste de los retos estratégicos de la firma con las acciones genéricas
relevantes.
5
Una descripción más detallada de esta metodología se puede encontrar R. Andreu, J. E. Ricart
y J. Valor (1996), Estrategia y Sistemas de Información, McGraw-Hill, libro del que se han extraído
algunos elementos fundamentales de esta sección.

Misión del negocio

Motores estratégicos corporativos
Retos de planificación
Análisis del entorno

Análisis tecnológico Interno
tecnológico
Acciones genéricas
Análisis detallado de la
de tecnologías de la
cadena de valor
información
Acciones estratégicas de
unidades de negocio y
funcionales
Crean capacidades competitivas
Figura 3.5. Esquema del procedimiento de integración

de las TIC en el pensamiento estratégico.
Las acciones estratégicas conseguidas deben aumentar el bagaje de capacida-

des competitivas de la empresa y son, por tanto, un elemento fundamental en el
diseño continuo de los retos de planificación y pensamiento estratégico.
El procedimiento de la Figura 3.5 parte de los análisis clásicos empleados en
el diseño de estrategias de negocio: misión del negocio, análisis del entorno y
análisis interno. El objetivo es simplemente llevar a cabo estos análisis poniendo
énfasis en una perspectiva de las TIC, de manera que se tengan en cuenta explí-
citamente las posibilidades competitivas de éstos. Así, se propone que el análisis
interno tenga en cuenta las tendencias tecnológicas previsibles, con objeto de
aquilatar la bondad de diseños de los sistemas y aplicaciones en explotación o
desarrollo. Aunque no se concreta en la Figura 3.5, debe entenderse que tales
tendencias tecnológicas son también relevantes para el análisis del entorno. Ade-
más, en dicha figura se añade un nuevo elemento en el proceso, procedente de
experiencias anteriores: las ITSGA descritas en la sección anterior.
Como en todo proceso de diseño estratégico, al final los análisis efectuados
deben integrarse con objeto de sintetizar la estrategia y definir acciones concre-
tas para su implementación. Esta actividad de síntesis es la más creativa del
proceso y depende, por tanto, de las percepciones y experiencia previas de quie-
nes participen en el mismo.

Las acciones estratégicas deducidas de esta síntesis son relevantes tanto en el

proceso de elaboración del plan de SI como para decidir qué otras aplicaciones
TIC tienen potencial competitivo. Estas acciones también son relevantes en el
diseño de la estrategia de negocio propiamente dicha, ya que, como se ha visto
en el apartado anterior, en ellas puede residir el embrión de un nuevo producto o
canal de distribución, etc.
Es importante recalcar esta doble interacción entre «acciones TIC-estrategia
de negocio»: las posibilidades y las decisiones que se adopten con respecto a las
TIC pueden reconfigurar la estrategia de negocio mientras que tanto el plan de
SI que se elabore como las aplicaciones que se desarrollen deben ser coherentes
con aquella. En la práctica, a menudo es preciso iterar el proceso varias veces
hasta estabilizar de forma simultánea la estrategia de negocio y el plan de TIC.
Aunque este procedimiento de planificación tiene un claro sesgo de TIC, lo
que aquí se describe es una parte muy específica del proceso de diseño de la
estrategia. Por tanto, otras partes del mismo proceso deben compensar dicho
sesgo con consideraciones más globales.
Finalmente es importante notar que determinados conocimientos (como los
relacionados con el sector o las tendencias tecnológicas) son muy relevantes
para este proceso. Es muy difícil explicar de dónde y cómo se obtienen estos
conocimientos, ya que cada caso es distinto. Lo importante es ser consciente de
que tales conocimientos son necesarios para conseguir un proceso realista. Aun-
que normalmente los participantes en el mismo aportarán estos conocimientos,
si existe la preocupación de que tales personas pueden flaquear en alguna de
estas áreas de conocimientos es preciso subsanar la deficiencia. Un ejemplo
sería crear una posición en el organigrama de la empresa responsable de otear el
horizonte tecnológico.
El Cuadro 3.1 describe de manera somera cómo llevar a cabo los análisis
indicados en esta sección.

El procedimiento propuesto en la sección anterior especifica qué se propone
hacer para conseguir, a la vez, una congruencia explícita entre el entorno de las
TIC de una empresa y su estrategia de negocio e identificar oportunidades estra-
tégicas basadas en dichas tecnologías. Se ha llegado a la conclusión de que am-
bas cosas son, de hecho, inseparables en cuanto al procedimiento que se emplee
para conseguirlas, ya que, asimismo, ocurre que ambas se logran en una parte
muy concreta del proceso de diseño de la estrategia competitiva de las empresas,
y éste es único. Lógicamente, todo ello tiene una serie de implicaciones organi-
zativas que se exploran brevemente en esta sección.
La primera implicación importante tiene que ver con quién debe intervenir
en el proceso esquematizado de diseño de la estrategia de empresa cuando se
busca una componente de TIC relevante. En el procedimiento «tradicional» de
planificación, denominada aquí metodología pasiva, discutido al principio de
este capítulo se puede ser mucho más explícito al respecto, pudiendo establecer
formalmente un comité de SI integrado por directores funcionales, determinar la
aprobación del plan de SI por parte del comité ejecutivo, y asignar la responsa-
bilidad de dicho plan al director del Departamento TIC.

Misión del negocio
En general, ésta estará especificada de antemano y debe incluir las coor-

denadas básicas del negocio. Debe especificar los ámbitos de productos,
mercados y zonas geográficas actuales y futuras, así como describir las
singularidades de la empresa tanto en el momento del análisis como las
previstas en el futuro que se consideren relevantes para distinguirla de
sus competidores. Disponer de una misión explícita es muy útil durante
todo el proceso porque ayuda a no perder el norte del mismo.
Análisis del entorno
Existen varias maneras de llevar a cabo este análisis. A escala de unidad

de negocio, interesa analizar el sector en que opera ésta y sus principales
competidores en un cierto marco macroeconómico, social y cultural. El obje-
tivo es identificar las oportunidades y amenazas para hacerles frente con
la ayuda de TIC.
Un posible análisis consiste en utilizar el marco conceptual de las
«cinco fuerzas» descrito por Porter6, desarrollando una evaluación respec-
to a cuán atractivo (o repulsivo) resulta el entorno para la misma. El obje-
tivo final es posicionar el negocio de forma consistente con las caracterís-
ticas del sector y las de los competidores. El análisis puede organizarse
identificando los factores más sobresalientes que configuran la estructu-
ra del sector y preguntándose, para cada uno de ellos, cómo pueden ser
fuente de ventajas (es decir, dónde existen oportunidades) o de desven-
tajas (es decir, qué amenazas latentes están presentes en el entorno).
Análisis interno: estructura detallada de la cadena de valor
El propósito de este análisis es explicar los procesos de negocio y/o las

actividades de la cadena de valor de mayor importancia estratégica para
la unidad de negocio objeto de estudio. Es conveniente detallar la estruc-
tura interna de cada proceso o actividad genérica de la cadena de valor
con objeto de aislar las actividades más relevantes. En el contexto de
planificación de sistemas existe una razón adicional que aconseja incre-
mentar el grado de detalle de este análisis: en la medida en que la apli-
cación de las tecnologías de la información sea susceptible de afectar el
funcionamiento de determinadas partes de una actividad genérica deter-
minada, es aconsejable tomar esas partes como unidad de análisis. Así,
por ejemplo, si se estuviera analizando el proceso de venta, sería ade-
cuado subdividirlo en subactividades como las que proponen Ives y Lear-
6
Porter, M. (1980), Competitive Strategy: Techniques for Analyzing Industries
and Competitors, New York: The Free Press.
Cuadro 3.1. Tareas de la metodología de «planificación activa».


month7. Una de ellas, por ejemplo, es «generar alternativas de compra

que satisfagan las condiciones del cliente potencial», para posteriormen-
te evaluarlas, elegir la que le parezca mejor, cursar el pedido correspon-
diente, etc. A este nivel de detalle es posible imaginar, con mucha más
facilidad y posibilidad de éxito, si la empresa puede usar la tecnología de
la información para apoyar esta actividad que no pensando genéricamen-
te en «venta».
Es preciso mencionar que el análisis de los procesos no debe limitar-
se a las actividades que lleva a cabo directamente la unidad de negocio
en estudio, sino que debe incluir las actividades del sistema de valor del
que la misma forma parte. De hecho, el mismo ejemplo de subactividad
(«generar alternativas de compra») antes mencionado ilustra este extre-
mo. En efecto, el posible cliente realiza esa subactividad de manera que,
estrictamente hablando, se trata de una subactividad del sistema de va-
lor y no del proceso de venta.
Finalmente, el análisis no debe descuidar las interrelaciones y los
vínculos entre actividades de la cadena de valor. Si hablamos de TIC, su
influencia en interrelaciones de coordinación de actividades o subactivi-
dades adyacentes es potencialmente muy importante debido a que la
propia naturaleza de los sistemas de información está muy relacionada
con la coordinación de actividades.
Análisis interno: posición en referencia a las TIC
Se trata aquí de identificar, desde una perspectiva de las TIC, los puntos
fuertes y débiles de la unidad de negocio objeto de estudio, tanto en el
momento actual como el futuro. El análisis debe hacerse en relación a los
competidores, reales o potenciales, más importantes. El resultado debe ser
un resumen de puntos fuertes sobre los que la empresa pueda capitalizar y
resaltar claras deficiencias a subsanar a corto plazo. Para identificar carac-
terísticas relevantes de las TIC a introducir en este análisis, a menudo resul-
ta conveniente realizar un repaso del entorno tecnológico con objeto de no
olvidar determinados factores que podrían convertirse en puntos fuertes o
débiles con la llegada al mercado de nuevos desarrollos tecnológicos.
Integración. Identificación de acciones estratégicas de TIC
Los resultados de los análisis descritos deben integrarse para sintetizar

las acciones estratégicas específicas de TIC. Para ello es posible simple-
mente entrar en un proceso creativo con los expertos de negocio y cono-
cedores de la tecnología pero en muchas ocasiones es útil considerar
explícitamente la interacción entre las acciones genéricas y los resulta-
dos de los análisis anteriores.
7
Ives B., y G. Learmonth (1984), The Information System as a Competitive Weapon,
Communications of the ACM, 27(12), p. 1193 - 1201.
Cuadro 3.1. (Continuación)

En cambio, en la metodología activa no es posible indicar nada tan explí-

cito ni nada parecido. Es lógico, sin embargo, que dicho proceso, por ser parte
del propio proceso de diseño de la estrategia precisa de la misma participación
de la alta dirección, ahora con más motivo, si cabe, que en el procedimiento
«tradicional». Existen, sin embargo, diferencias de matiz importantes. Por ejem-
plo, los conocimientos del sector, explícitamente necesarios para llevar a cabo
el proceso de la Figura 3.5, son responsabilidad de los directores funcionales
de la empresa, que deben en este caso proporcionar información de carácter
mucho más estratégico que en el planteamiento «tradicional». El director del
departamento TIC, por su parte, debe proporcionar datos acerca de los puntos
fuertes y débiles del entorno del sistema y de la tecnología existente o planifi-
cada, y también acerca de las posibilidades de las tendencias tecnológicas, todo
ello en un contexto de análisis estratégico en el que los componentes externos
a la empresa (estado de la tecnología y los sistemas empleados por la compe-
tencia, etc.) son mucho más necesarios que antes. Por estas razones, tanto los
directores funcionales como el director de las TIC precisan tener perfiles más
basados en experiencia en el negocio que en detalles estrictamente tecnológi-
cos. Esto implica que la formación de personas apropiadas para cubrir el pues-
to de director de las TIC debe contemplar explícitamente aspectos del nego-
cio, lo que hace necesario para las mismas haber tenido experiencia de gestión
de línea.
En otro orden de cosas, y debido precisamente a la necesidad de contar con
previsiones acerca de la posible evolución de las TIC, en determinadas empresas
puede ser necesario establecer un puesto en el organigrama con responsabilidad
específica sobre estos temas. Un puesto cuya misión principal sea «otear el hori-
zonte tecnológico», encargado de informar al resto de la organización de las
posibilidades de los desarrollos tecnológicos que «se ven venir» en cada mo-
mento ha sido, de hecho, instaurado en más de una empresa. La manera de desa-
rrollar estas funciones es muy variada, llegando incluso en ocasiones a la publi-
cación periódica de un boletín informativo interno acerca de los desarrollos
tecnológicos previsibles. Por supuesto, el responsable de tal actividad debe tener
sensibilidad para aspectos del negocio, no sólo para aspectos tecnológicos –lo
contrario produciría detallados informes acerca del último grito tecnológico sin
pasarlo por la criba de su relevancia en el contexto de las actividades de negocio
de la empresa de que se trate.
Aun desde otra perspectiva existen implicaciones para la organización inter-
na del departamento TIC, incluso en las partes aparentemente más técnicas del
mismo. Por ejemplo, el concepto de «mantenimiento estratégico de aplicacio-
nes», que a priori puede parecer un contrasentido en los términos, implica pro-
curar evitar un enfoque eminentemente técnico de las actividades de manteni-
miento presentes en cualquier departamento TIC. La razón es clara, si
contemplamos la actividad de mantenimiento desde la perspectiva de los ejem-
plos presentados en el capítulo anterior: El mantenimiento de una aplicación en
la que la empresa se apoya para conseguir ventajas competitivas es algo obvia-
mente no delegable a la responsabilidad de personas con formación exclusiva-
mente técnica, incluso en el caso de tratarse de aplicaciones puramente transac-
cionales –ya se vio que es posible obtener ventajas competitivas también a partir
de éstas–. Y, sin embargo, éste es el caso en muchos departamentos TIC de em-
presas españolas.


Sistemas para la gestión integrada de los recursos de la empresa 57
4
Sistemas para la gestión
integrada de los recursos
de la empresa
En el capítulo anterior se han presentado dos enfoques a la planificación de

sistemas, uno encaminado a alinear los sistemas con la estrategia de la empresa
y otro que propone diseñar simultáneamente las acciones estratégicas de la com-
pañía y sus tecnologías de la información. En ambos casos subyace la idea de
que la empresa dispone de una base de información integrada que reúne en un
único repositorio todos los datos transaccionales que la compañía genera con
sus operaciones. La estandarización de definiciones y criterios es esencial: todos
los departamentos deben referirse a unos mismos productos y suministros con
idéntico nombre; los códigos de clientes y proveedores deben ser los mismos
para todas las unidades, y los planes de cuentas de las diferentes subsidiarias han
de ser coherentes, cuando no idénticos. El establecimiento de esta base común
sobre la que edificar unos sistemas de información, especialmente los suscepti-
bles de proporcionar ventajas competitivas, no es tarea sencilla. Requiere un
paso previo de análisis como el descrito al principio del Capítulo 3, que hace
énfasis en la necesidad de detectar los elementos de información compartidos a
través de las diferentes unidades funcionales.
La desagregación de información es un reflejo de la evolución fragmentada de
los sistemas de información en la empresa, que se fueron introduciendo a medida
que surgían problemas puntuales y aislados de distintos departamentos con necesi-
dades de información también distintas. La fragmentación de la información pue-
de ocasionar problemas graves, como el que tuvo en los años noventa un impor-
tante constructor de aviones norteamericano. Este fabricante utilizaba cientos de
proveedores para los millones de componentes usados en la construcción de un
único avión. Para colocar la pieza correcta en el avión adecuado y en el momento
preciso, empleaba nada más y nada menos que cuatrocientos sistemas informáti-
cos distintos, independientes y diseñados en los años sesenta. En 1997, la falta de
consistencia de la información generada por sistemas diferentes e inconexos pro-
dujo tales retrasos en la llegada de piezas que varios aviones quedaron a medio
construir, lo que provocó el cierre de dos de las principales líneas de montaje de la
compañía y un descenso en los beneficios de unos 1.600 millones de dólares.
57

Algo parecido podría ocurrir con los diferentes departamentos, áreas fun-
cionales o unidades de negocio de cualquier empresa y con los flujos de infor-
mación que maneja. Sin ir más lejos, cada vez que llega el pedido de un cliente
se generan una gran cantidad de datos que, de no ser porque se ha pensado
previamente en ello, se almacenarían en sistemas diferentes e independientes
los unos de los otros. Eso, en el mejor de los casos, significa una duplicidad
absurda y costosa, y en el peor, un caos como el que vivió el constructor de
aviones.
Sin embargo, es frecuente que un mismo pedido se introduzca repetidas veces
en distintos sistemas de la empresa: una en el de producción y otra en el de admi-
nistración, por ejemplo. Aparte del coste extra de repetir el trabajo dos veces, esto
puede provocar retrasos, información inconsistente y pérdidas de tiempo inten-
tando descubrir el origen de los errores, cuya probabilidad también se multiplica
por dos al duplicar el proceso. Por otro lado, resulta en general difícil determinar
la posición global de un cliente, porque el estado de sus pedidos está en un siste-
ma, su situación de crédito en otro, etc. En definitiva, no hay forma de consultar
desde un departamento la información del sistema informático de otro para con-
trastarla.
Las necesidades de transferir información entre unidades funcionales son
enormes. En el área de Producción, por ejemplo, los planes de fabricación sue-
len estar basados en las ventas del producto, datos que proceden del departa-
mento de ventas. El departamento de compras, por su parte, debe adquirir la
materia prima necesaria en función de los planes de producción, del transporte,
de los plazos de entrega y de los niveles existentes de stock. Con la información
adecuada sobre los niveles de producción, la materia prima se puede pedir en el
momento en el que se necesita y pueden reducirse los niveles de inventario, con
el consiguiente ahorro.
De forma similar, el departamento de Contabilidad y Finanzas se encarga
de registrar todas las transacciones que tienen lugar en la empresa, desde los
pedidos de los clientes hasta los flujos de caja cuando se abona la materia prima
adquirida. Además, tiene la responsabilidad de elaborar los informes correspon-
dientes a todas las transacciones efectuadas de cara a determinar la posición
financiera de la empresa, por lo que necesitan datos de todos sus departamentos.
Finalmente, tiene que proporcionar los datos necesarios para un control eficaz
de los diferentes departamentos y poder evaluar la correcta gestión de los mis-
mos. De hecho, esta necesidad de control de la contabilidad –tanto del punto de
vista de gestión como legal– ocupan el centro de la mayoría de los sistemas de
información desarrollados en los años setenta. Eran sistemas «centrados en la
información financiera», en los que la realidad de la empresa se analizaba a
través de los movimientos contables. En estos sistemas, algunos de los cuales
todavía funcionan hoy en día, no era posible conocer las incidencias de la em-
presa hasta que se reflejaban en un movimiento contable.
La necesidad de la interoperabilidad de diferentes sistemas se pone tam-
bién de manifiesto en el departamento de Recursos Humanos, que al contra-
tar personal para la empresa, debe determinar, en primer lugar, las necesidades
de personal y, de acuerdo con éstas, los perfiles de los candidatos necesarios,
la tareas que han de desarrollar en la empresa y el sueldo que la empresa está
dispuesto a ofrecerles. Todos estos datos han de proceder de las diferentes
áreas funcionales de la empresa.

Finalmente, el departamento de Marketing y Ventas está en contacto con el

cliente y, por tanto, es quien recoge los pedidos y ofrece toda la información que
precisen los clientes acerca del estado de los mismos. Debe conocer tanto la
situación general del mercado como la realidad interna de la empresa para poder
fijar políticas de marketing y ventas eficaces. Así, por ejemplo, tiene que tener
información suficiente en términos de costes de producto, posibilidades de pro-
ducción, etc., para determinar la política de precios más adecuada. Además, la
información sobre los pedidos tiene que transmitirse correctamente a otras áreas
para su correcto procesamiento interno.
Estos sencillos ejemplos son suficientes para demostrar que los flujos de
información que circulan de unos departamentos a otros son elevados. Y es im-
pensable que dicha información circule gracias a personas que después de reco-
gerla a mano, quizá introducirla en un sistema propio de su departamento e
imprimirla, la transporten de un lugar a otro de la empresa para que posterior-
mente sean introducidas de nuevo en el sistema de otro departamento. Esta es la
situación que esquematiza la Figura 4.1. Esta forma de funcionar implica mu-
chas posibilidades de error y reproceso, y muchas veces acaba en situaciones
como las del fabricante de aviones que se ha descrito al comienzo de este capí-
tulo.
Para que no ocurran estos ineficientes trasiegos de información que con toda
probabilidad generan incongruencias y retrasos, es necesario disponer de un re-
positorio común de datos al que accedan todos los departamentos que necesiten
consultarlo, y actualizarlo cada vez que ocurre un suceso de negocio que lo
afecte.
Ventas Producción Logística Facturación
Pedido Envío
Figura 4.1. Flujos de información tradicionales con sistemas departamentales.


UN SISTEMA DE INFORMACIÓN INTEGRADO

PARA LA EMPRESA
Un sistema de información (SI) moderno ha de estar construido alrededor de una
única base de datos que, como mínimo, debe de tener las siguientes característi-
cas:
z Un dato debe entrarse una sola vez en el sistema.

z Todas las características del dato (sus atributos) deben estar relacionados
directamente con (y dependen del) mismo.
z Todo dato ha de tener un responsable de su actualización y manteni-
miento.
z Ha de existir un sistema de permisos que permita sólo a los usuarios (o
programas) autorizados acceder a los datos para leerlos o modificarlos.
z Debe existir un sistema de respaldo que permita reconstruir la base de
datos en caso de un fallo técnico o de una acción destructiva por parte de
un usuario o programa.
z El sistema debe proporcionar un historial de las personas o programas
que han accedido a un determinado dato.
De esta forma, los distintos sistemas informáticos de cada departamento es-

tarán integrados «de facto» en uno único, lo que permitirá automatizar al máxi-
mo los procesos de negocio, desde que el pedido llega a la empresa hasta que se
emite su factura. Así, cuando llegue la orden del cliente, la empresa generará
automáticamente toda la información necesaria relativa al cliente, al nivel de
stock, etc. Esta información se irá actualizando a medida que el pedido recorra
los diferentes departamentos de la empresa y será a la vez accesible a todos y
cada uno de ellos. Ahora, por ejemplo, desde el departamento financiero se po-
drá comprobar si ha llegado al almacén un determinado pedido. La Figura 4.2
presenta este nuevo escenario de flujos de información.
Origen y evolución de los sistemas integrados
El origen de los sistemas integrados puede situarse alrededor de los años sesen-
ta, gracias a la introducción en el mercado de los primeros ordenadores centrali-
zados –denominados mainframes– y el software empleado por grandes compa-
ñías manufactureras para planificar la producción de forma automatizada. El
objetivo de esos sistemas era ayudar a determinar los materiales necesarios para
cumplir la programación establecida. Se trataba de sistemas denominados MRP
(Material Requirements Planning, es decir, Planificador de Necesidades de Ma-
teriales). Estos sistemas usaban datos como el calendario de entregas, la situa-
ción del inventario y los tiempos necesarios para proveerse de materiales. A
partir de ellos desarrollaban calendarios de producción para una planta. Aunque
ya existía una vaga idea de lo que era un sistema integrado, esto no era posible
debido, principalmente, a limitaciones tecnológicas.
Durante los años ochenta apareció el concepto de MRPII que, a pesar de
tener las mismas iniciales que MRP, representaba un concepto diferente. Incluía
la gestión de la planta, así como actividades relacionadas con la distribución de

Análisis
de datos
Finanzas
Servicio
Manufactura
DATOS
CLIENTES PROVEEDORES
Ventas
Inventario
y almacén
Recursos
humanos
Figura 4.2. Flujos de información con un sistema integrado.

los productos fabricados. MRPII surgió como consecuencia de una mayor compe-
titividad y cambios en la demanda de los usuarios.
Antes de que aparecieran los sistemas MRPII, coordinar las diferentes partes
de una compañía ya era un objetivo claro, pero apenas había integración entre
sistemas. La mayoría de los mismos se habían desarrollado en diferentes mo-
mentos y para desempeñar funciones específicas de un departamento determina-
do; además habían sido programados en distintos lenguajes y los datos disponi-
bles en un sistema no eran fácilmente accesibles desde otro.
Aunque la llegada de los sistemas MRPII supuso una mejora con respecto a
los sistemas tradicionales, los canales de distribución global; la presencia de
plantas en diversos países; y acuerdos integrados sobre fuentes de aprovisiona-
miento, aumentaron la presión para conseguir una mayor integración entre siste-
mas. El objetivo era obtener una mejor información operativa que permitiese a
las empresas sacar mayor provecho de sus recursos.
Por otra parte, los PC fueron ganando popularidad. La posibilidad de mane-
jar datos localmente para análisis personalizados sin tener que pedir a Informá-
tica que desarrollara un programa representaba un gran avance, magnificado
cuando los desarrollos en las telecomunicaciones permitieron compartir datos a
través de redes locales. Esto ofrecía la posibilidad de no tener que entrar los
datos manualmente en el PC y poderlos «descargar» de un ordenador central
(ahora llamado servidor) al propio PC (ahora llamado cliente del servidor) para
poder así trabajar con dichos datos. Así surgió la arquitectura denominada clien-
te-servidor, base de las aplicaciones de gestión integrada de los recursos de la

empresa (más conocido por su acrónimo anglosajón ERP, Enterprise Resource

Planning) más exitosas.
A finales de los ochenta, la mayor parte del software y hardware necesarios
para el desarrollo de los sistemas ERP ya existía: ordenadores rápidos, acceso a
redes, una avanzada tecnología de bases de datos y, sobretodo, una visión más
clara de los sistemas integrados.
A principios de los años noventa se popularizó la utilización de los ERP, que
entonces sucesivamente iban incorporando nuevos módulos, incluyendo conta-
bilidad, finanzas, recursos humanos, gestión de materiales y otras funciones de
negocio y que en general estaban basados en una arquitectura de tipo cliente-
servidor.
A principios del año 2000 se introdujo el concepto de ERP extendido o ERP
II. Este concepto engloba toda la cadena de negocio, extendiendo el ERP tradi-
cional a proveedores y clientes. Desde un punto de vista tecnológico, los provee-
dores de ERP II están pasando de una arquitectura cliente/servidor a una basada
en Internet, revertiendo mucho del proceso hacía servidores muy potentes. Los
sistemas basados en la Web reducen significativamente los costes derivados de
las infraestructuras de comunicaciones y añaden como principal funcionalidad
la de permitir el acceso al sistema independientemente de dónde se encuentre el
usuario, y a través de una variedad de dispositivos como los propios PC, agen-
das, etc., sin disponer en ellos de ningún software especial más allá de un nave-
gador estándar.
Desde un punto de vista de funcionalidad, existen varias tendencias en la
evolución de los sistemas ERP. Además de la adaptación a sectores específicos y
especializados, hay dos líneas de evolución natural adicionales. Una es hacia el
exterior de la empresa, añadiendo funcionalidades de comunicación con los pro-
veedores y los clientes. La segunda añadiendo funcionalidades de apoyo a la
toma de decisiones, en particular combinando información interna extraída del
sistema transaccional con información externa, incrementando de manera nota-
ble la funcionalidad inicial.
A modo de resumen, las principales aportaciones de estos nuevos sistemas
son:
z No se centran únicamente en apoyar la gestión y optimizar los recursos

internos de la empresa sino que comparten la información de dichos re-
cursos con empresas de interés.
z Se pasa de un proceso interno a un proceso externo, que incluye todos los
componentes del sistema de valor, que puede ir desde la planificación de
la cadena de suministro, el e-aprovisionamiento, la gestión integral de
plantas, hasta la integración con clientes o la gestión de relaciones entre
socios (véase la Figura 4.3, ERP extendido).
z Los nuevos ERP amplían sus funciones incluyendo aquéllas más especí-
ficas de industrias individuales.
z Desde un punto de vista tecnológico, se apoyan en la tecnología Web
permitiendo su acceso desde diferentes periféricos con la única ayuda de
un navegador.
La Figura 4.3 muestra la evolución pasada y tendencia futura de estos siste-

mas. Son de especial interés las particularidades de las extensiones de los ERP

ERP extendido
Gestión integrada de plantas
ERP Planificación de la cadena

de suministros
MRP II Gestión de calidad Marketplaces privados

Gestión de calidad
Gestión de proyectos
Gestión de proyectos CRM
MRP
Ingeniería
Ingeniería Mantenimiento
Mantenimiento de
Lista de materiales de planta
planta SCM
Finanzas
Finanzas
Compras Distribución
Distribución
Planificación Compras Partner Relationship
de capacidades Marketing Transporte
Transporte Management
Marketing
MRP Fabricación
Fabricación Recursos
RecursosHumanos
Humanos E-aprovisionamiento
Gestión de inventario
Figura 4.3. Evolución y tendencias de los ERP.
hacia atrás y adelante en la cadena de valor. Estos se discuten en más profundidad

en los siguientes dos capítulos, de la Gestión de la cadena de suministro (SCM,
Capítulo 5) y de la Gestión de las relaciones con los clientes (CRM, Capítulo 6)
respectivamente.
¿DESARROLLO PROPIO O PAQUETE ESTÁNDAR?

La decisión de implantar un sistema integrado suele tener un impacto muy notable
sobre el funcionamiento de la empresa, ya que implícitamente implica una redefi-
nición de la manera de funcionar de la misma. Por ello, suele ser vista como una
decisión de empresa, aunque evidentemente el departamento TIC es normalmente
considerado el líder del proyecto.
De hecho, la primera gran decisión al considerar la implantación de un siste-
ma integrado es entre dos enfoques alternativos: decidir si (a) se opta por el
desarrollo de un sistema propio, que encaje de la mejor manera posible con las
maneras de hacer de la misma, o si (b) se prefiere acudir al mercado y comprar
un paquete de software que fuerce a la integración y que contenga los procedi-
mientos más habituales y comunes a todas las empresas del sector en que opere
la compañía, instalando un sistema de gestión empresarial estándar, el ERP.
Las dos vías de solución tienen ventajas e inconvenientes, y según el caso
una será más adecuada que la otra. Sin embargo, para muchas empresas desarro-
llar desde cero una aplicación que resuelva los problemas de integración de da-
tos y los procesos básicos de información es un esfuerzo elevadísimo para con-
seguir unos sistemas que no le van a diferenciar en el mercado.
A nadie se le ocurriría escribir su propio procesador de texto. Aunque podría
ser interesante que un procesador tuviera unas funcionalidades no disponibles
en el mercado, el coste que representaría desarrollarlo para un único usuario

hace que la idea sea a simple vista absurda. Algo parecido ocurre con los siste-
mas de empresa que no aportan ventaja diferencial; quizá el mercado no ofrezca
el paquete de contabilidad o de gestión de nóminas ideal para cada caso, pero
dada su poca capacidad de aportar ventaja competitiva, el uso de un sistema sub-
óptimo pero a una fracción del coste es seguramente la mejor solución. Eviden-
temente, como todo en sistemas, es imposible encontrar verdades absolutas. Por
ejemplo, sería imaginable una situación en la que debido a singularidades extre-
madamente inhabituales en una determinada empresa, ésta se encuentre sujeta a
tantas excepciones contables que no sea rentable introducir todas las modifica-
ciones que haría falta a un paquete estándar y sea mejor programar su propia
contabilidad. La tabla de la Figura 4.4 presenta las ventajas e inconvenientes
generalmente aducidos a la hora de comparar el desarrollo propio con la instala-
ción de un paquete del mercado. Evidentemente, cada empresa deberá juzgar la
dimensión estratégica que para ella tienen las actividades soportadas por los sis-
temas que esté decidiendo adquirir y las particularidades del sistema integrado
que se esté considerando.
En relación a los paquetes integrados ERP se puede decir que alrededor de
30.000 empresas de todo el mundo tienen implantado este tipo de sistemas. Su
Desarrollo propio de un sistema integrado Instalación de un paquete ERP
Mayor rigidez, ya que lleva incorporada

Mayor flexibilidad y adaptación a la empresa implícitamente una “manera de hacer” genérica.
Flexibilizarlo es extremadamente caro
Dilatado en el tiempo. Requiere un análisis

Instalaciones relativamente rápidas
exhaustivo de todos los procesos de la empresa
Requiere experiencia en programación de grandes

sistemas, normalmente ausente en los Requiere expertos en el paquete, generalmente
departamentos de sistemas de empresas un “implantador” especializado
medianas y pequeñas
Requiere experiencia en el análisis de todas las En general incorporan experiencias
funciones de la empresa de las empresas líderes del sector
Costes de parametrización bajos si se está
dispuesto a cambiar los procesos de la empresa;
Costes de desarrollo elevados
elevados si hay que adaptar el paquete a la
empresa
Costes de implantación elevados si hay
Costes de implantación bajos si no se han
que cambiar los procesos y manera de operar
introducido cambios en los procesos de negocio
de la empresa
Costes de licencias elevados, pero que aseguran
Costes de mantenimiento de aplicaciones elevados
una evolución tecnológica y
en entornos cambiantes
de funcionalidad
Tiende a perpetuar la manera de hacer de la Aporta unos procesos aceptados por la mayoría,
empresa, lo que puede ser bueno si la empresa lo que puede ser bueno o malo, dependiendo de
compite gracias a ello la situación de la empresa
Figura 4.4. Programación propia frente a paquete estándar.


creciente flexibilidad de adaptación a situaciones especiales, el hecho de que

muchas empresas hayan decidido que su forma de competir no radica en hacer
de manera diferente las funciones básicas; su relativamente fácil integración
con sistemas de comercio electrónico, y, además, la posibilidad que estos sis-
temas proporcionan para integrarse con otros eslabones del sistema de valor
(clientes y proveedores), garantizan en cierto modo el futuro de estas aplica-
ciones.
Beneficios de los sistemas ERP
Las expectativas empresariales acerca de los beneficios que aportarán los sistemas
integrados y los ERP en particular suelen ser elevadas. La idea de integrar todos
los sistemas informáticos hace que las empresas esperen una mejora en la cantidad
y la calidad de información disponible y, en general, una mejora en los procesos
de negocio con repercusión positiva en la cuenta de resultados.
De la experiencia de los autores y de la literatura sobre el sector, de entre los
beneficios reportados por la instalación de sistemas de información integrados,
sean desarrollos propios o paquetes ERP destacan:
Control sobre la actividad de los diferentes departamentos de la empresa
Integrar los sistemas de los diferentes departamentos en uno único permite obte-
ner una visión global del funcionamiento de la empresa. Ello posibilita el desa-
rrollo de sistemas de costes que van a proporcionar una visión coherente de la
actividad de cada área funcional y su impacto en los costes totales y en la renta-
bilidad de la compañía.
Mejorar y acelerar los diferentes procesos de la empresa
Los sistemas integrados permiten estandarizar y automatizar los diferentes proce-

sos de la empresa, lo que supone un ahorro de tiempo y, en definitiva, un aumento
de la productividad. Si la empresa adopta un ERP contrastado en su sector y está
dispuesta a aceptar la estructura de procesos que lleva incorporado, estará adop-
tando los procesos considerados estándar en el sector; esto representa un avance
sobre una situación de evolución poco planificada en la que generalmente se en-
cuentran las empresas que se plantean su instalación.
Reducción de inventarios
La mejor gestión de la cadena de producción y una automatización de los procesos

productivos gracias a la implantación de un sistema integrado hace que éstos sean
más ágiles y flexibles. Ello acostumbra a traducirse en una reducción de inventa-
rio y en una ayuda para planificar eficientemente las posteriores entregas a los
clientes evitando así una masiva acumulación de producto en almacenes o en zo-
nas de carga.

Mejora del «time to market»
La integración de información se ha demostrado clave para acortar el tiempo que

tarda la empresa en llegar al mercado con nuevos productos o servicios, normal-
mente retardados por ineficiencias de comunicación.
Mejora del servicio a clientes
Integrar toda la información sobre la actividad de la organización, más allá de la

meramente contable, permite conocer de forma inmediata dónde y cómo se está
cursando un pedido en cada instante, lo que posibilita informar sobre su estado y
mejorar sustancialmente el servicio percibido por el cliente.
Estandarizar la información de Recursos Humanos
Es posible que en aquellas empresas que disponen de múltiples unidades de

negocio, el área de RRHH no disponga de una metodología unificada para con-
trolar a sus empleados y comunicarse con ellos de una manera fácil. De ahí
también la necesidad de un sistema de ERP que estandarice la información de
todos los empleados.
Otros beneficios que se desprenden de los anteriores, o que están en la base
de los mismos son:
z Disponer una base de datos accesible desde todos los departamentos.

z Permitir una respuesta más rápida a los cambios en el negocio y en el sector.
z Mayor precisión de la información y mejores formatos más fáciles de
visualizar y utilizar.
z Reducción de los documentos en papel, lo que permite evitar la pérdida
de algunos de ellos al moverse de un lugar a otro de la empresa.
z Acceso a información completa en tiempo real.
z Menor tiempo para realizar las transacciones.
z Estandarizar y acelerar los procesos de manufactura.
Costes de un proyecto de ERP
El coste en un proyecto de ERP varía mucho en función de la empresa, los

diferentes módulos que desee implantar y los requisitos del programa, por lo que
la estimación del coste de implantación no suele ser fácil. Sin querer entrar a
fondo en el análisis de costes de un proyecto de inversión, tratado en profundi-
dad en el Capítulo 8, es necesario tener en consideración algunos aspectos parti-
culares a los ERP, como (1) las funcionalidades básicas que ofrece cada provee-
dor, (2) las características tecnológicas del producto, (3) el servicio de soporte
que ofrece el proveedor, (4) su estrategia y viabilidad a medio y largo plazo, y
finalmente (5) el coste total del proyecto.
Las necesidades específicas de cada compañía son las que finalmente deter-
minan el alcance del proyecto, y el coste asociado a un proyecto de ERP varía

Mediana Media Mínimo Máximo

Baan
16,1 13,6 0,8 25,6
J. D. Edwards
3,9 5,7 0,8 21,6
Lawson
1,9 4,1 0,4 16,4
Oracle
5,4 11,2 1,4 42,8
PeopleSoft
7,4 15,5 1,3 58,6
SAP
13,9 52,2 0,8 308,2
SSA
1,7 7,6 0,7 29,6
Figura 4.5. Costes asociados a ERP de diferentes proveedores

(en millones de dólares).
(Fuente: APICS - The Performance Advantage, 1999.)
muy considerablemente en función del tamaño del proyecto final y del proveedor
escogido, tal como se detalla en la Figura 4.5, que muestra las conclusiones de un
estudio llevado a cabo en EEUU en 19991.
Un proyecto ERP típico incorpora cinco categorías de costes claramente de-
finidos: software, hardware (infraestructura), equipo de implantación, forma-
ción, y consultoría. A titulo de ejemplo la Figura 4.6 presenta el porcentaje de
coste en cada categoría en empresas manufactureras americanas2.
Además de estos costes, evidentes y fáciles de calcular, existen otros costes,
los denominados «ocultos» que en numerosas ocasiones suelen pasar desaperci-
bidos pero que en ningún caso se pueden desestimar. Algunos ejemplos son:
z Costes relacionados con la dificultad de integración del software en los

procesos de la empresa.
z Horas de entrenamiento de los usuarios, en las que no pueden atender sus
tareas habituales.
z Necesidades de análisis y conversión de datos.
z Posible pérdida de know-how como consecuencia de la dependencia de
consultores externos y un proveedor de la solución tecnológica.
z Horas no contempladas del equipo de implantación.
z La denominada «depresión post-ERP», que incluye los diversos proble-
mas de arranque inherentes a la nueva manera de hacer.
1
«ERP Implementation Study Reveals Costs, Benefits», APICS - The Performance Advantage,
Octubre 1999.
2
V. A. Mabert, A. Soni y M. A. Venkataramanan (2000), «Enterprise Resource Planning Survey
of U.S. Manufacturing Firms» Production and Inventory Management Journal, pp.52-58.

Software 30,2%
Consulting 24,1%
Hardware 17,8%
Equipo de implantación 13,5%
Formación 10,9%
Otros 3,3%
Figura 4.6. Componentes de coste de un proyecto ERP.

(Fuente: Mabert, Soni y Venkatraman, 2000.)
LA DECISIÓN DE IMPLANTACIÓN
DE UN ERP EN LA EMPRESA
Dada la complejidad de los paquetes de ERP, su instalación requiere grandes
inversiones en tiempo, dinero y experiencia. Implantar un sistema de estas ca-
racterísticas supone a menudo cambiar la organización, la cultura y, en ocasio-
nes, también podría llegar a tener un impacto sobre las posibles estrategias que
la empresa pueda seguir en el futuro. Empuja a la organización hacia la adapta-
ción de procesos genéricos aún cuando procesos más personalizados pueden ser
fuente de ventajas competitivas.
La implantación de SI desarrollados a medida permite a las empresas definir
previamente cómo desean que sea el negocio y, bajo esas condiciones, escoger o
diseñar el software que mejor se adapte a sus procesos. En contraste, implantar
un software de ERP puede suponer la modificación de los procesos de la empre-
sa para adaptarse (en parte) al nuevo sistema.
Por tanto, antes de tomar la decisión de implantar o no un ERP, el decisor
debe formularse la siguiente pregunta: ¿coinciden los requisitos funcionales de
la propia empresa con los del sistema?
Un ejemplo: Una empresa que fabrica unas determinadas máquinas-herra-
mienta acaba de diseñar una estrategia alrededor de su habilidad para ofrecer un
gran servicio a sus clientes, sirviendo de forma inmediata las piezas de recambio
necesarias para el mantenimiento. Es capaz de hacerlo un 25% más rápido que
sus competidores, lo que le ha reportado un mayor número de clientes y más
fieles, dispuestos a pagar un poco más por sus productos. Si la implantación de
un ERP supone un proceso más racional pero menos flexible, su fuente de ven-
taja competitiva puede desvanecerse. Es posible que la compañía consiga inte-
grar toda la información y mejorar sus procesos, pero si pierde su capacidad de

servir más rápido a sus clientes, la implantación del ERP habrá destruido su prin-
cipal ventaja competitiva.
Por este motivo es necesario, antes de implantar un sistema de estas caracte-
rísticas, tener claros el funcionamiento actual de la empresa y la estrategia del
negocio, y comprobar que la implantación del nuevo sistema supondrá una me-
jora de los procesos y no que, por el contrario, impedirá realizar funciones vita-
les para competir.
Hay que tener en cuenta, además, que prácticamente toda la organización e
incluso su cultura se podrán ver afectadas por el nuevo sistema. Una correcta
implantación empieza por mentalizar a todo el personal y permitir su participa-
ción durante todo el proceso. Es importante que puedan adaptarse al nuevo soft-
ware desde el primer día, puesto que son ellos quienes estarán en contacto direc-
to con el sistema. Por ello, una adecuada gestión del proyecto (que se describe
con mayor detalle en el Capítulo 10) es prerequisito imprescindible para una
implantación con éxito.
Pasos a seguir para implantar un ERP
Una vez decidido que se va a implantar un ERP, hay que analizar cuál es el
paquete de ERP más adecuado, y si se precisa de ayuda de consultores externos
para la implantación del mismo.
Para determinar el paquete más adecuado, hay que analizar en qué medida las
diferentes ofertas cubren las necesidades de la empresa, teniendo en cuenta su
calidad técnica, el coste económico, y posibles costes de cambio que implique la
adopción del paquete, tal como se analiza en profundidad en el Capítulo 8. Este
análisis se puede llevar a cabo desde el departamento TIC, aunque muchas veces
se confía a un consultor externo que tenga un conocimiento suficiente del mercado
y experiencia en diferentes tipos de implantación. El Anexo 1 describe somera-
mente la situación del mercado de proveedores de sistemas de ERP.
Una vez determinada cuál va a ser la solución tecnológica a implantar, es im-
portante determinar cuál es el grado de adaptación que la empresa está dispuesta a
asumir. Aunque los diferentes paquetes de software que existen en el mercado son
relativamente flexibles, siempre es necesario un cierto grado de adaptación. En
general, las adaptaciones mutuas –del ERP a la empresa estableciendo parámetros
e incluso elaborando software específico que realice funciones no previstas en el
ERP, y de la empresa a los procesos que especifica el software– se deciden con la
ayuda de un consultor externo con experiencia en el paquete a comprar, el sector
en que opera la compañía y, si es posible, en la propia empresa.
La elección de la empresa consultora que va a apoyar en todo el proceso es,
si cabe, más importante que la del propio ERP, ya que será la que contribuya a
diseñar las modificaciones y ayude en los momentos críticos de la implantación.
Muchas veces, la empresa cliente ya se ha apoyado en un determinado provee-
dor de servicios para la fase de diagnóstico, y este proveedor está bien posicio-
nado para la realización del trabajo posterior. No obstante, una práctica habitual
y que acostumbra a reportar buenos beneficios es solicitar propuestas de dos o
tres consultoras con experiencia en la implantación de ERP en el sector en cues-
tión. Aunque ello requiere dedicación por parte de personas con responsabilidad
en la empresa, el mero hecho de exponer los propios problemas a los proveedo-

res de servicios y de estudiar las consiguientes propuestas de solución ayuda a

entender el alcance del reto a que se va a enfrentar la organización.
Una buena elección del implantador no debe basarse únicamente en su cono-
cimiento de la funcionalidad del paquete ERP y en el currículo dentro del sector,
sino también en su capacidad demostrada de ayudar a transformar los procesos
existentes para conseguir los objetivos deseados. Desde el inicio y durante toda
la relación, el proveedor de software y el implantador deberán recomendar me-
joras de acuerdo con sus conocimientos sobre la empresa y los objetivos del
cliente. Por este motivo, es necesario que el implantador conozca con suficiente
profundidad la cultura y la estructura de la organización cliente.
En función de los objetivos fijados por la empresa, el proveedor de servicios
ha de ser capaz de orientar adecuadamente a todo el personal implicado en la
implantación a conseguir dichos objetivos, y de adecuar correctamente el soft-
ware. Asimismo, debe proporcionar información detallada de cómo será imple-
mentado el sistema y cómo funcionará una vez esté operativo.
Llevado a un extremo, se podría decir que el proyecto de implantación de
ERP puede ser el gran proyecto de sistemas que tendrá lugar en un número de
años, por lo que la elección del proveedor sin suficiente conocimiento tanto de
la tecnología como del sector o análogos es un riesgo que no se debe correr.
De este modo, por ejemplo, una empresa dedicada al alquiler de equipamiento
para la construcción (hormigoneras, herramientas de varios tipos, etc.) estaba im-
plantando un ERP que no disponía en su módulo de gestión de obras de la
capacidad de hacer el seguimiento de las herramientas alquiladas. El problema
estribaba en poder controlar la devolución y el estado de las miles de unidades
que el cliente se llevaba y facturar en función del tiempo y de las unidades que
no se devolvían. El implantador propuso a la organización cliente el desarrollo
de un programa específico que recibiría información del ERP, llevaría el control
y calcularía la facturación, y volcaría los resultados en el ERP. El presupuesto
del desarrollo era de varios cientos de miles de euros. El cliente, buscando una
alternativa más barata al implantador para encargarle el desarrollo específico,
encontró a una pequeña empresa informática, que contaba con una persona ex-
perta en todo tipo de implantaciones de este paquete de ERP. Éste resolvió el
problema en una tarde: usó el módulo del ERP destinado al control de envases
en depósito: si bien esta parte del ERP no contemplaba el alquiler masivo de he-
rramientas, sí tenía la funcionalidad necesaria para hacer el seguimiento de los
envases dejados en depósito, y trivialmente adaptado para que el «contenido» fue-
ra de valor cero, servía para controlar el movimiento de equipamiento, solucio-
nando de este modo el problema de forma simple, prácticamente sin coste, y con
sustanciales ahorros en el tiempo de implantación.
Una vez decidido quién se encargará de la implantación del ERP, es necesa-
rio determinar la estrategia a seguir. Como ya se ha comentado, los ERP están
basados en módulos, por lo que la elección de qué módulos implantar, la manera
en que serán personalizados y el orden en que serán puestos en operación son
elementos críticos de una buena implantación.
Un ERP puede ser implantado de muy diversas maneras. En un extremo pue-
de optarse por instalar módulos que pertenezcan a un único proveedor. En el otro
extremo estarían aquellas implantaciones que usan módulos de distintos provee-
dores, en una solución llamada «lo mejor de cada casa» (best of breed). Cada
estrategia tiene sus ventajas e inconvenientes: la implantación con múltiples

proveedores tecnológicos permite obtener la máxima funcionalidad para cada

módulo, acercándose a la flexibilidad de los desarrollos propios pero mante-
niendo las ventajas de los paquetes. Eso sí, la implantación es más compleja
dada la necesidad de diseñar y establecer interfaces para conectar módulos de
diferentes proveedores. Cuando se implantan módulos de un único proveedor,
tal vez no se pueda obtener la máxima funcionalidad en cada uno de ellos pero a
cambio se gana en sencillez de implantación. Asimismo, los sucesivos upgrades
de versiones se llevarán a cabo con más facilidad, ya que no cabe esperar dificul-
tades de integridad entre módulos.
La Figura 4.7 resume las estrategias más comunes empleadas en la implanta-
ción de sistemas integrados, con clara dominancia de los ERP «conectados» a
algunos programas que solucionan problemáticas muy específicas.
Según un estudio del Grupo Penteo (2002)3 las aplicaciones de ERP en las
empresas españolas dominan en las áreas de finanzas, compras, logística y pro-
ducción, mientras que la comercial utiliza principalmente el software a medida
y la de recursos humanos, aplicaciones estándar específicas. De acuerdo con el
mismo estudio, las compañías que tradicionalmente han iniciado la implanta-
ción del módulo de finanzas posteriormente han ampliado hacia otros módulos,
consiguiendo así un único sistema totalmente integrado.
Factores para una correcta implantación

Figura 4.7 : Diferentes alternativas de implantación de ERP
Después de todo lo mencionado, no cabe duda de que la implantación de un ERP
supone un proyecto de gran envergadura para cualquier organización. Artículos y
• Un único ERP combinado con otros sistemas

(programas propios de cada empresa, con 50%
funcionalidades muy específicas, etc.)
• Un único ERP para todas las funciones 39,8%
• Múltiples ERP combinados con otros sistemas

(programas propios de cada empresa, con 4,9%
funcionalidades muy específicas, etc.)
• “Lo mejor de cada casa” de entre varios ERP 3,9%
• Aplicación desarrollada internamente en conjunción

1%
con otros programas para funcionalidades específicas
• Aplicación desarrollada internamente para todas

0,5%
las funciones
Figura 4.7. Diferentes alternativas de implantación de ERP.

(Fuente: Mabert, Soni y Venkatramanan, 2000.)
3
Grupo Penteo (2002), Aplicaciones Corporativas: Situación en España y tendencias futuras.

documentos difundidos en diversas revistas especializadas han resaltado el fracaso

de conocidas empresas a la hora de implantar un sistema de este tipo, señalando
como causas más comunes el incremento de los costes y el tiempo previstos, aun-
que en algunas ocasiones también se ha aducido a la falta de funcionalidad. Es
esencial pues planificar y dirigir convenientemente dicha implantación.
Los factores clave para una correcta implantación de ERP son relativamente
parecidos a los descritos en el Capítulo 3 para la planificación de sistemas, aun-
que presentan algunas peculiaridades, de las que merecen ser destacadas las
siguientes.
Alineamiento entre los procesos de negocio y las funcionalidades del ERP
En muchas ocasiones los directivos eligen la implantación de un ERP sin tener

completamente claras las funcionalidades y limitaciones del mismo. Es estricta-
mente necesario definir la estrategia de negocio y examinar los procesos actua-
les antes de implantarlo, lo que permitirá, además, transmitir a los proveedores
de software una mayor visión del negocio que ayudará a un mejor encaje con los
requerimientos del sistema.
Participación de los directivos
La implantación de un ERP requiere una inversión elevada y un alto nivel de

compromiso. Por este motivo, es necesario que los directivos estén completa-
mente involucrados, que establezcan claramente las prioridades estratégicas de
la organización y que involucren a los diferentes ejecutivos de las funciones de
negocio afectadas.
Escoger el equipo apropiado
Es necesario un equipo de implantación multifuncional para definir con detalle la

manera de llevar a cabo la implantación, decidiendo los módulos y procesos a
poner en funcionamiento. En los casos más habituales, suele existir un director de
proyecto con un elevado conocimiento de los diferentes procesos de la empresa, y
un equipo formado por una combinación de personal con conocimientos sobre el
negocio, los procesos y los productos que se verán afectados por el nuevo sistema.
Este equipo interno deberá tratar a diario con los consultores (ver el siguiente
punto) para evitar que el proyecto se aleje de los resultados deseados.
Selección y gestión de los consultores
Es preciso asegurarse de que los consultores contratados tengan experiencia en

el sector de actividad de la empresa y entiendan claramente el objetivo deseado.
Las líneas de trabajo de los consultores deben estar claramente definidas. Es
necesaria la transferencia continua de su conocimiento a los expertos internos,
para que tanto la configuración del sistema como su mantenimiento puedan rea-

lizarse sin problemas. Además, es aconsejable mantener un cierto equilibrio entre

personal interno y consultor externo en el equipo global, para asegurar que el co-
nocimiento específico de la realidad empresarial concreta esté presente en todas
las fases del proyecto.
Disponer de una metodología clara de implantación
Es necesaria una guía para implantar de forma correcta un ERP basada en la estra-
tegia, en el personal y en el proceso, y que se siga desde la identificación de las
necesidades para implantarlo hasta las mejoras en la post-implantación. La mayor
parte de los errores observados se podrían haber evitado con el uso de una buena
metodología. Además, es esencial percibir el proyecto de implantación de un ERP
como un proyecto de empresa y no como un proyecto exclusivo del departa-
mento TIC. Para ello debe recibir el apoyo necesario de toda la organización, que
debe ser consciente de la magnitud del proyecto y de su repercusión en todos los
ámbitos de la actividad empresarial.
Involucración y formación de los usuarios desde el inicio
La implantación de un ERP cambiará, como mínimo, la forma de introducir, ad-

ministrar y acceder a los datos en cada departamento, por lo que los usuarios
finales deben estar familiarizados con el nuevo sistema desde el primer momen-
to: se les debe comunicar cómo modificará el ERP las prácticas habituales en la
empresa, convencerles de que el nuevo sistema será fácil de usar y mejorará el
actual, y permitir la aportación de sugerencias durante todo el proceso. En algu-
nas empresas, ciertos departamentos se manifiestan en contra de un cambio en
sus actuales roles, mayoritariamente en aquellos cuyos directores tengan gran
antigüedad en la organización y estén habituados a una metodología concreta.
La implantación de un ERP significa con frecuencia redefinir los roles de gran
parte del personal de la empresa, principalmente de los directivos, para adaptar-
los a un sistema mucho más integrado, accesible a todos y con una base de datos
útil en todas las áreas funcionales.
Mejora continua y mantenimiento de la funcionalidad
Finalmente, cualquier proyecto de implantación de un ERP debe contemplar la

posibilidad de mejora continua, por lo que es imprescindible contar con una
estrategia de salida de los consultores, contando con un equipo permanente con
capacidad para el mantenimiento y mejora del sistema implantado.

Como todo sistema de información, la selección, parametrización e implantación
de un software de ERP no es únicamente un proyecto tecnológico sino también, y
fundamentalmente, un proyecto de empresa. Además de la instalación del propio

software, la implantación supone ciertos cambios en la organización, lo que impli-

ca tener muy en cuenta el factor humano en todos los departamentos, no única-
mente en el de departamento TIC.
Por ello, es importante que tanto la alta dirección como la dirección del
proyecto de la implantación del ERP tenga en mente los siguientes aspectos
críticos:
z Coordinación de la dirección del proceso de acuerdo con la estrategia

de la empresa. Hay que asegurar que el proceso y las implicaciones para
las diferentes partes implicadas se hayan explicitado.
z Análisis de la adecuación de la solución, dada la estrategia de negocio.
Aunque son pocos los casos que se conocen, existe evidencia empírica de
que algunas implantaciones no llegan a buen puerto debido a la imposibi-
lidad de cubrir suficientemente los requisitos de la empresa. Un ejemplo
es el de la implantación de un ERP en Dell Computers4. En 1996, después
de haber implantado tan sólo el módulo de Recursos Humanos, el direc-
tor de Sistemas, Jerry Gregoire, decidió parar el proceso por considerar
que un gran paquete estandarizado no podría soportar el crecimiento fu-
turo previsto de la compañía (de mil millones de dólares cada 6 a 8 sema-
nas). Alternativamente, la empresa diseñó un sistema con una arquitectu-
ra de middleware flexible que le posibilitaba añadir o substraer rápidamente
todo tipo de aplicaciones.
z La implantación de un ERP implica una equiparación sectorial. Al ho-
mogeneizar los procesos, los paquetes estándar permiten una diferencia-
ción relativamente menor de las empresas respecto a su competencia
mediante su sistema de información. Por esta razón, en aquellos casos en
los que el SI de una empresa resulta crítico para competir, como se ha
visto en el caso de Dell, muchas veces un sistema ERP no es la solución
más adecuada.
z Análisis de los procesos en profundidad. La falta de un análisis riguroso y
la consiguiente uniformizacion y adaptación de los procesos a los reque-
rimientos de la solución a implantar muchas veces conlleva una serie de
problemas, especialmente en términos de tiempo, coste y aceptación del
proyecto por parte de los usuarios, en fases posteriores de la implanta-
ción.
z Preparación adecuada del equipo de implantación. Al ser un proyecto
complejo, que involucra tanto personal de la casa como consultores ex-
ternos, el modo de funcionamiento tiene que ser explícitamente estable-
cido para evitar problemas. Además, hay que tener en cuenta que parte
del equipo suele ser de personal ajeno al departamento de Sistemas, por
lo que una comunicación fluida y buen trabajo conjunto es esencial.
z Estimación inicial de costes completos del proyecto y control de los mis-
mos durante la implantación. Muchas veces este tipo de implantaciones
acaban con incrementos sustanciales respecto al coste inicialmente pre-
visto. Éste suele ser consecuencia de la no contemplación de algunos
4
Slater, Derek (1999), «An ERP package for You… and You… and You … and Even You», CIO
Magazine, February 15, 1999.

costes ocultos (normalmente indirectos del departamento de Sistemas) como

los mencionados en un apartado anterior en este capítulo, o bien debido a
que aparecen problemas no anticipados en alguna de las etapas de la im-
plantación5.
z Prever la necesidad de expertos no disponibles internamente. Dada la
complejidad de la tecnología, puede darse el caso en el que para la reso-
lución de problemas puntuales se requiera la ayuda de un experto, más
allá del personal externo ya contemplado en el proyecto inicial.
z Gestión de las relaciones con el proveedor de software y el consultor de
implantación. Al contratar una solución de un proveedor de software que
es parametrizado por un consultor externo, se crea una relación de depen-
dencia a largo plazo, ya que el funcionamiento con un paquete ERP im-
plicará el pago de licencias y de cánones de mantenimiento, cuyo impac-
to económico muchas veces es difícil de estimar completamente a la hora
de tomar la decisión de la inversión. Además, futuras versiones del mis-
mo software pueden requerir nuevas adaptaciones a la realidad de la em-
presa, creando también dependencia con el consultor externo. Todo ello
hace que se tenga que crear un clima de colaboración y confianza que
permitan acomodar eventuales cambios futuros.
ANEXO 1: PRINCIPALES PROVEEDORES DE ERP

La decisión de implantar un ERP viene influenciada también por la oferta dispo-
nible en el mercado. El fuerte auge de estas aplicaciones tanto en Europa como
en el resto del mundo hace aumentar cada vez más el número de proveedores.
Esta sección repasa los líderes del mercado y presenta sus características más
representativas.
Según el Grupo Penteo (2002), SAP es el primer proveedor de ERP en Euro-
pa con un 32% de la cuota de mercado, seguido de Oracle con un 15%. También
es SAP quien lidera el mercado español con presencia en un 62% de las empre-
sas que han instalado ERP. La Figura 4.8 presenta los datos de participación de
mercado de las empresas líderes.
Descripción de los principales proveedores
z SAP. Esta empresa alemana con sede en Walldorf, líder en soluciones ERP
cuenta en 2004 con 79.800 instalaciones que prestan servicio a 12 millones
de usuarios de 23.400 empresas en 120 países de todo el mundo. Se ha
convertido en la tercera empresa de software del mundo. SAP tiene más de
28.900 trabajadores en más de 50 países, con un volumen de facturación de
7.400 millones de euros en 2002. El paquete básico cuenta con módulos
adaptados a multitud de sectores y además dispone de extensiones que pro-
porcionan sistemas de información para ejecutivos (EIS) y de relaciones
5
Los Capítulos 8 y 9 se dedican en profundidad al análisis de inversiones en SI y a su medición
y control, respectivamente.

Figura 4.8: El mercado de ERP en Europa y España
Cuota de mercado Presencia en las empresas

Proveedor Proveedor
(Europa) españolas
SAP 32% SAP 62%
Oracle 15% J. D. Edwards 8%
PeopleSoft 9% Movex 7%
J. D. Edwards 5% Baan 5%
Geac Computer 3% Ross 4%
Otros 36% Oracle 3%
Otros 11%
Figura 4.8. El mercado de ERP en Europa y España.

(Fuente: Grupo Penteo, 2002.)
con consumidores bajo el formato denominado de «inteligencia de nego-

cio». Debido a su alta implantación, en esta obra se describe la estructura
de los sistemas ERP usando el ejemplo de SAP R/3. Esta descripción puede
verse en el Anexo 2 de este capítulo.
z Oracle. Es líder en el mercado de sistemas de bases de datos con 120.000
clientes en todo el mundo y ofrece soluciones en el ámbito de ERP
desde 1993. Las ventas totales de su división de software en 2004 han
sido de 8.070 millones de dólares, de los cuales un 18% son del merca-
do ERP. Desde entonces, se ha convertido en la segunda mayor compa-
ñía de ERP. con más de 7.000 clientes y 11.500 instalaciones a nivel
mundial. Además la empresa se caracteriza por la innovación constan-
te, con un presupuesto de I&D superior a 1.000 millones de dólares. A
principios de 2005, Oracle ha obtenido el permiso de las autoridades de
vigilancia de la competencia para finalizar la compra hostil de su rival
PeopleSoft.
z PeopleSoft. Adquirida por Oracle en 2005, fue fundada en 1987 con el
objetivo de ofrecer software en entornos cliente-servidor para gestionar
las funciones de recursos humanos, posteriormente aumentó su
funcionalidad a aplicaciones para gestión de inventarios, distribución, fi-
nanzas y fabricación. La compañía cuenta con 2.900 clientes y unos 2.200
vendedores propios. Las últimas versiones de PeopleSoft han centrando
su estrategia en Internet, habilitando su ERP para funcionar sobre la red y
ofreciendo funcionalidades para el comercio electrónico.
z J. D. Edwards. La compañía fue fundada en marzo de 1977 en Denver,
EEUU, y desde sus inicios siempre ha estado orientada a pequeñas y

medianas empresas. Cuenta en la actualidad con más de 4.700 clientes en

todo el mundo.
z Geac. Con un 5% del mercado europeo de ERP, Geac emplea a 3.350
personas en 65 países. Además de su ERP, Geac ofrece soluciones secto-
riales en bienes inmuebles, gestión de propiedades, hostelería, construc-
ción, librerías y mercados de seguros públicos.
ANEXO 2: SAP (SYSTEMANALYSE

UND PROGRAMMENTWICKLUNG) R/3
La empresa fue fundada en 1972 por cinco ingenieros de sistemas de IBM en
Mannheim, Alemania, movidos por el deseo de desarrollar y comercializar un
software capaz de integrar los diferentes procesos de la empresa. El objetivo era
que la información fuese accesible a todos y en cualquier momento en las pro-
pias pantallas del ordenador, sin necesidad de documentos escritos. Pasaron 18
años hasta que estas ideas se hicieron realidad. La empresa, ahora con sede en
Walldorf, Alemania, salió a bolsa en el año 1988 y actualmente cotiza en varios
mercados de valores, incluyendo la Bolsa de Francfort y la de Nueva York, don-
de lo hace bajo el símbolo «SAP».
SAP R/3 es el paquete estándar de ERP más implantado en el mundo. Desde
su presentación en 1992 supuso una auténtica revolución en el mundo de los
sistemas de información, debido a que fue el primer paquete estándar pensado
para una arquitectura cliente/servidor. En febrero de 2004 SAP anunció el fin de
un ciclo, al parar sus ventas de R/3 aunque continuará dando soporte hasta el
primer trimestre de 2009.
La Figura 4.9 muestra el esquema utilizado por SAP para describir sus dife-
rentes módulos. Existen tres módulos funcionales en SAP R/3: Logística y Ope-
raciones, Gestión Financiera y Recursos Humanos, y dentro de ellos se engloban
una serie de «submódulos» que pueden implantarse a discreción.
Veamos una breve descripción de cada uno de ellos.
Logística y operaciones
En las aplicaciones de este módulo está contenido el motor del sistema logístico
de SAP R/3, que proporciona herramientas para analizar y gestionar el estado de
la logística de la compañía y realizar previsiones en la cadena de suministro.
Dentro de este módulo funcional están incluidos los siguientes submódulos:
z SD (Sales & Distribution, Ventas y distribución). Los distintos componen-

tes del módulo SD permiten gestionar todos los aspectos de las actividades
comerciales de la empresa: pedidos, promociones, competencia, ofertas,
seguimiento de llamadas, planificación, campañas, etc. Los clientes se
benefician al obtener un mejor y más rápido servicio, pudiendo recibir
confirmación directa de sus pedidos por fax, acceso web, correo, EDI, etc.
En el módulo SD se pueden definir y controlar las estructuras de precios y,
al estar integrado en un único sistema con la contabilidad y el control, las
cuentas a cobrar y la facturación se actualizan de forma inmediata.

Co S D FI n
me ó
rci e sti ra
a l G ncie
a
Ma MM fin
te r CO lling
ial o
e s ntr
Pr Co
od P P s
uc AM Fijo
ció o s
n tiv
Ac
SAP
R/3
Pr PS
QM a d oy
ec
lid tos
Ca
to Wo WF
PM ien rkf
n im l ow
nte
Ma H R so s
So
l
IS
r se ucio
ec u os cto ne
R m an ria s
Hu les
Figura 4.9. Módulos de SAP R/3.

(Fuente: Elaboración propia a partir de información en www.sap.com.)
z MM (Materials Management, Gestión de materiales). Se engloban todas

las actividades y funciones logísticas relacionadas con el aprovisiona-
miento (compras) y el control de la cadena de suministro.
z PP (Production Planning, Planificación de la producción). Los procesos
de control y planificación de la producción son una parte fundamental
dentro de las aplicaciones logísticas de SAP R/3. Existen funciones para
las diferentes fases, tareas y metodologías utilizadas en la planificación,
además de para el propio proceso de la producción.
z PS (Project System, Sistema de proyectos). Permite realizar el seguimiento
y la coordinación de todas las tareas de un proyecto a lo largo de todas las
fases de su ciclo de vida. Se puede aplicar a todo tipo de proyectos: inver-
sión, marketing, I+D, construcción de instalaciones, etc.
z QM (Quality Management, Gestión de la calidad). El sistema SAP R/3
incluye un control de calidad de aquellas áreas de negocio de cuyos pro-
cesos son responsables, como por ejemplo, la producción, el control de
costes, procesos de ventas, gestión de materiales, etc., encargándose de
tareas que implican la planificación de la calidad, el control, las inspec-
ciones y el cumplimiento de los estándares de calidad normalizados
internacionalmente.

z PM (Plant Maintenance, Mantenimiento de planta). Es el módulo encarga-

do del mantenimiento de los sistemas de planta. Permite disponer de repre-
sentaciones gráficas de las plantas de producción, pudiéndose conectar con
sistemas de información geográfica (GIS). El sistema de información per-
mite identificar fácilmente los puntos débiles y planificar el mantenimien-
to preventivo.
z SM (Service Management, Gestión de servicios). Permite una integra-
ción del sistema con todo aquello relacionado con el servicio a clientes.
z PDM (Product Data Management, Gestión de la información de produc-
to): Ayuda al control y gestión de todos los datos relacionados con un
cierto producto durante todo su ciclo de vida.
Recursos Humanos
Incluye todos los procesos de negocio necesarios para controlar y gestionar las
necesidades de recursos humanos de la empresa (gestión de candidatos a puestos
de trabajo, elaboración de nóminas, desarrollo de personal, etc.). Los datos es-
tán disponibles de forma inmediata para cualquier otra aplicación relacionada,
simplificando, por ejemplo, la contabilidad de las nóminas. Está formado por
los módulos: PM (Personnel Management, Gestión de personal), para adminis-
tración del personal de la empresa; OM (Organizational Management, Gestión
de la organización), empleado para el control de la estructura de la empresa; PA
(Payroll Accounting, Gestión de nóminas); TM (Time Management, Gestión del
tiempo), provee de recursos para el seguimiento y análisis de los tiempos de los
empleados; PD (Personnel Development, Desarrollo personal), asiste en la pla-
nificación, monitorización y análisis de seminarios, cursos de formación, reser-
vas de alojamientos, etc.
Gestión financiera
Conjunto de aplicaciones para controlar el aspecto operativo de la contabilidad,

así como para proporcionar información financiera de la empresa.
z AM (Asset Management, Gestión de activos). Es el módulo para gestio-

nar los activos fijos.
z FI (Financial Accounting, Control financiero). Permite gestionar todo lo
relativo a la contabilidad de la compañía.
z CO (Cost Control, Control de costes). El módulo CO se utiliza para re-
presentar las estructuras de costes de las empresas y los factores que tie-
nen influencia en los mismos. Las funciones de este módulo incluyen
áreas tales como el control de costes (internos, de producción, de produc-
tos...) y análisis de rentabilidad.
z IM (Investment Management, Gestión de inversiones). Ofrece una ges-
tión integrada de medidas de las inversiones y proyectos varios.
z TR (Treasury, Gestión de tesorería). Solución para la gestión de la tesore-
ría que permite controlar la liquidez a escala mundial de la compañía, es-
tructuras, activos financieros, beneficios,… minimizando riesgos.

z EC (Enterprise Controlling, Control de la empresa). Es el módulo más «es-

tratégico», y monitoriza de forma continua los factores definidos como
de éxito de la compañía y los indicadores de rendimiento de acuerdo a las
instrucciones que se especifiquen.
Aunque la nomenclatura que se ha usado para este conjunto de módulos es

exclusiva de SAP, todos los paquetes ERP del mercado presentan una estructura
similar. Sin embargo, cada empresa es diferente, por lo que no será lo mismo
implantar el mismo módulo en una que en otra. Aunque el ERP obliga a adaptar
la empresa al sistema (más que el sistema a la empresa), todos los proveedores
ofrecen múltiples herramientas para «personalizar» el producto en función de
los sistemas informáticos de las organizaciones.

Sistemas de información para la gestión de la cadena de suministro 81
5
Sistemas de información
para la gestión de la cadena
de suministro
Los sistemas de gestión integrados del capítulo anterior se enfocan casi por de-
finición a las actividades internas de la organización. Pero una gestión óptima de
la empresa pasa también por una adecuada coordinación con sus partners en los
negocios, especialmente con sus proveedores y clientes. Los sistemas de infor-
mación diseñados específicamente para sobrepasar los límites de la propia orga-
nización, enlazándose con los sistemas de los clientes y proveedores, son los
denominados sistemas de gestión de la cadena de suministro, Supply Chain
Management Systems (SCM) en inglés.
¿QUÉ ES LA CADENA DE SUMINISTRO?

La cadena de suministro (Supply Chain) se define como el conjunto de proce-
sos a través de los cuales fluyen los productos desde los proveedores hasta los
clientes finales, pasando por la propia empresa, por almacenes propios o ajenos,
distribuidores, etc. Esta definición se completa incluyendo la parte más «diná-
mica» de la cadena, que va más allá del mero flujo de materiales: los servicios,
el dinero y, por supuesto, información.
La cadena de distribución norteamericana Wal-Mart representa el paradigma
del concepto gestión de la cadena de suministro en su acepción actual, por la
manera como enlaza lo que sucede en las estanterías de sus tiendas con sus
órdenes de reposición, sus pedidos a proveedores y con la correspondiente ges-
tión administrativa de todo ello. Algunos de sus proveedores incluso llegan a
tener automáticamente conectado su propio proceso producción –y la consiguiente
compra de materias primas– con los sistemas de información de Wal-Mart; en el
extremo de la cadena siempre está el cliente final, que desencadena todo este
proceso cada vez que se lleva un producto de la tienda. Su principal distribuidor,
Procter & Gamble (P&G), tiene acceso a todas las ventas que Wal-Mart realiza
de sus productos. P&G almacena diariamente en su base de datos la información
procedente de todos los establecimientos Wal-Mart, de forma que puede cono-
81

cer en todo momento cuando un determinado producto está a su límite de stock.

Así, P&G sabe cuándo y cuánto tiene que producir y cómo distribuir los produc-
tos a Wal-Mart para minimizar las roturas de inventario y los costes de todo el
sistema. Como es de suponer, este entramado de sistemas de información inclu-
ye también los sistemas de los proveedores de servicios logísticos, transporte,
etcétera. Además, la información en tiempo real sobre movimientos de produc-
tos en las tiendas permite a P&G calibrar el efecto inmediato que tienen las
acciones publicitarias, propias o de la competencia.
Los sistemas de información enlazados son, pues, el elemento central de la
gestión de la cadena de suministro. Como se verá más adelante, la decisión de
instalar un sistema SCM compete a más de una empresa, y su éxito dependerá de
la voluntad de las diversas organizaciones para adaptarse unas a otras y compar-
tir información.
Es esencial entender que el estudio de la cadena de suministro de una empre-
sa requiere del estudio de todas las organizaciones implicadas en la producción
de un determinado bien o servicio y de todas sus etapas. Podríamos definir la
cadena de suministro como una red compuesta por las cadenas de las distintas
empresas que participan en el proceso de producción.
De acuerdo con lo anterior, podemos establecer los cuatro eslabones prin-
cipales de toda cadena de suministro: proveedores, producción, distribución y
clientes.
z Proveedores: Están al principio de la cadena de suministro. Según el tipo

de empresa y el producto que elabore, el entramado de proveedores pue-
de llegar a ser bastante complejo. Una empresa que fabrica coches, por
ejemplo, obtiene los asientos de un proveedor que se abastece, a su vez,
de otros proveedores que le proporcionan la tela y los componentes nece-
sarios para confeccionar el asiento, y así sucesivamente.
z Producción: Una vez que la empresa dispone de la materia prima y los
componentes necesarios, comienza el proceso de producción que los trans-
formará en el producto final. Dentro de éste deben incluirse todos aque-
llos procesos relacionados con el empaquetamiento y almacenamiento de
los productos acabados.
z Distribución: Es la parte de la cadena de suministro relacionada con el
transporte y la entrega del producto a los clientes. En muchas ocasiones
se utiliza la palabra logística para referirse a esta etapa de la cadena.
Evidentemente existe la posibilidad de que el producto no se entregue
directamente al cliente final y de que existan varios intermediarios de por
medio.
z Clientes: Son el último eslabón de la cadena; en productos de consumo
los clientes son los consumidores finales. Aunque la empresa no les ven-
da directamente a ellos, un estudio de la cadena de suministro no estará
completo hasta que contemple todos los procesos que permiten que el
producto llegue al usuario final.
La Figura 5.1 presenta una cadena de suministro muy simple de dos niveles.
Podríamos decir que se trata de una cadena tradicional. El flujo de materiales
circula de izquierda a derecha (o aguas abajo) y el monetario en sentido contra-
rio (aguas arriba), mientras que el de información lo hace en ambos sentidos.

Proveedores Fabricantes Distribuidores Vendedores Clientes
Figura 5.1. Flujos simplificados en una cadena de suministro.
Desde el punto de vista del fabricante, podemos distinguir:
1. La cadena de suministro aguas arriba: incluye a los proveedores de pri-

mer nivel (que a su vez pueden ser fabricantes) y se remonta hasta los
proveedores de las materias primas más elementales.
2. La cadena interna (no detallada en la figura): enlaza los almacenes pro-
pios con los procesos de fabricación dentro de la empresa. Controla los
flujos de materiales en diferentes estadios de producción.
3. La cadena de suministro aguas abajo: engloba todos los procesos relacio-
nados con la distribución del producto hasta el cliente final. Siendo ex-
haustivos, deberíamos incluir el proceso de deshecho de los envoltorios y
del propio producto ya que, de alguna manera, el análisis de la cadena de
suministro se corresponde con el análisis del ciclo de vida completo de
un producto.
La linealidad de la exposición anterior se pierde cuando consideramos, como

en la Figura 5.2, una empresa que es simultáneamente cliente y proveedora de
una tercera. En estos casos las cadenas de suministro se complican y se convier-
ten en «redes de suministro», aunque en general se mantiene la denominación de
«cadena de suministro».
La cadena de suministro es un complejo entramado en el que pueden interve-
nir un número elevado de empresas. Y su gestión, un proceso complejo en el que
las decisiones de suministro se toman con información proveniente de todas
ellas, independientemente de su localización geográfica.
¿Por qué preocuparse de las cadenas de suministro?
La necesidad de gestionar adecuadamente la cadena de suministro y de disponer

de información relativa a todo el proceso queda ilustrada en el siguiente ejem-
plo. Imaginemos un simple sistema de fabricación-distribución-producción de
un único producto en el que participan cuatro agentes: un fabricante, un distri-
buidor, un mayorista y un detallista que sirve al mercado. Supongamos también
que la comunicación entre los diferentes jugadores se limita a los pedidos que

Proveedores Distribuidores
Vendedores
Fabricantes
Mercados
Intercambios
proveedores Mercados
logísticos
Clientes
Fabricantes Fabricantes
bajo encargo virtuales
Proveedores
logísticos
Figura 5.2. Flujos habituales en una «red de suministro».
reciben de su cliente inmediato y a los que ellos efectúan a su proveedor, y que

entre la formulación del pedido y la recepción del mismo transcurre un lapso de
tiempo. La evolución de los pedidos a lo largo de la cadena de suministro sería
como en la Figura 5.3.
La línea de mercado muestra la demanda del mercado, más o menos estable
aunque sujeta a mínimas variaciones. La línea de producción muestra la produc-
ción que realiza el fabricante –cuatro etapas más allá en la cadena de suministro–
para satisfacer dicha demanda. Cuando la única información que una empresa tie-
ne sobre el mercado son los pedidos de su cliente adyacente en la cadena y debe
servirse del stock disponible, tiende a producirse un efecto amplificador: peque-
ñas diferencias en la demanda final se traducen en enormes variaciones aguas arri-
ba. Este efecto, denominado efecto latigazo en la literatura de producción, es debi-
do a la falta de información más allá de la siguiente etapa de la cadena y se ha
observado de manera dramática en sectores tan diversos como los pañales, la elec-
trónica, y los juguetes.
El efecto latigazo se explica por la confluencia de dos factores: la imprevisi-
bilidad de la demanda y la falta de comunicación entre las diferentes etapas de la
cadena de suministro. Son muchos los motivos que afectan la variabilidad de la
demanda; destacan las variaciones de precio no esperadas (por ejemplo en com-
bustibles), las promociones realizadas por el canal de distribución (que propi-
cian un almacenamiento por parte de los clientes fácilmente malinterpretable
por mayoristas y fabricantes como un incremento real de demanda), una supues-
ta escasez futura, etc. Todos estos factores pueden hacer que no se aprovechen y
optimicen los recursos de que dispone la organización, causando variaciones en
la producción, excesos de inventario, o variaciones en los pedidos. Dado que
evitar las variaciones en demanda es difícil, las empresas deben prevenir en lo

Figura 5.3. Unidades pedidas al proveedor inmediato cuando

únicamente se observa la demanda del cliente directo.
posible el efecto latigazo con información exacta acerca de la realidad más allá
de su cliente inmediato, es decir, con una gestión completa de la cadena de sumi-
nistro.
GESTIÓN EFECTIVA DE LA CADENA DE SUMINISTRO

De las explicaciones anteriores se desprende que la gestión efectiva de la cadena
de suministro consiste en llevar a cabo una serie de actividades necesarias para
integrar de forma eficiente a proveedores, centros de producción, almacenes y
detallistas, con el objetivo de que la mercancía se produzca y distribuya en las
cantidades correctas, a los lugares adecuados y en el tiempo deseado al mínimo
coste y satisfaciendo los niveles de servicio requeridos.
Desarrollo y evolución de la gestión de la cadena de suministro
Actividades relacionadas con lo que hoy llamamos gestión de la cadena de su-

ministro existen desde hace muchos años, aunque su formalización y concreción
bajo las siglas SCM se popularizó hacía los años ochenta.
Los primeros pasos en la gestión de la cadena de suministro los podemos
situar alrededor de la década de los sesenta, cuando bajo el concepto de «distri-
bución física» se planteó el objetivo de gestionar los inventarios a través de un
conjunto de actividades interrelacionadas que aseguraran la distribución eficien-
te de los productos acabados a los clientes. Eran muchas las empresas que entre
1960 y 1970 dirigían sus objetivos hacia la distribución física.

Poco a poco, la necesidad de ampliar la gestión más allá de la distribución hizo

que apareciera el concepto «gestión de logística integrada», que no sólo incluía la
gestión de la distribución física de la producción, sino también la gestión de las
entradas de materiales.
A principios de los ochenta, la voluntad de controlar todo el proceso de pro-
ducción, enlazándolo convenientemente con proveedores y clientes y poniendo
más énfasis en los flujos de información y de dinero, motivó el desarrollo de los
primeros sistemas formales de «gestión de la cadena de suministro». Estos siste-
mas, a su vez, favorecieron el desarrollo de sistemas de producción más avanza-
dos como just-in-time y kanban.
Desde el punto de vista de las TIC, la evolución de sistemas formales de
gestión de la cadena de suministro supuso evidentemente el desarrollo de siste-
mas de información capaces de no sólo gestionar internamente la información
necesaria, sino también de intercambiar información con empresas clientes y/o
proveedoras. Ello conllevó a una evolución de los SI, que tenían que ayudar a
transformar «empresas aisladas» en «empresas interconectadas.» Este proceso
se ilustra de forma esquemática en la Figura 5.4, que muestra las diferentes
etapas de esta transformación en términos de algunas de las tecnologías y fun-
cionalidades básicas requeridas de los SI que permiten el SCM.
De este modo, inicialmente las empresas se enfocaban en sus propios siste-
mas y desarrollaban programas a su medida para gestionar la cadena interna con
independencia de sus proveedores y/o clientes. Disponían de herramientas par-
ciales y fragmentadas, lo que obligaba a adoptar un planteamiento excesivamen-
te estático e incapaz de responder con rapidez a las necesidades del mercado.
Con el tiempo, la necesidad de intercambiar documentos como pedidos y factu-
ras de forma eficiente llevó al desarrollo de los sistemas de intercambio electró-
nico de datos EDI (Electronic Data Interchange).
Estos sistemas fueron ideados para llevar a cabo la automatización de las
transacciones y los procesos que tienen lugar en la cadena, pero sin la ambi-
ción de ayudar a gestionar mejor. Simplemente pretendían automatizar de
manera fiable las transacciones entre diferentes empresas. La mejora en las
herramientas de gestión tipo ERP (descritas en el capítulo anterior) y el desa-
rrollo de nuevos canales de comunicación permitieron una integración cada
vez mayor de todos los componentes de la cadena, desde proveedores hasta
clientes, haciendo posible optimizar todo el sistema como si de una única
empresa se tratara.
La Figura 5.5 presenta de forma esquemática la evolución de los sistemas
interempresariales.
Beneficios de los sistemas SCM
Aun con el riesgo de generalizar, y teniendo en cuenta que el éxito de un sistema

SCM depende siempre de su correcta implantación, podemos destacar de entre
sus beneficios los siguientes:
z Mejora del servicio al cliente: recibe los productos que desea en el mo-
mento en que los necesita y, potencialmente, a un mejor precio.
z Reducción de las ventas perdidas.

Figura de
Sistemas 5.4: Evoluciónpara
información de los Sistemas
la gestión de laSCM
cadena de suministro 87
Interconexión de empresas
Internet (banda ancha)
B2B, Marketplaces
Comunidades y clusters de
empresas y usuarios
XML+EAI
Conexión permanente con

proveedores y clientes
Integración total en aplicaciones
Negocio no presencial
Montaje y desmontaje continuo de
redes
SCM+CRM
Internet
Empresa con SC integrada

XML
Capaz de integrar relaciones

con proveedores y clientes
Empresa con “trading partners” Capacidad de diferenciar la
Se relaciona con unos información de los datos y
“partners” seleccionados planificar
Punto a punto
Programas preparados para

intercambiar transacciones
ERP
EDI
Empresa aislada
Enfocada a sí misma
Programas a medida
Sin conexión
Pasado Presente Futuro
Figura 5.4. Evolución de los Sistemas SCM1.

(Fuente: CIIL, 2002.)
Integración con
cualquiera
SCM
Integración con
nuestros
“partners”
Integración en
toda la empresa
Integración entre
departamentos
Aplicaciones
independientes
Pasado Presente Futuro
Figura 5.5. Evolución de los sistemas interempresariales.
1
Fuente: Centro Internacional de Investigación Logística del IESE (CIIL) - «Estudio de la Ges-
tión de la Cadena de Suministro en España», 2002.

z Reducción de los costes de mantenimiento y depreciación del inventario.

z Mejora en el flujo de caja por entregar y facturar antes los pedidos.
z Reducción del coste de tratamiento de pedidos urgentes.
z Reducción de costes por obsolescencia.
z Aumenta la eficiencia de las transacciones con los partners.
z Disminución de la edad media del producto servido.
Una de las empresas que ha obtenido ventajas evidentes con su sistema SCM
es Dell, que gracias a él ha conseguido romper la espiral de comoditización a la
que tradicionalmente ha estado sometido el sector de los PC, tal como muestra
el Cuadro 5.1.
Estos beneficios potenciales son los que impulsan a los ejecutivos a tomar la
decisión de implantar sistemas SCM. En un estudio del Centro Internacional de
Investigación Logística del IESE (CIIL) de 2003, se preguntó a una serie de
empresarios españoles con sistemas SCM implantados qué les había empujado a
ponerlos en marcha. La Figura 5.6 presenta los resultados en un gráfico de dos
dimensiones, finalidad e importancia, en el que se constata que los dos principa-
les motivos por los que se implanta SCM son la necesidad de mejorar el servicio
al cliente y el conseguir que los tiempos de respuesta sean cada vez menores.
EL PAPEL DE LOS SISTEMAS DE INFORMACIÓN

EN LA GESTIÓN DE LA CADENA DE SUMINISTRO
Aunque se puede concebir la gestión de la cadena de suministro sin un claro
apoyo en las tecnologías de información y comunicación (TIC) es evidente que
en la actualidad la práctica totalidad de empresas ha formalizado los flujos de
El sistema SCM de Dell
El fabricante de ordenadores Dell Computer es uno de los paradigmas de

la fabricación basada en el control de la cadena de suministro que ha
revolucionado el sector de los ensambladores de ordenadores persona-
les convirtiéndose en el fabricante mundial con más rentabilidad y el se-
gundo en volumen en ventas. Dell dispone de un sistema de fabricación
flexible que ensambla el ordenador según las especificaciones de cada
cliente en cuestión de horas. Encadenando el sistema de recepción de
pedidos vía Internet con la generación de órdenes de producción y los
pedidos a proveedores de forma automática, Dell consigue unos costes
de fabricación comparables e incluso inferiores a los fabricantes «en se-
rie» pero con una adaptabilidad máxima a las necesidades de sus clien-
tes sin necesidad de tener inventario esperando ser vendido. Y esto, en
un sector en el que los precios bajan de media un 1% al mes, tiene una
repercusión importantísima en la cuenta de resultados.
Cuadro 5.1. La gestión de la cadena de suministro en Dell Computer.

Alta
Mejoras servicio
al cliente
Tiempos
de respuesta
Mejoras
Importancia
Reducción de eficiencia
de stocks
Mejoras en la
planificación
Reducción
de costes
Incremento
Baja
Estandarización
de ventas
Finalidad
Ahorro de Incremento de la
costes competitividad
Figura 5.6. Razones para la implantación de un SCM.

(Fuente, CIIL, 2003.)
información con fines de gestión de la cadena de suministro. De esta manera, se da

lugar a la interconexión de sistemas de información de diferentes empresas, y se
requiere la integración sin fisuras con los sistemas de proveedores y clientes, para
poder tomar adecuadamente las múltiples decisiones que se suceden en las dife-
rentes etapas de la cadena.
Con el fin de establecer qué tipo de conexiones y de flujos de información se
requieren, un primer paso consiste en la determinación de las necesidades cojuntas
de información. Aunque es difícil hablar en términos generales sobre las necesida-
des de información en un sistema de SCM, debido a la multiplicidad de situacio-
nes y de relaciones entre empresas, clientes y proveedores que se pueden dar. Sin
embargo, a modo indicativo, se puede partir de la siguiente clasificación de infor-
mación que se transmite a lo largo de la cadena de suministro:
z Información de proveedores. La gestión adecuada de la cadena requiere

conocer la reacción del proveedor ante pedidos de diferentes cantidades,
saber cuál va a ser su plazo de entrega, qué condiciones económicas exi-
ge o qué ocurrirá cuando deba modificarse un pedido.
z Información de producción que permita determinar qué productos se
van a producir y en qué cantidad, sus costes y su tiempo o si formarán
parte de un lote, por ejemplo.
z Información para la distribución que permita conocer qué se tiene que
transportar y a qué lugares, en qué cantidades, los medios que se preten-
den utilizar, los plazos máximos de entrega y el coste que conllevan estas
operaciones.

z Información sobre la demanda que indique dónde se está adquiriendo el

producto y en qué cantidades. Deben incluirse aquí las predicciones sobre
la demanda de productos finales sujeta a aleatoriedad, pero no las de los
productos intermedios, que como se ha explicado antes es conocida por
actores a lo largo de la cadena y debe fluir a lo largo de la misma sin
distorsiones.
La identificación de las necesidades de información propias de cada eslabón

de la cadena de suministro parece sugerir la idea de que los sistemas ERP de las
diferentes empresas, enlazados convenientemente, sean la mejor herramienta para
gestionar eficientemente los procesos y tomar las decisiones correspondientes.
Desafortunadamente, eso no es así. Como se ha visto en el capítulo anterior, el
principal objetivo de los sistemas ERP es integrar toda la información de la empre-
sa en una base de datos común y accesible para todas sus áreas funcionales. ERP
es una herramienta eficaz para gestionar correctamente la producción, los inventa-
rios, las entradas de materiales o la contabilidad, y además facilita una visión
global de toda la información que fluye dentro de la organización.
Sin embargo, cuando se desea generar planes de producción o estimaciones
de demanda, los sistemas ERP presentan limitaciones: no tienen acceso a infor-
mación acerca de posibles campañas que nuestros clientes tengan planificadas
para incrementar la demanda, ni conocen las capacidades de las plantas que los
proveedores tienen disponibles en cada momento, ni la disponibilidad de la plan-
tilla o de la materia prima, etc. Los ERP deben pues «extenderse» para poder
gestionar la cadena de suministro al completo.
Aunque hoy en día es posible añadir funcionalidades específicas en los siste-
mas ERP para convertirlos en herramientas de gestión de la cadena de suminis-
tro, son muchas las compañías que –desde 1990– han introducido sistemas espe-
cíficos de Gestión de la Cadena de Suministro (sistemas SCM) para «tapar los
agujeros» de los anteriores sistemas. No obstante, no fue hasta bien entrado el
año 2000 cuando se empezaron a concebir los sistemas SCM como herramientas
exclusivas, independientes de las aplicaciones de ERP (aunque se «apoyan» en
ellas) y capaces de gestionar de forma global el conjunto de operaciones a través
de una única aplicación.
La Figura 5.7 representa las principales diferencias entre los sistemas ERP y
los SCM tal y como se conciben en la actualidad. Las herramientas modernas de
SCM incluyen todo tipo de actividades relacionadas con la adquisición de mate-
riales, la producción, la gestión de inventarios, el almacenamiento, el transporte
o el diseño del producto, entre otras. Con estas aplicaciones, por ejemplo, la
empresa es capaz de determinar el nivel exacto de stock de un producto concre-
to, crear una lista de materiales a transportar de acuerdo con un pedido, fijar con
el proveedor las cantidades de pedidos futuros o incluso procesar los pedidos
que, por el motivo que sea, han de ser devueltos.
Componentes básicos de un sistema formal de gestión

de la cadena de suministro
Con el fin de poder conseguir los diferentes potenciales beneficios de una buena
gestión de la cadena de suministro, desde el punto de vista formal suele ser útil

ERP: Enterprise Resource Planning SCM: Supply Chain Management
• Soporte a los procesos • Soporte a la toma de decisiones

transaccionales • Visión de conjunto de producto, capacidades
(Pregunta ĺ Respuesta) y limitaciones productivas
• Visión de las funciones de la empresa • Simulación interactiva de diversos escenarios

a través de módulos
• Previsión interactiva de diversos escenarios
• Control centralizado de datos • Previsión y gestión de posibles alternativas
que reflejan la realidad e historia
de la empresa • Optimización de los recursos
ERP como un paso previo a un sistema SCM.

ERP como proveedor de los datos requeridos por SCM.
Figura 5.7. Comparativa entre ERP y SCM.

(Fuente: Adaptado del Estudio CIIL-IESE, 2001.)
concebir el SCM como una combinación de diferentes componentes básicos que

cabe integrar adecuadamente con el fin de poder responder de forma satisfactoria
a los retos que presenta la complejidad del fenómeno. Aunque puede haber dife-
rentes visiones sobre cuáles son estos componentes básicos, en general se suelen
concebir en términos de (1) planificación de la producción, (2) relación con los
proveedores, (3) producción, (4) distribución o logística, y (5) gestión de quejas y
retornos.
Planificación de la producción
Es uno de los aspectos más importantes de la gestión de la cadena. Existen multi-

tud de algoritmos de optimización que planifican la producción de la empresa en
función de sus características, del sector en el que opera y de la demanda espera-
da– con variedad de objetivos, como pueden ser el minimizar los costes o el tiem-
po de producción. El problema inherente a estos módulos es la necesidad de fijar
de antemano la cantidad de cada producto a producir. Afortunadamente para mu-
chas empresas, no hace falta predecir la demanda futura de sus productos mediante
métodos estadísticos para conocerla con exactitud: sus clientes saben lo que les
van a comprar en el futuro, aunque no se lo dicen con la anticipación suficiente
como para poder producir bajo demanda. En el otro extremo, una relación fluida
que permita el intercambio de información desde el mismo momento en que está
disponible conlleva enormes ahorros para el proveedor y a la vez un mejor servi-
cio para el cliente.
Para situaciones en las que es inevitable realizar previsiones, existen produc-
tos en el mercado que ayudan a hacer estimaciones de la demanda en función de
la información disponible y que pueden integrarse con facilidad en los módulos
de planificación de la producción. Son, esencialmente, aplicaciones basadas en

métodos estadísticos y en herramientas de inteligencia artificial para el desarrollo

de previsiones en base a información de diversas fuentes, ya sean los sistemas
transaccionales de la propia empresa o fuentes externas. Habitualmente el soft-
ware incluye también elementos de simulación capaces de comparar el impacto en
ingresos y en la rentabilidad de diferentes previsiones.
Relación con los proveedores
Aguas arriba, un sistema SCM permite automatizar las relaciones con los provee-
dores en los términos de negocio establecidos. El sistema permite comunicar los
pedidos, verificar las cantidades o la situación de las mercancías, el enlace con
transportistas o las comprobaciones de crédito, entre otras cosas. Esta interrela-
ción de los sistemas de información de diferentes empresas es la que ha convertido
a Wal-Mart y Procter&Gamble en referentes de la gestión eficiente de la cadena de
suministro.
Producción
Este módulo proporciona información sobre el proceso productivo y, en muchos

casos, acaba formando parte del mismo con la información que recaba automá-
ticamente. En el control del proceso productivo se incluyen actividades como el
aseguramiento de la calidad, el empaquetamiento de los productos y los prepa-
rativos para ser transportados en la siguiente etapa de la cadena.
Distribución o logística
Controla el transporte, la red de almacenes, y todas las actividades relacionadas

con el envío del producto a su lugar de destino, que puede ser la estantería de un
detallista en productos de consumo o la línea de montaje de otro fabricante.
Gestión de quejas y retornos
Aunque esta función suele estar integrada en los sistemas CRM (discutidos en el
siguiente capítulo), el SCM gestiona la devolución de aquellos pedidos que han
sido entregados defectuosos o en exceso y, por tanto, también proporciona cierto
tipo de soporte al cliente.
Estructura de los sistemas comerciales SCM
Las soluciones de SCM en el mercado tienen diversos nombres que pueden con-
fundir sobre su verdadera funcionalidad. Suelen dividirse según sus funcionali-
dades concretas, y entre las aplicaciones más populares se encuentran: (a) apli-
caciones de ejecución (execution applications) y (b) las aplicaciones de
planificación (planning applications). Las aplicaciones de ejecución, de la mis-

ma familia que los tradicionales sistemas ERP, incluyen los sistemas de gestión de
almacenes WMS (Warehouse Management Systems), los sistemas de producción
MES (Manufacturing Execution Systems) y los sistemas de transporte TMS (Trans-
port Management Systems). Por otro lado las aplicaciones de planificación son
capaces, por ejemplo, de realizar predicciones para determinar dónde se deberán
almacenar los productos que se vayan a producir en los próximos meses.
Las aplicaciones SCM están basadas en módulos que, tal y como ocurría con
ERP, pueden implantarse de forma total o bien por partes, pero siempre en fun-
ción de las necesidades de la empresa. No obstante, y dado que estos sistemas
requieren información puntual y rápida acerca de cualquier área funcional, la
integración con los sistemas ERP se hace imprescindible. La experiencia de-
muestra que aquellas empresas que adquieren módulos de SCM al mismo pro-
veedor de sus aplicaciones ERP suelen tener menos problemas de integración a
la hora de implantarlos.
Puesto que estos sistemas son, en general, de nuevo diseño, la mayoría de
proveedores de SCM basan sus aplicaciones en una arquitectura cliente-servidor
con aplicaciones de cliente basadas en tecnología Web que permiten ser opera-
das con estaciones de trabajo muy simples.
Desde el punto de vista de la oferta, los sistemas SCM se pueden clasificar en
tres grupos: los derivados de las extensiones de los ERP, como SAP, Oracle y JD
Edwards; las soluciones específicas, lideradas por Manugistics y que incluyen a
sistemas como i2, Logility, TXT y Movex; y los sistemas que solucionan proble-
mas concretos como Toolsgroup, muy potente en previsión de la demanda.

Una buena gestión de la cadena de suministro permite incrementar los ingresos
y reducir los costes, así como facilitar la comunicación y la colaboración entre
los elementos que la componen. Un sistema SCM adecuado proporciona una
visión global de la cadena que permite conocer en todo momento su estado y
tomar las decisiones pertinentes. Pero esta comunicación y el compartir infor-
mación constantemente también lleva algunos riesgos asociados. Si, por ejem-
plo, un proveedor ofrece sus servicios a empresas de la competencia, puede
ocurrir que información sobre la demanda de nuestros productos caiga en manos
de estos competidores. Como siempre, es esencial gestionar adecuadamente el
nivel de confianza con los interlocutores y protegerse adecuadamente desde el
punto de vista legal.
Al igual que con los sistemas ERP del capítulo anterior, que implican cam-
bios en la forma de trabajar, la implantación de un sistema SCM se encontrará
con la resistencia al cambio de las personas en la organización. Los comentarios
sobre implantación allí realizados son completamente válidos aquí, con la com-
plejidad añadida del cambio cultural que para muchas empresas representa com-
partir información con clientes y proveedores, e incluso llegar a instalar siste-
mas que pueden desencadenar procesos de producción automáticamente, sin
control propio, cuando ocurren eventos en terceras empresas.
Como en toda implantación de grandes sistemas que lleven consigo cambios
en los procesos y en la organización en general, la participación de consultores
es normalmente inevitable ya que en las empresas clientes no suele haber personal

especializado en llevar a cabo el cambio organizativo de forma efectiva. Los co-

mentarios del capítulo anterior sobre la selección de un colaborador adecuado
para una implantación de ERP son completamente aplicables aquí.
Con todo, los sistemas productivos del futuro inmediato van a ser completa-
mente integrados, ya que la necesidad de reducir los costes de transacción entre
vecinos de la cadena de suministro es ineludible para poder subsistir, con lo que
la responsabilidad de los directivos en implantarlos es inexcusable.

Sistemas para la gestión de las relaciones con los clientes 95
6
Sistemas para la gestión
de las relaciones
con los clientes
Cualquier cliente aprecia la gran diferencia entre el trato que recibe del camare-
ro de la cafetería a la que acude a desayunar a diario y el que recibe del personal
del área de descanso de una autopista en verano. Muy probablemente en el pri-
mero le saludan por su nombre, le sirven con diligencia y saben de antemano
cómo le gusta el café. Es posible, incluso, que le aparten la pasta que le gusta si
está a punto de acabarse antes de que llegue o que pueda pedir sin problemas un
bocadillo personalizado a su gusto. En el área de descanso de la autopista, en
cambio, los empleados no nos conocen, nos tratan a todos igual (de mal, normal-
mente) y muy rara vez darán un paso más allá de lo que estén estrictamente
obligados para servirnos mejor.
Entonces, si todo cliente aprecia esta notable diferencia, ¿por qué algunas
empresas insisten en tratar a todos los clientes, incluso a los que compran desde
hace años, como si estuvieran en una cafetería de autopista?; ¿qué podría com-
portar hacerlo de otra manera?; ¿se pueden desarrollar procedimientos organiza-
tivos, con el soporte de sistemas de información avanzados, que permitan tratar
a los clientes de la forma más individualizada posible?
¿POR QUÉ GESTIONAR LAS RELACIONES

CON LOS CLIENTES?
Unos sencillos cálculos demuestran que para casi todas las empresas un cliente
que repite tiene mucho más valor que uno que compra una sola vez, y no sólo
por el valor agregado de las compras, sino también porque normalmente es mu-
cho más caro conseguir un cliente nuevo que influir sobre uno que ya lo es para
que repita compra. Además, los clientes con los que habitualmente trata una
empresa son una valiosa fuente de información sobre sus productos y servicios.
Información que suele llegar en forma de críticas, positivas o negativas. Convie-
ne conocer su opinión de cara a mejoras futuras, para poder ofrecer un producto
mejor, más adaptado a sus necesidades y a las del resto de clientes potenciales.
95

Las empresas deben esforzarse en trabajar para el cliente en todos los ámbi-
tos de la organización. Si la empresa centra todos sus procesos en el cliente
puede llegar a tener a toda una organización sensible a sus necesidades, sean los
departamentos que tradicionalmente están en contacto con él –como ventas, mar-
keting y servicio post-venta–, o los departamentos que normalmente viven aleja-
dos de la realidad comercial, como pueden ser administración y finanzas o com-
pras. La empresa debe personalizar cualquier tipo de interacción con el cliente
y ofrecerle aquellos productos que satisfagan sus necesidades de la mejor forma
posible. Servirle desde cualquier lugar, en cualquier momento y mediante el uso
de todos los canales de comunicación disponibles. Los procesos de negocio de-
ben ser diseñados también pensando en el cliente, ya que toda la actividad de la
empresa acaba teniendo un impacto en la calidad del producto o servicio entre-
gado y, por tanto, en la apreciación del cliente.
Durante los años noventa, la globalización de los mercados llevó a las empresas
occidentales a replantear de forma radical sus estructuras de costes para afrontar la
presión competitiva de economías emergentes. Fue entonces cuando se populariza-
ron los términos «reingeniería de procesos» y «reducción radical de costes», activi-
dades que, aun siendo esenciales para la supervivencia de la empresa en ese momen-
to, tuvieron como efecto secundario un enfoque «hacia adentro» de la organización
que en muchos casos descuidaba las relaciones con los clientes.
Poner al cliente en el centro de las decisiones de la empresa implica ser
capaz de detectar a los más rentables y a los que hacen perder dinero en cada
transacción, de medir la efectividad de las campañas de marketing y las promo-
ciones, de calcular el coste de los diferentes canales de distribución o de prede-
cir cuando un cliente está a punto de perderse. Realizar estas tareas con efectivi-
dad solo es posible si se dispone de una información –en el tiempo y la forma
adecuados– que a veces ya existe pero que no siempre es de fácil acceso.
Recoger la información, almacenarla, elaborarla, y ponerla a disposición de
quienes la necesiten para gestionar la relación con los clientes de forma adecua-
da y diferencial son los objetivos principales de los sistemas de gestión de la
relación con los clientes, quizá mejor conocido por su acrónimo anglosajón:
CRM (Customer Relationship Management).
En resumen, el CRM consiste fundamentalmente en poner al cliente en el
centro de la estrategia de negocio. Ello suele implicar una reorientación estraté-
gica de la compañía, que muchas veces va acompañada de un rediseño de sus
procesos de negocio, a su vez apoyado en el sistema de información (SI). Por
ello, si bien es perfectamente concebible el CRM sin tecnologías de información
y comunicación (TIC), en la actualidad el SI suele jugar un papel destacado para
su implantación en una empresa. Ofrece las herramientas necesarias para la re-
cogida de información, el análisis del comportamiento de los clientes, la detec-
ción de nuevas necesidades, etc. Ayuda a dar un mayor y mejor servicio desde
cualquier lugar de la empresa, debido a que un CRM formal bien implantado
proporciona a todos los decisores información relevante de los clientes de la em-
presa.
De hecho, todo el potencial del CRM queda más claro si se analizan cada
una de las tres palabras que componen su definición:
z Cliente (Customer): Es quien tiene la última palabra, puede comprar donde

quiera, está informado sobre las ofertas que tiene a su alcance, dispone de

comparativas, es riguroso en su análisis y quiere que se le reconozca y en-

tienda. El cliente es la fuente de ingresos de cualquier empresa. Sin clientes
no hay empresa, por lo que mantener a los existentes y conseguir nuevos ha
de ser uno de los objetivos principales. Los buenos clientes son los que
aportan mayores ingresos por menos recursos, es decir, los más rentables.
Es esencial poder calcular la rentabilidad de cada cliente, conocer el coste
que ha supuesto «capturarle» y servirle el primer pedido e incluso predecir
su comportamiento a lo largo de los años de relación con la organización
para estimar lo que se denomina el «valor actual del cliente». Definido
formalmente, el valor actual del cliente (o Customer Lifetime Value) es el
valor que éste representa para la compañía, estimado en base a su coste, al
valor actual de los futuros ingresos que pueden reportar sus compras y a su
ciclo de vida esperado como cliente de la empresa. Cálculos avanzados de
este valor llegan a incluir las referencias que un cliente puede generar (a tra-
vés de recomendaciones a otras personas) y los beneficios que éstas pueden
representar para la compañía. El valor de todos los clientes de una empresa se
acostumbra a denominar en inglés customer equity.
z Relación (Relationship): Bajo los términos descritos anteriormente, es
fácil observar por qué es más rentable un cliente que repite que uno que
compra una sola vez. La clave, pues, es mantener la relación con los que
ya se tiene, intentando que la información entre cliente y proveedor fluya
en ambas direcciones. Hay que mantener siempre el contacto con el cliente,
conocer sus preferencias y cómo evolucionan en el tiempo para minimi-
zar el riesgo de que se plantee romper el vínculo con la compañía y la
deje para irse a la competencia. CRM constituye una herramienta básica
para la gestión de las relaciones con clientes, ya que no se limita a reca-
bar la información que surge de ellas sino que aporta otras aplicaciones
útiles para predecir su comportamiento y ayudar a la empresa en la pues-
ta en marcha de acciones dirigidas a incrementar el valor de esa relación.
z Gestión (Management): Aunque las siglas son las mismas, la «M» de
Management en CRM no debe confundirse con la de Marketing: no se
trata de una actividad exclusiva de este departamento, sino que afecta a
toda la empresa. CRM pretende situar al cliente en el centro de la organi-
zación y enfocar todos los departamentos a la satisfacción de sus necesi-
dades, proporcionando la información necesaria para que la empresa pueda
adaptarse con agilidad a los cambiantes requisitos del mercado.
Las empresas que empiezan suelen ver a sus clientes como su fuente
de ingresos e intentan tratarles de forma diferenciada. Sin embargo, a
medida que la empresa crece, personalizar productos y servicios se hace
prácticamente imposible. Una iniciativa formal de CRM puede ayudar a
la hora de re-enfocar toda la empresa hacia la satisfacción de las necesi-
dades individuales de sus clientes porque identifica las acciones suscepti-
bles de maximizar su valor a lo largo del tiempo.
Entendido de esta manera, un sistema de CRM captura la información sobre el

cliente generada en las diversas áreas funcionales de la empresa y la almacena en
una única base de datos para después analizarla y distribuirla a los lugares clave en
que se desarrolla la relación con el cliente, para utilizarla en lo que en el ámbito de
los servicios se denomina la gestión de los «momentos de verdad».

Principales beneficios de los sistemas CRM
Idealmente, una correcta implantación de CRM ayuda a la rentabilidad de la

empresa gracias a un círculo virtuoso: CRM permite a todos los departamentos
disponer de los recursos necesarios para mejorar el producto y su entorno con el
objetivo de satisfacer al cliente, mientras que el cliente satisfecho –dispuesto a
pagar un poco más por un producto mejor y de más calidad o a comprar en
cantidades más elevadas– aporta ingresos mayores a la empresa y, por tanto,
incentivos a esforzarse por conseguir nuevas mejoras. De este modo, un buen
sistema de CRM contribuye a mejorar en tres ámbitos diferentes: (a) la mejora
del servicio a clientes actuales, (b) captación de nuevos clientes, y (c) ayudar en
la gestión de los departamentos de ventas, marketing y servicios.
Mejora el servicio al cliente
Es el objetivo último de todo CRM. La satisfacción de un cliente es lo que le

hace fiel a una empresa y lo que puede hacer que incremente su negocio con
nosotros. Incluso es posible que él mismo consiga clientes nuevos para nuestros
productos. Sólo con un mejor servicio se consigue sacar provecho de estas rela-
ciones. Al recoger y analizar datos sobre el comportamiento actual de los clien-
tes, el CRM puede ayudar a identificar posibles problemas, definir ofertas atrac-
tivas, gestionar promociones conjuntas, etc.
Descubrir nuevos clientes
El CRM también es un apoyo esencial para la captura de nuevos clientes. A base

de observar el comportamiento de los clientes existentes, de segmentarlos y de
analizarlos a través de bases de datos externas y estudios de mercado, pueden
obtenerse conclusiones muy útiles para ampliar el mercado. El seguimiento de
los contactos iniciales llevados a cabo antes de conseguir la primera venta es
también uno de los objetivos más buscados con la implantación de estos siste-
mas, ya que en muchas ocasiones potenciales clientes no acaban comprando por
no realizarse el seguimiento adecuado.
Ayudar a los departamentos de ventas, marketing y servicios
Aunque CRM es para toda la empresa y el objetivo de satisfacer al cliente se

extiende a todos sus departamentos, no hay duda de que los de ventas, marketing
y servicios son los que generan un mayor feedback del cliente y los que, en
general, se dedican a identificar a los clientes más rentables y a los de mayor
potencial. De este modo, los departamentos involucrados pueden llegar a obte-
ner toda una serie de ventajas:
z Incremento de la lealtad de los clientes.

z Respuesta más rápida a preguntas y peticiones de información.
z Mayor comprensión de las necesidades de los clientes.

z Aumento de las oportunidades de ventas y mejora del enfoque del marke-

ting.
z Identificación de los clientes más rentables.
z Recepción y análisis del feedback del cliente.
z Detección de oportunidades y apoyo a las ventas cruzadas.
z Aumento del componente servicio y, por tanto, de la posibilidad de au-
mentar los márgenes.
z Posibilidad de venta de productos y servicios adicionales.
z Seguimiento de contactos y aumento de la conversión de potenciales a
clientes.
z Mayor información sobre los cambios en el mercado.
z Fortalecimiento de la marca.
z Reducción del tiempo de desarrollo de productos, al conocer mejor las
necesidades y requerimientos del cliente.
EL PAPEL DE LOS SISTEMAS DE INFORMACIÓN

EN LA GESTIÓN DE LAS RELACIONES CON LOS CLIENTES
Los SI pueden apoyar la gestión de las relaciones con los clientes tanto desde
un punto de vista de mejorar la operativa diaria, como mediante un mejor
análisis de los datos disponibles. Es por ello que desde un punto de vista fun-
cional, las aplicaciones informáticas de CRM se clasifican en operacionales y
analíticas.
CRM operacional: mejorando las actividades cotidianas de contacto

con el cliente
Las aplicaciones operacionales incluyen un conjunto de herramientas de sopor-

te para los procesos más tradicionales de interacción con el cliente, tales como
la automatización de las ventas, el marketing o el propio servicio al cliente. Se
puede decir que constituye la parte más «técnica» de CRM. Pretende abarcar
todo el camino que va desde la identificación de clientes potenciales hasta la
obtención de una respuesta, incluyendo el servicio que se les da una vez han
adquirido un producto.
Los «paquetes» de CRM operacionales varían en función de los diferentes
proveedores de estas aplicaciones, y se pueden encontrar en el Anexo a este capí-
tulo. Sin embargo, todos suelen presentar las siguientes funcionalidades básicas.
Automatización de la fuerza de ventas
La automatización de algunas tareas de la fuerza de ventas está en el origen de

los primeros paquetes específicos de CRM que aparecieron en el mercado a
mediados de los años noventa, y todavía hoy se considera el núcleo más impor-
tante de un sistema CRM. Es utilizado sobre todo por el personal del departa-
mento de ventas y por los directivos de la empresa para automatizar todo aquello
relacionado con el proceso de ventas.

Por lo general, comprende:
z Procesos de gestión de ventas.

z Gestión de contactos.
z Seguimiento y detección de prospectos de venta.
z Información disponible sobre el cliente para compartir entre los diferen-
tes puntos de contacto.
z Gestión de oportunidades.
z Análisis de ventas.
z Generación de propuestas y presupuestos para el cliente.
z Apoyo en la configuración del producto.
z Apoyo en el cálculo/fijación de precios.
Automatización de marketing
Permite a la empresa planificar, ejecutar y mejorar en tiempo real las activida-

des relacionadas con marketing, con el objetivo de realizar campañas mucho
más efectivas a un coste menor. Suele incluir los siguientes elementos:
z Gestión de listas de clientes.

z Gestión de campañas.
z Apoyo a las ventas cruzadas: detección de candidatos, de posibles pro-
ductos y servicios a empaquetar, etc.
z Selección de los clientes con más valor potencial.
z Seguimiento de eventos y alarmas (cuando un cliente está a punto de
dejarnos, por ejemplo).
Servicio de atención al cliente
Trata de gestionar y organizar aquellas funciones de servicio al cliente 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. Los elementos más habituales que incluye son:
z Programación y previsión de las necesidades de personal de atención al cliente.

z Apoyo a la gestión de las reclamaciones u otros contactos relacionados
con el servicio al cliente.
z Apoyo a la gestión de los contratos de garantía y mantenimiento.
z Gestión de producto en depósito para reparación.
z Asesoramiento técnico al cliente y envío de técnicos.
z Seguimiento de la calidad.
Soporte, Help Desk y centros de contacto
Son aplicaciones diseñadas para prestar servicio técnico a los clientes en aque-
llos casos en que tengan dificultades con el funcionamiento del producto que
han adquirido.

Suele incluir:
z Seguimiento de llamadas y gestión y resolución de problemas.

z Clasificación y consolidación de toda la información relativa a los con-
tactos con el cliente.
z Historial de los problemas más frecuentes originados con clientes especí-
ficos o con líneas de producto determinadas.
z Visualización de la información acerca del cliente para poder atenderle
de forma personal y diferenciada.
z Visualización de la información acerca de los productos y servicios de
los clientes para identificar y resolver sus problemas.
CRM analítico: entender el comportamiento del cliente

para poder ofrecer mejores respuestas a sus necesidades
El segundo bloque de aplicaciones de un sistema CRM están encaminadas a

«entender» mejor al cliente. De este modo el CRM analítico está compuesto por
herramientas que ayudan a analizar toda la información que proporciona el CRM
operacional para comprender mejor el comportamiento de los clientes. Las em-
presas suelen utilizar aplicaciones de CRM analítico para diseñar estrategias de
marketing así como para la predicción de ventas.
Normalmente, las aplicaciones de CRM analítico analizan las relaciones con
los clientes mediante el uso de minería de datos, de los denominados sistemas
OLAP (OnLine Analysis Processing, Análisis de Datos Online) y de otras herra-
mientas capaces de identificar en tiempo real, por ejemplo, a aquellos clientes
que comprarán un determinado producto, o bien a entender cuáles pueden ser
clientes que pretenden abandonar la empresa.
Una implantación adecuada de un sistema CRM permitirá responder positi-
vamente preguntas como:
z ¿Conocemos la contribución actual y potencial de cada uno de nuestros

clientes a los beneficios de la empresa (el denominado «valor esperado
actual» del cliente)?
z ¿Hemos desarrollado canales específicos de marketing, ventas y servi-
cios de acuerdo con las preferencias de cada uno de nuestros clientes?
z ¿Es posible compartir la información de nuestros clientes con todos los
ámbitos de la empresa?
z ¿Poseemos una estructura fiable capaz de facilitarnos una interacción
personalizada con cada cliente?
z En definitiva, ¿disponemos de un sistema que nos permita gestionar de
forma eficaz las interacciones con nuestros clientes?
IMPLANTACIÓN DE UN SISTEMA CRM

Implantar CRM en la empresa es una decisión de gran trascendencia porque,
como se ha visto, suele comportar cierta reestructuración de la empresa necesa-
ria para centrar su actividad en el cliente.

Existen muchos paralelismos entre la implantación de un sistema ERP y un

sistema CRM, por lo que remitimos al lector interesado a repasar el capítulo
correspondiente. Sin embargo, existen algunas particularidades de los sistemas
CRM que merece la pena repasar detenidamente. Entre las diferentes alternativas
para implantar un CRM, una primera decisión fundamental es la de decidir entre
la adquisición de un paquete estándar o la de diseñar el sistema dentro de la
propia empresa. Ya en un segundo plano, hay que evaluar también la convenien-
cia de adoptar paquetes específicos: existen suministradores especializados en la
gestión de call centers (centros de llamadas), en la automatización de campañas
de marketing o en el análisis de datos. Por tanto, es imprescindible evaluar las
diferentes alternativas de forma clara y precisa, observando las diferentes carac-
terísticas de cada una de ellas, los requisitos y, sobre todo, las repercusiones que
tendrán en la empresa.
A modo general, y siendo conscientes de que pueden existir alternativas inter-
medias, existen las siguientes alternativas para la implantación de un sistema CRM:
CRM como parte de un paquete estándar de aplicación de empresa
La idea básica es la «integración» de CRM con aplicaciones como un sistema

ERP y/o SCM, todas de un mismo proveedor. Tiene como principales ventajas el
hecho de poseer un modelo de datos centralizado por diseño, unos perfiles estan-
darizados, dando lugar a un sistema muy integrado.
Su principal desventaja es la dependencia de un único proveedor, cuando lo
más probable es que otros proveedores posean algunos módulos con caracterís-
ticas más favorables para nuestros procesos. Además, suele ser una opción de
implantación muy compleja, que compromete una gran cantidad de recursos,
tanto financieros como generales, de la empresa, como se ha visto en el capítulo
dedicado a los ERP.
CRM específico
Supone la implantación de una aplicación exclusiva de CRM, y aunque está

prevista una cierta integración con los diferentes sistemas de la empresa, no se
trata de una solución «tan» integrada como la anterior. De todos modos, existen
casos de empresas que no disponían de un sistema ERP, en las que el CRM ha
ido creciendo hacia atrás proporcionando varias de las funcionalidades que nor-
malmente son típicas de los ERP.
«Lo mejor de cada casa» («Best-of-breed»)
Igual que en el caso de ERP, esta es la alternativa escogida por aquellas empresas,
con procesos muy particulares, que requieren un mayor grado de adaptación de las
aplicaciones de CRM a sus necesidades. Esta situación se da, por ejemplo, cuando
una empresa decide combinar el sistema de call center de un proveedor con una
aplicación de gestión de contactos y apoyo a los vendedores de campo de otro
proveedor. Suelen ser soluciones más difíciles de implantar que las de CRM úni-

co, puesto que requieren un gran conocimiento del funcionamiento de cada módulo
y necesitan de una mayor participación de los técnicos especialistas internos.
Tiene como principales desventajas la dificultad de integración de diferentes
tecnologías y la necesidad de coordinar varios proveedores, cada uno con su
propia agenda y motivaciones, lo que llevado a un extremo puede derivar en una
situación de dilución de responsabilidades ante posibles problemas.
Diseño propio
Tal como se vio en el Capítulo 4, la decisión de diseño propio responde muchas

veces a unas necesidades excepcionales –de flexibilidad, de acceso inmediato a da-
tos, de movilidad de los empleados, etc.– de una determinada empresa, por lo que
ninguno de los paquetes existentes puede ofrecer una solución adecuada. De este
modo, las empresas que optan por esta alternativa de implantación no han encontra-
do ningún proveedor en el mercado capaz de satisfacer adecuadamente sus necesi-
dades, y por eso se decantan por una solución propia elaborada dentro de la empresa.
En el caso del CRM, esta situación se suele dar con cierta frecuencia en
empresas pequeñas o medianas que quizá no tienen como prioridad principal
centrarse en el cliente pero sí buscan una mínima ayuda en la gestión de sus
relaciones con ellos, o prefieren una inversión paulatina normalmente asociada
a desarrollos propios de sistemas con pocas funcionalidades muy concretas.
Requisitos a tener en cuenta para una implantación existosa
En cualquier caso, y sea cual sea la solución de CRM adoptada, podemos citar tres
requisitos mínimos que cualquier alternativa de implantación debería contemplar:
z Aunque la empresa no disponga de una aplicación de ERP, un CRM nece-

sita de la existencia de una base de datos integrada a la que se pueda
acceder desde cualquier área funcional y que contenga datos de toda la
organización, especialmente de sus clientes.
z Es necesaria la existencia de un software capaz de gestionar las campañas de
marketing desde el inicio hasta el final, de realizar una selección tanto de los
grupos de clientes como de los canales que se deberán utilizar para cada uno
de ellos, e incluso de prever alguna medida de la efectividad de la campaña.
z Se debe disponer de una herramienta que permita evaluar las relaciones
con los clientes y seguir de forma continuada su comportamiento. Con ella
la empresa debería ser capaz de analizar la rentabilidad de los clientes.
Dicha herramienta debería aportar también datos predictivos orientados a
la obtención de un mayor rendimiento de las relaciones con los clientes.
Los fracasos de los CRM
No todas las implantaciones de sistemas complejos como CRM acaban en éxito.

Entre los factores que hacen que estos sistemas no proporcionen los resultados
pretendidos, cabe destacar:

Calidad de los datos
Un sistema de CRM requiere el uso de una gran cantidad de datos sobre clientes,
productos y mercados. Especialmente en este tipo de aplicaciones es esencial esta-
blecer prioridades en el almacenamiento y procesamiento de los datos para asegu-
rar la coherencia tanto en sus magnitudes como en el tiempo. Si la empresa no está
acostumbrada a almacenar de manera sistemática datos de su actividad comercial,
es muy posible que los primeros datos que se recojan contengan errores.
Falta de alineamiento entre la empresa y el departamento TIC
CRM es un proyecto de empresa orientado a facilitar la consecución de su estra-

tegia, no un mero proyecto tecnológico. Sin embargo, la empresa requiere la
participación del departamento de TIC para aplicar las tecnologías adecuadas y
el departamento de TIC, a su vez, necesita la colaboración de toda la empresa
para establecer los requisitos del sistema que sirve de apoyo a la estrategia. Sin
esta mutua colaboración es imposible alcanzar el éxito en la implantación de un
sistema de estas características.
Ausencia de un plan
De la misma manera que no se puede construir un edificio sin unos planos previos,
es imposible implantar CRM en una empresa sin tener un plan claro sobre los
objetivos que se pretende conseguir, los departamentos y el personal implicados
en el proyecto o las fases en las que se dividirá su progresiva implantación.
Insuficiente compromiso de los empleados
Como en cualquier aplicación nueva que se implante en una empresa, la expe-

riencia y el compromiso de los empleados es vital para su buen uso. Es necesario
formar a los empleados antes y durante la implantación del sistema y facilitar su
adaptación en todo momento. Los Capítulos 3 y 10 sobre planificación de siste-
mas y gestión de proyectos presentan ideas sobre la implantación de sistemas y
la generación de compromiso en empleados perfectamente aplicables a aplica-
ciones de CRM.
Olvidar que el CRM existe para servir al cliente
A veces puede ocurrir que la empresa, inmersa en la vorágine de la implantación

de CRM y en el ajetreo del día a día, acabe viviendo este proceso de puertas
adentro y como algo puramente interno a la empresa. En su libro Why CRM Doesn’t
Work (Por qué los CRM no funcionan)1 Frederick Newell, uno de los autores que
1
Newell, Frederick: «Why CRM Doesn't Work», Kogan-Page, 2003.

más ha escrito sobre CRM, sostiene que los fracasos de los CRM son debidos a que
las empresas acaban olvidando la razón última de estos sistemas: servir mejor al
cliente. Cuando nos empeñamos en servir al cliente como nosotros creemos que
quiere ser servido en lugar de escucharle constantemente, estamos a un paso del
fracaso más rotundo. Un CRM que dé la sensación de que se sabe lo que el cliente
quiere sin siquiera haberle preguntado puede ser la puerta del caos comercial.
En cualquier caso, y tal y como se apuntaba al principio, las razones del
fracaso en la implantación de estos sistemas no suelen venir del lado de la tecno-
logía. Las principales causas de un proyecto fallido pueden resumirse en una: la
carencia de una visión global de lo que se pretende conseguir con una aplicación
de estas características. Tanto los objetivos que se persiguen como los medios
que se pondrán para alcanzarlos deben ser conocidos por los principales respon-
sables de departamento de la empresa, quienes, además, tienen la misión de
transmitir esta información a sus subordinados para acercarles a la nueva solu-
ción y facilitarles la adaptación al cambio.
Costes de implantación de CRM
Según una encuesta realizada por Gartner Group a finales de 2002 más del 50% de
los costes de implantación de CRM responden a los servicios necesarios para im-
plantarlo, desde consultores externos hasta personal de la propia empresa (espe-
cialmente del departamento TIC). El 50% restante se divide, principalmente, entre
software (35%) y hardware (15%). Entre los módulos a implantar, el más costoso
en términos monetarios es el de automatización de la fuerza de ventas, mientras
que el de gestión de los recursos de marketing suele ser el más económico.
La Figura 6.1 muestra los resultados obtenidos tras una encuesta en un total de
200 empresas de todo el mundo sobre cuatro categorías siguientes: coste total del
Media del Coste total

Coste total Coste total
coste total del Hardware Software Servicios Encuestas
del proyecto del proyecto
del proyecto proyecto (%) (%) (%) (n)
bajo (en $) medio (en $)
(en $) alto (en $)
Cambio en los costes
823.375 60.000 5.520.000 119.500 5,06 68,48 26,46 8
de gestión
Análisis 1.043.250 265.000 3.000.000 825.000 13,52 38,44 48,05 8
Servicios de Internet 1.247.808 40.000 18.000.000 418.000 20,85 32,24 46,91 36
Incentivos y
1.449.039 435.000 3.500.000 1.123.500 11,97 45,03 42,99 10
compensaciones
Marketing 1.565.750 75.000 4.000.000 650.500 15,53 26,66 57,81 8
Parametrización 1.627.600 230.000 4.000.000 1.500.000 27,69 34,13 38,18 11
Módulo comercio electr. 1.770.455 300.000 3.600.000 1.300.000 10,12 33,5 56,38 11
Desarrollo/entrenamiento
de clientes 1.816.733 117.000 6.500.000 800.000 11,3 31,13 57,57 15
Desarrollo/entrenamiento
2.400.615 75.000 15.000.000 1.200.000 15,69 33,28 51,03 33
de partners
Mantenimiento 3.390.545 120.000 30.000.000 500.000 3,45 17,86 78,69 11
Análisis proceso de venta 3.668.652 180.000 40.000.000 950.000 14,47 22,74 62,78 23
Parametrización proceso
5.830.346 155.000 80.000.000 1.345.000 16,34 26,93 56,73 26
de venta
Figura 6.1. Distribución de los costes de CRM.

(Fuente: Eisenfeld, B. «CRM Project Costs Identified and Defined»,
Gartner Group, April 2003.)

proyecto, del hardware, del software y de los servicios. Conviene tener en cuenta,
no obstante, que los datos que se presentan no cubren necesariamente todas las
posibles aplicaciones de CRM existentes.
Aunque software, hardware y servicio son los tres costes más importantes de
un proyecto de implantación de CRM, no debemos olvidar los «costes escondi-
dos», difíciles de anticipar en muchas ocasiones. Los más significativos corres-
ponden a:
z Adaptación al cambio en los procesos de la empresa.

z Recopilación de datos.
z Conversión de datos al nuevo sistema.
z Transferencia de conocimientos.
z Software adicional complementario al nuevo.
z Mantenimiento del sistema una vez instalado.
z Costes futuros de actualización.
z Entrenamiento de los usuarios.
FACTORES CRÍTICOS DE ÉXITO EN LA IMPLANTACIÓN

DE SISTEMAS CRM
La implantación de un sistema formal de CRM conlleva siempre un cierto grado
de redefinición de los procesos de la empresa. Los más afectados son los que
tienen una relación más directa con los clientes. Pero si aceptamos que el CRM
es una herramienta que «pone al cliente en el centro» de la empresa, debemos
aceptar también que conseguirlo requiere mucho más que la puesta en escena de
una tecnología: requiere, ante todo, un cambio de mentalidad. En realidad, el
éxito de CRM depende mucho más de otros factores que de los puramente tec-
nológicos.
Por ello, es bueno recordar que existen algunos factores que se tienen que
tener en cuenta antes de poner en marcha un proyecto CRM, ya que pueden
resultar claves para el éxito de la implantación.
Establecer una estrategia de CRM con objetivos claros
Como ocurre con casi todos los sistemas de información de alta complejidad,
muchos proyectos de CRM pueden fracasar por no haber fijado unos objetivos
claros de antemano. Existen muchas soluciones de CRM diferentes en función
de los objetivos que se pretendan alcanzar: reducir el coste de retener clientes,
reducir los tiempos de respuesta, mejorar las previsiones, etc. Se debe seleccio-
nar la mejor solución de CRM de acuerdo con unas prioridades fijadas. Además,
conviene especificar de manera explícita qué es exactamente lo que se pretende
conseguir. Por ejemplo, reducir los tiempos de servicio en un 10% o aumentar el
número de visitas a clientes por cada comercial en un 20%.
La «estrategia de empresa» de un sistema CRM no puede desligarse de las
estrategias comerciales y de marketing convencionales, que se construyen alre-
dedor de cuatro dimensiones clásicas: producto, precio, canal y publicidad. Sin
embargo, y si la empresa pretende sacar el máximo provecho a la implantación

de un CRM, ha de tener claro que estas cuatro dimensiones han cambiado también
en los últimos años. Pongamos el precio como ejemplo. Hoy día, hay que contem-
plar la posibilidad de individualizar los precios para cada cliente: no basta con
fijar una política de precios más o menos compleja que discrimine diferentes seg-
mentos de clientes, hay que pensar en llegar al precio óptimo para cada cliente.
Pero, si se opta por este camino, ¿cómo implantar el precio personalizado que
maximice el ingreso? Si se vende un producto distinto a cada cliente, por ejemplo
un proyecto de ingeniería, establecer un precio individualizado resulta relativa-
mente fácil. Pero si se comercializan distintos productos al mismo tiempo, la cosa
puede ser algo más complicada. Para estos casos, una solución puede ser la utiliza-
ción de una tarjeta que identifique a los clientes y premie a los más fieles con
descuentos personalizados. Más o menos del mismo modo en que algunos super-
mercados premian las compras con sistemas de puntos y descuentos diferentes
para cada cliente.
Alinear las TIC con las operaciones de negocio
Como en cualquier proyecto TIC de gran envergadura, la tecnología suele ser un

factor muy importante, si bien pocas veces es el más importante. Hay que recor-
dar que en un proyecto de CRM, el objetivo final es llegar mejor al cliente, y que
para ello las TIC son sólo un medio para mejorar aquellos procesos de negocio
que repercuten directamente en el cliente.
Por ello, los proyectos de implantación de CRM deben involucrar tanto al
personal de los diferentes departamentos implicados como al de sistemas de
información. Además, los objetivos de ambos departamentos no sólo deben ser
compatibles, sino que deben estar perfectamente alineados.
Apoyo de los ejecutivos
Los directivos y altos cargos de la empresa son quienes deben prestar el máximo
apoyo al proyecto de CRM, dado el elevado grado de interconexión que existe
entre estos sistemas.
Esto incluye, por supuesto, al director general o máximo responsable de la
empresa.
Contar con consultores experimentados
La implantación de un sistema complejo como CRM, que además conlleva un

cierto grado de reingeniería de procesos, obliga a la mayoría de empresas a
recabar ayuda de consultores externos.
Como en todo contrato de servicios de este tipo, hay que valorar su experien-
cia previa y su especialización tanto en el software elegido como en el conoci-
miento del sector en general y, si es posible, de la empresa en particular en la
que se va implantar un sistema CRM. Los comentarios acerca de la participa-
ción de consultores del Capítulo 4 (ERP) son de aplicación también en el con-
texto del CRM.

Involucrar a los usuarios finales en el diseño de la solución
Al igual que con los sistemas ERP, los usuarios son los más afectados por la
implantación de un nuevo software de CRM y por el cambio en las prácticas de
trabajo que eso supone.
Al fin y al cabo, son ellos quienes van a enfrentarse día a día con el nuevo
formato y quienes, muy probablemente, deberán cambiar su manera de enfocar
la relación con el cliente para adaptarse a la nueva situación. El nuevo programa
ha de ser, en consecuencia, intuitivo y relativamente fácil de manejar para los
usuarios. En este sentido, es muy importante tener en cuenta que ellos son los
únicos que pueden afirmar si un programa es o no intuitivo y fácil de manejar,
por lo que hay que darles un cierto grado de decisión durante el proceso de
implantación.
Formación de los usuarios
La comprensión de la estrategia que subyace a la implantación de un CRM (en-

tender por qué se ha implantado) es la clave para que los empleados se adapten
con facilidad a la «nueva empresa».
A los usuarios finales no se les debe enseñar únicamente a utilizar el nuevo
programa, sino que han de saber también cómo gestionar los nuevos procesos de
negocio con la ayuda del nuevo sistema de CRM y cómo dirigir sus actuaciones
para conseguir los objetivos fijados. Deben tener un buen conocimiento de los
cambios que el nuevo sistema introducirá en el funcionamiento de la empresa y
entender claramente cómo el CRM y los nuevos procesos permitirán ofrecer un
mayor servicio a los clientes.
Metodología de implantación
La implantación de un sistema CRM, igual que la de un ERP, es un proceso lento

y costoso. La duración típica de este proceso es de unos 16 meses, por lo que es
necesaria una buena planificación inicial que conviene controlar frecuentemente
con hitos e informes de progreso. Tal como se propone en el Capítulo 10 sobre
gestión de proyectos, una metodología adecuada para la implantación de este
tipo de sistemas puede ser distribuirla en diferentes etapas (de 3 o 4 meses cada
una), definiendo para cada una de ellas una serie de metas concretas, medibles y
relacionadas entre sí.
No olvidar la post-implantación
Una vez implantado el programa en la empresa, es conveniente evaluar periódi-

camente su funcionamiento para determinar si se están consiguiendo los resulta-
dos para los que se diseñó. Conviene asimismo comunicarse y entrevistarse con
los clientes, a fin de evaluar el impacto real de CRM en su actitud y comporta-
miento, y mostrar los resultados obtenidos a todos los usuarios del nuevo soft-
ware para mejorar aquellos puntos que lo requieran.

DEL CRM AL e-CRM

Añadir una «e» al principio de cualquier palabra estaba de moda antes de la
catástrofe bursátil del 2001, aunque ahora parece haber perdido glamour. De
hecho, en el mundo de los sistemas de información, e-CRM se refiere a los
sistemas CRM basados en una tecnología concreta: la tecnología Web. Esta tec-
nología tiene la particularidad de, al funcionar mediante unos protocolos cono-
cidos y compartidos, permitir que el cliente acceda al sistema CRM mediante un
acceso web, por lo que se posibilita el autoservicio del propio cliente, una mayor
interactividad, etc., reforzando de esta manera la continuidad de las relaciones
entre la empresa y sus clientes.
Un ejemplo claro de e-CRM (o CRM con tecnología Web) es la Web de
Amazon (www.amazon.com), que revolucionó el mundo con su venta de libros
y más tarde abrió sus fronteras a otros productos como la electrónica o el entre-
tenimiento. Es una de las páginas que da más protagonismo al cliente, con nu-
merosas referencias durante todo el proceso de consulta o compra de un produc-
to que van desde la información sobre sus anteriores pedidos hasta la recomendación
de otros productos relacionados con los que ha adquirido o por los que ha mostra-
do interés. Según la American Consumer Association, Amazon tuvo un 88% de
clientes satisfechos con el servicio proporcionado, en los años 2002 y 2003, una
cifra altísima para una empresa de servicios que no trata cara a cara con los clien-
tes.
La Figura 6.2 reproduce la nota publicada en la página Web de Amazon
haciendo referencia a esta situación.
Figura 6.2. Éxito de Amazon por una buena gestión

de sus relaciones con los clientes.
(Fuente: Amazon.com.)

Pero no todo son ventajas para las empresas que operan en el canal Internet.
Por ejemplo, es el cliente quien decide cuándo y cómo comunicarse con la em-
presa, por lo que debe ser la empresa quien planifique (a través de CRM) cómo
atraer al cliente y llamar su atención. Además, en estos nuevos canales es más
facil para el cliente acudir a la competencia: basta un solo «clic» para acceder a
otras empresas y comparar (o comprar) el producto que desea.
Un canal de comunicación natural entre la empresa y sus clientes es el teléfono
móvil. Actualmente son ya muchas las compañías que utilizan los mensajes de
texto (SMS) para vender sus productos, ofrecer rebajas y promociones o, simple-
mente, dar un servicio más al cliente. Como los avisos de algunas consultas médi-
cas, que se comunican con el paciente a través de un mensaje «corto» para recor-
darle el día en que deberá acudir a su siguiente visita. Otro ejemplo es el de los
bancos que ofrecen la posibilidad de consultar el estado de las cuentas a través de
un simple mensaje o ser notificados cada vez que ocurre una transacción con su
tarjeta de crédito a fin de poder detectar un fraude de forma inmediata.
La popularización de tecnologías móviles más potentes que la de los SMS,
como GPRS y la UMTS, va a permitir que pronto las empresas estén en contac-
to con sus clientes de forma casi permanente, gracias a un medio con muchas
posibilidades, capaz de ofrecer servicios a cualquier hora y lugar.

Los sistemas CRM, desde el más simple control de la información necesaria
para poder servir al cliente a través de los canales tradicionales lo mejor posible,
hasta los más sofisticados de seguimiento de la actividad comercial, cálculo de
rutas óptimas y propuestas de acciones comerciales, se están convirtiendo en
herramientas imprescindibles no sólo para la actividad comercial si no para la
gestión integral de la empresa. La información que se desprende de un CRM
adecuado permite calcular parámetros de negocio tan necesarios como el «valor
del cliente» (client equity), el valor esperado que representa un cliente de la
empresa a lo largo de su relación con la misma. Para un cálculo adecuado es
necesario disponer de costes como el de servir a un cliente concreto, cálculo que
sólo es posible si se dispone de información sobre el número de visitas de co-
merciales que ha recibido, el número de entregas, desde qué almacenes, las lla-
madas que ha realizado a los números de contacto, etc.
En definitiva, un sistema CRM, sea de mínimos o muy sofisticado, de elabo-
ración propia o de compra de paquete, es una necesidad ineludible para la em-
presa actual, y la alta dirección, de no haberlo hecho ya, debería poner en mar-
cha un proyecto para definir las características más adecuadas de CRM a implantar
en la empresa.
ANEXO: ESTRUCTURA DE LOS SISTEMAS CRM

Y PRINCIPALES PROVEEDORES
Aunque cada proveedor es diferente, existen unos «módulos básicos» comunes a
prácticamente todos ellos. El criterio para escoger uno u otro dependerá de la
funcionalidad y de la facilidad de adaptación a los sistemas actuales de la em-

presa, así como de la confianza que se tenga en los proveedores, tanto en el del
software propiamente dicho como en el implantador (prestigio, conocimiento,
etcétera). Los comentarios del Capítulo 4 sobre la elección de sistemas ERP son
de total aplicabilidad en este caso también. La Figura 6.3 muestra algunas de las
funcionalidades más comunes de los paquetes disponibles en el mercado.
Actualmente, son más de 200 los proveedores de aplicaciones CRM. Operan
en un mercado muy fragmentado, liderado por Siebel Systems –con más de un
23% de los ingresos mundiales derivados de CRM en el año 2003–, a quien
sigue Oracle con un 5,5 (véase Figura 6.4).
La evolución de los sistemas CRM ha estado marcada por dos fenómenos: en
primer lugar, el aumento de la funcionalidad de las aplicaciones exclusivas de
CRM y, en segundo, la necesidad de relacionar dichas aplicaciones con otros
sistemas integrados dentro de la empresa.
Los primeros proveedores del mercado de CRM se caracterizaban por estar
especializados en una de las posibles áreas de implantación de estas aplicacio-
nes, como marketing, ventas o servicio al cliente. Esto obligaba a las empresas
que deseaban implantarlo a adquirir aplicaciones de distintos proveedores, con
el consiguiente coste de integración, particularmente en tiempo. Esto obligó a
los principales vendedores a incrementar la funcionalidad de sus aplicaciones
para abarcar poco a poco todas las áreas relacionadas con los clientes.
Por otra parte, la necesidad de integrar aplicaciones de front-office (CRM) y
back-office (ERP) ha provocado que muchos proveedores de ERP y SCM, como
PeopleSoft o SAP, se «lancen» al mercado de CRM adquiriendo a pequeños pro-
Figura 6.3. Módulos típicos de los sistemas CRM.
Funcionalidad Módulos básicos Módulos avanzados (opciones)

Gestión de cuentas Generador de propuestas
Gestión de contactos Presentaciones
Gestión de oportunidades Campañas
Presupuestos de ventas Asistente de ventas
Seguimiento de actividades Integrador servicio al cliente
Ventas
Incentivos Integrador configurador
Mensajes corporativos Configurador de producto
Búsquedas Ofertas
Análisis de ventas Previsiones
Apoyo al cálculo / fijación de precios
Gestión de cuentas Asistente
Gestión de contactos Correo electrónico
Gestión de peticiones de servicio Gestión de calidad
Seguimiento de actividades Planificación de recursos de atención al cliente
Servicio al cliente Gestión de soluciones
Búsquedas
Seguimiento de activos
Mensajes corporativos
Seguimiento de la calidad
Seguimiento y configuración de activos Inventario
Servicio técnico Gestión de actividades de técnicos Gestión logística
Partes de servicio Expediciones
Data Mart Análisis de ventas
Comunicaciones de marketing Informes prediseñados
Campañas Data Mart Server
Marketing Análisis de campañas
Apoyo a la venta cruzada Análisis de servicio
Selección de clientes con mayor potencial comercial Seguimiento de eventos y alarmas
Figura 6.3. Módulos típicos de los sistemas CRM.

(Fuente: Conde, Antonio.; Trabado, Ana Mª.;
De la Torre, Juan Manuel, ICEMD, 2001.)

Kana Onyx E.piphany PeopleSoft

1,2 1,6 1,6 3,3
Pivitol
1,1 Amdocs
3,3
Oracle
5,5
Otros
59
Siebel
23,4
Figura 6.4. Distribución del mercado mundial de CRM por proveedores.

(Fuente: PwC Technology Forecast, 2002-2004.)
veedores de este sistema. De hecho, si comparamos los proveedores de CRM que

aparecen en el gráfico anterior con los de ERP que vimos en el Capítulo 4, obser-
vamos algunos que coinciden, como Oracle, PeopleSoft o E.piphany. Son muchos
los proveedores de ERP que en los últimos años se han lanzado a implantar solu-
ciones CRM en las empresas, no sólo para obtener una parte más del mercado del
software de empresa, sino como movimiento defensivo para impedir que entre
otro proveedor a gestionar partes importantes del sistema de información. Sin
embargo, como se ha comentado anteriormente, la mayoría de los estudios de
mercado realizados hasta finales de 2004 muestran que el mercado de CRM está
todavía liderado por proveedores de aplicaciones exclusivas de CRM como Sie-
bel. Aunque con la aparición de módulos CRM en los ERP, las empresas que
tienen implantado este último y se plantean adoptar un CRM consideran muy
seriamente la opción de seguir con el mismo proveedor, con lo que consiguen (en
principio) una mejor integración de información.
Los principales proveedores de CRM son los siguientes:
z Siebel Systems. Siebel es el primer proveedor del mundo de aplicaciones

de CRM. Con más de 3.500 clientes y un millón de usuarios en todo el
mundo, proporciona soluciones para todo tipo de industrias basadas en el
establecimiento y mejora de las relaciones con clientes gracias a sus apli-
caciones de marketing, sistemas de call center, servicios y ventas
multicanal. Además, es uno de los proveedores con más aplicaciones es-
pecíficas para industrias como automoción, comunicaciones, energía, fi-
nanzas, seguros, medicina o viajes. La mayoría de sus clientes adquieren
más aplicaciones específicas que genéricas. Poco a poco, la empresa ha
ido transformando su arquitectura de aplicaciones, basada exclusivamen-
te en software de cliente muy pesado (thick client applications), en apli-
caciones Web que han incorporado un gran número de mejoras durante
los años 2000 y 2001, añadiendo una considerable funcionalidad a sus

productos y convirtiéndolos en aplicaciones mucho más integradas y lige-

ras para el hardware del usuario final. (www.siebel.com)
z Oracle. Es el segundo proveedor de CRM más importante del mercado
después de Siebel. Sus aplicaciones contienen call centers (que ellos de-
nominan Interaction Centers), e-commerce, automatización de ventas,
configuración del producto, servicio al cliente, gestión de las campañas
de marketing y módulos de apoyo a los comerciales. (www.oracle.com)
z PeopleSoft. Desde el lanzamiento en 2001 de su aplicación PeopleSoft 8
CRM (PS 8 CRM) presenta una arquitectura basada en la Web que hace que
las aplicaciones CRM sean accesibles desde cualquier navegador. Además de
sus propias aplicaciones, PeopleSoft decidió adquirir Vantive en 1998. Ac-
tualmente, los principales módulos que incluye son marketing, ventas, man-
tenimiento y servicio, HelpDesk, Soporte, el Customer Interaction Center y
aplicaciones móviles para ventas (www.peoplesoft.com). En enero de 2005,
Oracle adquirió Peoplesoft.
z Amdocs/Clarify. Clarify, especializada en clientes y soporte técnico para
call centers y Amdocs, con sus sistemas de gestión de pedidos y factura-
ción para telecomunicaciones o mercados verticales de servicios, se fu-
sionaron en 2001 para convertirse en un proveedor potencial de aplica-
ciones CRM. Su CRM contiene tres módulos básicos: ventas y marketing;
servicio, soporte e inteligencia de negocio; y análisis del cliente.
(www.amdocs.com)
z E. Piphany. Aunque inicialmente era un proveedor exclusivo de solucio-
nes analíticas, comenzó a distribuir aplicaciones de CRM gracias a la
adquisición de la compañía Octane en el año 2000. Sus productos se ba-
san principalmente en software de análisis de e-business y enlazan siste-
mas analíticos y sistemas operacionales. Los analíticos son los más im-
portantes dentro de E.Piphany. Así lo demostró su aplicación E.5, que
incluía marketing integrado y personalizado y aplicaciones de ventas y
servicios. A finales de 2002 E.Piphany lanzó su nueva aplicación E.6,
provista de una de las más modernas arquitecturas basadas en la Web,
mucho más integrada y con herramientas de CRM, tanto analítico como
operacional, capaces de gestionar de forma eficaz y personalizada las
relaciones con los clientes desde cualquier punto de contacto o touch
poin. (www.epiphany.com)
z Kana Software. Se describen a sí mismos como proveedores de solucio-
nes e-CRM. Incluyen aplicaciones de marketing, e-commerce y funcio-
nes de servicio basadas en una arquitectura capaz de funcionar tanto en
sistemas UNIX como en Windows. Entre estas funciones cabe destacar la
solución para la gestión de e-mails a un bajo coste y con elevadas presta-
ciones. (www.kana.com)


La externalización de los servicios de TIC y el Business Process... 115
7
La externalización
de los servicios de TIC
y el Business Process
Outsourcing (BPO)
En 1999, una editorial de la Harvard Business Review rezaba: «Cuando una

compañía hace algo que otros pueden comprar o hacer de forma más eficiente,
está sacrificando una ventaja competitiva. Concéntrese en aquello que propor-
ciona a su empresa ventaja competitiva. Subcontrate el resto. El outsourcing es
una de las herramientas de gestión más importantes de los últimos 75 años»1.
Inicialmente, las empresas desarrollaban internamente todas las actividades
necesarias para su operativa diaria, estuvieran o no directamente relacionadas
con su negocio principal. Pronto se dieron cuenta de que era mucho mejor cen-
trar sus esfuerzos y capacidades en aquellas operaciones que constituían el nú-
cleo de su negocio y añadían valor a los clientes, permitiéndoles diferenciarse de
la competencia.
Las empresas empezaron por subcontratar a terceros (hoy se usa el vocablo
«externalizar», traducción libre del inglés to outsource, o outsourcing en gerun-
dio2) procesos poco críticos, como los servicios generales de limpieza, los de
agencia de viajes, mensajería, etc. Lo hacían por diversas razones, entre las que
destacan el menor coste y la falta de personal especializado. Después continua-
ron externalizando procesos con impacto más directo en el negocio, como la
logística y la distribución. Se trataba de procesos que requerían de infraestructu-
ra y know-how importante, que aconsejaban dejar estas tareas en manos de em-
presas especialistas cuyos procesos centrales fueran precisamente estos.
En el área de sistemas de información, la externalización ha estado presente
ya desde los albores de la informática, cuando los denominados «centros de
cálculo» externos ejecutaban los procesos batch de terceras empresas.
El auge de la informática durante la década de los ochenta y el abaratamiento
de estos sistemas hizo que las empresas dispusiesen de recursos necesarios para
1
Ertel, Danny. Turning negotiation into a corporate capability, Harvard Business Review,
1999.
2
En este texto se usarán indistintamente los vocablos externalización y outsourcing.
115

desarrollar de forma interna la mayoría de aplicaciones que necesitaban. En aquella

época, por norma general sólo aquellas empresas que requerían sistemas complejos,
altamente especializados y a un coste muy elevado, recurrían al outsourcing.
No obstante, el concepto de outsourcing desde el punto de vista de las tecno-
logías de información y comunicación (TIC) dio un giro de 180 grados a princi-
pios de 1990. Son innumerables las referencias que se han hecho a lo largo de
los últimos años a la alianza entre Eastman Kodak e IBM (véase Cuadro 7.1),
considerándolo como el primer ejemplo de lo que se podría denominar «out-
sourcing estratégico». No se trataba de una simple contratación de servicios
informáticos a un proveedor especializado, sino un modelo de gestión que per-
mitía a Kodak centrarse en su negocio básico y dejar en manos de otros aquello
que no suponía un aspecto crítico para su desarrollo estratégico.
Hasta los años noventa, los principales motivos de la externalización de las
TIC eran la relación coste-eficiencia: el ahorro derivado de no desarrollar inter-
namente determinadas capacidades y el acceso a perfiles profesionales específi-
cos. Sin embargo, a partir de los noventa se produjo un auge del IT Outsourcing.
Además de los factores anteriores, también incidían la alta variabilidad del en-
torno tecnológico y las alianzas estratégicas con proveedores de TIC, cada vez
mejor organizados y con políticas de venta muy agresivas, quienes aseguraban
la última tecnología a unos costes controlados.
Sin embargo, la evolución del outsourcing continúa y al inicio del nuevo mile-
nio da un paso más, algunas empresas empiezan a externalizar procesos de nego-
cio completos, no considerados estratégicos para la compañía pero con un alto
componente tecnológico y de capital humano. En su mayoría se trata de procesos
administrativos, lo que permite a las empresas centrarse en su negocio principal.
Es lo que se ha venido a llamar el Business Process Outsourcing (BPO). Este
capítulo trata en su mayor parte de la externalización de las TIC, y la última sec-
ción extiende los conceptos desarrollados al BPO.
¿QUÉ SE ENTIENDE POR LA EXTERNALIZACIÓN

DE LAS TIC?
La externalización u outsourcing es la ejecución de procesos y actividades rela-
cionadas con las TIC de una organización por parte de una empresa externa que
cuenta con su propia estructura, recursos, capacidad de decisión y gestión. Las
relaciones entre ambas empresas se rigen por un contrato que contiene los acuer-
dos de nivel de servicio. De hecho, externalizar no es más que un tipo de acuerdo
por el que una empresa proporciona a otra servicios, que podrían haber sido
desarrollados internamente.
En un ámbito más general, se puede entender la externalización como:
z La transferencia a un tercero de la responsabilidad continuada del sumi-

nistro de servicios, gobernado por un acuerdo de nivel de servicio.
z El acto de transferir alguna de las actividades y derechos de decisión
internos y repetitivos de una organización a un suministrador externo,
amparados en un contrato.
z La práctica de transferir la planificación, administración y operación de
ciertas funciones a un tercero independiente.

En 1989, KODAK cerró un acuerdo con IBM Corporation, Digital Equipment

Corporation y Businessland Inc. para externalizar la gestión de los siste-
mas informáticos durante 10 años por 250 millones de dólares. Éste no
fue el primer acuerdo de IT Outsourcing de la historia pero sí el de más
difusión. De hecho, con este movimiento, KODAK hizo con el IT Outsour-
cing lo que IBM había hecho con el PC: legitimarlo frente a las grandes
empresas.
Al decidir sobre la externalización de la gestión de sus sistemas infor-
máticos, KODAK pretendía centrarse en su negocio principal y abandonar
el negocio de los sistemas de información, que se había visto obligada a
adoptar después de 109 años de operatividad. Sobre unos ingresos anua-
les de 18.400 millones de dólares, el presupuesto de TIC era de 250
millones de dólares, de los que 90 millones suponían gastos de perso-
nal. «¿Por qué estábamos gastando tanto en algo que no era fotografía?
¿Cuál era nuestra misión? Nuestra misión no era ser el líder mundial en
sistemas de información», afirmaba Kathy Hudson, Directora de Sistemas
de Información (CIO)3 de KODAK.
Después de un año de negociaciones, la externalización se llevó a
cabo de la siguiente manera: Digital Equipment Corporation se encargó
de la gestión de telecomunicaciones, Businessland de la compra y mante-
nimiento de PC e IBM asumió la gestión del proceso de datos. Para garan-
tizar el éxito de la operación, KODAK transfirió 700 de sus empleados a
las tres compañías –300 de ellos a IBM.
Lo que en aquel momento se interpretó como una «locura» liderada
por Kathy Hudson, fue el inicio de un proceso que permitió a KODAK,
durante su primer año de IT Outsourcing, reducir los costes de personal
de TIC en un 95%, los costes de mantenimiento de PC de un 5 a un 10%,
y los costes de telecomunicaciones entre un 10 y un 15%. De las 700
personas trasladadas a las empresas proveedoras, sólo un 1% rechaza-
ron el nuevo trabajo. El resto lo entendieron como una oportunidad de
desarrollo profesional. En 1991, Hudson fue promocionada a CEO de la
división de Impresoras y Publicaciones de KODAK y en 1994 pasó a ser la
CEO de Brady Corporation.
Pero lo más destacable del caso KODAK es que originó un cambio de
mentalidad en los directores de TIC. Hasta entonces, ningún director res-
petable se hubiera atrevido a externalizar masivamente las TIC a un terce-
ro. A partir de KODAK, ningún director respetable se hubiera podido permi-
tir no considerar el IT Outsourcing como una alternativa en la toma de
decisiones.
3
CIO: Chief Information Officer.
Cuadro 7.1. Los inicios del IT Outsourcing: el caso KODAK.

Aunque la idea inicial tras estas definiciones ha sido constante desde el inicio
del outsourcing, los fuertes cambios que experimentan continuamente los merca-
dos han variado los motivos que impulsan a las empresas a externalizar. Hoy en
día, es la elevada complejidad de los procesos que tienen lugar en las empresas lo
que hace necesaria la ayuda de otras compañías especializadas.
Basados, pues, en el incremento de la complejidad y los retos de la empresa,
se puede pensar en cuatro motivos que pueden llevar a las empresas a externali-
zar parcial o totalmente algunos de sus procesos internos:
z Debido a la existencia de una competencia muy elevada en prácticamente

todos los sectores y a la mejora continua de la relación calidad/precio, las
empresas tienen la necesidad de centrarse en el negocio básico, dejan-
do en manos de otros aquellos procesos que no sean de vital importancia
para el desarrollo global del producto o servicio.
z En la línea de conseguir una mayor calidad en los productos finales y a un
coste menor, muchas compañías están obligadas a renovar sus equipos y
sistemas de información, por lo que deben enfrentarse a un cambio tec-
nológico sustancial para poder competir. En ocasiones, dicho cambio no
puede llevarse a cabo de forma íntegra en la empresa y requiere la ayuda
de externos para la realización de aquellos procesos más sofisticados.
z Sin embargo, no basta con adaptar la empresa a los cambios tecnológi-
cos. Es necesario, además, la participación de personal (altamente) cuali-
ficado para poder llevar a cabo las operaciones que tienen lugar en los
procesos más complejos. El alto coste que supone el personal especiali-
zado y la alta rotación hacen de la escasez de especialistas una razón
para externalizar ciertos servicios.
z Por último, los cortos ciclos de vida de muchos productos, los cambios
constantes en la demanda del mercado y, en ocasiones, la exigencia de
servicios a medida, hacen necesaria una mayor flexibilidad en la presta-
ción de los servicios TIC de las empresas.
Aunque las que se acaban de citar son las razones más representativas que
pueden llevar a una empresa a externalizar un servicio, también se deben tener
en cuenta otras capacidades de los proveedores que pueden ser beneficiosas para
la empresa. Entre éstas, cabe destacar la mayor capacidad que normalmente
éstos tienen para negociar las licencias de software, una respuesta mucho más
agresiva a los cambios del mercado, costes de personal menores gracias al tras-
lado de la producción a otros países y, en general, su enfoque en la calidad del
servicio prestado ya que su éxito depende exclusivamente de la satisfacción de
sus clientes y su recomendación a otros.
De acuerdo con lo anterior el outsourcing, al liberar recursos, es una posible
fuente de ventaja competitiva para las empresas.
Al estudiar el outsourcing cabe distinguir entre diversos niveles en función
del grado de subcontratación. Los niveles típicos de análisis, de mayor grado de
externalización a menor, son el «ousourcing total», el «selectivo», y el «out-
tasking».
Se habla de outsourcing total cuando todo el departamento de sistemas de
información pasa a manos de un proveedor externo. El proveedor decide qué
hardware instalar en el centro de datos, qué procedimientos de desarrollo de

sistemas seguir, qué proveedor de telecomunicaciones contratar e incluso las polí-

ticas de personal. La empresa cliente transfiere la responsabilidad de cómo hacer
las cosas al proveedor, y se limita a exigir una calidad de servicio acordada al
precio pactado.
Existe también la posibilidad de externalizar los servicios parcialmente. Es
lo que se define como outsourcing parcial o selectivo, en el que únicamente
ciertos procesos se transfieren al proveedor. Entre los más habituales están:
z Operación de equipos informáticos en la localización física del cliente.

z Operación de equipos informáticos en la localización del suministrador
con un parque informático compartido.
z Suministro de servicios de redes de telecomunicaciones ya sean circuitos
de datos, voz o ambas cosas.
z Explotación y desarrollo de aplicaciones ya existentes.
z Explotación de nuevos sistemas.
z Desarrollo y soporte técnico de los sistemas.
Actualmente, una de las variantes del outsourcing parcial es el denominado

out-tasking. El out-tasking es un modelo de contratación de servicios que permi-
te a las organizaciones encargar a determinadas personas o compañías que se
hagan cargo de cuestiones específicas de la operación, por ejemplo la impresión
de facturas o del desarrollo de sus sistemas de información. En ocasiones, el out-
tasking se considera el paso inicial hacia un futuro contrato de externalización
más amplio
Si se toma la decisión de externalizar totalmente los servicios, el Departa-
mento TIC se reduce drásticamente. Las tareas que siguen siendo responsabili-
dad del reducido departamento se limitan a la relación con el proveedor y al
control de la calidad de los servicios prestados. A estas tareas se dedica la parte
del personal original que se queda en el Departamento. Es habitual acordar con
el proveedor que se haga cargo de la parte de la plantilla que no se quedará en la
empresa. Esta transición se acostumbra a ver con buenos ojos por la mayor parte
de los empleados con conocimientos de tecnología, ya que en general podrán
disponer de mejores oportunidades de carrera en una empresa de servicios de
outsourcing que en la empresa original.
Outsourcing de infraestructura y outsourcing de aplicaciones
Desde el punto de vista de «qué» se subcontrata, se suele distinguir entre la

subcontratación de infraestructura y la de aplicaciones. El outsourcing de infra-
estructura consiste en ceder a un proveedor el control sobre toda (o parte) de la
infraestructura de TIC y puede incluir tanto los sistemas distribuidos y la micro-
informática como los centros de procesos, y/o la red de comunicación:
z Outsourcing de sistemas distribuidos y microinformática: engloba el ase-

soramiento, implantación y gestión de plataformas, la renovación tecno-
lógica –inventario y renovación de equipos–, el help desk centralizado, la
gestión y administración de servidores y la implantación de herramientas
y procedimientos.

z Outsourcing de centros de procesos: aglutina la operación y explotación de

sistemas, la gestión de base de datos, la monitorización de sistemas, el
reporting, el soporte a técnica de sistemas, el soporte a usuarios (help
desk), la seguridad física y lógica y los servicios de back-up y de recupe-
ración de negocio.
z Outsourcing de la red: engloba la gestión de redes WAN4, LAN5, las
infraestructuras de redes y la integración de gestión de datos, voz y vídeo.
El outsourcing de aplicaciones cede al proveedor la ejecución de los proce-

sos y normalmente conlleva que éste contrate directamente con el proveedor de
software. Puede llevarse a cabo en dos niveles: el Outsourcing realizado por
personal externo en casa del cliente, utilizando por tanto su infraestructura, o el
outsourcing realizado por personal externo fuera de las instalaciones del cliente,
utilizando la infraestructura del propio proveedor tecnológico.
En el primer nivel, también denominado in-house, el proveedor tecnológi-
co se encarga de contratar las licencias necesarias, llevar a cabo desarrollos de
aplicaciones, así como su mantenimiento. Puede tratarse de aplicaciones a
medida para la empresa o simplemente de instalación y/o mantenimiento de
paquetes estándares (como los ERP o CRM discutidos en los Capítulos 4 y 6).
Las aplicaciones se alojan en los servidores de la empresa y son de su uso
exclusivo.
En el segundo nivel, llevado a cabo fuera de las instalaciones de la empresa
–y por ello denominado off-house–, el proveedor tecnológico realiza el mismo
trabajo pero utilizando sus propios servidores, posibilitando que las aplicacio-
nes puedan ser compartidas por varias empresas que tengan el mismo proveedor.
En este segundo tipo de outsourcing, cuando las aplicaciones son compartidas
por múltiples clientes, el proveedor de servicios se denomina también Applica-
tion Service Provider o ASP.
La decisión sobre si perseguir un enfoque in-house u off-house del outsour-
cing de aplicaciones se debería tomar teniendo en cuenta sus respectivas venta-
jas e inconvenientes, tal como se muestra en la Figura 7.1.
Finalmente, el outsourcing de entornos Internet o e-business hosting de una
empresa se encarga del alojamiento y la gestión del entorno e-business de sus
clientes.
Por alojamiento se entiende desde el espacio físico especialmente preparado
para que las empresas instalen allí sus máquinas, contando con toda la infraes-
tructura de comunicaciones y las funciones necesarias (seguridad física, siste-
mas de refrigeración, generadores, etc.), hasta el «alquiler» de un espacio dentro
de un ordenador para instalar allí sus sistemas. Servicios adicionales como la
monitorización (seguimiento) de los sistemas, la elaboración de informes de
rendimiento y la disponibilidad o la implantación de sistemas de seguridad (fi-
rewalls) que, por ejemplo, eviten las entradas al sistema no autorizadas, también
se incluirían dentro de este apartado.
4
WAN: Wide Area Network. Véase Capítulo 2 y el glosario al final de esta obra para una defini-
ción más completa de estos términos.
5
LAN: Local Area Network. Véase Capítulo 2 y el glosario al final de esta obra para una defini-
ción más completa de estos términos.

Ventajas Inconvenientes
Adecuación “a medida” del Caro

producto Mantenimiento
Outsourcing Mayor control sobre el impacto personalizado con personal
de aplicaciones en usuarios exclusivo
“in-house” Autonomía en gestión de Dificultad en actualizaciones
modificaciones/actualizaciones debido a los desarrollos a
Confidencialidad absoluta medida
Permite variabilizar
Mayor impacto sobre
completamente los recursos
usuarios –adecuación a
Outsourcing Compartición de recursos
estándares
de aplicaciones técnicos para instalación y
Menor nivel de autonomía
“off- house” mantenimiento
para cambios
Evolución “garantizada” por el
Accesible por competidores
proveedor
Figura 7.1. Ventajas e inconvenientes del outsourcing de aplicaciones in-house

frente a off-house.
Ventajas y desventajas del outsourcing de las TIC
Según sus defensores y los proveedores de servicios, el outsourcing presenta múl-

tiples ventajas. Permite controlar los costes derivados de la gestión de la infraes-
tructura tecnológica durante los años de vigencia del contrato, transformar costes
fijos en costes variables; centrarse en el negocio clave de la empresa; mejorar la
calidad del servicio al establecer, de forma garantizada, unos objetivos de calidad
y nivel de servicio determinados; mayor capacidad para adaptarse rápidamente a
los cambios en el negocio; y una mayor agilidad para tomar decisiones al centrar
los esfuerzos, tiempo y recursos en aquellas actividades que aportan mayor valor
añadido. La externalización fomenta la innovación al proporcionar acceso a las
últimas TIC y, si el proveedor es de entidad suficiente, posibilita el aprendizaje de
las mejores prácticas en la gestión del recurso TIC en el sector. Además presenta
oportunidades de carrera a personas con perfil tecnológico que acostumbran a ver
cerradas sus posibilidades de desarrollo profesional en empresas cuyo negocio
central no son las TIC.
También existen argumentos contra la externalización de las funciones de TIC6.
Los detractores de este tipo de soluciones argumentan que los proveedores tecno-
lógicos no están plenamente involucrados al no depender sus ingresos de los resul-
6
Véase: «The Information Systems Outsourcing Bandwagon», Lacity, MC y Hirschheim, R.
Sloan Management Review, Otoño 1993.

tados de negocio de la compañía a la que sirven. Además, los departamentos inter-

nos de TIC pueden ser tan competitivos en coste como los propios proveedores, ya
que la mayoría de las empresas pueden funcionar correctamente sin necesidad de
utilizar la tecnología más avanzada. Otras razones para no externalizar son que los
descuentos por volumen a grandes empresas muchas veces son imperceptibles una
vez transferidos al cliente, y que la desaparición de personal interno dificulta la
adquisición de nuevos conocimientos, aunque si éstos no están directamente rela-
cionados con el core business quizá no sean tan importantes. También argumentan
los detractores del outsourcing que en muchos casos la empresa no obtiene ventaja
del abaratamiento de los costes de la tecnología del que se aprovecha el propio
proveedor y que muchos de los ahorros no provienen de realizar una labor más
eficiente sino de realizar negociaciones contractuales más exitosas e imaginativas,
así como de explicitar de forma evidente los costes de las operaciones.
El Cuadro 7.2 presenta de modo resumido los potenciales beneficios y ries-
gos normalmente asociados con la externalización de los diferentes servicios de
TI, sea ésta total o parcial.
Beneficios
Estratégicos:
z Mejorar la posición competitiva mediante un rápido acceso a la van-
guardia tecnológica.
z Mejorar la calidad del servicio a sus clientes.
z Incorporar visión y experiencias de otros sectores de actividad a tra-
vés de las capacidades adquiridas por el proveedor.
Financieros:
z Reducir las necesidades de capital inmovilizado.
z Incrementar el control del flujo de caja y de los costes.
z Reducir los costes propiamente dichos por economías de escala y
poder compartir equipos, instalaciones y personal.
z Liberar espacio en las propias instalaciones.
Técnicos:
z Conseguir flexibilidad tecnológica tanto en software como en hardware.
z Mejorar la capacidad tecnológica disponible para la empresa.
z Acceder a un repositorio de conocimiento para obtener la solución
más adecuada en cada momento.
Gestión:
z Concentrarse en las partes del negocio cruciales para competir.
z Delegar en un proveedor partes engorrosas de la planificación, desa-
rrollo y gestión de grandes sistemas.
Cuadro 7.2. Beneficios y riesgos potenciales del outsourcing.

z Eliminar la necesidad de contratar y retener personal competente de

TIC.
Recursos Humanos:
z Conseguir la participación de especialistas para resolver problemas
concretos de un pool del proveedor.
z Enriquecer las oportunidades de carrera del personal propio.
Calidad:
z Definir con claridad los niveles de servicio.
z Aumentar la responsabilidad sobre los sistemas, su explotación y
mantenimiento.
z Trabajar con un departamento certificado por su calidad.
Flexibilidad:
z Responder con rapidez a las necesidades del negocio.
z Gestionar los picos y valles de demanda con efectividad.
Riesgos
Estratégicos:
z El proveedor usa las capacidades y habilidades desarrolladas durante
la relación con la empresa para ayudar a un rival a competir mejor
contra la primera empresa.
z El proveedor quiebra y deja de prestar el servicio de manera súbita.
z Perdida del "conocimiento interno" sobre las funciones o servicios
externalizados, dificultando la marcha atrás si fuera necesaria.
Financieros:
z Utilizando los costes asociados a romper el contrato, el proveedor in-
crementa desproporcionadamente las tarifas al añadir más servicios
al contrato inicial.
Calidad:
z El proveedor no alcanza los niveles de calidad acordados, sea de ma-
nera deliberada o no7.
z Los niveles de calidad acordados se manifiestan insuficientes para el
negocio.
7
Algunos autores, por ejemplo Clemons (en Clemons EK «The Build/Buy Battle» CIO
Magazine, 1 diciembre 2000), argumentan que los proveedores tienen tendencia a reducir la
calidad de los servicios manteniendo la facturación; ello se acostumbra a hacer reduciendo
el nivel de las personas dedicadas a los proyectos.

Técnicos:
z Tasas elevadas de rotación del personal del proveedor pueden provo-
car problemas para el mantenimiento o desarrollo de los servicios
prestados y niveles de cualificación por debajo de los esperados.
Gestión:
z La falta de homogeneidad en la gestión del proveedor por múltiples
gestores internos puede erosionar la capacidad de gestión del mismo,
con impactos directos en la calidad de los servicios prestados y en
los costes.
LA GESTIÓN DE LA EXTERNALIZACIÓN
Desde el momento en que una empresa empieza a contemplar la posibilidad de
externalizar sus TIC, sea de forma total o parcial, hasta que el nuevo formato
funciona adecuadamente, se deben seguir una serie de pasos que, aun no siendo
estrictamente secuenciales, ayudan a que el proceso de cambio llegue a buen
puerto. Estos pasos, que se describen en los siguientes párrafos, son:
1. Evaluación de la necesidad de externalizar.

2. Determinación del tipo de relación a establecer.
3. Establecimiento de los acuerdos de nivel de servicio.
4. Selección del proveedor y contratación.
5. Transición.
6. Seguimiento de la relación.
Fase 1. Evaluación de la necesidad de externalizar
La decisión de externalizar un proyecto o servicio debe tomarse sobre la base de

un conocimiento global de la empresa y de su funcionamiento y, principalmen-
te, de la estructura y actividades que realiza el departamento TIC. Es necesario
conocer perfectamente qué procesos se están realizando internamente y cuáles
están subcontratados, cuál es el coste de ambos, qué grado de satisfacción hay
en el resto de la empresa acerca de los trabajos del departamento o cuál es el
grado de eficacia del control de la organización sobre el departamento TIC.
Para evaluar de forma efectiva la necesidad de externalizar parcial o total-
mente los servicios del área de TIC, tres son las etapas en las que se debe dividir
el proceso:
z Estudio y construcción del actual modelo de Sistemas de Información

(SI).
z Determinación de los objetivos estratégicos de las funciones de TIC.

z Evaluación de la conveniencia de externalizar o llevar a cabo las activida-

des internamente.
Estudio y construcción del actual modelo de Sistemas de Información (SI)
El estudio y la construcción del actual modelo que se plantea en la primera fase del
proceso debe identificar y definir las funciones de la organización, analizando los
costes de los actuales sistemas y todo aquello relacionado con este coste, así como
definir los componentes tecnológicos de que dispone la empresa. El principal ob-
jetivo de esta fase es separar los hechos y los datos de las percepciones, así como
desarrollar con suficiente detalle un esquema general del funcionamiento de la
organización, su situación financiera y el uso y la importancia de los sistemas de
información que tiene a su disposición. En esta fase, también se debe desarrollar
un marco para medir el rendimiento de estos sistemas.
Para llevar a cabo esta etapa, es necesario establecer una metodología de
búsqueda de información y su posterior análisis a través de entrevistas con la
dirección general, componentes del departamento de TIC y un buen número de
usuarios de los sistemas que la empresa utiliza actualmente. Se debe además
definir explícitamente la organización de TIC (su equipo, responsabilidades fun-
cionales, servicios que realizan, servicios que tienen contratados y datos históri-
cos que puedan resultar de utilidad), así como sus costes de estructura, desde la
inversión en sistemas hasta el mantenimiento o soporte.
En cualquier caso, todos estos datos permitirán construir un modelo para
poder seguir de cerca el funcionamiento actual del departamento TIC y poder
controlar fácilmente lo que se podría denominar la «productividad» de este de-
partamento. Además, se debe ser capaz de evaluar todos estos datos a través de
parámetros específicos de rendimiento. No se olvide que lo que no se puede
medir, difícilmente se podrá controlar (la experiencia demuestra que el 90% de
operaciones relacionadas con las TIC no utilizan medidas de productividad).
Hay pues que definir un marco en el que poder medir la calidad, productividad,
productos y procesos del departamento TIC. La evaluación de todos estos pará-
metros es uno de los aspectos más costosos del proceso.
Hay dos motivos por los que el desarrollo de las medidas de productividad es
crítico para el estudio de un futuro proceso de outsourcing: (1) Si al final se
decide externalizar algunos de los servicios, las medidas que se han tomado
deben servir para aceptar o no los niveles de rendimiento y eficacia que vaya a
proporcionar el proveedor, y (2) implementando las medidas tomadas, se pue-
den identificar aquellos productos o procesos que pueden tener algún defecto en
el futuro y, una vez detectados, corregirlos para ganar en productividad.
Algunas estadísticas muestran que un elevado porcentaje de los costes aso-
ciados a la explotación y mantenimiento de los sistemas de información son
prácticamente innecesarios. Muchas organizaciones no tienen acceso a informa-
ción tan básica como el coste agregado de reparar defectos de software, la fre-
cuencia o tipo de errores en el procesamiento de datos, o las causas de numero-
sos otros defectos. Puesto que la productividad es un derivado directo del coste,
el correcto establecimiento de medidas de rendimiento y eficiencia pueden ayu-
dar a los departamentos TIC a gestionar y manejar las mejoras de calidad y
producción de sus operaciones, aún antes, o incluso sin, llegar al outsourcing.

Determinación de los objetivos estratégicos
Es aquí donde se debe evaluar el funcionamiento del departamento TIC y juzgar

su productividad en el contexto global de la empresa. En esta fase se debe estu-
diar cómo este departamento contribuye al éxito de la empresa. Por ejemplo, se
debe establecer si el departamento de sistemas proporciona ventajas estratégicas
o competitivas para la empresa, si proporciona algún componente que diferencia
a la organización de la competencia o si, simplemente, es un servicio de soporte
para la realización de las demás funciones de negocio.
El consenso a niveles estratégicos es importante puesto que constituye la base
para tomar decisiones futuras respecto a los SI. Aquí es donde se desarrolla am-
pliamente el verdadero propósito/objetivo de estos sistemas. En este sentido, se
puede estudiar su contribución a la empresa desde diferentes puntos de vista.
En un primer caso, se puede pensar en las TIC como elementos que incorpo-
ren ventajas competitivas a la organización en los términos discutidos en los capí-
tulos anteriores. A un nivel menos estratégico se puede ver los SI de una empresa
como una ayuda indirecta para mantener posiciones competitivas mediante ope-
raciones de bajo coste o, simplemente, como elementos de soporte a otras unida-
des funcionales sin que aquellos influyan en la diferenciación de la empresa.
Evaluación de la conveniencia de externalizar o llevar a cabo

las actividades internamente
La filosofía de la externalización de servicios consiste en dejar en manos de em-

presas externas aquello que no tenga una importancia crítica en la estrategia vi-
gente y que no necesite capacidades internas especiales. En cualquier caso es nece-
sario mantener internamente un núcleo central de profesionales con capacidad de
gestión, visión de servicio y del cliente y conocimiento de las necesidades del
negocio, de la organización interna y, en su caso, de la integración de tecnologías.
Se puede basar la decisión de externalizar en función del nivel de riesgo o
grado de vulnerabilidad por posibles fallos y del grado de relación de los procesos
con las competencias clave del negocio, tal como se muestra en la Figura 7.2.
Fase 2. ¿Qué tipo de relación establecer?
Una vez seleccionados aquellos servicios que se externalizarán, se debe adoptar

una metodología a seguir para gestionar correctamente el proceso. Aunque no
hay unas pautas obligadas a seguir por las empresas que deseen externalizar, el
siguiente guión aporta una base para llevar a cabo el proceso.
Uno de los condicionantes del tipo de relación es determinar en qué cuadran-
te de la Figura 7.2 están los procesos a externalizar, es decir si aportan ventaja
competitiva, son críticos o simplemente son de soporte.
Servicios de soporte de baja criticidad
z Son los candidatos por excelencia a la externalización.

Externalización Mantener
Alto
condicionada “en casa”
Nivel de riesgo
asociado
Externalización
Bajo Externalizar
condicionada
Soporte Aporta valor
Tipo de proceso
Figura 7.2. Evaluación de deseabilidad y tipo de externalización en función

del nivel de riesgo y el tipo de proceso.
z Proporcionan, mantienen y actualizan los sistemas y soportes técnicos.

z No son críticos, puesto que no paralizan la actividad normal del negocio
en caso de incidencia.
z Son necesarios para que todas las aplicaciones técnicas y de negocio fun-
cionen a plena capacidad.
z En su externalización, la empresa debe mantener el control de la forma
de hacer las cosas pero el coste pasa a ser un elemento muy relevante en
la elección del proveedor.
Servicios de soporte de alta criticidad
z Son necesarios para la operatividad normal del negocio.

z Los fallos en estos servicios pueden llegar a detener la actividad diaria
pero no aportan valor diferencial.
z Los planes de contingencia son imprescindibles y deben ser una parte
fundamental del acuerdo de servicio.
z Aunque el servicio en sí mismo se puede externalizar, el conocimiento de
los parámetros clave de su seguimiento y su control deben quedar dentro
de la empresa.
Servicios que aportan ventaja competitiva pero de baja o moderada criticidad
z Están íntimamente ligados a las competencias clave del negocio y las

potencian y dan mayor valor a la empresa a través del aumento de nego-
cio o de eficiencia/calidad, en el momento actual o futuro.

z La externalización de estos servicios debe preservar estas ventajas y a ser

posible aumentar las competencias clave.
z En estos casos es necesaria una selección cuidadosa de la parte del servi-
cio a subcontratar y una elección meticulosa del proveedor.
z Para este tipo de actividades será necesario contar con un proveedor que
se pueda calificar más de «socio» que de simple proveedor con el que se
mantienen relaciones comerciales más o menos distantes.
Servicios críticos y de alto valor añadido
z Son los menos indicados para la externalización.

z Es posible, y a veces imprescindible, subcontratar cuando sea necesa-
rio completar el know-how interno con aportaciones externas, pero
siempre con el objetivo de internalizar en lo posible el conocimiento
externo.
z Hay que ser extraordinariamente meticuloso con la elección del provee-
dor.
z El coste pasa a un segundo término.
De acuerdo con esta clasificación, se deben determinar las bases en las que
deberá fundamentarse la relación con los proveedores, fijando no sólo los nive-
les de servicio (de los que se habla en la sección siguiente), sino también la
periodicidad de reuniones de seguimiento, informes a entregar, y eventuales po-
sibilidades de renegociación del acuerdo.
Fase 3. Establecimiento de los niveles de servicio
Un elemento esencial de toda relación de outsourcing es el establecimiento,

seguimiento y cumplimiento de los acuerdos de nivel de servicio, a los que nor-
malmente se refiere por su siglas inglesas SLA (Service Level Agreements). Los
SLA constituirán la base para el correcto seguimiento de la calidad de los proce-
sos subcontratados una vez implantados y por ello, deberán ser lo más claros y
detallados posible, sin que pueda haber duda sobre los parámetros que se están
midiendo.
Ejemplos de SLA son:
z «El 95% de las facturas se enviarán en menos de 24 horas tras recibir los
ficheros».
z «Todas las llamadas al Help Desk se responderán en menos de 90 segun-
dos».
z «La página Web estará disponible el 99,99% del tiempo».
Desafortunadamente, el problema está en los detalles, que muchas veces ha-

cen difícil el seguimiento de lo que aparentemente es trivial. En el ejemplo
anterior de impresión y envío de facturas no hay suficiente detalle para poder
juzgar el desempeño del proveedor. Una redacción mejor del primer ejemplo
podría decir:

z Las facturas se deben imprimir, ensobrar y enviar de la manera más rápida

posible para asegurar el máximo adelanto en el cobro. El objetivo es que el
95% de las facturas sean correctamente impresas y depositadas en el servi-
cio de mensajería antes de las 24 horas posteriores a la transferencia de los
ficheros. La medida de la producción será el informe del servicio de
mensajería y el informe (log) del programa de facturación. Si el número de
facturas emitidas está por debajo del 95% se establecerá una penalización
del 1% de la cantidad total no facturada a tiempo.
Es esencial que los parámetros del SLA sean cuantificables y fácilmente

medibles. Para ello, es necesario tener un conocimiento completo de las necesi-
dades actuales y futuras de la empresa. Estos parámetros deben recogerse por
contrato y revisarse sistemáticamente con una frecuencia prefijada y negociada
con cada proveedor.
El nivel de servicio es el nexo de unión entre la empresa y el proveedor de
servicios. La Figura 7.3 presenta los principales aspectos a considerar en la re-
dacción de los SLA y una breve descripción de cada uno de ellos.
Fase 4. Selección del proveedor y el proceso de contratación
Una vez determinado el proyecto o servicio, detectada la necesidad de externaliza-

ción y fijados los objetivos que se pretenden alcanzar, se debe formalizar la pro-
puesta y definir el proceso que llevará a la firma del contrato con el/los proveedor/
Parámetros Descripción
Criticidades asociadas • Valoración de la repercusión que podría tener un incumplimiento en el
a cada proceso del servicio proceso del conjunto del servicio
• Valor a partir del cual se considera que se deteriora el servicio.
Objetivo
Habitualmente, se aplican penalizaciones al sobrepasarlo
Herramienta de medición • Soporte para la medición de los resultados del SLA
Herramienta de registro • Soporte para recogida de los resultados del SLA
• Requerimientos mínimos en cuanto a la calidad en la prestación
Nivel mínimo de servicio
del servicio.
• Aspectos a considerar para la contabilización de los resultados
Criterios de medición
de los SLA
• Especificación de si se define o no penalización asociada a los
Penalización
incumplimientos producidos en el servicio
• Operaciones a llevar a cabo para la obtención de la penalización

Fórmula de cálculo
asociada a los incumplimientos producidos en el servicio
• Período de medición y aplicación, además de otros condicionantes

Criterios de aplicación
a tener en cuenta para la aplicación de penalizaciones al proveedor
• Importe máximo al que puede ascender la penalización repercutida

Nivel máximo de penalización
al proveedor.
• Especificación de si se define o no bonificación asociada a la
Bonificación superación de las expectativas previstas en el servicio, con las
consiguientes fórmulas de cálculo y criterios de aplicación.
Figura 7.3. Principales aspectos a considerar en la redacción de los SLA.


Identificar Preseleccionar la Formalizar

Pedir propuesta
Negociar el contrato
proveedores de solución solución
y el presupuesto
Figura 7.4. El proceso de contratación.

es. El proceso de contratación deberá contemplar, entre otros aspectos, especial-

mente (1) los criterios de identificación y selección de proveedores, (2) el análisis
para la justificación del servicio y su idoneidad estratégica, técnica, económica y
organizativa, y (3) los aspectos formales y específicos a contemplar. De este modo,
se puede esquematizar el proceso de contratación en cinco fases, presentadas en la
Figura 7.4.
Identificación de proveedores
El primer paso hacia la identificación de los posibles proveedores es establecer los

criterios de selección e identificar los posibles proveedores. Los criterios de selec-
ción deberán contemplar diversos factores de cada uno de los proveedores poten-
ciales, entre los que destacan:
z Su capacidad tecnológica.
z Historial probado de calidad de los servicios prestados, sea en la propia
organización o en otras referencias.
z Grado de innovación que puede aportar.
z Medida de los riesgos inherentes a la externalización asociados al pro-
veedor, como posibilidad de dificultades financieras, pérdida de informa-
ción, de lealtad, etc.
Como norma general, pero sin restringirnos a ellos, se debe dar prioridad en
el análisis de los proveedores, a aquellos que actualmente están prestando sus
servicios a la empresa, ya que los costes de coordinación serán siempre mucho
más bajos con una empresa «conocida» que con un proveedor de nuevo cuño.
Es aconsejable en este punto el uso de fuentes externas para la identificación
de posibles proveedores. En cualquier caso, deben seleccionarse un mínimo de
dos o tres ofertantes para poder comparar diferentes puntos de vista y realizar la
asignación definitiva del proyecto o servicio con garantías de éxito.
Petición de la propuesta de solución
En esta fase se debe elaborar la petición de la propuesta de solución y notificarla

a los proveedores seleccionados para poder así recibir ofertas, de acuerdo con un
calendario preestablecido.

El documento elaborado debe explicitar las expectativas de la empresa contra-

tante en el pliego de condiciones y un calendario de recepción de ofertas. En gene-
ral será indispensable abrir las puertas de la organización a las empresas ofertantes
para que analicen en el detalle que consideren necesario los procesos sobre los que
deben realizar sus ofertas.
Preselección de la solución
Es en esta fase donde la empresa recibe las ofertas del servicio o proyecto como
respuesta a la propuesta de solución formulada en la fase anterior. En primer
lugar, una vez recibidas, se deberá analizar el cumplimiento de ciertos requisitos
para su posible selección. Entre otros, se pueden destacar requisitos de tipo es-
tratégico, económico, técnico y/o organizativo.
El objetivo de esta fase es la realización de un análisis exhaustivo compara-
tivo de las soluciones ofertadas por los diferentes proveedores. En función de las
conclusiones que se extraigan de dicho análisis, y como consecuencia del apren-
dizaje que muchas veces ocurre con el mero estudio de las ofertas, son posibles
tres alternativas:
z Seleccionar uno de los proveedores para continuar el proceso.

z Replanteamiento del servicio y de la estrategia por parte de la empresa.
z Necesidad de actualizar los criterios de selección de proveedores.
Partiendo de la identificación de la necesidad del servicio realizada al inicio

del proceso, se debe justificar dicha necesidad, presentar las alternativas corres-
pondientes y seleccionar al proveedor definitivo en función de los análisis técni-
cos, estratégicos, organizativos y económicos realizados, es decir, de acuerdo
con los criterios de selección previamente establecidos. Es en esta etapa donde,
además, se debería seleccionar un responsable operativo del servicio.
El principal responsable de seleccionar la solución finalmente adoptada es el
responsable de departamento TIC.
Negociación
Una vez seleccionado el proveedor, llega el momento de comenzar las negocia-

ciones acerca de las condiciones finales del servicio y concretar las cláusulas del
contrato teniendo siempre en cuenta los SLA acordados de antemano.
Formalización contractual y presupuestaria
Tras la negociación sólo queda formalizar el acuerdo y desarrollar el proceso

administrativo hasta la firma del contrato final por el director de TIC si dispone
de la capacidad contractual o por el responsable de compras y contratación de la
empresa.
El proceso se iniciará con la entrega al proveedor de los contenidos del contra-
to para su transcripción. Internamente, hay que enviar el contrato al departamento

que ostente la responsabilidad contractual para la revisión de los aspectos forma-

les y el contenido de las cláusulas.
Fase 5. La transición
El proceso de transición es crítico para el buen fin del proyecto de externali-

zación. En primer lugar, se debe identificar a las personas que se verán afecta-
das por el proceso de externalización de algún servicio o proyecto y asignar
las responsabilidades adecuadas y la capacidad de tomar decisiones en fun-
ción de lo que se desee externalizar y del departamento implicado. En este
sentido, como se verá, es esencial la asignación de un líder o principal res-
ponsable y, si se trata de un proyecto de dimensiones considerables, la parti-
cipación de la alta dirección es obligatoria. Tal y como ocurre en muchos pro-
yectos de envergadura en la empresa, suele ser habitual que sea la propia
dirección del departamento TIC quien asuma, con el apoyo explícito de la
dirección general, las responsabilidades de control y seguimiento del proyec-
to externalizado.
Junto con el principal responsable, se debe crear un comité o equipo de pro-
yecto (guiado por el líder) basado en criterios técnicos, pero también en crite-
rios de gestión, puesto que no es posible dejar en manos de otros un servicio, si
se desconoce el funcionamiento global de la empresa y los objetivos que se pre-
tenden alcanzar con dicha decisión. Aunque el tamaño del equipo depende del
proyecto en sí, suele ser habitual la participación de un número reducido de
personas durante la planificación y su posterior ampliación en las etapas de aná-
lisis. Han de formar parte de este equipo de proyecto algunos de los componen-
tes clave del departamento TIC, aunque la externalización vaya a ser total y el
departamento vaya a quedar reducido a la función de control del proveedor.
Además de personas con el conocimiento de la empresa, la aportación de perso-
nas experimentadas en procesos de outsourcing es muy recomendable y, en este
sentido, la participación de consultoras externas puede resultar, en ocasiones,
imprescindible.
Desde el punto de vista interno de la empresa, existen cuatro aspectos relevan-
tes en los que focalizar los esfuerzos en la etapa de traspaso de actividad:
z Comunicación. Se debe establecer un plan de comunicación a toda la

organización (o, en su caso, a aquellas áreas más afectadas) de la necesi-
dad o conveniencia de la externalización, del ámbito y sus contenidos y
del modelo de relación que se piensa establecer con el proveedor. Esta
comunicación debe abarcar desde la etapa de negociación hasta el mo-
mento en que el proyecto está finalizado.
z Factor humano. En este aspecto se incluye la formación del equipo in-
terno así como la asignación de roles y funciones, la ejecución de medi-
das para asegurar los cambios de roles en los equipos humanos y el re-
planteamiento a la nueva situación de las condiciones laborales tanto del
personal traspasado como de las personas que se quedarán en el departa-
mento, muy posiblemente con roles diferentes.
z Traspaso. Es necesario analizar y elaborar las medidas de contingencia
durante el traspaso: organizativas, de entorno y las relacionadas con los

activos. Además, se debe revisar el inventario de activos materiales e

inmateriales.
z Seguimiento. Mediante reuniones, documentación e involucración directa
del equipo responsable durante la transición se deberá realizar un segui-
miento del contenido del SLA y adoptar las medidas necesarias para ase-
gurar la continuidad de derechos y obligaciones de terceros.
El éxito de un acuerdo requiere de órganos de seguimiento y mecanismos de

control adaptados al tipo de servicio. En un ámbito general, es necesaria la pre-
sencia de responsables con habilidades técnicas y capacidades de planificación
y gestión operativa. Dichos responsables deben ser capaces de validar la valora-
ción de esfuerzos y metodología del proveedor, dar seguimiento a los niveles de
servicio y puntos de control y planificar, supervisar y validar la gestión de recur-
sos del proveedor.
Fase 6. Proceso de gestión y seguimiento
Una vez finalizadas las tareas de decisión y contratación, el proveedor seleccio-

nado debe comenzar a prestar sus servicios. Es a partir de este momento cuando
el control exhaustivo de las actividades del proveedor y su seguimiento cobran
especial importancia. Aquí es donde el establecimiento de un comité de segui-
miento y control juega un papel esencial. La externalización y su gestión re-
quieren la elaboración de los procedimientos asociados al servicio, documen-
tando las actividades, responsabilidades y roles de las partes. Dichos procedimientos
deberían incluir:
z La descripción de actividades y su secuencia en el tiempo.

z Los participantes y roles en cada una de las actividades.
z Los entregables y/o productos resultantes en cada una de las etapas del
proceso, incluyendo los parámetros del nivel de servicio.
z La identificación de riesgos operativos.
Definidos los procedimientos, se deben verificar las idoneidades y el enca-

je de los parámetros de nivel de servicio (SLA) introducidos en el Aparta-
do 3 de esta sección. Además de la responsabilidad obvia de velar por el cum-
plimiento de los SLA, el Comité de Seguimiento debe revisarlos sistemática-
mente con una frecuencia prefijada y negociada con cada proveedor para ase-
gurar su coherencia con los, normalmente cambiantes, objetivos estratégicos
de la empresa.
Las bases de la gestión eficiente de la relación pasan por identificar las nece-
sidades de seguimiento del servicio en función de sus características. Por ello, es
recomendable clasificar los servicios en categorías según las variables que afec-
tan a su necesidad de seguimiento. Para ello, conviene establecer una metodolo-
gía de categorización de los servicios externalizados. Ello permite particulari-
zar su seguimiento y no excederse en el control cuando sea innecesario o dejar
de seguir actividades que requieran ser controladas minuciosamente. El Anexo
7.2 presenta un ejemplo de clasificación de los servicios y el tipo y periodicidad
de su seguimiento usado en una entidad financiera.

FACTORES CRÍTICOS DE ÉXITO EN LA EXTERNALIZACIÓN

DE LAS TIC
Aunque después de todo lo dicho hasta aquí pueda parecer difícil extraer las cla-
ves del éxito de un proceso de outsourcing, algunos aspectos determinantes de la
satisfacción de los gestores tras un período de funcionamiento suelen ser:
z Definir la estrategia de subcontratación teniendo en cuenta toda la gama

de actividades informáticas que realiza la empresa en su globalidad; no
realizar análisis parciales.
z Evaluar la oferta de los proveedores externos en comparación con la rea-
lización interna. Para ello es necesario disponer de métricas del desempe-
ño del propio departamento.
z Negociar contratos que aseguren tanto el control como la flexibilidad.
z Gestionar la evaluación del rendimiento del proveedor y disponer de ele-
mentos contractuales que sirvan de motivación para mejorarlo.
z Mantener capacidades «en casa» que aseguren el futuro de las activida-
des TIC si fuera necesario recuperar totalmente el control de los servi-
cios.
El rol del director del departamento TIC
Independientemente de que la externalización haya sido parcial o total, las prin-

cipales actividades del director del departamento TIC en un proceso de outsour-
cing son la de planificar, asegurando que los recursos se distribuyen de forma
correcta y la de controlar que los servicios prestados por el proveedor son conse-
cuentes con el contrato firmado. Debe enfrentarse a los problemas que puedan
surgir en las relaciones con el proveedor y saber adaptar las condiciones del
contrato a los cambios que puedan darse tanto en la empresa como en las TI. En
este sentido, el director del departamento TIC debe ser el principal responsable
de mantenerse al día en la evolución de las TIC para valorar si el proveedor
dispone de las actualizaciones y recursos necesarios para proporcionar el servi-
cio acordado y proponer, si hace al caso, las innovaciones que propondría un
departamento interno de TIC.
Algunas consideraciones adicionales
z Es más fácil comenzar un proceso de outsourcing que mantenerlo eficaz-

mente, mejorando la productividad, o disolverlo en caso necesario.
z Ambas partes deben hacer el máximo esfuerzo para trabajar de forma
coordinada, teniendo siempre en mente que el éxito de una empresa es
esencial para el de la otra.
z La gestión de las alianzas estratégicas entre empresa y proveedor es una
de las claves para que el proceso de outsourcing resulte efectivo.
z Los acuerdos alcanzados al inicio del contrato pueden carecer de sentido
al cabo de unos años y, por tanto, requerirán cambios para continuar fun-
cionando de forma efectiva.

z A priori, el proveedor no tiene por qué ser más eficiente que el propio de-
partamento TIC de la empresa.
z Si una compañía decide externalizar, el contrato es el único mecanismo
que asegura que las expectativas se están llevando a cabo.
Hasta aquí se ha estudiado en este capítulo la externalización desde el punto

de vista de los sistemas actuales, pero además es esencial tener en cuenta que la
relación con un proveedor proporcionará tanto acceso a conocimientos de los
que quizá no disponemos cómo hará posible que competidores nuestros puedan
acceder a capacidades que el proveedor desarrolle a través de su relación con
nosotros. Es necesario pues decidir si optar por soluciones compartidas o por
soluciones exclusivas (cerradas a otros clientes del proveedor). El éxito de cual-
quier iniciativa de outsourcing dependerá en gran medida en la capacidad de
gestión de la relación con el o los proveedores del outsourcing. Aunque más
adelante se hablará en detalle sobre la gestión de la externalización, hay que
tener en cuenta algunas consideraciones básicas acerca de las posibilidades de la
gestión de la relación ya en el momento de plantearse la externalización de
actividades. Dependiendo de la relevancia estratégica de las funciones externali-
zadas, la relación puede basarse en un control directo y estricto en función de
costes y niveles de servicio (SLA), o se puede considerar la posibilidad de una
crear una sociedad conjunta, alianza o joint-venture con otras empresas del sec-
tor y/o empresas proveedoras. Además, conviene establecer la proporción inter-
no-externo adecuada de recursos y servicios, así como un cuidadoso estudio de
la posibilidad de contratación de más de un proveedor. Con estas premisas, se
puede determinar con detalle las implicaciones que la decisión de externalizar
las diferentes actividades tiene en la empresa y el/los proveedor/es. El Cuadro
7.3 presenta el caso de Infocaja, una sociedad creada entre varias entidades de
ahorro para compartir los costes de TIC manteniendo un foco en innovación.
DEL OUTSOURCING DE LAS TIC AL BUSINES PROCESS

OUTSOURCING
Al inicio del nuevo milenio se está produciendo un salto cualitativo en la toma
de decisiones del outsourcing de las empresas. Ya no sólo consideran el outsour-
cing de algunas áreas de actividad o de partes concretas de las TIC, sino que
están evaluando la conveniencia de hacer un outsourcing completo de algunos
de sus procesos de negocio. De hecho, tampoco este fenómeno es nuevo, y ya en
1980 Margaret Thatcher decidió la externalización de grandes partes de la acti-
vidad del sector público británico, básicamente concibiéndolo como un modo
de reducir el poder de los sindicatos.
El creciente interés en el denominado Business Process Outsourcing o BPO
viene motivado por el hecho de que en la actualidad toda una serie de fuerzas
están obligando a las empresas a replantearse sus maneras de hacer internas, tal
como se muestra en la Figura 7.5.
El BPO consiste en la externalización de la totalidad de procesos no estraté-
gicos o non core, incluyendo tareas operativas y funciones tecnológicas. Ello
requiere un cuidadoso análisis para determinar cuáles son procesos potencial-
mente externalizables, y dependerá de la estrategia de negocio de cada empresa.

Infocaja
A inicios de 2002 se puso en marcha Infocaja, una compañía de servicios

tecnológicos creada por las entidades financieras Cajastur, CajaCanarias,
Caja Castilla La Mancha, Caja Murcia y «Sa Nostra» Caixa de Balears. De
esta forma, las cajas pretendían compartir sus servicios de TI con el
objetivo de posicionarse en la vanguardia tecnológica e impulsar así la
excelencia de los servicios ofrecidos a sus clientes.Los objetivos plantea-
dos inicialmente para la colaboración fueron una mejora de la eficiencia
en costes derivada del uso compartido de la tecnología, mejorar su posi-
ción competitiva mediante un mejor y mas rápido acceso a la vanguardia
tecnológica, así como un incremento de la calidad del servicio a sus
clientes.Dado que ninguna de las cajas se encontraba en una posición de
liderazgo tecnológico en el sector, el establecimiento de una empresa
conjunta posibilitó a todas ellas llegar a notables mejoras en su nivel
tecnológico, sin tener que correr con todos los gastos de forma individual.
Asimismo, dado que se carecía del conocimiento tecnológico necesario,
se asociaron a su vez con un proveedor tecnológico responsable de la
gestión del nuevo centro así como de la implantación y evolución del nue-
vo centro. Finalmente, al contar con un socio externo, se garantizaba la
confidencialidad y el no traspaso de datos de una organización a otra.
Cuadro 7.3. Estableciendo una empresa conjunta para la provisión

de servicios TIC: El caso de Infocaja.
¿BPO como
Empuje una nueva Empuje
del vendedor manera de del negocio
funcionar?
• Reducción de márgenes • Necesidad de focalizarse

en los negocios tradicionales en procesos clave para
• Necesidad de incrementar la estrategia del negocio
ingresos dominando el pocket • Rediseño de operaciones
share de los consumidores
• Aparición de competidores
con ofertas muy amplias
Figura 7.5. Reflexión estratégica para la consideración del BPO.

Sin embargo, parece que existen algunos procesos que en general son más fácil-
mente externalizables a terceros. Algunos de los procesos que actualmente ex-
ternalizan algunas empresas pertenecen a las áreas de:
z Recursos Humanos, como por ejemplo la gestión de nóminas, la compen-

sación de beneficios, o incluso fases de la selección de personal y forma-
ción.
z Gestión de relaciones con clientes, como por ejemplo el servicio de aten-
ción al cliente, el centro de atención telefónica al cliente, o la gestión de
campañas, promociones y ofertas.
z Finanzas y Contabilidad, como la gestión de órdenes de compras, factu-
ras, recibos, gestión de riesgos; informes financieros; planificación y pre-
visión.
El desarrollo tecnológico de muchas compañías hacia modelos estándar de

gestión como los ERP o CRM ha creado denominadores comunes entre procesos
que ahora hacen posible que los proveedores de servicios tecnológicos puedan
ofrecer soluciones globales, multicliente, obteniendo economías de escala.
Aún así, para estos proveedores, ofrecer soluciones globales para llevar a
cabo operaciones diversas, haciendo uso de perfiles diferentes a los que tradi-
cionalmente utilizaban y que pueden fácilmente estar situados en diferentes
geografías, no es tarea fácil. Por ejemplo, IBM Consulting Services ha decidido
crear un Centro de Excelencia Financiero que soporte el modelo BPO para
Banco Urquijo. En este Centro de Excelencia Financiero trabajará personal
específicamente trasladado de Banco Urquijo junto con personal técnico de
IBM. La gestión de estos nuevos empleados de IBM –y la resolución de consul-
tas e incidencias operativas resultado del trabajo diario en la ejecución de los
procesos administrativos de back-office introducidos en el modelo BPO– será
sin duda un reto para IBM, que se ampliará muchísimo al ofrecer los mismos
servicios de backoffice a otras entidades con procedimientos parecidos pero no
idénticos.
Necesariamente, todo proyecto de BPO debe ser desarrollado minuciosa-
mente por la empresa y su proveedor tecnológico, con la finalidad de formalizar
un contrato de colaboración que garantice un nivel de servicio adecuado al mis-
mo tiempo que permita flexibilidad.
Beneficios de un modelo BPO
A través del modelo BPO las empresas buscan la ejecución de un proceso de

negocio completo con una mayor eficacia a un menor coste, consiguiendo de
este modo beneficios como la variación de costes fijos, tener acceso a la última
tecnología, aprovechar economías de escala derivadas de compartir recursos,
incrementar la velocidad de salida al mercado (speed to market) aprovechando
capacidades complementarias internas con las de socios externos, beneficiarse
de la excelencia de operaciones de otras empresas, o aprovechar que las nuevas
TIC permiten llevar procesos de negocio a economías en vía de desarrollo, con
costes laborales mucho más bajos, como India, Rusia, China o Filipinas, entre
otros.

Según un informe de Forrester Research de agosto de 2003, basado en una

encuesta realizada a 82 altos ejecutivos y directores de TIC, 67% de los cuales
están aplicando un modelo BPO o investigándolo, las empresas consideran que
el modelo BPO es una opción real para rebajar costes, al introducir eficiencias
en la ejecución de tareas y al implicar mano de obra más económica. Además,
mejorar la eficiencia de las operaciones, al poder delegar en un tercero las inver-
siones necesarias para mantener al día las aplicaciones estándares que, como los
ERP, están sujetas a continuas actualizaciones. Bajo una hipótesis de presupues-
to TIC constante, la empresa se vería obligada a invertir todo su presupuesto en
formación para lograr la adquisición de nuevas competencias, así como nuevas
aplicaciones y licencias. Sin embargo, el proveedor podrá ofrecer este servicio a
un precio más competitivo al repartir sus costes entre varios clientes. El tercer
gran beneficio, según las empresas encuestadas, es convertir un gran coste fijo
en uno variable, ya que la mayoría de los encuestados habían cerrado acuerdos
con sus proveedores en los que pagaban por trabajo realizado, como por ejemplo
por número de reclamaciones gestionadas, número de nóminas soportadas, vo-
lumen de facturación, etc.
Riesgos de un modelo BPO
Existen múltiples riesgos a la hora de poner en funcionamiento un modelo BPO.

Algunos de ellos deberían ser solventados por la empresa cliente, mientras que
otros dependerán del proveedor elegido.
Para la empresa contratante, se puede decir que el mayor riesgo para poner
en práctica un modelo BPO estriba en la dificultad de identificar procesos de
negocio potencialmente externalizables. Similarmente al caso del outsourcing
de tecnología de la información, ser capaz de diferenciar procesos centrales (core)
de los non-core, así como los críticos de los no-críticos, no deja de ser una
fortaleza de empresa. Realizar una labor de «reingeniería» en la que se analicen
cada uno de los procesos con el objetivo de estandarizarlos y eliminar todas las
ineficiencias posibles es una tarea indispensable antes de traspasar funciones al
proveedor. Disponer de indicadores de actuación para aquellos procesos exter-
nalizables es igualmente importante, ya que son estos indicadores los que per-
mitirán evaluar el éxito del modelo. Asimismo la empresa deberá preparar un
equipo de personas con los conocimientos técnicos y funcionales necesarios para
gestionar el proyecto BPO tanto en la fase de desarrollo como en la de explota-
ción. Igualmente, una vez el modelo BPO se encuentre operativo, la empresa
deberá preferiblemente evitar la pérdida de conocimiento interno –aún tratándo-
se de procesos non-core–, producida por la desvinculación del día a día en la
ejecución de los procesos. Para evitar esta pérdida de conocimiento se deberá
trabajar internamente a fin de asegurar, vía documentación o vía equipos especí-
ficos, que esa información no puede llegar a caer en el olvido ocasionando la
pérdida de control sobre los procesos y creando una dependencia con el provee-
dor que puede significar la pérdida de autonomía en la toma de decisiones.
Respecto al proveedor, existen riesgos asociados al coste de las operaciones
ya que, a pesar de que uno de los beneficios del modelo BPO es transformar
costes fijos en variables, existe el temor a que estos costes puedan dispararse al
tratarse de compañías que necesitan realizar fuertes inversiones en tecnología y

capital humano. También pueden aparecer riesgos asociados a la funcionalidad,

ya que deberá disponer de experiencia desde el punto de vista técnico y funcio-
nal para aquellos procesos transferidos. Los problemas de integración con otros
sistemas y la pérdida de confidencialidad de la información también preocupan
a las empresas al asumirse que la infraestructura tecnológica será compartida
por otras empresas del mismo u otro sector. Por último, cabe destacar como
riesgo las diferencias culturales que puedan existir entre las organizaciones que
dificulten la gestión de los recursos humanos transferidos al proveedor tecnoló-
gico para llevar adelante el modelo BPO, tanto a nivel de operativa diaria como
de planes de carrera, y la adaptación a los posibles cambios que requiera el
negocio.
Pero los riesgos no se acaban con los que puedan provenir únicamente del
cliente o del proveedor, sino que también existen riesgos derivados de la misma
relación. Un modelo BPO necesita del patrocinio de la empresa al más alto
nivel, y no sólo en su fase de desarrollo, sino también en su fase de explotación.
Será necesario desarrollar capacidades adicionales para garantizar un buen fun-
cionamiento del modelo que asegure el mantenimiento del conocimiento sobre
aquellos procesos que han sido externalizados a través de buenos y eficientes
planes de comunicación entre empresa y proveedor, así como la obtención de
sinergias y economías de escala por parte del proveedor derivadas del hecho de
compartir recursos con múltiples clientes.
Banco Urquijo, pionero en España en la puesta en marcha de un modelo BPO
para sus procesos backoffice con IBM, ha definido responsabilidades sobre cada
proceso a nivel de actualizaciones, mejoras e innovaciones. Ha asignado a su
departamento de control la tarea de supervisar el resultado del trabajo realizado
por IBM y el mantenimiento de toda la documentación relativa a los procesos
externalizados para mantener el conocimiento del banco sobre ellos.
Por todo ello es crítico realizar un análisis riguroso de los potenciales pro-
veedores tecnológicos antes de llevar a cabo un modelo BPO.
Características de los proveedores para garantizar un buen BPO
El modelo BPO requiere de un proveedor con unas características especiales, ya

que debe ofrecer amplios conocimientos sobre los procesos de negocio, conocer
los inputs y outputs de un proceso así como su parte operacional y entender
cómo ese proceso impacta en otras áreas y en el negocio global de la compañía.
Además, el proveedor necesita experiencia acreditada en consultoría para
poder comparar las operaciones llevadas a cabo por el cliente con las mejores
prácticas (best practices) en el sector. También debe realizar la reingeniería de
los procesos con el objetivo de eliminar ineficiencias y estandarizarlos, así como
ofrecer soporte al cliente en todas las necesidades derivadas de un cambio orga-
nizativo. Debe poseer conocimientos técnicos suficientes, que le permitan anali-
zar y ofrecer las mejores soluciones técnicas, garantizar el día a día de la empre-
sa, realizar el mantenimiento de las aplicaciones y llevar a cabo integraciones de
sistemas cuando sea necesario. Debe disponer de conocimientos operacionales,
que le permitan llevar la gestión del personal técnico/operacional en el día a día
y que garantice su proactividad en la mejora de la eficiencia de los procesos
externalizados. También debería garantizar capacidad económica con el fin de

asegurar la disponibilidad de recursos técnicos/humanos para poner en funciona-

miento el modelo y la capacidad de reacción ante cualquier eventualidad.
Existen otros factores, ajenos al propio proveedor, que también deberían ser
tenidos en cuenta en su selección como la creciente complejidad de las solucio-
nes técnicas, la cada vez más frecuente cobertura de servicios desde emplaza-
mientos económicamente ventajosos, la inestabilidad causada por la tendencia a
fusiones y adquisiciones y la mayor oferta de proveedores.
Una vez escogido el proveedor deberá cerrarse el acuerdo de colaboración,
cuya esencia dependerá de la importancia que se otorguen el cliente-proveedor
en los dos sentidos.
Puntos clave a tener en cuenta en el proceso de elaboración

de un contrato BPO
Normalmente los contratos BPO tienen una duración de 5 a 10 años aunque es

frecuente que cuenten con revisiones anuales o bianuales en las que se realizan
los ajustes necesarios sobre los niveles de servicio, haciendo que el contrato de
outsourcing de procesos se convierta en un elemento vivo para adecuarse a las
necesidades de la empresa.
Dependiendo de la importancia mutua que se otorguen respectivamente el
cliente y el proveedor la relación deberá tener una u otras bases. Si para los dos
se trata de una operación poco importante su relación se basará únicamente en el
coste. Pero si para el cliente se trata de una operación importante por razones
estratégicas y para el proveedor no lo es –porque ese cliente no le representa un
alto valor añadido–, el cliente deberá presentar un contrato detallado en el que
se le garanticen unos niveles de servicio determinados en un SLA comparable a
los que se presentaron en la sección anterior al hablar del outsourcing de TIC.
Sin embargo, si para el proveedor representa una operación importante porque le
permite obtener nuevas capacidades mientras que para el cliente no, el contrato
se basará en coste y en transferencia de conocimientos. Por último, si para los
dos se trata de una operación importante ya que les ofrece un valor añadido, se
buscará una alianza estratégica, basada en la confianza mutua trabajando bajo
una relación de socios más que de cliente-proveedor. El Anexo 7.1 a este capítu-
lo presenta unas consideraciones adicionales sobre las relaciones cliente-pro-
veedor.
Es esencial también que el contrato incluya un análisis cuidadoso de los
procesos de negocio de la compañía en términos de objetivos económicos, de
negocio y tecnológicos, la estandarización de las especificaciones creando una
plataforma de licitación, el análisis de los costes, incluyendo los costes de la
externalización en sí más los producidos por la deficiente prestación del servi-
cio, y escenarios de futuro. La externalización de procesos mal definidos única-
mente llevará al caos. Es necesario conocer la estrategia de la compañía a largo
plazo y seleccionar un proveedor que pueda acompañar y aportar valor en la
transformación futura de la organización, definir los niveles de cumplimiento de
servicio, midiéndolos si es posible en términos relacionados con el negocio, a
través de indicadores clave de nivel de servicio o Key Performance Indicators
(KPIs), y especificando las penalizaciones en caso de incumplimiento, estable-
cer los procedimientos de medición del servicio lo más claros posible y dedicar

equipo interno a su seguimiento. Por último, es necesario redactar un contrato

flexible a nivel tecnológico, operativo y financiero, que incluya siempre cláusu-
las de devolución de servicio.
El futuro del BPO
Según informes de Forrester Research de 2003 y 2005, dada la complejidad de

poner en marcha un modelo BPO generalista que pretende cubrir todas las áreas
técnicas –infraestructuras, sistemas operativos, software, etc.– y funcionales
–procesos de negocio–, las empresas proveedoras de este servicio van a dejar de
atacar el mercado BPO como un único mercado para orientarse por segmentos
de funcionalidad. Así sus mercados serán:
z Transacciones de gran volumen, caracterizadas por tareas fácilmente

estandarizables y por tanto automatizables, como la gestión de pagos o la
gestión de inventarios. Son las más fáciles de satisfacer desde el punto de
vista del proveedor. Se estima que este segmento será el mayor, alcanzan-
do los 58.000 millones de dólares en 2008.
z Servicios ampliamente compartibles como finanzas, gestión de nóminas,
compras de varios o atención a clientes, que son muy comunes entre las
empresas pero que necesitan de más intervención manual que las transac-
ciones de gran volumen. En este segmento, los proveedores deberán con-
tar con perfiles técnicos y funcionales, aunque sin demasiada especializa-
ción. Se espera un volumen de 57.000 millones de dólares en 2008.
Proveedores localizados en países con mano de obra altamente competi-
tiva dominarán parte de este segmento.
z Procesos con gran volumen de operaciones en mercados concretos, como
por ejemplo reclamaciones, préstamos, etc, llegando a los 6.000 millones
de dólares en 2008.
z Aplicaciones especializadas en mercados, como las destinadas a cubrir
procesos relacionados con información medioambiental y monitorizaciones
químicas. Este nivel de especialización hará que este segmento de merca-
do sea pequeño llegando a 5.000 millones de dólares en 2008. Es previsi-
ble que los grandes proveedores de outsourcing no se especialicen en este
segmento, dejándolo para las pequeñas empresas.
Con el objetivo de cubrir los segmentos anteriores, los proveedores intenta-

rán obtener las capacidades necesarias para cubrir el mayor número de ellos. Así
las empresas más técnicas empezarán por el segmento de servicios compartidos
con un mayor número de perfiles funcionales, mientras que empresas que ya
cuentan con plantillas mixtas utilizarán sus conocimientos funcionales para pro-
fundizar en el segmento de grandes volúmenes y especialización por mercado.
A su vez, los clientes serán cada vez más exigentes en precio, resultado de un
mejor conocimiento de la oferta. Por ello, una práctica común será solicitar
participación en los ahorros obtenidos en los costes operacionales, derivados de
la reingeniería, la estandarización de procesos y la utilización de mano de obra
barata. Para ello las empresas cliente buscarán contratos flexibles en los que se
contemple la renegociación de tarifas y bonus de productividad.

Como resultado de la fuerte inversión que deberán realizar los proveedores a

fin de poder satisfacer a sus cada vez más exigentes clientes –tareas centradas en
el desarrollo de procesos, reingeniería, formación, etc.– será necesario que ob-
tengan rápidamente economías de escala, derivadas de disponer de un volumen
significativo de clientes y de empleados, lo que conducirá a una ola de fusiones
y adquisiciones en este sector tecnológico. Las empresas cliente delegarán la
gestión de sus TIC a su proveedor BPO dejando a las empresas desarrolladoras
de software en un segundo plano, ya que perderán su interlocución directa con el
cliente. El proveedor BPO será su nuevo cliente y los desarrolladores de soft-
ware deberán orientar su negocio a satisfacerlo, ofreciéndole soluciones enmar-
cadas en un modelo BPO como podrían ser las aplicaciones que permitan nuevas
funcionalidades multicliente, módulos que permitan gestionar de forma única
diferentes versiones de una misma aplicación, sistemas de documentación o he-
rramientas para la gestión de flujos de información. Es previsible pues que los
precios cobrados por los mismos servicios se vayan reduciendo en el tiempo a
medida que el proveedor aumente su volumen con nuevos clientes y el avance
inexorable de las tecnologías le permitan hacer lo mismo a menor coste y lo
transfiera al cliente.
Internet jugará un papel importante en esta evolución, permitiendo el acceso
a la información desde cualquier punto de forma ágil. Para poder garantizarlo,
los proveedores deberán trabajar la usabilidad de sus aplicaciones con la doble
finalidad de unificar las interfaces con el usuario y de minimizar al máximo las
inversiones en soporte al usuario.
Esta nueva manera de organizarse significa el inicio de la era de la tecnolo-
gía orientada a los procesos compartidos, a diferencia de la visión de las TIC
tradicionales, centradas en tecnologías individuales y en soluciones uni-organi-
zacionales. Habiendo externalizado los procesos non-core, las empresas se foca-
lizarán aún más en sus procesos diferenciales y especialmente en aquellas ope-
raciones de alto valor añadido derivando en especializaciones, lo que de nuevo
tendrá un impacto directo sobre la inversión en tecnología.

Las decisiones de externalización, sean de parte de las TIC o de procesos de
empresa, implican por su propia naturaleza cambios en los procedimientos y
responsabilidades, por lo que deben evaluarse de manera concienzuda y desde
múltiples ópticas antes de acometerlos.
Como se ha comentado a lo largo del capítulo, no es únicamente el coste (y aún
así éste es difícil de evaluar dada su multitud de componentes, véase la discusión
sobre Coste Total de Propiedad, TCO, en el Capítulo 8) la única razón por la que una
empresa acomete la externalización. El outsourcing puede proporcionar ventajas
de coste, pero también aportar conocimiento al proceso, flexibilidad, y tecnología.
Por el lado de los inconvenientes, la subcontratación masiva puede descapi-
talizar a la empresa de algún tipo de know-how que pasa a ser competencia del
proveedor, e incrementar los costes de coordinación, ya que en general será más
complicado entenderse con un proveedor con una cuenta de resultados ajena que
con un departamento interno. Afortunadamente, un buen análisis sobre la sepa-
rabilidad y las posibilidades de control del proceso a externalizar reducen de

forma sustancial estos costes, haciendo cada vez más atractiva la posibilidad de
subcontratación.
La responsabilidad de la Dirección pasa por analizar explícita y formalmente
las posibilidades de externalización tal como se ha propuesto en este capítulo.
Después del análisis es posible que por las razones que se estime oportuno no se
lleve a cabo ningún outsourcing, pero ello debe ser consecuencia de un proceso
de análisis y reflexión, no por no haber estudiado dicha posibilidad.
ANEXO 7.1: LA RELACIÓN CON EL PROVEEDOR

De acuerdo con una reciente encuesta realizada por The Outsourcing Institute en
colaboración con Deloitte Consulting, uno de los factores de éxito más impor-
tantes en cualquier proceso de externalización suele ser la elección correcta del
proveedor. De hecho, ésta es la principal preocupación para directivos de pe-
queñas y medianas empresas, mientras que las grandes creen que, por encima de
esto, lo principal es saber gestionar correctamente las relaciones con los provee-
dores. La tercera gran preocupación es la de estructurar convenientemente el
contrato al inicio y que éste sea flexible para poder hacer frente a los posibles
cambios en las condiciones del negocio (véase Figura 7.6).
En cualquier caso, y de acuerdo con el mismo estudio, el precio es el principal
criterio en el que se basan las empresas a la hora de escoger el proveedor, seguido
del compromiso de calidad que puedan ofrecer y de la flexibilidad del contrato.
A pesar de estosPorcentaje
datos, todosde responsables de TIC que consideran
coinciden en admitir que, aunque es esencial
relevante o muy relevante un criterio determinado. Fuente:
escogerDeloitte,
al proveedor
2003 más adecuado de acuerdo con los criterios anteriores, lo
más importante es escoger aquel que mejor se adapte a las necesidades del
servicio o proyecto requerido. Sin embargo, de nada sirve contratar al mejor
proveedor si las relaciones entre ambos no se gestionan correctamente.
100
80
60
40
20
0
to
ad
io
es
ió
tra
ec
lid
bl
ac
on
Pr
i
ca
on
ut
c
ep
sp
de
el
di
R
o
en
is
s
so
om
ad
ur
il id
pr
ec
om
ib
R
ex
C
Fl
Figura 7.6. Porcentaje de responsables de TIC que consideran relevante

o muy relevante un criterio determinado.
(Fuente: Deloitte, 2003.)

En primer lugar, es necesario establecer de forma clara y precisa el servicio o

proyecto para el cual ha sido contratado y asegurarse de que ambas partes entien-
den de la misma forma los objetivos que se persiguen. En segundo lugar, ambos
deben establecer las pautas para gestionar las relaciones diarias y el plan de comu-
nicación (seguimiento, reuniones, etc.). Las principales pautas en las que se deben
basar las relaciones con los proveedores son la confianza y el grado de reacción y
de innovación. Así, el objetivo del proveedor en una relación de outsourcing es
asegurarse de haber aportado al cliente el mejor servicio y las mejores soluciones
y haber entendido claramente su cultura.
No hay que olvidar que los proveedores de servicios, como buenos vendedores
que son, suelen enfocar sus esfuerzos en promocionarse y adquirir nuevos clientes
día a día. Están especializados en ejercer presión sobre las empresas y «forzarlas»
a que externalicen sus servicios. Aunque la información que puedan proporcionar
a la hora de decidir si adoptar o no sus servicios (precio, requisitos, etcétera) son
necesarias y, en ocasiones, suficientes para tomar la decisión, no se debe olvidar
que cada empresa es diferente y, lo que es más importante, cada proyecto o servi-
cio a externalizar tiene sus propios objetivos y condiciones que no tienen por qué
adaptarse a las características de los servicios que propone el proveedor.
Por este motivo, es recomendable basar la decisión de externalizar en la in-
formación proporcionada por varios proveedores diferentes.
Las relaciones con el proveedor
De la misma forma que una buena gestión de las relaciones con los proveedores
puede resultar muy favorable para una organización, una mala gestión puede ser
la causa de pérdidas económicas considerables que pueden llevar a romper el
contrato establecido con el proveedor.
Algunas de las causas de una mala relación con el proveedor son:
z Falta de alineación de los requisitos del negocio con las obligaciones

contractuales del proveedor capaces de provocar que determinadas uni-
dades de negocio no se sientan satisfechas con el servicio que reciben. La
situación puede incluso llevar a ciertos equipos internos a culpar a los
proveedores de ciertos servicios aunque éstos cumplan con sus obligacio-
nes pactadas en el contrato.
z Falta de comunicación entre los principales responsables de las diferen-
tes unidades de negocio que, en ocasiones, no entienden los informes de
rendimiento o bien no muestran interés por ellos.
z Percepción tardía de que la contratación de servicios externos no era
necesaria dada la posibilidad de desarrollarlos de forma interna gracias a
los recursos disponibles y a la disminución de costes que ello conlleva.
z Falta de coordinación y liderazgo de ciertos equipos internos que no
son capaces de gestionar relaciones complejas con los proveedores o que
no disponen de recursos para hacerlo.
Dada la creciente necesidad de muchas empresas de externalizar un número

elevado de sus servicios o proyectos, la cuestión no debería ser tanto «qué exter-
nalizar» sino «cómo incrementar el valor de las relaciones». De ahí la necesidad

de crear indicadores como los que se han descrito a lo largo de este capítulo para
gestionar eficientemente estas relaciones.
ANEXO 7.2: CATEGORIZACIÓN DE LOS SERVICIOS

EXTERNALIZADOS
Aunque no se trata de una metodología universal, en los siguientes párrafos se
tratará de mostrar un modelo a seguir para la categorización de estos servicios.
Dicho modelo se dividirá en cuatro fases: (1) Definición de criterios de catego-
rización; (2) Valoración de dichos criterios y obtención de la categoría del servi-
cio; (3) Definición del seguimiento estándar en función de la categoría resultan-
te y (4) Particularización del seguimiento a realizar en cada servicio.
Definición de criterios de categorización
Se pueden definir seis criterios de categorización de servicios que obedecen a

las variables que determinan las necesidades e intensidad de seguimiento de
dichos servicios:
1. Posibilidad de gestión: valoración de la capacidad interna de la influen-

cia sobre el servicio prestado y las posibilidades de sustitución del pro-
veedor.
2. Experiencia y estabilidad del servicio: número de años que el servicio
lleva externalizado y cantidad de incidencias que habitualmente se pro-
ducen en el servicio.
3. Criticidad: Repercusión que podría tener un incumplimiento en la pres-
tación de un servicio por parte del proveedor (en este caso se debe deter-
minar cuándo un servicio se considera crítico).
4. Importancia económica: relevancia del servicio en cuanto a la cuantía
económica presupuestada.
5. Concentración del proveedor del servicio: resultado del análisis de la
importancia relativa de la facturación del proveedor según el tipo de ser-
vicio respecto a la facturación total de proveedores de la misma tipología.
6. Satisfacción con los servicios prestados: resultado de encuestas de sa-
tisfacción con el proveedor cumplimentadas por los responsables de ser-
vicio para cada una de las tipologías de servicios que ofrece.
A continuación, para cada uno de estos criterios de categorización, se esta-

blecen diferentes rangos de afectación (por ejemplo, bajo, medio y alto). La
Figura 7.7 muestra un ejemplo.
Valoración de los criterios y obtención de la categoría
Una vez determinados los criterios, se debe valorar el servicio bajo cada uno de
ellos y, de ahí, obtener la categoría (alta, media o baja). La Figura 7.8 muestra
una matriz de referencia donde se establecen las diferentes categorías de intensi-

Criterios
Posibilidad de gestión Sin posibilidad de gestión Con poca posibilidad Con amplia posibilidad
de gestión de gestión
Experiencia y estabilidad Experiencia >5 años/ Experiencia >3 años / Experiencia <3 años /
del servicio incidencias en el último incidencias en el último año incidencias en el último
año <10 de 10 a 60 año >60
Criticidad Servicio no crítico Servicio crítico
Importancia económica Bajo importe económico Importe económico medio Elevado importe
(<100.000 €)) (entre 100.000 y 300.000€ ) económico (>300.000€)
Concentración del Baja concentración Concentración media Elevada concentración

proveedor del servicio (acumulado facturación (acumulado facturación (acumulado facturación
anual <30%) anual entre 30 y 50%) anual >50%)
Satisfacción servicios Satisfacción alta Satisfacción media Satisfacción baja

prestados (valoración >4 en la (valoración entre 2,5 y 4 en (valoración <2,5 en la
encuesta de satisfacción) la encuesta de satisfacción) encuesta de satisfacción)
Figura 7.7. Impacto sobre la intensidad necesaria de seguimiento.
Concentración
Experiencia y Satisfacción
Posibilidad Importancia del
estabilidad del Criticidad Servicios
de gestión económica proveedor
servicio prestados
del servicio
Posibilidad
de gestión
Tabla de referencia Experiencia y

estabilidad
del servicio
Impacto de la intensidad
Criticidad
del seguimiento
Reduce
Incrementa o reduce Importancia

en función del cruce económica
con otros criterios
Incrementa Concentración
del proveedor
Categorías de intensidad de seguimiento del servicio
Alta
Satisfacción
Media servicios
prestados
Baja
Figura 7.8. Criterios de categorización de servicios para la asignación

de intensidades de seguimiento.

dad de seguimiento en función de los criterios de categorización anteriores y de su

impacto sobre dicha intensidad.
Definición del seguimiento estándar en función de la categoría resultante
Se puede distinguir asimismo entre tres niveles de gestión del seguimiento (mos-
trados en la Figura 7.9), cada uno de los cuales se llevará a cabo a través de
diferentes reuniones e informes: seguimiento operativo, seguimiento del servi-
cio y seguimiento del proveedor. En función de éstos y de su intensidad, se
identifica la frecuencia: diaria, semanal, mensual o anual (o nula si no se consi-
dera relevante).
Seguimiento operativo Seguimiento del servicio Seguimiento proveedor

Intensidad de
seguimiento
Reuniones Informes Reuniones Informes Reuniones Informes
Alta Frecuencia
Semanal Diario Mensual Mensual Bimestral Bimestral
Media Frecuencia
- Diario Bimestral Mensual Anual Anual
Baja Frecuencia - Diario Semestral Trimestral Anual Anual
Figura 7.9. Gestión del seguimiento del outsourcing.
Particularización del seguimiento a realizar en cada servicio
Con este tipo de análisis se obtiene el estándar de seguimiento para cada servicio
en función de su categorización. No obstante, en función de las características
propias de cada servicio/proveedor y la experiencia previa del responsable del
servicio, podrá particularizarse la sistemática de seguimiento, ajustándose en lo
posible al estándar de su categoría.
Ni que decir tiene que una vez definido el seguimiento de cada servicio, debe
institucionalizarse y estar al alcance de los diversos servicios involucrados en la
gestión de proveedores en los tres niveles de gestión (seguimiento operativo,
seguimiento del servicio y seguimiento del proveedor), poniendo a su disposi-
ción los recursos necesarios para poder desarrollarlo.


La toma de decisiones de inversión en tecnologías de la información... 149
8
La toma de decisiones
de inversión en tecnologías
de la información
y comunicaciones
Si el Capítulo 3 analizaba en profundidad la planificación de sistemas –bien

para apoyar un determinado planteamiento competitivo o bien para mejorar el
posicionamiento de una empresa– este capítulo explica cómo tomar las decisio-
nes de inversión necesarias para llevar a cabo el plan de sistemas resultante de la
planificación. El capítulo finaliza con una reflexión sobre el papel de los están-
dares en la toma de decisiones por parte de los responsables de las Tecnologías
de la Información y Comunicaciones (TIC) y contiene dos anexos en los que se
particularizan estos conceptos para el caso del software de código abierto.
TOMAR DECISIONES DE INVERSIÓN EN TIC:

¿QUÉ CRITERIOS IMPORTAN?1
Decidir sobre la adopción de una determinada tecnología es una ardua tarea.
Aunque las TIC son cada vez más una parte sustancial del presupuesto anual de
una empresa, con porcentajes sobre ventas entre un 2 y un 5 por ciento en mu-
chos casos, y los proyectos comprometen los recursos de la empresa durante
varios años, estas decisiones se suelen tomar en condiciones de relativa incerti-
dumbre. Esto se debe al menos a dos razones: la rapidez de las innovaciones
tecnológicas y el hecho que los sistemas de información suelen afectar a varias
áreas de la empresa, lo que dificulta estimar el beneficio de una determinada
decisión.
Además, en numerosas ocasiones la implantación de un sistema conlleva
tales cambios de procesos y maneras de hacer que pueden dar lugar a nuevas
capacidades, cuyos beneficios no sólo son monetarios, y pueden ser imposibles
de determinar a priori. Por ello, la valoración global de una inversión incluye
1
Un análisis más detallado de los conceptos que se detallan en este capítulo pueden encontrarse en
«Criterios de adopción de las TIC», Sieber, S. y Valor, J. Cuadernos del ebCenter, PwC-IESE, 2005.
149

factores que van más allá del aspecto económico. En este sentido, es importante
evitar las simplificaciones propias de la evaluación de proyectos que, en apa-
riencia, presentan costes de adquisición de tecnología extraordinariamente ba-
jos. Tal como se verá más adelante, esta es la línea de argumentación seguida
por muchos defensores del denominado software de código abierto. Éstos de-
fienden que una solución con coste de licencia cero es más aconsejable que una
solución basada en software propietario, ignorando muchos otros costes ocultos.
Así, las decisiones de inversión deben tener en cuenta factores relacionados
con la estructura organizativa o los servicios adicionales que deberán contratar-
se para su utilización. Asimismo, cuando el éxito en la implantación requiere
una activa implicación de otras áreas de la empresa, habrá que asegurar su dis-
ponibilidad, así como el beneplácito y apoyo activo por parte de la alta direc-
ción. Si se plantea un proceso de sustitución, deberán considerarse los costes de
cambio de la TIC existente, y tener en cuenta además los posibles cambios en la
interoperabilidad del nuevo sistema con otros pre-existentes, sean propios o de
otras organizaciones con los que se relacione.
Por ello, en este capítulo se propone una forma de llevar a cabo un análisis
detallado que consiste en el estudio conjunto de tres criterios: (1) la calidad del
sistema, (2) los aspectos económicos, y (3) los posibles costes de cambio o de
efecto lock-in que puedan existir.
Estos tres criterios permiten analizar los diferentes aspectos que pueden in-
fluir en la toma de decisión. La calidad del sistema recoge las vertientes técnicas
relevantes. Por ejemplo, en la compra de una cámara de video digital se evalua-
rían primero características como sus prestaciones en término de óptica, resolu-
ción, vida de la batería, salida de datos, memoria o la marca del proveedor. En
segundo lugar, la evaluación de los aspectos económicos tiene en cuenta la rela-
ción calidad-precio incluyendo, además del precio de la cámara, eventuales ga-
rantías o necesidades de mantenimiento, coste de películas y otros fungibles, la
facilidad de uso y la necesidad de aprendizaje inicial. Pero estos dos criterios no
tienen en cuenta el contexto o las particularidades de cada industria. Así, obvia-
rían otros puntos que pueden ser de gran importancia como, siguiendo el ejem-
plo anterior, la compatibilidad de la cámara con el reproductor de vídeo o el
televisor. Este es un aspecto que normalmente se olvida, si bien tiene una impli-
cación económica, y por tanto debe ser incluido en el análisis coste-beneficio.
El análisis del coste de cambio es muy importante, por ejemplo, en las migracio-
nes de software.
Criterios de calidad técnica del sistema
Este concepto debe interpretarse de forma amplia, por lo que se propone evaluar
la calidad de un sistema en cinco dimensiones cualitativas: fiabilidad, rendi-
miento, escalabilidad del sistema, seguridad e imagen de marca.
Fiabilidad
La fiabilidad (en inglés reliability) calcula la capacidad de un sistema informá-

tico para dar servicio a un usuario de forma ininterrumpida.

La fiabilidad se mide a través de valores estadísticos que indican la cantidad

de minutos al año que un servidor se encuentra disponible para dar servicio. Así
un 99,999% de disponibilidad implica que el servidor se encuentra no disponi-
ble menos de 5 minutos al año.
La fiabilidad del sistema es importante no sólo porque tiene implicaciones
de coste asociadas a la no-disponibilidad (en inglés downtime –que se estudiará
en el apartado de coste–, sino que además tiene un efecto directo en la falta de
calidad percibida por el usuario. Por ello, al hablar de fiabilidad resulta útil
diferenciar entre caídas inesperadas del sistema y un downtime planificado –que
corresponde a las paradas previstas por mantenimiento regular o para instalar
modificaciones de emergencia, parches para prevenir ataques de virus, etc.
Rendimiento
El rendimiento mide la velocidad de respuesta de un sistema operativo ante la

demanda de una tarea determinada. Debe evaluarse en relación al software de
aplicación que se utiliza con ese sistema, y con el hardware disponible para
hacerlo funcionar.
Escalabilidad
La escalabilidad es la capacidad del sistema para adaptarse a una demanda cre-

ciente de servicios. La escalabilidad es una de las características más importan-
tes en la evaluación de arquitecturas informáticas. Un sistema no escalable no
puede crecer, por lo que corre el riesgo de llegar a ser insuficiente y obligar a la
empresa a sustituirlo.
Seguridad
La seguridad de los sistemas informáticos se refiere a un conjunto de técnicas que

tienen por objeto proteger la integridad de los datos almacenados en un ordenador,
permitiendo su consulta o modificación en función de una serie de permisos y
restricciones. Este concepto también se aplica a los procesos de envío y recepción
de datos. Aunque la seguridad absoluta no existe, la asignatura pendiente de un
gran número de empresas es alcanzar unos estándares adecuados de seguridad: los
incidentes por falta de seguridad se han multiplicado en los últimos años, muchas
veces con efectos muy negativos para las empresas implicadas. Por ello, hay que
evaluar no sólo la probabilidad de una violación de los sistemas, sino las conse-
cuencias que una situación de inseguridad no deseada tiene para el negocio.
Marca
En situaciones de incertidumbre tecnológica, la marca suele servir como garante

de continuidad y soporte de una solución tecnológica. Cobra importancia sobre
todo cuando se prevén problemas, ya que un proveedor de renombre promete

mayor atención y servicio. En última instancia, esto es una cierta garantía de

fiabilidad, rendimiento, escalabilidad y seguridad en situaciones en las que la
evolución tecnológica no permite hacer predicciones fiables. Así, los intangibles
asociados a la marca reducen la incertidumbre y el riesgo de la decisión.
Criterios económicos
La justificación económica de las inversiones en tecnologías de la información

es, casi siempre, un requisito previo para obtener el plácet para su realización.
Esta no es una tarea fácil ya que la propia naturaleza de este tipo de inversiones
impide disponer de una metodología única y aceptada de forma general. Quizá
uno de los frenos a la estandarización de estas metodologías es la dificultad de
identificar los elementos a considerar.
Así, toda solución basada en tecnologías de la información tendrá unos cos-
tes intrínsecos a la propia solución cuya identificación es relativamente fácil,
como el hardware o las licencias de productos software.
Pero existen otros costes asociados a una solución más difíciles de identificar
y cuya consideración está sujeta a interpretaciones de los decisores. Ejemplos
son el mantenimiento del hardware y el software, la renovación de los activos
tecnológicos, o la cantidad necesaria de formación del personal. Pero, a pesar de
las posibles discrecionalidades en la decisión, todos estos costes suelen tener un
impacto tangible. Por ello, el primer paso para analizar el impacto económico de
una decisión de TIC es determinar cuán tangibles son sus beneficios. Y es que
algunas soluciones tienen consecuencias que van más allá del control del máxi-
mo responsable de sistemas, o incluso de la empresa. Por ejemplo, cuando se
prevé que la adopción de una determinada tecnología puede incrementar la cuo-
ta de mercado o la productividad, el resultado esperado está sujeto a factores que
el director de sistemas no puede controlar, como la respuesta de los consumido-
res. En estos casos, tiene que hacerse un esfuerzo para cuantificar el impacto en
el presupuesto, señalando asimismo quién o quiénes son los agentes implicados
de la organización para la consecución de los objetivos. Cuando realmente se
crea que el impacto final no es cuantificable, como mínimo hay que describir y
debatir estas consecuencias.
Una vez determinada la intangibilidad de los beneficios derivados de la adop-
ción de una determinada tecnología es el momento de analizar los costes. Como
se ha adelantado al principio del capítulo, este proceso consta de dos fases: 1)
identificar los costes en función de la actividad de la que deriven –teniendo en
cuenta que algunos suelen no estar directamente atribuidos al departamento TIC–
y 2) clasificarlos según sean directos o indirectos. Como se verá en el siguiente
capítulo, este segundo paso cobra especial relevancia para una buena medición y
control de los gastos, especialmente en las fases de mantenimiento de los siste-
mas.
El coste total de propiedad (Total Cost of Ownership, TCO)
Una forma útil de pensar en los costes de una inversión en tecnologías de la infor-
mación es considerar el coste total de propiedad de la implantación de una solución

tecnológica. Este término, cuyas siglas inglesas son TCO (Total Cost of Owners-
hip), se ha convertido en una herramienta popular desde que fue introducido por
Gartner Group a finales de los ochenta para evaluar las decisiones relativas a los PC.
La firma introdujo una sofisticada metodología para evaluar los costes de TIC a
partir de la estimación del coste total de adquirir y mantener un ordenador personal.
Conceptualmente, la idea de estimar el coste total de propiedad es simple:
establecer los criterios necesarios para valorar y comparar distintas alternativas
tecnológicas. Para ello, hay que determinar de forma clara (a) los costes asocia-
dos a una determinada inversión, incluyendo licencias, mantenimiento y repara-
ciones estimadas, etc., (b) el tiempo en el cual la inversión va a ser amortizada,
como por ejemplo entre 24 y 60 meses en el caso de los PC y (c) las medidas de
normalización para que las comparaciones se puedan realizar sobre bases iguales.
Los párrafos siguientes introducen los conceptos de coste más relevantes que
deben formar parte de un análisis de TCO. Es importante recalcar que algunos
de estos costes son directos del departamento de sistemas, y por tanto normal-
mente están incluidos en el presupuesto normal del departamento. Otros, en
cambio, suelen estar ocultos, o diluidos en la organización, pero son igualmente
necesarios para una evaluación económica completa.
Estos costes son:
1. Costes de personal de la empresa.

2. Costes de capital.
3. Costes de personal externo.
4. Costes de mantenimiento.
5. Costes de soporte.
6. Gastos de explotación.
7. Gastos recurrentes no de explotación.
8. Repercusión de los costes indirectos.
9. Costes asociados al usuario final.
10. Implicaciones de negocio del tiempo de no disponibilidad (downtime).
1. Costes de personal de la empresa
Se evalúa el tiempo que los agentes de la organización dedican al proyecto. Es

importante incluir el coste de oportunidad de empleados en formación, muchas
veces ignorado al evaluar los costes de personal. A modo de sugerencia, debe-
rían contemplarse:
z Tiempo de la alta dirección y directores funcionales: ¿Cuánto tiempo

dedican las diferentes áreas funcionales a la evaluación del proyecto?
¿Hay que evaluar el impacto sobre la competitividad o sobre la estrategia
general de la empresa? ¿Requiere un cambio organizacional, y con ello el
soporte activo de la alta dirección? ¿Cuán involucrada tiene que estar la
dirección general en las fases de definición e implantación del proyecto?
z Director del departamento TIC: ¿Cuánto tiempo dedica la dirección de
sistemas a la definición del proyecto? ¿Y a las diferentes fases de la im-
plantación? ¿En qué medida se requiere la coordinación con otras áreas
funcionales?

z Personal del departamento: ¿Cuánto tiempo requiere el desarrollo del

sistema? ¿Cuántas personas tienen que formar parte del proyecto de desa-
rrollo? ¿Hace falta formar al personal? ¿El proyecto requerirá personal
adicional en el departamento de sistemas? Una vez implantado el siste-
ma, ¿cuánto tiempo de mantenimiento requiere? En caso de contratar
personal externo para algunas de las fases del proyecto (costes de los que
se habla en otro apartado), aquí habrá que calcular el tiempo que la coor-
dinación exija a algunas personas del departamento.
z Formación de usuarios: ¿Cuántos profesionales formarán a los usuarios?
¿Cuántas personas, y durante cuánto tiempo, deberán formarse? ¿Cuál es el
coste de oportunidad para la empresa de tener a usuarios en formación?
2. Costes de capital
Incluye las inversiones en hardware, software y redes de telecomunicación:
z Hardware: Compra, reparación, amortización y actualización de todos

los componentes físicos de la solución informática, dependiendo del pro-
yecto que se esté evaluando. Se incluyen las inversiones en ordenadores
centrales (servidores), terminales clientes (tanto fijas como móviles) y
todo tipo de dispositivo periférico (impresora, escáner, lector de CD, etc.)
e infraestructura de cableado.
z Software: Sistemas operativos de servidores y de las estaciones de traba-
jo clientes, sistemas de gestión de la red necesarios para hacer funcionar
la aplicación, software de bases de datos y de aplicación. Es recomenda-
ble distinguir entre los paquetes de software adquiridos a proveedores
externos –que suelen establecer esquemas de pago multi-anuales en for-
ma de licencias y gastos de mantenimiento–, y los desarrollos internos de
software. Muchas veces los desarrollos internos se separan en un capítulo
aparte, como se señala en el siguiente punto.
z Redes de telecomunicación: Compra, separación y actualización de la
infraestructura de comunicaciones, incluyendo el cableado.
3. Costes de personal externo
Bajo este concepto se incluyen todos los desembolsos en servicios externos ne-
cesarios para el diseño, desarrollo, prueba, documentación, gestión de la confi-
guración y el mantenimiento de todas las aplicaciones desarrolladas interna-
mente (in-house). Debe incluir tanto el apoyo al diseño de sistemas como la
ayuda a la toma de decisiones en forma de consultoría y la mano de obra de
menor nivel.
4. Costes de mantenimiento
Incluye los costes de mantenimiento de servidores, componentes activos de redes

(conmutadores, routers, etc.) o PC, pero también actualizaciones de software.

5. Costes de soporte
Muchas veces se contrata personal externo para los proyectos de inversión en

TIC, por lo que habrá que cuantificar el coste total del proyecto, respondiendo a
preguntas como:
z ¿Va a haber contratos de soporte? ¿Con qué cuantía y duración?

z ¿Se contratarán servicios profesionales externos para la definición y/o
implantación del proyecto? ¿Cuál va a ser su ámbito de actuación y
coste?
z ¿Se contratarán servicios externos para la formación de los empleados?
6. Gastos de explotación
Bajo este concepto se incluyen los desembolsos derivados de la explotación dia-

ria de los sistemas en operación. Ello incluye la gestión de redes, del parque de
ordenadores, servidores, aplicaciones y de la infraestructura de almacenamien-
to. Es importante que se incluyan los desembolsos necesarios para dar servicio
de telecomunicaciones, tanto de voz como de datos, como los servicios de acce-
so remoto, el alquiler de líneas digitales, pagos a proveedores de acceso a Inter-
net (PAI) o de almacenamiento de la web (web hosting), servicios de banda
ancha, e incluso los servicios tradicionales de voz si son relevantes a la decisión
que se esté evaluando. Los gastos de explotación de un sistema también inclu-
yen el soporte tanto al usuario final (helpdesk) como el necesario a los operado-
res del propio sistema.
7. Gastos recurrentes no de explotación
Son aquellos costes en los que se incurren repetidamente una vez está en marcha
el sistema y que en general las diferentes unidades de negocio, otros departa-
mentos o la estructura de la empresa absorben, por lo que desaparecen del presu-
puesto del departamento de sistemas. Existen formas de imputación indirecta
que pueden paliar esta situación, como se verá en el siguiente capítulo. Para
cuantificar los gastos recurrentes, es útil considerar las siguientes partidas:
z Cantidades previsibles de consumibles (cartuchos de tinta, tóner, CD, etc.).

z Piezas de recambio necesarias, si no están cubiertas en un contrato de
mantenimiento.
z Costes de hospedaje de los sistemas (hosting) y comunicación, cuando no
son directamente cargados al departamento de sistemas.
8. Repercusión de los costes indirectos
Se incluyen los gastos en servicios administrativos y financieros del departa-

mento TIC, así como los costes por entrenamiento de su personal. Entre las
tareas administrativas se pueden mencionar la supervisión del personal, presu-

puesto, auditoria, administración del inventario, etc. También incluye los gastos
necesarios para la solución de problemas concretos en el hardware, el software o
en la red que requieren de servicio técnico especializado. Otras tareas cuyo cos-
te se engloba dentro de este concepto suelen ser la planificación y el balanceo de
la carga de datos en la red, de los servidores y las aplicaciones, el desarrollo de
software y el mantenimiento del sistema operativo, así como la configuración de
todos los sistemas, la administración de las copias de seguridad (backup), la
evaluación de las compras de nuevo equipamiento, la política de seguridad, la
administración de bases de datos, y la planificación de la capacidad de almace-
namiento de la organización.
9. Costes asociados al usuario final
En este concepto se incluyen costes ocultos que reflejan una disminución en la

productividad del usuario final. Incluye todos los elementos que disminuyen la
productividad debido a eventuales problemas de los sistemas de información
que utiliza: tiempo dedicado a la solución de problemas (del empleado o algún
compañero), entrenamiento informal (lectura de manuales, utilización de la fun-
ción de ayuda online, procesos de prueba y error hasta que el problema se solu-
ciona, etc.), así como cursos formales de entrenamiento del usuario. También
incluye el tiempo empleado en el uso del sistema con fines personales.
10. Implicaciones de negocio del tiempo de no disponibilidad (downtime)
Finalmente, hay que tener en cuenta cuál es el tiempo de no disponibilidad del

sistema (downtime). El hecho de que un ordenador, un servidor, la red, las im-
presoras o las aplicaciones no estén disponibles tiene un impacto negativo en la
productividad de los empleados, ya que constituye un tiempo perdido. Cuando
el downtime se ha planificado (tareas de mantenimiento en horas nocturnas, avi-
sos con suficiente antelación que permitan al empleado organizar su trabajo,
etcétera), las pérdidas de productividad pueden ser mínimas. Por ello, el downti-
me con más impacto en la productividad suele ser el no planificado, como los
mantenimientos de emergencia o las caídas repentinas del sistema. Este coste se
mide en valor de horas perdidas: normalmente se multiplica el tiempo de parada
del sistema por un porcentaje (el tiempo real que el usuario permanece impro-
ductivo) y por el valor de una hora del usuario final. Se debe mencionar aquí que
en según qué tipo de aplicaciones, el downtime puede tener efectos catastrófi-
cos, con lo que los costes asociados al mismo pueden ser con mucho el mayor de
los costes considerados.
Criterios de costes de cambio (Lock-in)
El tercer criterio para la toma de decisiones de tecnología son los costes de

cambio, o lock-in. En muchas ocasiones, el coste de cambio de una tecnología a
otra es inexistente, pero en otras tantas puede llegar a ser prohibitivo. En estas
situaciones, el usuario puede llegar a sentirse, coloquialmente hablando, «ma-

niatado» por una cierta tecnología o proveedor debido a la complejidad de pasar

de la tecnología que se está utilizando en la actualidad a una más moderna,
mejor preparada o simplemente diferente. Este fenómeno se conoce por el nom-
bre de lock-in y ha sido objeto de estudio de numerosas investigaciones en los
últimos años2.
Este tipo de costes son, en general, inevitables, por lo que deben verse como
la norma y no como la excepción. De hecho, en el sector de TIC, los proveedo-
res suelen perseguir estrategias para aumentar los costes de cambio de sus clientes
ya que, de esa manera, se aseguran una mayor estabilidad de su base de ingre-
sos. En algunos casos, es la única ventaja competitiva sostenible de la que
gozan.
Los compradores deberían ser conscientes de ello, porque afecta a sus deci-
siones a largo plazo. No tener en cuenta los costes de cambio puede, además de
afectar a las inversiones futuras, dejarlos a merced de las acciones oportunistas
de los proveedores.
Ejemplos de costes de cambio son el reentrenamiento del personal, la migra-
ción de datos, adaptación de programas y otras aplicaciones, etc. Algunos costes
menos obvios pueden ser cambios en la manera de comunicarse con otras em-
presas para compartir datos, necesidades de traductores de datos y/o formatos, y
disponibilidad y coste de técnicos en el mercado si fueren necesarios.
El papel de los estándares
Detrás de muchas de las decisiones de adopción de TIC está un concepto que

está tomando cada vez más relevancia: los estándares. Su impacto es fundamen-
tal para entender las discusiones sobre, por ejemplo, posibilidades de interope-
rabilidad entre sistemas o de la capacidad modular de los mismos. En este senti-
do, entender el papel de los estándares es especialmente relevante para poder
tomar adecuadamente una decisión como la adopción de software libre, que se
analiza en detalle al final de este capítulo. Pero, ¿qué se entiende exactamente
por un estándar? A efectos prácticos, un estándar permite interoperabilidad. En
el caso del protocolo TCP/IP (véase Capítulo 2) significa que los ordenadores
que se comunican siguiendo este patrón se entienden entre sí. De forma similar,
en la empresa pueden existir otros estándares, como el uso del procesador Mi-
crosoft Word para redactar todos los documentos de texto. Eso significa que,
implícitamente, se ha acordado la utilización del estándar .doc y todos los usua-
rios pueden leer o modificar un documento en formato electrónico. Aunque téc-
nicamente los documentos escritos con el procesador Microsoft Word se podrían
guardar también en formatos legibles por otros procesadores, como .txt o .rtf, en
la práctica empresarial parece que se ha adoptado el estándar de facto .doc, hasta
el punto que es difícil de imaginar a una empresa que no acepte a sus clientes o
proveedores en dicho formato. De este modo, una decisión de adopción de tec-
nología implica la aceptación de determinados estándares, por lo que conviene
2
Véase por ejemplo: Shapiro, C., Varian, H. R., Information Rules, Harvard Business School
Press, 1999.

saber que, detrás de los estándares, rigen una serie de reglas económicas de
consecuencias muy diferentes3.
Por ejemplo, el protocolo TCP/IP es un estándar público y abierto. Es públi-
co porque su propiedad intelectual se ha donado a la comunidad internacional
para su libre utilización, y a su vez es abierto porque el acceso a su código
fuente (el lenguaje básico utilizado para escribir el programa informático) está a
disposición del público en general. Es decir, cualquiera puede acceder libremen-
te al código fuente, así como modificarlo y construir nuevos programas utilizan-
do este código4.
En cambio, el estándar .doc es privado y con código cerrado. Es propiedad
de Microsoft, que distribuye versiones ejecutables del software, es decir, un có-
digo que pueden entender las máquinas pero que es ininteligible para el ser
humano excepto por complejas operaciones de reingeniería inversa. Estas ver-
siones de código no se pueden estudiar ni alterar, lo que implica que los ficheros
en formato .doc sólo se pueden obtener utilizando una determinada aplicación y
sólo se pueden abrir desde aplicaciones autorizadas por Microsoft.
Para las empresas, la utilización de estándares públicos o privados suele te-
ner, en primer lugar, un impacto económico en términos de pago de licencias,
como se ha descrito en el análisis de impacto económico. Pero tienen también
una segunda clase de implicaciones económicas, en términos de costes de cam-
bio y de compatibilidad con otras tecnologías que van mucho más allá de lo que
puede parecer a primera vista.
Estándares y competitividad en los mercados
Los estándares, independientemente de que su propiedad sea pública o privada,

alteran la naturaleza de la competencia en varios aspectos. En primer lugar, al
facilitar la compatibilidad o interoperabilidad, la adopción de un estándar por
una determinada empresa beneficia a los usuarios que ya lo utilizan, porque les
facilita la comunicación y la posibilidad de compartir datos e información.
La adopción de un estándar por un conjunto de usuarios tiene efectos posi-
tivos para toda la red, lo que a su vez atrae a más consumidores a utilizar el
mismo estándar en detrimento de otros formatos menos populares. Es decir,
los estándares generan efectos de red. Una consecuencia directa es que existen
mercados en los que se impone un solo estándar. Esto, en principio, tiene efec-
tos positivos para todo el mercado, ya que reduce el riesgo tecnológico de los
consumidores.
Pero en mercados de tecnología incipiente, muchas veces coexisten varios
estándares que luchan por hacerse un hueco en el mercado. En estas situaciones,
los consumidores (o adoptadores de tecnología) suelen reaccionar con cautela y
muchas veces prefieren esperar a que se clarifique el panorama tecnológico.
3
El Anexo 2 que sigue a este capítulo explica de forma más precisa cómo se adoptan los estándares
y su influencia en el mercado del software.
4
De hecho, un programador que utiliza código abierto se compromete a hacer público el resulta-
do de su trabajo. Esta práctica viene regida por el denominado copyleft.

Una vez empieza a surgir un estándar dominante, la adopción de la tecnología se

suele acelerar: el consumidor tiene mayor seguridad de que el estándar que adopta
no desaparecerá en pocos años.
No obstante, las consecuencias económicas para los consumidores son muy
diferentes según la propiedad del estándar. Cuando es de dominio público pue-
den adoptarlo sin necesidad de pagar por ello. En cambio, si es de propiedad
privada, el titular puede cobrar precios monopolísticos una vez haya convertido
su estándar en el dominante. Esto tiene un impacto económico muy notable
sobre el coste total de adopción de una determinada tecnología, no tanto en
concepto de las licencias, sino por los costes de cambio a una tecnología alterna-
tiva en el futuro.
En mercados con estándares privados controlados por una empresa, los pro-
pietarios de la empresa gozan de un mercado cautivo que le va generando rentas.
En estas situaciones, se deja de competir por la mejor solución tecnológica para
luchar por el dominio del mercado. Por ello, en situaciones con varios estánda-
res donde al menos uno es de propiedad privada, suelen producirse feroces situa-
ciones competitivas hasta el momento en que se impone un solo estándar. Si es
privado, el competidor dominante puede cobrar rentas monopolísticas, mientras
que los usuarios de la tecnología se encuentran maniatados (locked-in) por los
elevados costes de cambio.
En cambio, los estándares públicos dan lugar a costes de cambio más reduci-
dos, ya que el consumidor o la empresa puede descontar que el formato se man-
tendrá en el futuro y que las nuevas soluciones serán compatibles con versiones
anteriores. Incluso si se plantean migraciones hacia otros sistemas no supondrán
problemas de compatibilidad, al poder escribirse siempre los programas puente
necesarios para migrar hacia cualquier otro formato. Con ello, una decisión de
un sistema con estándar público no tendrá implicaciones económicas futuras
más allá del desarrollo de los programas puente. Por ejemplo, si una empresa
tiene que decidir si adopta o no una solución de telefonía móvil, sabe que las tres
operadoras del mercado español compiten en el mercado con ofertas de produc-
tos y servicios determinados, pero siempre bajo el estándar de comunicación
GSM. Y dada esta circunstancia, junto con una interoperabilidad garantizadas
por la regulación del mercado, los costes de cambiar de un proveedor de telefo-
nía móvil a otro son muy bajos.
Por otra parte, en un mercado dominado por un estándar público donde no
se compite por la diferenciación técnica de las soluciones que ofrecen, el rit-
mo de innovación es superior al de los mercados dominados por un estándar
privado.
Finalmente, hay que tener en cuenta que no todos los mercados tecnológicos
convergen hacia un solo estándar. Esto está claro en el caso de que se trate de
estándares abiertos, ya que entonces suele existir interoperabilidad entre los
mismos. Sin embargo, también se han dado mercados en los que, a pesar de estar
dominados por estándares cerrados, no se ha podido observar aún la convergen-
cia hacia un determinado estándar. Este es el caso de las PDA, en los que co-
existen productos basados en los sistemas PalmOS y WindowsCE, respectiva-
mente.
Los Anexos 1 y 2 a este capítulo explican de forma más detallada el movi-
miento de software abierto y el papel de los estándares en la industria del soft-
ware y las dinámicas competitivas que éstos implican.

Un ejemplo del efecto de los estándares en la toma de decisiones:

Evaluación del software de código abierto versus un sistema
propietario5
A lo largo de los últimos años, el denominado software de código abierto ha

recibido mucha atención por parte de la prensa especializada y de los responsa-
bles de sistemas. Lo que más se destaca es que las soluciones basadas en soft-
ware de código abierto tienen un coste muy inferior a las soluciones propietarias
de algunos proveedores líderes en sus mercados. Sin embargo, tal como se ha
venido indicando a la largo de este capítulo, un análisis que se ciñe al impacto
económico directo es necesariamente miope, ya que también deben tenerse en
cuenta consideraciones más allá del impacto económico y de la calidad del sis-
tema, así como las posibles implicaciones de un efecto lock-in.
Aunque sea difícil hablar en términos generales, sí se puede describir uno de
los casos que más interés ha despertado en los últimos años: la comparación
entre el software abierto Linux y el propietario Windows, tanto en el mercado de
los ordenadores personales como en el de los servidores (véase Anexo 1 para una
explicación más detallada del mercado de software abierto y el funcionamiento
de Linux).
Aunque sin duda los análisis económicos publicados irán variando con el
tiempo, de momento no está claro qué alternativa es la más conveniente. Depen-
de de múltiples variables como la necesidad de software profesional, de soft-
ware a medida, de hardware especializado, etc. Sin embargo, pueden destacarse
algunas ventajas de una y otra solución (véase la tabla de la Figura 8.1). Las
licencias y el hardware resultan más económicos con soluciones Linux que con
Windows. En cambio, el coste de personal especializado sigue beneficiando a
las soluciones del software propietario. Por último, los costes debidos a la inte-
rrupción del servicio (downtime) parecen dar ventaja a Linux.
En cuanto a los aspectos técnicos, Linux ofrece, en general, mejor rendi-
miento y fiabilidad que Windows, y permite mayor control de sus niveles de
seguridad. Linux también aventaja a Windows en términos de escalabilidad. Según
un informe de IBM disponible en la Web www.ibm.com, Linux se puede ejecutar
desde su portátil más pequeño hasta su súper-ordenador multiprocesador de la
serie Z.
Pero el problema de la decisión de migrar a Linux estriba en el lock-in que
Windows tiene sobre las instalaciones tradicionales. Cambiar la plataforma im-
plica cambiar las aplicaciones que corren sobre la misma, y puede que en mu-
chos casos no sea posible. No en vano, la penetración de Linux en los entornos
en que se ejecutan muchas aplicaciones, como estaciones de trabajo y PC de
sobremesa, es mínima, mientras que en las situaciones en las que únicamente
corre un programa (caso de los servidores Web), la participación de mercado de
los sistemas basados en Linux sobrepasa el 50%. El éxito de Linux y el servidor
Web de código libre Apache se debe a que el lock-in de Windows es mínimo, ya
que si el desarrollo sobre Windows se ha hecho usando páginas Web estándar,
5
Información adicinal sobre los criterios de adopción del software libre pueden encontrarse en
Miralles, F., Sieber, S. y Valor, J. «CIO Herds and User Gangs in the Adoption of Open Source Soft-
ware», IESE Working Paper 595, Junio 2005, y en «Linux y la Revolución del Software de Código
Abierto», Miralles, F. y Armelini, G., Cuadernos del ebCenter, PwC-IESE, 2005.

Emilia Romagna
Fuente IDC CYBERSOURCE Robert Frances
Group
100.000
Arquitectura 25 usuarios 100 usuarios 250 usuarios
hits diarios
Período de tiempo 3 años 5 años 3 años 3 años
Costes Directos
Sistema operativo 0 € 8.644 € $0 $24.499 $80 $56.121 $400 $7.980
Software 9.433 € 62.295 € $10.288 $18.800 $80 $282.974 $400 $7.980
Hardware 59.000 € 59.000 € $11.362 $16.827 $284.037 $284.037 $38.015 $39.042
Coste de operaciones 130.610 € 160.410 € $242.556 $168.380 $482.500 $451.000 $36.010 $143.640
Coste de administración N/C N/C $2.389 $258 N/C N/C N/C N/C
Costes Indirectos
Downtime 2.572 € 31.803 € $67.954 $82.383 N/C N/C N/C N/C
Coste de usuario 36.312 € 51.662 € $21.658 $13.816 N/C N/C N/C N/C
TOTAL $237.927 $365.170 $356.207 $300.464 $766.617 $1.018.011 $74.425 $190.662
SO como % del total 0,00% 2,37% 0,00% 8,15% 0,01% 5,51% 0,54% 4,19%
Figura 8.1. Impacto económico de Linux frente a Windows.
sin recurrir a particularidades propiedad de Microsoft, se puede sustituir un ser-

vidor por otro con problemas mínimos.
ASPECTOS PSICOLÓGICOS EN LA TOMA DE DECISIONES

Hasta aquí se han descrito una serie de elementos objetivos usados para la toma
de decisiones de inversión en TIC; se ha hablado de características técnicas, de
coste total de propiedad y de los costes de cambio normalmente ocultos y debi-
dos a los estándares. Hay además unos factores subjetivos que están en la mente
del decisor, normalmente el responsable de TIC, que no por no ser cuantificables
han de pasar desapercibidos. De hecho, es esencial que la alta dirección de la
empresa conozca de la existencia de estos sesgos ya que así van a poder realizar
las preguntas adecuadas para saber si la propuesta de inversión y el sistema
seleccionado por los técnicos es el que mejor soluciona los retos de la empresa o
por el contrario es una propuesta sesgada.
Lo sesgos más habituales se resumen en dos: los problemas de agencia y el
comportamiento de manada.
Problemas de agencia
Existe todo un cuerpo de teoría de la decisión denominado «teoría de la agen-

cia» que estudia cómo un «agente» toma decisiones por cuenta de un «princi-
pal» que le ha delegado la responsabilidad de la decisión. En el caso de la selec-

ción de un determinado sistema, el principal es la propia empresa (o sus accio-

nistas y la dirección general) y el agente el responsable de TIC. La teoría dice, y
la práctica corrobora en muchas ocasiones, que el agente no decidirá lo que
mejor conviene a la empresa, si no que estará mediatizado por lo que le conviene
a él mismo. Supongamos que un responsable de TIC debe decidir entre la im-
plantación de dos ERP. Uno de ellos tiene una notable implantación en el merca-
do y hay una elevada demanda de expertos en el mismo; la alternativa es un
software muy especializado del que no hay otras implantaciones cercanas y la
posibilidad de que las haya es remota. Desde el punto de vista del responsable de
TIC, convertirse en un experto en el sistema generalista de gran implantación es
mucho más valioso para él que convertirse en experto en el sistema especializa-
do para el que no hay mercado. De alguna manera, existe una tendencia a «man-
tener el propio valor de mercado» siguiendo la senda más transitada proponien-
do la instalación de los sistemas más populares.
Comportamiento de manada
Hace unos años se decía que «nadie era despedido por comprar una determinada
marca de hardware», se entiende que fuera esta marca la que convenía a la em-
presa o no. Hoy se podría aplicar la misma frase a un determinado sistema ope-
rativo de ordenadores personales. Este tipo de comportamiento, que hace que los
directores de sistemas parezcan una manada de antílopes todos corriendo hacía
el mismo lado sin saber si hay un león detrás o no, tiene también una explicación
lógica. Tal como se ha visto en este mismo capítulo, las decisiones de inversión
en TIC no son obvias y hay multitud de factores de los que no se conoce con
certeza su efecto; son decisiones no exentas de riesgo tomadas con información
imperfecta. En estas circunstancias, «hacer lo que hacen los demás» tiene mu-
chas ventajas psicológicas. Si todo el grupo de referencia del decisor ha elegido
una determinada plataforma, la evidencia para ir contra corriente ha de ser apa-
bullante. Para ser el primero en elegir un sistema que nadie del entorno utiliza,
no basta con que un estudio lo señale como mejor al predominante; de hecho,
puede que no haya ninguna posibilidad de que se elija algo que no sea lo que
tiene todo el grupo de referencia.
Estos dos fenómenos, el de agencia y el de manada, ayudan más si cabe al
efecto de red ya de por si elevado en las plataformas tecnológicas, abundando en
el fenómeno conocido como «el ganador se queda con todo».

La toma de decisiones de inversión en TIC debe considerar, de forma más o
menos explícita, el conjunto de criterios expuestos. Por tanto, deben tenerse en
cuenta en primer lugar las barreras psicológicas que debe salvar el decisor o los
decidores. En segundo lugar, evaluar según criterios (1) más técnicos asociados
a la calidad de la solución a implantar, es decir, fiabilidad, rendimiento, escalabi-
lidad, seguridad y marca); (2) puramente económicos (tanto en términos de ca-
pacidad de generación de ingresos como de los costes totales de propiedad aso-
ciados a la inversión); y finalmente (3) eventuales costes de cambio o lock-in.

El peso relativo de cada unos de estos criterios se verá modificado en función

de las características de la inversión a realizar (madurez de la tecnología) y del
impacto o importancia estratégica de la misma para la empresa (programa ofi-
mático frente a adquisición de ERP, etc.).
De este modo, es evidente que en una decisión de renovación del parque de
PC instalados serán los factores económicos y de calidad de la tecnología los
relevantes a la hora de decidir; mientras que en decisiones de renovación o sus-
titución del host, los factores psicológicos del decisor y los costes de cambio
adquieren un protagonismo mayor.
Corresponde a la dirección del departamento TIC y a la alta dirección de la
empresa la definición de su importancia y su formalización en el proceso de
toma de decisiones de TIC.
ANEXO 1: EL MOVIMIENTO DEL SOFTWARE DE CÓDIGO

ABIERTO
Los vocablos «software libre», «gratis» y, particularmente, «Linux» han entrado
con fuerza en el lenguaje utilizado por los responsables de TIC en los últimos
años. Noticias como la de la ciudad de Munich, que migró su software propieta-
rio a uno de código abierto para «ser dueña de su destino»; el comunicado de
Google de que su red de 20.000 servidores trabaja con software que no paga
licencia; o el ahorro de 27 millones de dólares en costes de informática por
parte de Amazon al migrar a Linux en 2002, han hecho que muchos responsables
de sistemas se estén planteando la conveniencia de adoptar alguna modalidad de
software de código abierto.
¿Qué significa software de código abierto? En primer lugar, hay que
saber que cuando se instala un programa en un ordenador, el software que
utiliza esa máquina se denomina código ejecutable. Se utiliza la palabra «có-
digo» porque las operaciones que puede realizar un ordenador están «codifi-
cadas» en un conjunto de órdenes o instrucciones. Y «ejecutable» se refiere a
que el ordenador entiende, ejecuta y cumple estas instrucciones que forman
el código. Pero es muy difícil (aunque no imposible) construir un programa
usando las órdenes tal y como las entiende el ordenador, normalmente se-
cuencias de unos y ceros. Para ello, en los inicios de la informática, se inven-
taron los lenguajes de programación, que facilitan la escritura de órdenes en
términos más asequibles para el ser humano, transformando esa codificación
en código entendible por la máquina. Una vez el programa está construido
en un lenguaje de programación, se convierte en la fuente para obtener (sin
ninguna complicación importante) la versión en código ejecutable del pro-
grama construido. Es decir, si se dispone del código fuente, se obtendrá lo
que el programador escribió en su día para realizar el programa. Si, adicio-
nalmente, se conoce el lenguaje en que ha sido construido, se podrá cambiar,
mejorar o adaptar a las necesidades particulares de cada organización o indi-
viduo. Por tanto el concepto de código fuente abierto (en inglés Open Source
Software, OSS) se refiere a aquellos programas que se distribuyen enviando
el código fuente y no el código ejecutable. Varias empresas están comprome-
tidas con esta filosofía de código fuente abierto (entre ellas SUN Microsys-
tems, IBM, Oracle o Hewlett Packard); la organización Open Source Initiati-

ve (OSI) trabaja exclusivamente para gestionar y promover las iniciativas de

código abierto.
Una iniciativa particular de software de código fuente abierto es la que ha
impulsado Linus Torvalds, quien se interesó en la creación de un sistema opera-
tivo al que llamó Linux (del que se hablará más adelante), y que en la actualidad
se ha convertido en uno de los máximos referentes del mundo del software de
código fuente abierto.
Por otro lado, existe otro movimiento, el del «software libre». En contra de
lo que se podría pensar, no todo el software abierto es libre. Esta denominación
se refiere a la libertad de los usuarios para ejecutar, copiar, distribuir, estudiar,
cambiar y mejorar el software. De modo más preciso, se refiere a cuatro liberta-
des de los usuarios del software6:
z La libertad de usar el programa, con cualquier propósito.

z La libertad de estudiar cómo funciona el programa, y adaptarlo a las ne-
cesidades (el acceso al código fuente es una condición previa para ello).
z La libertad de distribuir copias.
z La libertad de mejorar el programa y hacer públicos estos progresos, de
modo que toda la comunidad se beneficie.
Desde Free Software Foundation (FSF), sociedad liderada por el investiga-

dor del MIT Richard Stallman, se ha dirigido el movimiento de software libre
para mantener esa filosofía de libertad aunque en algunos casos se tengan que
sacrificar prestaciones o avances hacia nuevas funcionalidades.
Para que la libertad de modificar y publicar versiones mejoradas tenga sen-
tido, hay que tener acceso al código fuente del programa. Por tanto, la posibi-
lidad de acceder al código fuente es una condición necesaria para el software
libre.
Aunque, como se ha dicho, «libre» no tiene relación con el coste, indirecta-
mente es cierto que la mayor parte del software libre es de acceso casi gratuito.
En inglés la confusión es aún mayor, ya que se usa la palabra free tanto para
denominar «libre» en el sentido de «entrada libre» como «gratis». La realidad es
que existen empresas que distribuyen software libre a cierto coste, pero propor-
cionando servicios de valor añadido como manuales, servicios de ayuda, y pie-
zas de software propietarias que hacen al software libre más útil, aunque no
totalmente gratis.
De este modo, software propietario, de código fuente abierto o software libre
forman parte del panorama de software, tal como se puede ver en la Figura 8.2.
Linux: un sistema operativo de código abierto
Linux nació en 1991, cuando Linus Torvalds, estudiante de informática de la

Universidad de Helsinki, empezó a programar las primeras líneas de código de
6
Extraída de la web de la Fundación del Software Libre http://www.fsf.org/philosophy/
free-sw.es.html.

Tipo de software Descripción Ejemplo
Software cuyo único mecanismo de intercambio de información es el

Propietario MS Office
paso de ficheros con un formato acordado (propio o estándar)
Software propietario que dispone de mecanismos para

APIS Windows, SAP
intercambiar información con otros productos
Software propietario que se adhiere a los mecanismos de conexión

Conector Siebel
de estándares abiertos
Software que cumple las normas definidas por algún estándar

Estándar abierto J2EE, W3C
en el intercambio de información
Software del que se tiene acceso al código fuente y existen

Fuente abierto JAVA
mecanismos para poderlo adaptar
Software cuyo desarrollo está en manos de los profesionales

Software libre My SQL, Linux
que desean contribuir a su evolución
Figura 8.2. Tipos de software desde una perspectiva de la apertura

de su código fuente.
este sistema operativo como una simple afición, sin imaginar el futuro alcance
de su proyecto.
Estos inicios estuvieron inspirados en MINIX, un pequeño sistema que per-
tenecía a la familia de sistemas Unix. Las primeras discusiones sobre Linux
aparecieron en el grupo de noticias7 comp.os.minix, donde se discutía sobre el
desarrollo de un nuevo sistema Unix «universal» que se pudiera ejecutar sobre
cualquier tipo de hardware.
El sistema se desarrolló bajo el concepto de modularidad, por el cual el ker-
nel o núcleo del sistema operativo cumple únicamente las funciones mínimas,
permitiendo agregar de forma muy estructurada módulos que cumplen funcio-
nes determinadas en el sistema operativo. Hoy en día, el kernel de Linux sigue
controlado por un grupo de trabajo liderado por el propio Linus Torvalds, y ha
experimentado sucesivas mejoras desde la creación de la primera versión. La
página www.linux.org proporciona toda la información actualizada sobre Linux,
y permite descargar las últimas versiones del kernel.
Al éxito de Linux han contribuido tanto el diseño estructurado y modular del
núcleo como la propia existencia de Internet, que ha permitido que miles de
programadores de todo el mundo hayan experimentado con el sistema y le pue-
dan añadir funcionalidad de forma continuada.
7
Los «grupos de noticias» o newsgroups son lugares de Internet en los que se reúnen personas
interesadas en diversos temas para discutir sus intereses comunes. Los newsgroups son muy anterio-
res a la aparición de la Web tal y como la conocemos hoy, ya que usan una tecnología basada única-
mente en simples caracteres, sin componente gráfico alguno.

La versatilidad de este sistema se debe a la solidez de su programación, que

se deriva de UNIX, tanto para estaciones de trabajo como para redes de trabajo e
incluso aplicaciones cliente/servidor. Su diseño modular permite que se puedan
desarrollar con relativa facilidad sistemas Linux que soporten las configuracio-
nes más variables, desde un ordenador con procesador 80386 de los años ochen-
ta hasta los Pentium Pro, pasando por plataformas basadas en otras arquitecturas
como Alpha de Digital y SPARC de Sun (tecnologías RISC), MIPS de Silicon
Graphics, Power PC de Apple, y toda la gama de procesadores de IBM.
Otra de las principales ventajas es la rapidez con la que son corregidos erro-
res y fallos de seguridad. Linux cuenta con varios grupos de noticias y de discu-
sión donde se presentan los problemas y, en pocas horas, las soluciones. En
cualquier producto comercial que dependa de unos pocos técnicos conocedores
de las características «secretas» del producto, este proceso de corrección tarda
mucho en producirse. En el mundo Linux, contrariamente a la política de casi
todos los fabricantes y distribuidores de productos comerciales, los «parches»
son un proceso interactivo entre el desarrollador y el usuario, cooperación fun-
damental para la calidad del software. El cuadro adjunto presenta las caracterís-
ticas técnicas más destacadas de Linux.
Características de Linux:
z Multitarea: La palabra multitarea describe la habilidad que tiene el

sistema de ejecutar varios programas al mismo tiempo.
z Multiusuario: Permite a muchos usuarios trabajar con la misma máqui-
na simultáneamente.
z Multiplataforma: Existen versiones de Linux para, virtualmente, cual-
quier plataforma de hardware, desde los antiguos 386 de Intel hasta
potentes super-ordenadores de la Serie Z de IBM.
z Multiprocesador: Soporte para sistemas con más de un procesador.
Esta característica hace que Linux sea el sistema operativo con el que
opera una parte importante de los ordenadores más potentes del
mundo8.
8
http://www.top500.org.
ANEXO 2: LOS ESTÁNDARES EN LA DINÁMICA

COMPETITIVA DEL SECTOR DEL SOFTWARE
El hecho de tener estándares abiertos o cerrados, y privados o públicos, tiene
enormes consecuencias sobre las posibilidades de apropiación de valor de las
empresas que desarrollan software basado en estos estándares. Así, por ejemplo,
una compañía que utiliza un estándar abierto y público tiene la obligación de
revertir cualquier desarrollo a la comunidad manteniendo el estado de propiedad

y de disponibilidad del mismo. Esto obliga a las empresas fabricantes a adoptar

estrategias muy distintas a las de empresas con estándares cerrados y privados,
ya que pueden aprovechar la comercialización del mismo a través de licencias.
Este último modelo de negocio resulta especialmente atractivo cuando una em-
presa consigue que su software se convierta en el estándar de facto de los usua-
rios, como ha sido el caso de Windows en el mercado de los PC, o del sistema
integral SAP en algunos sectores concretos. Por ello, merece la pena hacer una
breve incursión para entender la dinámica de creación de los estándares, puesto
que un estándar dominante es, al fin y al cabo, la causa última de costes de
cambio elevados y que permite a determinadas compañías dominar el mercado
con productos que se podrían incluso considerar mediocres.
En la práctica, los estándares se crean a través de dos mecanismos básicos:
z Por imposición: a través de un acuerdo entre organismos internacionales

o asociaciones de fabricantes que se ponen de acuerdo en la definición de
la norma. En este caso, el estándar nace como tal, siendo innecesaria la
creación de mecanismos para imponerlo. Por ejemplo, en la telefonía
móvil de segunda generación, la Comisión Europea para las Comunica-
ciones Móviles decretó en 1982 que todos los países de la Unión deberían
adoptar el estándar GSM en un plazo máximo de 10 años. Este estándar
se impuso porque así lo reguló un organismo, en este caso, con compe-
tencia en el ámbito europeo.
z Por adopción: es el mecanismo más común de constitución de estándares
en las industrias relacionadas con la economía de la información9. Por lo
general, en estas industrias los estándares se construyen siguiendo un pa-
trón más o menos homogéneo que se presenta de forma esquemática en la
Figura 8.3.
Creación de una base Retención de clientes

Externalidad de red
de usuarios (lock-in)
Figura 8.3. Dinámica de creación de estándares.
9
Se entiende por industrias de la economía de la información aquellas que tienen como princi-
pal objeto de negocio el intercambio de información, como empresas dedicadas al comercio electró-
nico, al negocio de la transferencia de datos a través de móviles, toda clase de software, etc.

Siguiendo esta lógica, la adopción de un estándar empieza con la construc-

ción de la base de usuarios. Cuando un producto o servicio se lanza al mercado
con el objeto de constituirlo en un estándar, es necesario que en una primera
etapa se desarrolle un mecanismo disparador que genere en la comunidad un
sentido de pertenencia. No hay una receta determinada para saber cómo cons-
truir esa base inicial. En realidad hay varios ejemplos de estándares, cuya fase
inicial es diferente entre sí: por ejemplo, el sistema operativo DOS de Microsoft,
que luego sería la base para el desarrollo de Windows, se popularizó gracias al
impulso inicial de IBM, cuando ésta lo adoptó como el sistema operativo de sus
PC. Gracias al apoyo de IBM, Microsoft logró una base de clientes importante
en poco tiempo.
Otro caso es el de Adobe, una de las empresas líderes en software de imagen
y diseño gráfico, que impuso como estándar el interpretador universal de docu-
mentos o formato PDF. En sus inicios, y para construir la base de usuarios,
Adobe desarrolló una tecnología propia llamada PostScript, que permite conser-
var los aspectos gráficos de un documento, independientemente del software en
que haya sido desarrollado. Luego lo adoptó como estándar de sus propios docu-
mentos y trabajó con instituciones para que hicieran lo propio; el Ministerio de
Hacienda de EE.UU. fue uno de los primeros en hacerlo y reconocerlo pública-
mente.
Una vez que se constituye la base de usuarios, el éxito de una tecnología se
verá enormemente favorecido si es capaz de crear externalidades de red. Se
entiende por externalidad de red (o efecto red) un fenómeno por el cual la utili-
dad de un producto o servicio aumenta para cada usuario con el número de
usuarios de dicho producto o servicio. El ejemplo típico es el fax, en la que
cuantos más usuarios dispongan del equipo, más valiosa se vuelve la red tanto
para los que la utilizan como para los que desean hacerlo.
A través de la externalidad de red, un producto puede convertirse en líder de
mercado, ya que el beneficio de pertenecer a una red atrae a nuevos usuarios,
haciendo que este producto o tecnología sea adoptado por un número de consu-
midores cada vez mayor. Como consecuencia, el producto líder se puede conver-
tir en un estándar de facto. Este es el caso de eBay, estándar de sitios de subas-
tas; allí acuden vendedores y compradores porque es «donde está la acción»,
dejando sin actividad lugares que ofrecen los mismos servicios a menor precio,
incluso gratis.
Los beneficios que los usuarios obtienen de pertenecer a una Red pueden ser
directos o indirectos:
z Directos: son aquéllos generados directamente por un producto o servi-

cio sobre sus usuarios. El fax, por ejemplo, genera efectos de red directos
sobre los que usan estos dispositivos. Cuantas más máquinas de fax haya
conectadas creando una red más amplia de usuarios de fax, más valiosa
es la máquina de un usuario ya que le sirve para comunicarse con mucha
más gente.
z Indirectos: son aquéllos que se producen cuando un producto «media»
entre uno o varios productos y los usuarios. Por ejemplo, cuando un siste-
ma operativo se impone como estándar, se crean más aplicaciones com-
patibles con el mismo, ya que al existir un número importante de usua-
rios, los fabricantes de software se ven empujados a crear y comercializar

aplicaciones sobre la plataforma mayoritaria. En general se puede decir

que una tecnología puede estar sujeta a externalidades de red cuando tie-
ne un componente de comunicación: el fax comunica a los usuarios entre
sí, y el sistema operativo «comunica» a los usuarios con los fabricantes
de hardware y aplicaciones.
¿De qué dependerá entonces que un producto se convierta en un estándar a

través del mecanismo de externalidad de red? Básicamente de dos aspectos:
z Cuando un volumen suficiente de consumidores lo adopta: este es el

caso del PDF mencionado anteriormente. Adobe ha utilizado inteligente-
mente la capacidad de expansión de Internet para distribuir gratis el Acrobat
Reader, y estandarizar de esta manera la forma de leer e imprimir docu-
mentos.
z Cuando un número suficiente de actores en el mercado cree que un
estándar será adoptado: esto es lo que pasó por ejemplo en la guerra de
los estándares de vídeos entre VHS y BetaMax, en el que VHS se impuso
gracias a un acuerdo de fabricantes con videoclubs y proveedores de con-
tenido.
Tanto en uno como en otro caso, el convencimiento se genera:
z Con la potencia del concepto, diseño o la manera de entregar el producto.

z Entrando en el mercado antes que la competencia.
z Creando expectativas.
z Con precios muy agresivos o incluso regalando el producto.
z Desarrollando o apoyando el desarrollo de productos y servicios comple-
mentarios.
En la historia de la adopción de distintas tecnologías, por lo general, se sigue

el siguiente patrón: al principio existen varias tecnologías, con diferentes carac-
terísticas, en la que por varios medios una intenta imponerse sobre las otras.
Después, a través de los efectos de red, el público consumidor se inclina por una
única solución tecnológica, efecto que los economistas denominan market tip-
ping10. Este concepto implica que en la competencia por imponer un estándar
normalmente sólo existe un ganador, que no necesariamente es superior desde el
punto de vista tecnológico.
Existen varios ejemplos que lo ratifican. A principios del siglo XX, el siste-
ma de corriente continua perdió la guerra contra el sistema de corriente alterna,
a pesar de que la primera era más segura y eficiente. Lo mismo sucedió en el
mercado de estándares de vídeo con VHS y BetaMax. BetaMax era sensible-
mente mejor: tenía dos pistas de audio (lo que permitía la grabación separada de
la música), sus casetes eran más pequeños, y tenía una mayor fidelidad; sin
10
Tipping debe traducirse en su acepción de inflexión de tendencia. La idea es que hasta el
momento no estaba claro qué producto se iba a hacer con el mercado y de repente uno se empieza a
«quedar con todo».

embargo, el sistema VHS fue adoptado por los videoclubes, lo que generó la red,
y con ello el efecto red que terminó por imponer el estándar.
¿Qué es lo que hace que un mercado se decante o no por un estándar? Según
Shapiro y Varian11 (1999), la posibilidad de que un mercado se incline por un
solo estándar depende de dos fuerzas fundamentales: economías de escala y la
variedad en la demanda. La Figura 8.4 resume la posición de estos autores.
Cuando la variedad exigida por el consumidor es baja y las economías de
escala importantes, estamos ante la situación más probable de que el mercado se
decante por un solo estándar: un ejemplo es la industria del software, donde lo
que más valora el usuario es la uniformidad y estandarización de las aplicacio-
nes para evitar incompatibilidades, por lo que es lógico que un sistema operativo
domine el mercado. DOS, y su evolución Windows, se impusieron gracias a la
masa crítica creada por IBM. Cuando las economías de escala son grandes pero
la demanda muy variada, es más difícil que un estándar se imponga sobre otras
tecnologías. Por ejemplo, los Pocket PC y las Palm Pilot, que aparentemente
cubren la misma necesidad, conviven en el mismo mercado como dos tecnolo-
gías distintas entre sí, y es probable que sigan así a no ser que se desarrolle una
necesidad de interoperabilidad entre equipos, forzando entonces el tipping hacía
uno de ellos.
En ausencia de economías de escala es poco probable que el mercado se
decante por un ganador absoluto, ya que al no tener ventaja de costes el mayor,
existe la posibilidad de que jugadores menores presenten alternativas adecuadas
en precio y funcionalidad.
El ciclo hacia la dominancia completa del mercado de la Figura 8.3 se com-
pleta con un mecanismo de retención del cliente. Cuando resulta difícil para el
consumidor cambiar de estándar y los efectos de red son difíciles y caros de
crear para los competidores, los mercados quedan prisioneros de un determina-
do estándar. Aunque a los consumidores les guste usar un estándar diferente
puede serles imposible cambiar, porque a nadie le conviene dar «el primer paso»
de cambiar a otro patrón.
Una vez establecido un estándar de facto, los nuevos usuarios de la tecnolo-
gía optarán por el mismo, ya que por los efectos de red antes comentados, es más
útil para el nuevo usuario utilizar la tecnología impuesta que probar una nueva.
Bajas economías de escala Altas economías de escala
Baja demanda por variedad Poco probable Alto
Alta demanda por variedad Bajo Depende
Figura 8.4. Probabilidad de que un mercado se decante

por una sola tecnología.
11
Shapiro C. y Varian H., Information Rules, Harvard Business School Press, 1999.

Por ello se concluye que, si bien los estándares por «adopción» se construyen a
través de efectos de red, estos mismos efectos hacen que el estándar se mantenga
como tal.


Medición y control de costes 173
9
Medición y control de costes
Los costes del Departamento de Tecnologías de la Información y Comunicacio-

nes (Departamento TIC) son como consecuencia del papel de soporte que el
departamento presta al funcionamiento de la empresa vistos a menudo como un
«coste de estructura».
Los costes en TIC cuando no son contemplados como propios por las áreas
que consumen los servicios, puede generar a lo largo del tiempo una incapaci-
dad para asociar o relacionar un coste del departamento de tecnologías de la
información con un servicio o producto final, lo que acostumbra a llevar a inefi-
ciencias notables en la gestión de la empresa, no sólo por la imposibilidad de
determinar la utilidad del departamento TIC, sino también por el hecho de des-
conocer el provecho que las diferentes áreas sacan de los sistemas en operación.
Se pueden dar por tanto situaciones en las que un área tiene sistemas implanta-
dos con una utilidad final baja, mientras que otros proyectos, con mayor utilidad
global, no se han acometido aún por el simple hecho de que la priorización de
proyectos se ha hecho en base a criterios subjetivos.
Esta forma de proceder es especialmente preocupante en las empresas con
un presupuesto elevado en TIC. La media del presupuesto TIC sobre ventas es
ya de un 2,82% mientras que en el sector financiero, por ejemplo, el presupues-
to llega a 4,06%1 sobre ventas. Las empresas tienen más que nunca la necesidad
de llevar a cabo un buen control de gestión de los costes, pero rara vez se han
definido modelos formales que permitan asignar los costes, dejando de clasifi-
carlos como costes de estructura y considerarlos como un elemento más de los
costes directos del producto vendido o servicio proporcionado a los clientes
finales.
Además, en línea de los argumentos esgrimidos en el Capítulo 3 donde se
comentaba que las TIC pueden hacer mucho más que apoyar y dar soporte a las
1
Valor de 2002 reportado así por Gartner Group en su «IT Spending and Staffing Survey Results
Report». Strategic Analysis Report, October 2003, R-21-2290.
173

actividades tradicionales de la empresa, una buena asignación y reparto de los

costes de TIC es imprescindible para poder establecer el valor estratégico de los
sistemas y las tecnologías de la información. Dado que frecuentemente las in-
versiones en TIC requieren también del esfuerzo de otros departamentos para su
correcta implantación, la imputación de costes parece la forma más lógica de
apoyarla.
Un buen modelo de control y gestión de costes ayudará además al responsa-
ble de las TIC a responder a las presiones que las áreas de la empresa suelen
ejercer sobre su departamento para conseguir servicios, redefiniendo a su vez las
relaciones interdepartamentales existentes.
EL NIVEL ADECUADO DE COSTES EN CADA EMPRESA

En los últimos años se han podido ver múltiples casos en los que para mejorar sus
resultados económicos las empresas anunciaban políticas de contención y de re-
ducción de los costes de los servicios centrales y de las áreas de soporte. En la
mayoría de estos casos, uno de los primeros presupuestos afectados por la reduc-
ción presupuestaria suele ser el del departamento de sistemas y tecnologías de la
información.
Cuando esto ocurre, los costes de TIC están sin duda siendo considerados
costes de estructura y además se supone que son de tal naturaleza que se pueden
reducir manteniendo un servicio adecuado. Desafortunadamente, cuando los sis-
temas de información son un elemento clave para la estrategia, sea porque per-
miten la diferenciación o porque apoyan de manera crítica algunos procesos, no
se puede considerar el área de sistemas como simplemente de soporte y que se
puede pasar con una reducción presupuestaria son más. Además, en organizacio-
nes en las que no se dispone de un departamento de organización encargado de
la innovación de procesos, el área TIC es la que en la mayoría de los casos
promueve y facilita el incremento de la productividad a través de la mecaniza-
ción y sistematización de la información. En situaciones de reducción presu-
puestaria en las que el día a día consume los recursos asignados, una de las
primeras actividades del departamento TIC que se reduce es precisamente la de
innovación y de mejora, perdiéndose una oportunidad para conseguir precisa-
mente lo que se perseguía con el recorte presupuestario: aumentar la eficiencia
de la empresa.
Es esencial que la empresa disponga de un sistema de medición de sus cos-
tes, que pueda juzgar si el nivel de gasto es el adecuado, y que sea posible saber
qué departamentos de la empresa reciben qué servicios y a qué costes. Por tanto,
las consideraciones acerca de la medición de costes tienen que contemplarse desde
cuatro ámbitos diferenciados:
1. Optimización de los costes totales
– ¿Tiene la Dirección de TIC la información adecuada para gestionar

sus costes y los de los servicios asociados?
– ¿Dónde hay eficiencia/ineficiencia?
– ¿Cuáles son las áreas de mejora?
– ¿Cómo se comparan con datos del sector o generales?

2. Demostrar la eficiencia de los servicios prestados
– ¿Son razonables los costes?

– ¿Dónde hay oportunidades de reducción?
– ¿Hay actividades potencialmente externalizables?
3. Aportar valor añadido al negocio
– ¿Son todos los servicios realmente necesarios?

– ¿Hay coherencia entre los niveles de servicio prestados y los costes
asociados?
– ¿Cuáles han sido las mejoras de eficiencia o productividad del nego-
cio derivadas de la aplicación de las TIC?
4. Ayudar a la creación de nuevas capacidades
– ¿Cómo lograr economías de escala ofreciendo servicios adaptados a

las áreas cliente?
– ¿Cuál es el nivel de apalancamiento del negocio en las TIC?
– ¿Cómo pueden las TIC ayudar a competir mejor, en procesos, produc-
tos o servicios, o mediante la redefinición del modelo de negocio?
Para poder responder adecuadamente las preguntas formuladas para cada uno
de los ámbitos, es necesario conocer en profundidad los costes en los que incurre
el departamento TIC, los servicios que ofrece, quiénes son los usuarios y de-
mandantes de estos servicios y cómo se puede valorar globalmente el servicio
prestado, así como tener una valoración adicional en términos de su impacto en
el posicionamiento competitivo de la empresa.
Sin embargo, son muchas las compañías que ni tan siquiera hacen algún
cargo de los costes de las TIC a otras áreas. En esta situación, las áreas «cliente»
no asumen los costes derivados del uso de las tecnologías de la información y
este departamento acomete todos sus proyectos de acuerdo con un presupuesto
acordado. Uno podría pensar que este modo de funcionamiento tiene la ventaja
de que siempre que se mantengan dentro del presupuesto, se pueden llevar a
cabo proyectos estratégicos para la empresa, que presumiblemente darán resul-
tados a largo plazo, sin necesidad de justificar resultados a corto término. Sin
embargo, la experiencia demuestra no cargar los costes al resto de las áreas suele
llevar a un incremento importante de aquéllos sin una mejora paralela de la
calidad percibida por el resto de los departamentos, o sin un objetivo de empresa
obvio. Paradójicamente, aunque no se les repercutan los costes, en estas circuns-
tancias los departamentos suelen tener la sensación de servicio caro y que por
tanto deben exigir un servicio de mayor calidad, actitud por otra parte compren-
sible ya que el coste de sus demandas no afecta a sus cuentas de resultados. En
general, pues, considerar los costes TIC como de estructura provoca que el coste
de las TIC se incremente fuertemente.
En contraste, en otras empresas los costes del departamento TIC se cargan
«por decreto» a otras unidades de la empresa. Sin haber llevado a cabo un análi-
sis en profundidad, la asignación de costes resultante suele ser incompleta y
normalmente «injusta» en el sentido de que no se asignan los costes en función

de los consumos de recursos y de los propulsores de dichos costes. Muchas ve-

ces, las decisiones «por decreto» son consecuencia de un intento de conciencia-
ción de la importancia de los costes de las TIC. Ésta, junto a su simplicidad de
aplicación, es la principal ventaja de esta forma de asignación de los costes. No
obstante, el hecho de que la asignación sea subjetiva y decidida por la dirección
puede fomentar el rechazo del modelo por parte de los gestores de otros departa-
mentos que cuestionan la actividad desarrollada por el departamento TIC. Adi-
cionalmente, el modelo puede fomentar el desequilibrio de servicios que el de-
partamento TIC ofrece a unos departamentos o a otros, y puede llegar a frenar el
desarrollo de proyectos de alto coste independientemente de sus beneficios para
la empresa.
Un tercer grupo de situaciones son aquellas en las que los costes comparti-
dos son cargados de forma directa, siendo asignados en base a criterios simples
y conocidos, o en las que los usuarios/clientes pagan sus costes según su uso
real.
Este modelo es más «justo» y normalmente aceptado por la totalidad de la
empresa, promoviendo así la responsabilidad compartida de los costes. Los car-
gos directos obligan a los departamentos cliente a solicitar los servicios de TIC,
generando un nuevo esquema de interacción basado en información económica
y en la calidad del servicio. El cliente se conciencia de la necesidad de gestionar
los costes, y el departamento TIC de adaptar a cada departamento cliente el
nivel de servicio ofrecido. El inconveniente de este modelo reside en la comple-
jidad de su puesta en marcha, y en la dificultad de establecer el coste de los
servicios.
Finalmente, algunas empresas optan por una relación en la que el departa-
mento TIC se asemeja más a un proveedor externo y «factura» a cada área clien-
te en función de sus consumos o de los servicios recibidos. El resto de los depar-
tamentos pueden solicitar sus servicios bien al departamento interno, bien a
proveedores externos, introduciendo de esta forma las ventajas del mercado (op-
timización de costes y mejora del servicio). Son departamentos TIC gestio-
nados como centros de beneficios, y en numerosas ocasiones venden sus servi-
cios a otras empresas. Estos modelos promueven la eficiencia y la eficacia en el
funcionamiento del departamento TIC. No obstante, a medio y largo plazo pue-
den generar riesgos para la empresa, ya que al tener que negociar cada servicio
como si de una empresa se tratase, aumentan considerablemente los costes de
transacción y en aras a la comodidad y a la flexibilidad se pueden crear subes-
tructuras TIC en los departamentos usuarios, desapareciendo la gestión global
de los sistemas, y perdiendo de esta forma una posible fuente de ventaja compe-
titiva.
Es evidente pues, que cada empresa debe encontrar el modelo de asignación
de costes más adecuado a su modelo de gestión, pero en cualquier caso debiera
ser evidente que la definición de los servicios y la medición de los consumos de
los mismos por parte de las áreas funcionales permite el establecimiento de rela-
ciones «cliente»/«proveedor» a nivel interno, forzando a las diferentes áreas a
tomar conciencia del coste real de la provisión de los servicios TIC. Además, al
favorecer la focalización del esfuerzo en las necesidades reales de los departa-
mentos clientes, ello suele conllevar un incremento de productividad en el de-
partamento TIC, maximizando a su vez la ecuación «calidad ofrecida frente a
calidad percibida».

UN MODELO DE CONTROL Y GESTIÓN DE COSTES

DEL DEPARTAMENTO DE SI
Un modelo adecuado de gestión y control de costes tiene que cumplir una serie de
características. Entre ellas cabe destacar que el modelo debe ser:
z justo a la hora de repartir los costes a las áreas cliente.

z entendible por todas las áreas cliente, para que pueden aceptar los costes
que se les asigne.
z estable y replicable en el tiempo en cuanto a su estructura, para obtener
datos comparables entre los distintos períodos.
z validado y aceptado por toda la organización, esto es, que los cargos que
se realicen y su evolución sean compartidos.
z realista y que refleje la situación del departamento o de la entidad en
cada momento.
z comparable, es decir, que ofrezca datos fácilmente comparables con in-
formación estándar del mercado o con información de benchmarking tra-
dicionalmente publicados por empresas del mercado.
z flexible, de manera que pueda recoger de forma sencilla los cambios
organizativos de la entidad y los cambios en la tecnología.
Estas características generales han de tenerse presentes durante el proceso de

definición del modelo de control y gestión. Este proceso consiste en tres grandes
etapas: (1) identificación los costes de TIC y capacidad de medirlos, (2) clasifi-
cación de forma que proporcionen información de interés para su gestión, y (3)
asignación a los responsables de los mismos o a sus usuarios finales.
Identificación y medición de los costes que corresponden

al departamento TIC
La identificación de los costes es el primer paso para un adecuado control del

gasto en TIC de una empresa. Consiste en definir qué elementos o actividades se
consideran como propios del departamento TIC, de dónde se obtiene la informa-
ción sobre sus costes, y qué proporción de dichos costes se debe imputar a cada
período.
Este ejercicio parece sencillo, y conceptualmente presenta pocos problemas.
Sin embargo, en la realidad empresarial suelen aparecer una serie de dificultades
al intentar concretar la información necesaria. Las primeras dificultades surgen a
la hora de identificar los costes de TIC. Suele existir una multitud de elementos
con un alto componente tecnológico gestionados por departamentos externos al
de TIC, y cuya pertenencia al mundo de los sistemas puede ser más que discuti-
ble. Así, las divergencias sobre la asunción de costes puede ir desde el gasto de
telefonía hasta el control de acceso a los edificios si, por ejemplo, el sistema es
electrónico y debe acceder a una base de datos de personal centralizada. Además,
aparecen dificultades relacionadas con la distinta naturaleza de los costes de TIC
–gasto e inversión– y su tratamiento contable. Finalmente, se dan dificultades
que hacen referencia a la puntualidad de la contratación y a la facturación de
servicios frente a la pluri-periodicidad de la recepción de los servicios de TIC.

¿Qué elementos o actividades deben formar parte del coste

del departamento TIC?
El primer punto a aclarar es pues la definición de los elementos o actividades

cuyos costes van a medirse y a considerarse coste de TIC. De manera general, tal
y como se introdujo en el Capítulo 2, el departamento TIC es responsable de
toda la actividad relacionada con la gestión de las TIC, entendidas como un
conjunto formal de procesos mayoritariamente apoyados en tecnología que ope-
ran sobre una colección de datos estructurada de acuerdo con las necesidades de
la empresa, con el fin de apoyar la toma de decisiones necesaria para el buen
desempeño de funciones y procesos de negocio de acuerdo con la estrategia de
la empresa. Consecuentemente, todos los costes derivados del ejercicio de esta
responsabilidad deberán ser tenidos en cuenta en su medición.
En este sentido, a modo de guía, puede considerarse que los costes del de-
partamento TIC son los correspondientes al desarrollo de las siguientes activi-
dades:
z La gestión estratégica de los sistemas.

z La innovación en TIC y su incorporación a los procesos de la empresa.
z La compra y el mantenimiento del sistema central o centro de proceso de
datos.
z La compra y el mantenimiento de equipos de microinformática.
z La instalación y el mantenimiento de la red de datos y voz.
z El desarrollo, adaptación y mantenimiento de aplicaciones.
z La compra y el mantenimiento de licencias de software.
z El despliegue e instalación de equipos informáticos o aplicaciones.
z La formación de los usuarios en el uso de los productos y servicios facili-
tados por las TIC.
Sin embargo no existe un criterio homogéneo a la hora de decidir si se inclu-

yen o no como costes las siguientes partidas:
z Los asociados a las telecomunicaciones y a la seguridad (fax, teléfonos,

alarmas...).
z Los de los consumibles de los equipos informáticos (toner, cintas, cartu-
chos, papel,...).
z Los asociados a determinados equipos (fotocopiadoras, lectores de códi-
go de barras, destructoras de papel...).
Corresponde a cada empresa, en función de su organización y del peso rela-

tivo de estos elementos, decidir el tratamiento a dar a los costes relacionados,
para reflejar de la mejor forma posible su realidad empresarial.
¿Se trata de un gasto o de una inversión?
Un segundo punto muy común que se tiene que aclarar se refiere a la distinta
naturaleza de los costes, y por consiguiente del tratamiento que se les va a dar.
Dado que el interés de la medición y control de costes se centra en proveer los

instrumentos de análisis más adecuados, el tratamiento que se puede dar a un de-

terminado coste a efectos analíticos puede diferir del criterio contable que se apli-
ca para la contabilidad financiera. Básicamente, en los modelos de coste cualquier
inversión se puede tratar de tres formas diferentes.
En primer lugar, se los puede considerar como gasto del ejercicio. Numero-
sos informes comparativos de gastos de TIC entre empresas dan este tratamiento
a las inversiones. Ofrece la ventaja de facilitar el tratamiento de los datos, aun-
que tiene la desventaja de penalizar los años en los que se realizan importantes
esfuerzos inversores, como la renovación del parque de PC o la migración del
sistema central a una nueva tecnología.
En segundo lugar, se puede considerar su periodificación de acuerdo a su
duración y utilidad para la empresa. El coste del bien se deprecia en función de
la utilidad que proporciona periódicamente a la empresa, y es este coste el que
se asigna a cada ejercicio. Es el método utilizado en el TCO (Total Cost of
Ownership) descrito en el Capítulo 8, que ofrece la ventaja de asignar a cada
período el coste del inmovilizado que le corresponde. No obstante, introduce un
elemento de subjetividad a la hora de definir a priori la duración del inmoviliza-
do, y plantea la problemática de qué hacer en el caso de que una inversión quede
obsoleta antes de su baja programada. Otra de sus desventajas reside en la com-
plejidad de su gestión, ya que al no considerar una depreciación lineal si no real
es necesario definir y desarrollar sistemas de medición de la utilidad de cada
elemento (por ejemplo, el número de transacciones realizadas de un software o
el número de horas de utilización de una máquina,...).
Finalmente, el coste de inversión se puede periodificar según las normas
del Plan General Contable (PGC). El coste de las inversiones es periodificado
según la naturaleza de los bienes y de acuerdo con las tablas definidas en el
PGC. Sólo se activará el inmovilizado cuando entre en funcionamiento, esto es,
cuando dé servicio2. En la actualidad, parece ser que éste es el método más
utilizado en el entorno empresarial español. Tiene la ventaja de ser un método
sencillo, al utilizar información disponible por la empresa y publicada por el
departamento financiero. Además, permite cuadrar fácilmente la información de
la contabilidad analítica con la información de la contabilidad financiera. Su
principal desventaja radica en el carácter de «estimación» que tienen los datos y
en la falta de tratamiento de la obsolescencia anticipada de determinados ele-
mentos y del alargamiento de la vida útil de otros.
No todas las partidas del presupuesto del departamento presentan esta pro-
blemática. Existen algunas que se pueden considerar directamente como gasto
interno del departamento. Ello incluye algunos costes directos, como el coste
del personal interno, y otros indirectos en forma de los recursos básicos que
necesita el departamento TIC para el desempeño de sus funciones y que son
proporcionados por otras áreas de la empresa: el espacio físico, la luz, la forma-
ción, la tramitación de la nómina del personal interno, la selección de personal,
etc. Todos estos gastos, en su parte alícuota o directamente imputable al departa-
mento TIC, se consideran gastos de tecnología, ya que son imprescindibles para
que el departamento ofrezca los servicios que le son propios.
2
En el caso de entidades financieras y siguiendo los principios dictados por el Banco de España,
las inversiones se activarán en el momento de la recepción de la factura.

En segundo lugar, suele existir una serie de gastos de servicios externos, es

decir aquellos que el departamento TIC adquiere en el mercado, pero que con-
ceptualmente no difieren de los gastos internos, y son por tanto necesarios
para que el departamento cumpla adecuadamente su función. De este modo,
puede tratarse de (1) servicios que no podrían ser suministrados internamente
por el área, como es el caso de la contratación de una línea ADSL o de una
certificación de calidad, o (2) servicios que son simplemente subcontratados a
empresas externas pudiendo ser desarrollados internamente por la empresa. En
este caso, tal como se explica en detalle en el Capítulo 7, la decisión de subcon-
tratar un servicio está relacionada con el conocimiento que tenga la empresa
subcontratada frente a los conocimientos internos de la empresa, o bien con sus
costes, en muchos casos inferiores ya que la empresa subcontratada dispone de
mejores infraestructuras, y tiene economías de escala que por sí solo un departa-
mento TIC no es capaz de desarrollar.
Por ello, las dificultades de medición afectan sobre toda a aquellas adquisi-
ciones o desarrollos que tienen un impacto plurianual, muchas veces en situa-
ciones de desconocimiento del marco temporal exacto. Estas inversiones pue-
den ser tanto en software como en hardware, y normalmente representan un alto
porcentaje del presupuesto global del departamento. En el caso de los elementos
de hardware, la decisión de consideración del coste como inversión o gasto suele
estar más clara. De manera general, la adquisición y las mejoras del hardware se
consideran inversión, mientras que su mantenimiento o mejora post-instalación
se consideran gasto. En el caso del desarrollo de elementos de software, el límite
no está tan definido. Por norma, si se trata de un nuevo sistema que sustituye a
uno antiguo o que permite la generación de un nuevo servicio, se habla de inver-
sión. Si se trata de una mejora de un sistema ya existente, se considera gasto. El
problema aparece en aquellas mejoras que suponen un coste de desarrollo muy
elevado y que tienen un fuerte impacto en la organización (por ejemplo incre-
mento de la productividad de un determinado departamento). En estos casos es
necesario establecer criterios estables que determinen si un desarrollo debe ser
considerado inversión o gasto. Dichos criterios se tienen que consensuar interna-
mente con otras áreas de la empresa, estableciéndose de tal manera que reflejen
fidedignamente la realidad empresarial. A modo de ejemplo, la Figura 9.1 reco-
ge algunas posibilidades de variables discriminantes, así como de los criterios
de discriminación para considerar un desarrollo de mejora como gasto o inver-
sión.
¿Cuándo conviene periodificar?
El tercer punto a aclarar para la correcta medición de los costes es el tratamiento

que se da a las contrataciones plurianuales. En los departamentos TIC hay nu-
merosos contratos que afectan a más de un período y son facturados a la vez.
También existen servicios «post venta» cuyo coste se incluye en el coste de
adquisición de los inmovilizados (y como tales son amortizados), y que suponen
la anticipación de un servicio, por ejemplo de mantenimiento. De forma general
se debe periodificar el coste asociado a estas contrataciones haciéndolas coinci-
dir con el período de prestación del servicio. Así, si por ejemplo un servicio de
mantenimiento que dura 24 meses se contrata y se paga de una sola vez, se

Variables que permiten Criterios de discriminación para considerar una

discriminar los desarrollos mejora como inversión
x De manera general si se supera el 5% de las

horas de desarrollo de la solución inicial
Número de horas de desarrollo
x Para entidades bancarias si se superan las 120
horas de desarrollo
Incremento de la vida útil de la x Si la mejora supone un incremento de al menos

aplicación 2 años en la vida estimada de la aplicación
Importe anual de las mejoras x Si la mejora supera el 5% del coste de la

realizadas inversión total en software
Figura 9.1. Ejemplos de variables discriminantes y criterios para considerar los

desarrollos como inversión o gasto.
considerará un coste mensual de mantenimiento de la vigésimo cuarta parte del

total desembolsado.
Clasificación de los costes
Una vez los costes asociados al departamento TIC han sido identificados y se
han establecido los criterios de medición más adecuados para cada período, es
necesario estructurar la información de manera que sea útil para la gestión del
departamento y para el control de los costes.
Es evidente que la información que se genere tendrá diferentes destinatarios:
la dirección de la empresa, la dirección del departamento TIC y los usuarios/
clientes del departamento. Cada uno de los destinatarios de la información bus-
cará en ella las claves para la gestión de los elementos de los que es responsable.
Por ello es necesario que la información sea entendible y adecuada a las necesi-
dades de gestión de los distintos usuarios.
Para estructurar correctamente la información de costes, ésta debe clasifi-
carse y asignarse. Por clasificación del coste se entiende la estructuración de la
información de partida, es decir la información suministrada por la contabilidad
financiera, en bloques o epígrafes. De esta forma, permite analizar la estructura
de los mismos, realizar comparativas entre años y conocer su utilidad (o aplica-
ción). Es necesario, por tanto, disponer de la información económica con un
nivel de detalle adecuado, para lo cual a veces será necesario remitirse a infor-
mación contenida en las facturas y bajar a niveles de desagregación superiores a
los que imponen las normas de la contabilidad financiera. Los presupuestos y la
revisión de éstos, así como los documentos auxiliares de soporte a los mismos,
suelen ser útiles fuentes de información.

Tipos de clasificaciones
Se pueden realizar diferentes tipos de clasificaciones de costes según el objetivo

que se persiga con el análisis o con el tipo de análisis que se desea hacer. Tradi-
cionalmente, dado que la contabilidad analítica se desarrolló principalmente en
empresas industriales con actividad productiva, las clasificaciones de los costes
han estado orientadas en conocer el impacto de la actividad productiva en el
incremento de los costes. Para un departamento TIC, clasificaciones tradiciona-
les como la distinción entre costes directos versus indirectos, fijos versus varia-
bles o diferenciales versus marginales suele ser de poca utilidad, ya que aportan
escasa información para la gestión y el control del departamento. Sin embargo,
existen otras clasificaciones que pueden reflejar mejor la realidad del departa-
mento TIC.
Clasificación por la naturaleza del recurso
Consiste en la discriminación entre gasto interno, externo e inversión. Esta in-

formación es de gran utilidad para la dirección de la empresa, ya que permite
conocer a grandes trazos la estrategia del departamento TIC, el grado de subcon-
tratación de servicios, la política de inversión, la necesidad de renovar elemen-
tos del hardware o software, o el foco de la contención del gasto, tal como se
muestra en la Figura 9.2.
Clasificación por proyecto
Esta clasificación permite conocer los costes asociados a cada proyecto y facili-
ta una mejor gestión de los mismos por parte de los responsables del departa-
mento TIC, identificando desviaciones o niveles de ejecución del presupuesto.
También permite evaluar a los responsables de los proyectos.
Costes de personal
Gastos internos
Costes de infraestructura interna
Coste de outsourcing
Gastos de servicios Coste de servicios
externos Compra de consumibles
Cuotas y tasas
Amortización de software
Amortización
Amortización de hardware
Figura 9.2. Clasificación por naturaleza del recurso.


Clasificación por área interna de TIC que gestiona el presupuesto

(o centro)
La información de los costes por área interna de TIC que gestiona el presupuesto
permite evaluar a los responsables de cada área, permitiendo a la dirección exigir
responsabilidades en función de los costes incurridos, de la evolución de los mis-
mos y del nivel de ejecución del presupuesto en los distintos momentos del año.
Clasificación por la recurrencia o no de los costes
En un departamento TIC, suelen existir toda una serie de costes recurrentes,

entendidos como aquellos que se producen de forma sistemática todos los años,
tal y como se muestra en la Figura 9.3. Esta clasificación permite a la dirección
de la empresa identificar de forma inmediata los gastos mínimos habituales de
mantenimiento, permitiendo a la dirección del departamento TIC enfocar sus
esfuerzos de contención de gastos en las partidas que tengan un impacto «per-
manente» en la entidad, y no un impacto puntual únicamente en el año en el que
se lleva a cabo el esfuerzo.
Clasificación por entorno informático
Esta clasificación facilita el conocimiento del coste por entorno, la eficiencia de

cada entorno y la comparación de los costes con estándares de mercado. Es una
Clasificación de costes por recurrencia
Impresión
Gestión operacional
Explotación
Explotación
Soporte de sistemas
Software
Gestión evolutiva Aplicaciones
Mantenimiento
licencias
Mantenimiento equipos
Hardware
Soporte a negocio
Gestión estratégica y
Gestión estratégica y
operativa
operativa
Trasmisión de voz y
datos Nuevos desarrollos
Actividades de Amortización Nuevos negocios,

soporte crecimiento
Figura 9.3. Ejemplo de una clasificación de costes por recurrencia.


información de gran utilidad tanto para la dirección general de la empresa como

para la dirección del departamento TIC, ya que permite tomar decisiones sobre
qué entornos desarrollar o sobre los entornos donde llevar a cabo políticas de
reestructuración. Además, gran parte de la publicación de costes para realizar
benchmarking se presenta por entornos. La Figura 9.4 presenta un ejemplo de
clasificación de costes de este tipo.
Clasificación por actividad y procesos
Es la clasificación más completa, ya que permite conocer –y posteriormente

repercutir costes a los diversos clientes internos del departamento TIC– el coste
de las actividades que lleva a cabo el departamento, y por tanto en qué procesos
se centra el esfuerzo de las TIC. Para hacer la clasificación por actividades, se
agrupan los distintos costes identificados en grupos más extensos. Para ello, es
útil definir un mapa productivo (como muestra la Figura 9.5), y a partir de éste ir
clasificando por actividades.
Host
• Producción
• Contingencia
Sistema central Sistemas medios
• UNIX
• AIX
• NT
PC
• Portátiles
• Fijos
Microinformática Impresoras
• Financieras
• Láser
• Color
Voz
Datos
Comunicaciones • Backbone
• Líneas
• Frame Relay
• Líneas ADSL
Orientado a aplicaciones de negocio
• Productos
• Logística
Desarrollo
Orientado a sistemas
• Seguridad
• Arquitectura
Figura 9.4. Clasificación de costes por entorno tecnológico.


Innovación Tecnológica
Productos / Canales
Áreas Internas
Nuevos desarrollos de soluciones
Mantenimiento y Explotación
Arquitectura e Ingeniería
Figura 9.5. Mapa productivo de un departamento TIC.

La Figura 9.6 muestra de forma detallada una posible clasificación de este tipo.
Para la correcta clasificación, es crítico definir correctamente los criterios de re-
parto de los elementos de coste inicialmente indicados hacia las diferentes activi-
dades establecidas en el mapa productivo. Para definirlos habrá que preguntarse
en función de qué elementos una actividad consume más o menos recursos, para
así definir correctamente una serie de criterios de reparto.
De este modo, la clasificación por actividades (una explicación más deta-
llada del por qué de este modelo de costes se encuentra en el Cuadro 9.1, en el
que se describe el sistema de costes basado en actividades o «ABC costing»)
permite identificar de forma estructurada las presiones o solicitudes de otras
áreas internas de la empresa (Input) sobre el departamento TIC y el impacto en
su mapa productivo, así como a quién van dirigidos sus esfuerzos del área
(Output). En este sentido, constituye el punto de partida para cualquier discu-
sión sobre la conveniencia o no de los costes de TIC, ya que indica no sólo
cómo y por qué se producen, sino también a quién van dirigidos, tal y como se
ilustra en la Figura 9.7.
Asignación y reparto de costes
El proceso de asignación de coste constituye la parte final del proceso de identi-

ficación, medición y clasificación de los costes. A grandes rasgos, consiste en
una nueva distribución y clasificación de los mismos al «beneficiario» de los
servicios que suministra el área de TIC, a través de una serie de criterios prede-
finidos y aceptados por toda la organización. De esta forma, se llega al modelo
de control deseado.

Ingeniería Planificación estratégica de los sistemas

y arquitectura Normas de construcción de software
Desarrollo de herramientas o piezas básicas
de software
Innovación Investigación y prospección de mercado

tecnológica Evaluación de soluciones
Realización de prototipos
Nuevos Análisis de los requerimientos de hardware,

desarrollos software de base y comunicación
de soluciones z Identificación de problemáticas
z Análisis de la problemática
z Identificación de soluciones
Estudio de soluciones
z Diseño de soluciones
z Evaluación de las soluciones
z Priorización y definición de la solución
Compra, instalación máquinas y sistemas operativos

z Compra, instalación y baja de hardware
z Compra, Instalación
z Configuración/re-configuración
z Baja, Desplazamiento
z Compra, instalación y baja de licencias
z Compra, Distribución, Instalación
z Baja
Análisis de requerimientos de negocio

z Análisis de requerimientos globales
z Planificación con el cliente
z Gestión de cartera
Desarrollo de aplicaciones/Mantenimiento evolutivo

z Definición de la solución
z Diseño dirigido al cliente
z Diseño dirigido a la construcción
z Adquisición de paquetes
z Construcción
Pruebas e implantación
z Pruebas de clientes
Figura 9.6. Servicios del departamento TIC clasificados por actividades

y procesos
(Fuente: Elaboración propia)

z Implantación
z Formación
z Puesta en producción
z Soporte al arranque
Mantenimiento Soporte a usuarios/Help Desk

y explotación z Registro de incidencias
z Resolución de incidencias de primer nivel
z Recogida de sugerencias
Mantenimiento de software de base/Middleware

z Correctivo
z Evolutivo
Mantenimiento de hardware
z Preventivo
z Correctivo
z Evolutivo
Comunicaciones
z Compra, instalación y baja
z Mantenimiento de la conectividad
Técnica de sistemas
z Gestión de sistemas operativos/Herramientas
de base
z Instalación y distribución de software
z Gestión y planificación de capacidades
de máquinas
z Gestión y planificación del tráfico de datos
z Gestión de la seguridad en los sistemas
o Back up
o Altas y bajas de usuarios
o Control de la accesibilidad de los sistemas
o Protección de los sistemas
z Buscar utilities (infraestructura técnica)
Explotación
z Supervisión de la operativa
z Seguimiento del rendimiento de las máquinas
z Gestión del almacenamiento de datos
Mantenimiento correctivo de aplicaciones

Soporte operacional de aplicaciones
Figura 9.6. (Continuación)

¿Por qué un modelo de costes ABC?
En la contabilidad analítica se contemplan tres familias básicas de mode-

los de: (1) Basados en centros de coste en el que los costes son reparti-
dos a centros de responsabilidad o actividad. A su vez, los centros de
naturaleza productiva reparten el coste que se les ha asignado a los pro-
ductos en función de la producción realizada. (2) Basados en órdenes de
producción/proyectos, en los que los costes directos se asocian a cada
orden de producción o a cada proyecto y de éstos a los productos. (3)
Basados en actividades donde los costes son asociados a las activida-
des que realiza la empresa y posteriormente a los clientes o productos de
ésta en función del consumo que hacen de las mismas. Una de las dife-
rencias entre ellos radica en el tratamiento de los costes indirectos3. En
un departamento de SI los costes indirectos son de especial relevancia,
ya que hay que escoger cuidadosamente el modelo de asignación a se-
guir, optando por aquel que mejor refleje las particularidades del funcio-
namiento del departamento de SI. En este sentido, el modelo de costes
basado en actividades o modelo ABC (Activity Based Costing) es el que
mejor se ajusta. Además de permitir un óptimo tratamiento de los costes
indirectos, ofrece información sobre costes no únicamente para su ges-
tión interna (a través de la clasificación de los costes), sino que también
permite una asignación detallada de los mismos a los clientes internos
de la empresa. De este modo, cumple los objetivos inicialmente fijados
de asignación de costes a los usuarios finales y obtención de información
relevante para la buena gestión del departamento de SI. Antes de entrar
en una descripción detallada del método conviene entender los grandes
pasos a seguir. Partiendo de la clasificación de actividades, se identifican
unos criterios de reparto, o drivers, que sirven para la asignación de los
costes a las actividades. De este modo, se pueden obtener costes unita-
rios que pueden ser comparados con estándares de mercado, como por
ejemplo el coste de mantenimiento de un PC o el coste de una transac-
ción host en un sector de actividad. Además, permite un control exhausti-
vo de cada actividad y el análisis de tendencias, entendiendo el por qué
de eventuales variaciones.
3
Las diferencias en el tratamiento de los costes indirectos en cada uno de los modelos
consisten, a grosso modo, en que en los modelos basados en centros de coste, los costes
indirectos son repartidos en base a un criterio predefinido o de manera proporcional a los
costes de cada centro, mientras que en los modelos basados en órdenes de producción/pro-
yectos los costes indirectos no suelen ser repartidos, aunque ocasionalmente se incrementa
en un porcentaje el coste de cada orden para que asuma la parte de costes de estructura o
indirectos. Finalmente, en los modelos basados en actividades se intenta «convertir en direc-
tos» estos costes a través de las actividades definidas, usando el consumo de unas activida-
des como indicador del consumo de otras.
Cuadro 9.1. Modelo de costes ABC.

¿Cuánto cuesta dar servicio?
Coste
de
recursos
¿Cómo se Trabaja?
Reducir costes
Coste de
Generadores Coste Indicadores
Aumentar
de coste/Drivers de de
rendimiento y
actividades rendimiento
productividad
Coste de los
objetos de coste
Conocer costes
Aumentar rentabilidad
Figura 9.7. El coste de las actividades como figura central del análisis
de costes.
Para llevar a cabo esta asignación es necesario contar en primer lugar con una
lista bien definida de los servicios, resultado del proceso de clasificación, como
por ejemplo, en caso de seguirse una clasificación por actividades, la lista de acti-
vidades del departamento TIC. Para la asignación, hace falta definir (1) la lista de
posibles causantes de los costes y (2) las métricas de reparto adecuadas que permi-
tan asignar a cada «beneficiario» su parte de coste. Ello es necesario ya que rara
vez el 100% de un coste se asigna a un único departamento beneficiario.
Los objetos de costes: ¿Cuál es la causa por la que se incurre el coste?
La definición de objetos de coste y su asignación a las diferentes áreas de la em-

presa favorece la corresponsabilidad en los costes por las áreas usuarias. Un buen
modelo de asignación de los costes de prestación de servicios de TIC puede llevar
cambios en los modelos de relación entre usuarios y el área de TIC debido a que
las áreas funcionales cogen conciencia del coste real de los servicios del departa-
mento de tecnología.
Los departamentos que hemos denominado «beneficiarios» de las actividades
realizadas por el departamento TIC suelen llamarse en la nomenclatura habitual de

análisis de costes «objetos de coste», ya que son los responsables últimos de los
mismos. En una entidad financiera, por ejemplo, se podrían definir tres tipos de
objetos de coste, tal como se detalla en la Figura 9.8:
z Productos y/o servicios.

z Clientes.
z Canales.
Establecimiento de métricas de reparto
Una vez definidos los objetos de coste, se les debe asignar la parte proporcional
del coste del departamento mediante las métricas y criterios de reparto preesta-
blecidos, denominados drivers en la nomenclatura habitual. La Figura 9.9 pre-
senta unos ejemplos de drivers. La información sobre cuáles deben ser los dri-
vers y su magnitud proviene normalmente de multitud de fuentes. Buena parte
de la información se registra en los inventarios del inmovilizado, otra es sumi-
nistrada directamente por los proveedores, y una última parte registrada por he-
rramientas de contabilidad interna de los propios sistemas, por ejemplo el núme-
ro de Mips (actividad de la CPU) consumidos, número de transacciones procesadas,
etc.
Con la asignación del coste de las actividades a los objetos de coste termina
el proceso de construcción del modelo de costes para la medición y control de
las actividades del departamento TIC. A modo de resumen, la Figura 9.10 esque-
matiza los principales pasos que se han seguido.
En el mercado existen una serie de herramientas que soportan los modelos de
costes basados en actividades4. Hasta la fecha estas herramientas son aplicaciones
Externos Internos
Pólizas de vida Puesto de trabajo

Servicios / Modelo X1 Nuevo desarrollo
Productos Concesión Conexión a Internet
…
Administraciones públicas Área comercial

Clientes Empresas / Particulares Área producción
… …
Retail No aplica
Autoservicio
Canales
Internet
…
Figura 9.8. Ejemplo de objetos de coste por tipos en una entidad financiera.

Elemento a repartir Driver de reparto
Coste mantenimiento de PC´s Nº de PC’s
Amortización de fax Nº de Fax

Amortización de fotocopiadora Nº de personas por departamento
Operador de voz Consumo de cada línea
Licencias de aplicaciones UNIX Nº de procesadores
Licencias de aplicaciones Host MIPS instalados
Cableado Nº de puestos de trabajo
Mantenimiento de la intranet Hits descargados
Datawarehouse Nº de consultas
Help Desk Nº de llamadas realizadas
Desarrollo de una aplicación Usuario de la aplicación / Nº de transacciones realizadas
CPU del Host MIPS consumidos
Robótica asociada al Host Cintas consumidas
Discos asociados al Host Gigas consumidas
Conexiones Host Input-Output
Entorno de desarrollo Número de compilaciones
Entornos distribuidos Espacio en disco asignado a distintos servicios
Figura 9.9. Ejemplo de criterios de reparto para la imputación

de las actividades a los objetos de coste finales.
Otros gastos
Recursos
Recursos
Recursos Gastos Amortización Personal
internos
Asignaci—n
Asignación
Asignaci—n dede
de Métricas /
recursos
recursos
recursos Criterios de reparto
Centros
Centros de
Centrosde coste
decoste
coste Entornos
Definición de procesos
Mapa
Mapa productivo
Mapaproductivo
productivo y actividades
Asignaci—n
Asignación
Asignaci—n dede
de Métricas /
actividades
actividades
actividades Criterios de reparto
Objetos
Objetos de
Objetosde coste
decoste
coste Productos y servicios Clientes Canales
Figura 9.10. Resumen del proceso de establecimiento de un modelo

de control y gestión de costes del departamento TIC.

independientes que tienen predefinidas interfaces con los principales ERP del
mercado, y permiten la carga de datos a partir de ficheros externos. Estas herra-
mientas suelen tener incorporadas funcionalidades de diseño para la representa-
ción gráfica de las actividades y procesos, y en general incorporan la posibilidad
de realizar simulaciones y planificación de necesidades de infraestructura en fun-
ción de los volúmenes de actividad estimados.

La responsabilidad de los departamentos usuarios sobre los costes del departa-
mento TIC es esencial si la empresa desea ejercer algún tipo de control sobre los
mismos. El tradicional control presupuestario consistente en seguir un presupues-
to agregado y asegurarse que el departamento TIC no gasta más de lo asignado a
Lista de funcionalidades desde un punto de vista general

Multiidioma
Multiperíodo (orientado a costes)
Librería de informes estándar y a medida
Establecer perfiles de usuario con distintos niveles de autorización
Lista de funcionalidades del Modelo de Asignación de Costes
Definir centros de coste
x Establecer jerarquías de centros de coste
x Clasificar los costes por naturaleza, características y estructura organizativa
x Registrar diferentes tipos de coste (real, presupuestario, consumido)
Definir actividades
x Crear actividades primarias y secundarias
x Establecer jerarquía de actividades
x Definir capacidades de actividades
Establecer reglas de reparto
x Asignar diferentes tipos de costes
x Realizar diferentes tipos de repartos
Definir objetos de coste
x Establecer jerarquía / clasificación de objetos de coste
x Definir criterios de reparto (qué actividad consumen y que porcentaje
de capacidad)
Realizar simulaciones
Elaborar informes por centro de coste, actividad y objeto de coste
Figura 9.11. Ejemplos de funcionalidades de una solución de modelo

de costes.
4
Como ejemplos de estas herramientas, cabe destacar en el momento de escribir esta obra,
Prodacapo ABC/M, Oros® ABC/M, Aris Toolset, ABC Toolbox y ProcessGuide.

principio de ejercicio tiene dos defectos fundamentales: los departamentos usua-

rios no se sienten responsables de los costes de sus demandas al departamento TIC
y es imposible saber si sería deseable aumentar o disminuir el presupuesto para
conseguir un servicio distinto del ofrecido. Un sistema consensuado de asigna-
ción de costes que permita repercutir la mayor parte de los costes de las TIC a los
usuarios es esencial para una gestión adecuada del recurso ya que además de res-
ponsabilizar a los beneficiarios de los costes, permite ciertas comparaciones con
estándares y empresas del sector.
Es pues tarea de la dirección poner los medios para que exista en la empresa
un sistema de contabilidad de costes que permita conocer con el detalle adecua-
do los costes del departamento TIC, que servicios presta, y que departamentos
de la organización son los «beneficiarios» de dichos servicios.


Gestión de proyectos de tecnologías de la información y comunicaciones 195
10
Gestión de proyectos
de tecnologías
de la información
y comunicaciones
La mayoría de las actividades del departamento de Tecnologías y Sistemas de In-

formación (departamento TIC) se estructuran alrededor de proyectos, por lo que
su gestión es la actividad que más recursos personales consume del área de TIC.
Prácticamente la totalidad de las decisiones de inversión, desarrollo de sistemas e
incluso las de mantenimiento de aplicaciones y la actualización de sistemas opera-
tivos y los cambios de versión de ERP se convierten en proyectos en los que se
definen las distintas fases, las acciones a desarrollar en cada una de ellas, las per-
sonas involucradas, los responsables de su ejecución y los tiempos estimados para
las mismas. En este sentido, las distintas metodologías y herramientas de gestión
de proyectos, bien sean específicas de una empresa o estándares de mercado, están
enfocadas a facilitar tanto las tareas de definición de los objetivos, alcance, etc. del
proyecto como la posterior coordinación y seguimiento del logro de los resultados
previstos, la identificación de desviaciones y la incorporación de medidas correc-
toras para asegurarlos.
Este capítulo no pretende ser en absoluto un manual sobre gestión de proyec-
tos, ya que se supone que el departamento TIC dispone de las herramientas clá-
sicas de gestión de proyectos como son los diagramas de Gant, los sistemas
PERT para el control de tiempos y uso de recursos, etc. Los párrafos que siguen
revisan los aspectos característicos de los proyectos TIC que los diferencian de
otros proyectos de empresa, presenta las etapas en que se suelen dividir los pro-
yectos TIC y sus elementos más comunes.
FASES DE UN PROYECTO TIC

Se pueden definir cuatro fases en la vida de todo proyecto TIC: (1) la definición,
(2) el desarrollo, (3) su implantación o puesta en marcha y utilización por los
usuarios a los que va destinado y finalmente (4) el mantenimiento y operación
de la solución desarrollada. La Figura 10.1 presenta estos bloques básicos. Sin
embargo, en función del tamaño y de la naturaleza del proyecto, estas fases
195

Operación y
Inicio Desarrollo Implantación
mantenimiento
Figura 10.1. Fases generales de la gestión de un proyecto.

pueden verse modificadas o ampliadas, incorporando bloques de actividades rele-

vantes como el diseño, prototipaje o pruebas.
Hay que tener en cuenta, no obstante, que la gestión de un proyecto no se
ejecuta de forma secuencial (de izquierda a derecha). En función de su comple-
jidad, su coste, el número de personas involucradas o de la radicalidad de los
cambios que el mismo pueda introducir en las actividades de la empresa, las
distintas fases aparecerán solapadas en el tiempo y su peso relativo también se
verá afectado.
Fase 1: Inicio y definición de un proyecto TIC
Todo proyecto TIC debe tener un patrocinador y son diversos los motivos que
pueden llevar a un individuo dentro de la organización a plantear la posibilidad
de patrocinarlo. En ocasiones, puede tratarse de un usuario quien detecte la ne-
cesidad de un nuevo sistema y se lo comunique al departamento TIC o bien es el
propio departamento TIC quien descubre la oportunidad de usar sistemas de
información y decide comunicar los beneficios a los usuarios. También son mu-
chos los casos en los que un proyecto se ha iniciado como consecuencia de un
problema en los sistemas actuales que puede ser grave en un futuro y que no
puede tratarse como una simple mejora si no que debe plantearse y desarrollarse
como un sistema nuevo. No obstante en la mayoría de las situaciones suele ser
un director o máximo responsable fuera del departamento TIC quien detecta el
problema o una oportunidad relacionada con el área en la que trabaja y pide la
colaboración del departamento TIC para analizar si puede o no llevarse a cabo
un proyecto.
Es al inicio del proyecto cuando se especifica el alcance de la necesidad de
modificar o mejorar un sistema actual, de desarrollar uno nuevo o incluso de
adquirir una solución estándar de mercado (ERP, SCM, etc.). Es necesario des-
cribir cuáles son las pautas bajo las cuales deberá funcionar el nuevo sistema,
qué tipos de información requerirá, los resultados esperados y quiénes se encar-
garán de la toma de decisiones para llevar a cabo el proyecto. Adicionalmente,
se deberán identificar y evaluar, aunque sea de forma somera, los posibles cam-
bios organizativos y de procesos de gestión internos asociados al nuevo proyecto
y planificar su adaptación de forma consistente con la ejecución y desarrollo del
mismo. La participación de distintos grupos de usuarios (técnicos, de negocio,

etcétera) y el proceso de «aceptación» de las especificaciones del sistema deberán

ser consistentes con la complejidad del mismo.
La experiencia demuestra que en los proyectos en los que la concreción de
los resultados esperados no se ha realizado con suficiente profundidad y conse-
cuentemente no se han considerado las adaptaciones y cambios necesarios en la
organización, los costes y los plazos de desarrollo crecen de forma desmesurada
respecto a las previsiones iniciales.
Fase 2. Desarrollo del proyecto
Es la fase más técnica del proceso, consistente en la creación o adquisición y

configuración del hardware, software y de los recursos y componentes necesa-
rios para que el nuevo sistema de información entre en funcionamiento. En el
caso concreto del software, éste puede ser diseñado y desarrollado dentro de la
propia empresa o bien contratado externamente (outsourcing). Tal como se deta-
lló en el Capítulo 2, son necesarios mecanismos de participación de los usuarios
finales en la validación de especificaciones de detalle (tanto a nivel del proceso
como de los resultados del mismo), o de prototipos que permitan aceptar el
«look and feel» del proyecto y su funcionalidad.
Para llevar a cabo el desarrollo de un sistema, existen diferentes tipos de
enfoques, entre los que, sin ánimo de ser exhaustivos, cabe destacar los cuatro
siguientes:
z «Ciclo de vida» tradicional (Traditional system lifecycle).

z Prototipaje (Prototyping).
z Desarrollo conjunto (Joint Application Development JAD).
z Paquetes de aplicación (Application packages).
Los siguientes párrafos repasan cada una de ellos, el «ciclo de vida» con algo
más de detalle debido a ser tradicionalmente el más usado, aunque está siendo
sustituido paulatinamente por el prototipaje.
Desarrollo mediante el «ciclo de vida» tradicional
Tal y como su nombre indica, se trata de un sistema tradicional ampliamente utili-

zado que se basa en la división del desarrollo proyectado en una serie de etapas que
configuran el ciclo de vida del sistema, cada una de ellas con sus propios objetivos
específicos y entregas programadas relacionadas entre sí. El principal objetivo de
esta visión es mantener un exhaustivo control a lo largo de todo el proyecto y
asegurar que el nuevo sistema satisface los requisitos para el cual se está diseñando.
El número de etapas de que se compone el proyecto depende del proyecto en
sí y de los objetivos que persiga la propia empresa En su extensión completa, las
etapas en las que se subdivide el desarrollo son: (a) análisis, (b) diseño, (c) pro-
gramación, y (d) instalación. Hay que recordar que estas etapas se refieren sólo
al proceso de desarrollo del proyecto; la implantación organizativa es objeto de
discusión una vez el sistema está desarrollado, instalado en el hardware, y listo
para entrar en explotación.

a. Análisis de sistemas
Dentro de esta fase existen a su vez dos etapas muy significativas. Por una parte, el
análisis de sistemas propiamente dicho, es decir, el análisis de la situación a
informatizar y, por otra, los estudios de viabilidad para determinar las posibili-
dades de éxito de la futura solución.
El análisis de sistemas pretende dar una visión global del funcionamiento de
la parte de la empresa objeto del estudio y de la situación del sistema dentro de
la organización, teniendo en cuenta tanto los actuales sistemas de información
como las personas que se pueden ver afectadas por el cambio al nuevo sistema.
Se deben identificar claramente los procesos de negocio y los flujos de informa-
ción que tienen lugar en dichos procesos.
Hoy en día, existen diferentes métodos para llevar a cabo el análisis de siste-
mas, incluso software destinado exclusivamente a este propósito. En cualquier
caso, tanto la propia observación como la revisión de documentos y las entrevis-
tas personales son de absoluta necesidad para el análisis de sistemas.
Por otra parte, para determinar si la solución adoptada será más o menos
exitosa, es necesaria la realización de estudios de viabilidad de proyectos, in-
cluyendo factores técnicos, económicos, organizacionales e incluso éticos y le-
gales. Dichos estudios deberán, además, actualizarse a medida que el proyecto
pasa por las sucesivas etapas del ciclo.
z En primer lugar, los estudios de viabilidad económica, pretenden averi-

guar si la organización es capaz de afrontar el proyecto y en qué porcen-
taje los beneficios serán superiores a los costes que conllevará. Es reco-
mendable analizar también el riesgo que conlleva, en términos de coste,
un proyecto de estas características y cuáles son las razones para darle
prioridad ante otros proyectos que puedan consumir los mismos recursos.
z Desde el punto de vista técnico, deberemos averiguar si la empresa dis-
pone de la tecnología adecuada para llevar a cabo el proyecto y los res-
ponsables de la experiencia necesaria para manejarlos. En caso de que se
detecten deficiencias, el proyecto deberá incluir los pasos adecuados para
solventar las deficiencias, bien a través de formación, bien a través de la
contratación de personas con los conocimientos adecuados.
z Los factores organizacionales de viabilidad pretenden asegurar que el
nuevo sistema sea compatible con la cultura de la empresa y con el modo
de trabajar de los usuarios. Se debe asegurar también el apoyo de toda la
organización para que la implantación sea exitosa y que los usuarios es-
tén preparados para el cambio.
b. Diseño
Finalizados los estudios de viabilidad se está en disposición de describir los

requisitos funcionales del proyecto así como realizar un plan detallado de las
actividades y «subproyectos» con sus correspondientes fechas de inicio y fin.
La idea que se persigue con la definición de los requisitos funcionales es
especificar el verdadero objetivo del proyecto analizando los procesos de la
empresa que se verán afectados y cómo ayudará a mejorar su rendimiento. Las

diferentes etapas o «subproyectos» en los que se dividirá se deben representar

gráficamente de manera que los diferentes implicados puedan conocer el tiempo
de que disponen y que secuencia se debe seguir para realizarlo.
Son muchas y muy diversas las herramientas que existen para apoyar el dise-
ño de sistemas. La mayoría están basadas en los tradicionales diagramas de flu-
jos para representar procesos y los modelos entidad-relación para representar las
estructuras de datos. Con una representación adecuada, la información resulta
mucho más visible y fácil de entender e interpretar tanto por los programadores
que han de llevar a cabo el desarrollo como por los usuarios que los han de
validar.
Dentro de esta misma etapa del ciclo de vida del proyecto, se deben sentar
las bases para «crear» el software y adquirir hardware necesarios para satisfacer
los requisitos funcionales. En otras palabras, se trata de convertir dichos requisi-
tos funcionales en una combinación de tecnologías capaz de satisfacerlos. Para
esto es necesario, en primer lugar, realizar un análisis detallado de los requisi-
tos, en donde se especifique claramente qué hará el sistema de información. Tal
como se proponía en el Capítulo 3, es recomendable en esta etapa la creación de
un equipo (equipo de diseño) formado por personal del departamento TIC así
como otros usuarios de diferentes departamentos.
Con el análisis detallado en mano, el equipo de diseño es capaz de expresar
por escrito cuál será el funcionamiento del nuevo sistema para determinar si será
capaz de satisfacer y soportar los procesos de negocio para el cual está siendo
diseñado. Hay que tener en cuenta que no se trata de diseñar todo el sistema,
sino de dar una visión general de cómo funcionará en un ordenador. La progra-
mación de dicho sistema se abordará en la siguiente fase del ciclo.
c. Programación
Esta es, posiblemente, la fase más técnica del ciclo y en la que más interviene el
personal del departamento TIC (o menos interviene el resto). Programar consis-
te en crear el código necesario para llevar a cabo la recopilación de datos, cálcu-
los y generación de informes e incluye la prueba del programa por separado para
determinar si funciona correctamente.
Son muchos los avances que se han llevado a cabo en los últimos años en los
lenguajes de programación necesarios para codificar y escribir las funciones
necesarias de esta etapa. La denominada programación estructurada o los len-
guajes de cuarta generación hacen de la programación una tarea mucho más
rápida y fiable que en los inicios de la informática, habiendo reducido los costes
de programación sustancialmente.
d. Instalación
Una vez los programas están disponibles y probados, hay que ponerlos a disposi-
ción de los usuarios para su entrada en explotación. Una parte importante de la
puesta en marcha tecnológica de un sistema cuando sustituye a uno antiguo es la
conversión de los datos al nuevo sistema. Esta etapa dependerá de las caracterís-
ticas de ambos sistemas. En un extremo, nos encontramos con la arriesgada

aunque económica solución de fijar una fecha para «apagar» el antiguo sistema,
transportar/convertir los datos y «encender» el nuevo. Otras soluciones menos
críticas podrían ser:
z Conversión en paralelo, en donde los dos sistemas, antiguo y nuevo,

funcionan a la vez durante un período determinado hasta que el antiguo
se deja de utilizar definitivamente. Aunque se trata de una solución segu-
ra, suele ser de las más caras.
z Conversión «piloto», en la que se empieza a usar el sistema en determi-
nadas áreas y poco a poco se va extendiendo a toda la organización. Visto
desde un punto de vista global, se puede clasificar como una conversión
en paralelo, puesto que en unas áreas se hará uso del antiguo sistema y en
otras, del nuevo. Tanto los riesgos implicados como los costes suelen ser
aceptables.
z Conversión modular o por fases en aquellos sistemas formados por di-
ferentes módulos, cada uno de los cuales se puede implantar progresiva-
mente y de forma independiente asegurando el correcto funcionamiento a
lo largo de todo el proceso. Suele ser una solución lenta puesto que es
necesario revisar las demás partes del sistema cada vez que se implanta
uno de sus módulos.
Algunas consideraciones finales sobre el desarrollo mediante el ciclo

de vida tradicional
Esta versión del ciclo de vida tradicional ha sido la metodología utilizada en

proyectos de infinidad de empresas durante la década de los ochenta y noventa y
todavía sigue siendo útil en la actualidad. No obstante, los numerosos casos de
fallos con sistemas que no satisfacen las necesidades de los usuarios o se com-
pletan con desfases presupuestarios exorbitantes invitan a la reflexión acerca de
la eficacia de este método.
De hecho, este método tradicional es una herencia del desarrollo de hard-
ware, en el que es necesario saber con exactitud las características del objeto a
fabricar antes de ponerse manos a la obra; corregir el diseño sobre la marcha en
la fabricación de hardware tiene elevadísimas consecuencias económicas. Afor-
tunadamente, el software se puede modificar en cualquier momento a una frac-
ción del coste de modificar un diseño de hardware. Pierde sentido una metodolo-
gía que después de recoger la información sobre las necesidades se encierra en
la trastienda y reaparece después de un cierto tiempo (largo) con un producto
que se supone satisface las necesidades especificadas de antemano.
El problema inherente a este proceso es que en general es muy difícil para
los usuarios saber exactamente qué es lo que van a necesitar del sistema una vez
esté en explotación. Los usuarios avezados y que se han encontrado en esta
tesitura anteriormente tienden a sobre-especificar sus requerimientos, pidiendo
todas las funcionalidades que se les ocurre «por si acaso», ya que saben de la
dificultad de añadirlas una vez el proyecto ha pasado a manos de los programa-
dores. Desafortunadamente, esto no es en muchos casos suficiente, ya que al ver
el sistema funcionando y empezar a explotarlo, los usuarios tienen «mejores
ideas» de cómo debería ser el sistema.

Los sistemas que se describen a continuación, de prototipaje y de desarrollo

conjunto, intentan paliar estas deficiencias del procedimiento tradicional.
Desarrollo mediante prototipaje
Desarrollar un proyecto con el sistema de prototipaje parte de la creación de un

primer sistema simplificado (prototipo) a partir del cual se determinarán con
más detalle los requisitos para la futura construcción del sistema real, tal como
se muestra en la Figura 10.2. Las empresas hacen uso de esta metodología ante
la dificultad de definir con exactitud los requisitos precisos del nuevo sistema de
información. Así como en el modelo tradicional los usuarios finales (o los ejecu-
tivos que quieren impulsar un cambio) deben describir exactamente cómo de-
sean el sistema antes de empezar a programar, en este caso tan sólo es necesaria
una idea de qué se pretende conseguir para más tarde irla perfilando con el pro-
totipo en mano. El principal objetivo de este método es producir una solución
inicial rápida para que, posteriormente, los usuarios la verifiquen y decidan so-
bre ella. Habitualmente, los programadores suelen basarse en lenguajes de cuar-
ta generación para esta primera etapa de diseño del prototipo que da muy rápida-
mente una idea de las funcionalidades que se persiguen y, a partir de éste, diseñar
la solución final con lenguajes de tercera generación1.
Pasar al ciclo de
Abandonar
vida tradicional
Construcción del Evaluar el Prototipaje

Decidir
prototipo inicial prototipo exitoso
Completar el
Revisar prototipo sistema a partir
del prototipo
Figura 10.2. Proceso de prototipaje de proyectos.

(Fuente: Alter, 2000.)
1
Los lenguajes de cuarta generación permiten un desarrollo muy rápido de programas que efec-
túan operaciones complejas pero son relativamente ineficientes para desarrollar sistemas que deban
entrar en explotación. Los lenguajes menos evolucionados permiten un control mayor de los recur-
sos del ordenador y en general producen sistemas que consumen menos recursos pero son más labo-
riosos de programar.

Es un método eficaz en aquellos proyectos en los que los usuarios finales

jugarán un rol esencial en el futuro uso del sistema que se pretende diseñar,
puesto que participan activamente en su propio diseño. No obstante, el prototi-
paje presenta dos desventajas que no podemos obviar: (1) la menor «disciplina»
en el proceso no promueve la generación de la documentación asociada, y si no
se es muy riguroso, la empresa tendrá dificultades con su posterior actualización
y mantenimiento, y (2) la dificultad de «parar» en la mejora y las modificacio-
nes al sistema.
Desarrollo conjunto
Más que una metodología completa de desarrollo, esta terminología se refiere a la

fase de recogida de información de las características deseadas del sistema; pre-
tende «aligerar» el proceso de recopilación de requisitos de los usuarios a la hora
de iniciar el análisis de un sistema. Normalmente la recogida de requisitos se rea-
liza mediante una serie de reuniones individuales e independientes con usuarios
líderes. Después, son los analistas los que juntan toda la información y proponen
las funcionalidades a los usuarios, que normalmente no están cien por cien de
acuerdo y debe iniciarse un proceso iterativo hasta llegar a un acuerdo sobre las
funcionalidades a implantar. Con el «desarrollo conjunto» la recogida de las pro-
puestas de los usuarios se realiza mediante reuniones que permitan llegar a un
acuerdo entre los distintos usuarios y los analistas en una sola sesión. La metodo-
logía requiere de la presencia de un «moderador» o principal «tomador de decisio-
nes» que evite que la reunión se convierta en un verdadero caos. Aunque, a priori,
es una solución bastante útil y acertada, la realidad no permite llevarla a cabo en
muchas organizaciones debido a la dificultad de reunir a todos los usuarios que
deben participar en el análisis y diseño de un sistema de información simultánea-
mente en un mismo lugar. Es el caso, por ejemplo, de grandes multinacionales que
tienen a sus usuarios repartidos por todo el mundo.
Desarrollo mediante la implantación de paquetes
La selección de paquetes de mercado, su implantación, con las consideraciones y

requisitos necesarios han sido presentados y discutidos ampliamente en los Capí-
tulos 4 a 6 para los casos de ERP, SCM y CRM respectivamente. Como se discutió
allí, la implantación de paquetes no obvia la fase de recogida de necesidades, aun-
que en cierta medida viene mediatizada por la existencia de una determinada solu-
ción en partes de la empresa.
Fase 3. Implantación, puesta en marcha y utilización por los usuarios
Si bien en el desarrollo del sistema es el personal de TIC el principal responsable,

son los usuarios finales los que juegan un papel determinante en la implantación.
Esta es, quizá, la etapa más crítica pues es aquí donde se hace funcionar el sistema
«acabado» en el seno de la organización y, por tanto, donde suelen aparecer los
problemas e incompatibilidades.

Existen numerosos ejemplos de proyectos que, superada la fase de desarrollo

correctamente, han llegado a fracasar por no llevar a cabo la implantación de
forma eficaz, siendo los costes necesarios para corregir los errores suficiente-
mente elevados como para plantearse abandonar el proyecto en este punto. Esta
fase es particularmente relevante cuanto mayor es la complejidad del proyecto a
desarrollar. Al hablar de ERP en el Capítulo 4 ya se explicitó la importancia de
este aspecto para el buen fin del proyecto.
Para llevar a cabo una implantación eficaz, conviene dividir esta etapa en
varias subetapas. En primer lugar, es necesario llevar a cabo la formación de los
futuros usuarios para asegurar que saben todo lo que tienen que saber acerca del
funcionamiento del nuevo sistema. Dicha formación dependerá del nuevo siste-
ma y de los conocimientos previos o experiencia de los usuarios implicados. Si,
por ejemplo, hay un número de usuarios que no han utilizado nunca un ordena-
dor, la formación será mucho más larga e intensa que en aquellos que ya están
familiarizados con ellos.
En este punto es relevante repasar los momentos de todo el proceso en los
que la interacción con los usuarios finales y recoger de forma adecuada sus
opiniones es esencial para una implantación exitosa. Una lista, no exhausti-
va, es:
z Detección de oportunidades de mejora en los procesos de negocio a

informatizar.
z Definición de requisitos.
z Documentación y rediseño de los procesos de negocio afectados.
z Diseño de elementos externos al propio sistema, por ejemplo fuentes de
información externa que se deban incorporar.
z Validación de la ergonomía, la funcionalidad y la «usabilidad»2.
z Validación de maquetas y prototipos.
z Redacción de normativas y manuales de usuario.
z Elaboración/validación del material para la formación/información.
z Formación a formadores.
z Comunicación y venta del nuevo sistema, mediante reuniones presencia-
les y con instrumentos de apoyo para la capacitación: Formación on line
(e-learning), medios audiovisuales, etc.
z Elaboración/validación del material de divulgación.
z Validación del plan de puesta en marcha.
z Sugerencias post-implantación.
z Estudios de satisfacción.
Resulta evidente que una implantación adecuada empieza en la fase de defi-

nición del proyecto y continúa durante todas las demás. Para cada actividad y en
función del impacto en los usuarios finales, se deberán identificar los métodos
de participación más idóneos.
2
Se entiende por «usabilidad» el conjunto de reglas destinadas a garantizar la facilidad de apren-
dizaje y fácil uso de las aplicaciones y sistemas por los usuarios finales (formatos de campos, secuen-
cias de entrada de datos o de información requerida, protección contra errores,...).

La intensidad de la interacción con los usuarios dependerá de varios factores.

Los dos más importantes son los requerimientos de usabilidad y la complejidad
intrínseca del sistema. Como ilustración de la decisión de cuántos usuarios invo-
lucrar, la Figura 10.3 presenta un esquema utilizado en una entidad financiera
para decidir el número de equipos de usuarios que se van a involucrar depen-
diendo de la combinación de variables de complejidad (eje vertical) y usabilidad
(eje horizontal).
Fase 4. Operación y mantenimiento de la solución desarrollada
Una vez puesta en marcha una nueva solución es necesario garantizar tanto su
permanente adecuación a las necesidades del negocio y del mercado (manteni-
miento evolutivo) como la disponibilidad y calidad del sistema, resolviendo las
incidencias detectadas (mantenimiento correctivo) y asegurando que se siguen
cumpliendo los objetivos para los que fue diseñado.
Su importancia estriba en que los costes asociados a la operación y mante-
nimiento de los sistemas consumen una parte significativa de los presupuestos
disponibles de las áreas de TIC. El diseño de políticas rigurosas de control de
calidad de los sistemas desde el inicio permitirá gestionar la operación de los
sistemas de forma eficiente.
Participación de los usuarios

No aplica, A
Variables que determinan la

complejidad y los requerimientos de
usabilidad de un proyecto:
Ilu
str
• Cambios que introduce en la ati
Baja, B
operativa o circuitos nuevos que vo

genera Val Ergonómica 1 grupo
Complejidad
Pruebas 1 grupo
• Dificultad conceptual de los cambios
de negocio que introduce o genera
Val ergonómica 1 grupo
Media, C
Requerimientos por DB/Call Center

Pruebas 2 grupos
Validación ergonómica 2 grupos

• Frecuencia de uso de la aplicación Pruebas 2 grupos
• Momento de uso de la aplicación
• Cantidad de usuarios Requerimiento en Grupos
Alta, D
Val. ergonómica 2 grupos

• Importancia estratégica para la
Pruebas 2 grupos
empresa o repercusión en caso de
fallo
Altos, 4 Medios, 3 Bajos, 2 Muy bajos, 1
Requerimientos de usabilidad
Figura 10.3. Participación de usuarios en función

de la complejidad/usabilidad.

EL CONCEPTO DE RIESGO DE UN PROYECTO

La gestión adecuada de un proyecto TIC debe matizarse minimizando el riesgo de
fracaso, y debe ser una de las principales preocupaciones de los responsables des-
de el momento de la planificación. La gestión del riesgo empieza por identificarlo
con suficiente antelación para minimizarlo, poder detectar los problemas, e inter-
venir antes de que no se acaben convirtiendo en irresolubles. Las organizaciones
que se preocupan por la gestión del riesgo proceden a su evaluación durante la fase
de planificación, cuando los problemas todavía no han aparecido. Un análisis es-
pecífico destinado a detallar los factores de riesgo, controlarlos, y tomar las medi-
das defensivas adecuadas aumenta de forma considerable las probabilidades de
llevar el proyecto a buen término.
Si bien la gran mayoría de los estudios de viabilidad previos a la decisión de
llevar adelante un proyecto constan de multitud de documentos acerca de los
costes de implantación, beneficios financieros y cualitativos, plazos de entrega y
disposición de los usuarios, raramente contienen documentación acerca de los
posibles riesgos derivados de retrasos en las entregas, errores técnicos o el fraca-
so en general. Ignorar el riesgo en un proyecto puede convertirse en un grave
error con consecuencias, entre ellas:
z Problemas con los beneficios anticipados debido a dificultades durante la

implantación.
z Costes de implantación más elevados de lo esperado.
z Plazos de entrega más largos de lo previsto.
z Sistemas resultantes con rendimientos menores de los planificados.
z Incompatibilidad del sistema con el software y hardware previstos.
Tres son las dimensiones que influyen de forma inherente en el riesgo: (1)
tamaño del proyecto, (2) experiencia con la tecnología y (3) estructura de los
procesos a informatizar. La Figura 10.4 lo representa de forma gráfica.
Tamaño del proyecto
Cuanto mayor sea la dimensión del proyecto en cuanto a términos monetarios,

número de colaboradores, tiempo necesario y número de departamentos a los
que afecta, mayor es el riesgo. Además, desde un punto de vista organizativo, un
proyecto grande es muy probable que implique un cambio de procesos de nego-
cio y la manera de trabajar habitual de las personas. Cuantos más cambios orga-
nizativos sean necesarios, mayor es también el riesgo del proyecto.
Experiencia con la tecnología
La experiencia con la tecnología debe evaluarse en dos colectivos: el técnico y

los usuarios. Puesto que los problemas técnicos inesperados son probables, el
riesgo en los proyectos aumenta cuanto menor sea el conocimiento del hard-
ware, de los sistemas operativos, de las bases de datos y del lenguaje utilizado
por parte del equipo de proyecto. En relación a los usuarios, si éstos ya son

206 Figura 10.4: Dimensiones
Los sistemas de información del riesgo
en la empresa actual
Tecnología
Alta
Baja
Estructura
Pequeño Muy
Poco
estructurada estructurada
Grande
Tamaño
Figura 10.4. Dimensiones del riesgo.

avezados usuarios de la informática, el riego es mucho menor que si se trata de

implantar un sistema con unos usuarios que nunca se han enfrentado a una pan-
talla de ordenador.
Estructura del proyecto
No corren el mismo riesgo aquellos proyectos en los que las tareas están estructu-
radas desde el inicio y no permiten excesivos cambios que aquellos que sí permi-
ten modificaciones durante la realización.
La tabla de la Figura 10.5 presenta los tres principales conceptos de riesgo de
forma resumida.
Factores adicionales que influencian el riesgo en la implementación
Como complemento para gestionar adecuadamente el riesgo de los proyectos,

cada compañía debería desarrollar un perfil de los posibles riesgos de imple-
mentación para su programa de proyectos. Aunque no existe una lista de riesgos
de implementación universal, diferentes tipos de empresas y estrategias ofrecen

Baja estructura Elevada estructura
Riesgo medio
(muy susceptible
Proyecto Grande Riesgo bajo
a una mala dirección
del proyecto)
Baja Tecnología
Riesgo bajo
(muy susceptible
Proyecto Pequeño Riesgo muy bajo
a una mala dirección
del proyecto)
Riesgo
Proyecto Grande Riesgo medio
muy elevado
Alta Tecnología
Riesgo
Proyecto Pequeño Riesgo elevado
medio-bajo
Figura 10.5. Categorías de proyectos y grado de riesgo.

diferentes perfiles y deben complementar los tres riesgos básicos con la lista si-
guiente:
z Estabilidad del grupo de desarrollo de sistemas.

z Percepción de calidad del grupo de desarrollo por parte de especialistas y
de los usuarios.
z Criticidad de las TIC en la oferta de servicios actual de la empresa.
z Nivel de colaboración de la alta dirección en la toma de decisiones TIC.
z Experiencia del grupo de desarrollo.
z Existencia de fiascos en TIC en los últimos dos años; credibilidad del
equipo.
z Experiencia en la empresa de equipo directivo de las TIC.
z Nivel de percepción de la futura criticidad de las TIC.
z Percepción de que la compañía está atrasada en el uso de las TIC.

La gestión de proyectos TIC es una compleja tarea que requiere tanto conocimien-
tos de las tecnologías involucradas en el proyecto como, mayoritariamente, habi-
lidades de gestión. La dirección de la empresa debe asegurarse que el responsable
de un proyecto TIC conoce los sistemas genéricos de gestión de proyectos, las
herramientas disponibles, como los diagramas de Gantt y los de Pert para el con-
trol de los tiempos y los recursos utilizados, y las características diferenciales de
los proyectos TIC. La medición constante del progreso del proyecto es esencial no

sólo para el control del gasto y del tiempo, si no que hacer explícito el avance
ayuda enormemente a mantener elevada la moral de equipo y de los usuarios que
esperan el sistema.
La evaluación de la viabilidad de los proyectos debe incluir un análisis deta-
llado de los factores de riesgo, y proveer de los recursos necesarios para contro-
larlos. Todas las etapas deben ser llevadas a cabo por equipos mixtos técnicos-
usuarios, ser de poca duración, tener unos entregables concretos, y su progreso
sujeto a evaluación por personas no directamente involucradas en el proyecto.
Un seguimiento, no necesariamente minucioso pero sí constante, del progreso
de los proyectos por parte de la alta dirección es esencial para transmitir al
responsable del proyecto y a su equipo la importancia para la empresa de su
trabajo.

Gobierno del departamento de tecnologías de la información... 209
11
Gobierno del departamento
de tecnologías
de la información
y comunicaciones
A medida que los Sistemas de Información (SI) se están convirtiendo en elemen-

tos críticos para el éxito de las empresas, las decisiones relacionadas con los
mismos van adquiriendo mayor complejidad. Dicha complejidad evidencia la
necesidad de que el departamento TIC1 adopte un modelo de gestión que con-
temple de manera formal su encaje con el resto de la organización, y proporcio-
ne las herramientas necesarias para la toma de decisiones y el seguimiento y
control de las mismas.
Para que el departamento TIC pueda obtener los resultados que de él se espe-
ran y cumplir con sus objetivos, es necesaria una gran capacidad de gestión de
las personas y de extracción de valor de los recursos disponibles, sean internos o
externos, con independencia del sector de actividad en que la empresa opere.
Además, al igual que cualquier otro ámbito funcional, el departamento TIC debe
motivar a su equipo y garantizarle un desarrollo profesional. Pero es difícil
cumplir estas expectativas con la aparición de outsourcing, que ha transformado
significativamente el conjunto de competencias y capacidades que las empresas
necesitan. Por ejemplo, los proveedores de servicios son ahora responsables de
gran parte de las posibilidades de desarrollo de la carrera profesional, reducien-
do las posibilidades de promoción en la propia empresa.
Este capítulo pretende contestar a preguntas como ¿cuáles son los rasgos
diferenciales del departamento de sistemas respecto a otras áreas de la empresa?
¿Qué tipos de organización son mejores, por qué y para qué? ¿Qué modelos de
gestión es conveniente desarrollar y cuáles son sus características esenciales?
¿Cómo organizarse para gestionar la demanda interna de servicios? ¿Dónde ubi-
car el área de TIC en la organización? ¿Cuáles son los perfiles profesionales más
1
En este capítulo, al igual que en el resto de la obra, se usan de manera indistinta los términos
«departamento de Sistemas de Información» y «departamento TIC» para referirnos a la unidad
organizativa con responsabilidad sobre las tecnologías de la información y los sistemas de informa-
ción.
209

adecuados a las necesidades de la empresa? ¿Qué planes de carrera son posi-

bles? ¿Cuáles son las competencias y capacidades necesarias para el desarrollo
del área de TIC en la organización? ¿Cuál ha de ser el perfil del responsable del
departamento, el CIO2?
EL GOBIERNO DE LAS TIC Y LA APORTACIÓN DE VALOR

Las respuestas a estas preguntas se ven mediatizadas por cómo el conjunto de la
empresa ve al Departamento de Sistemas, y sus posibilidades de aportar valor a
la misma. Por ejemplo, si el departamento se considera un centro de coste, la
empresa tomará decisiones distintas a si se le considera un centro de inversión
cuyo objetivo es desarrollar capacidades competitivas. Las siguientes secciones
abordan estas cuestiones de manera más formal.
La aportación de valor, o falta del mismo, de las TIC a la empresa ha sido
motivo de controversia durante los últimos años en los foros de discusión de CIO
y de directivos en general. Un polémico artículo de la Harvard Business Review3
sostenía que las TIC son un elemento genérico, como lo puedan ser la electrici-
dad o la logística. Por tanto, toda «estrategia» de TIC ha de consistir en fijar
unos requerimientos funcionales con sus niveles de servicio, y conseguirlos al
menor precio posible. Tal como se ha podido ver a lo largo de los capítulos
anteriores, esta obra no comparte en absoluto este punto de vista. El argumento
de las «TIC genéricas» es únicamente válido para aquellas actividades TIC –que
las hay– que aún siendo importantes, no pueden proporcionar ningún tipo de
diferenciación a la empresa. Como se ha venido describiendo hasta aquí, las TIC
pueden y deben ser un factor competitivo diferencial, para el que ha de ser posi-
ble determinar su aportación de valor.
En toda empresa, conforme la tecnología se va incorporando a los procesos de
negocio y se internalizan sus posibilidades, los diferentes aspectos de las TIC
siguen un ciclo de vida como el esquematizado en la Figura 11.1. Pasan de ser
primordialmente una innovación, a proporcionar servicio, convertirse en una fuente
de costes y finalmente pasar a ser generadora de ingresos. Estas etapas no son ni
disjuntas ni absolutas en su definición, pero muestran que la empresa ve, gestio-
na, y extrae valor de las tecnologías de diferente manera a lo largo de su ciclo de
vida. Las medidas de la aportación de valor de una particular tecnología a la
empresa varían pues en función del estadio evolutivo en que se encuentra.
Los siguientes párrafos detallan las diferentes medidas de aportación de va-
lor que pueden usarse en cada fase evolutiva.
Innovación
A medida que el área de TIC conoce, analiza y eventualmente adopta las tecno-
logías de la información y la comunicación para generar ventajas competitivas,
2
Siguiendo la nomenclatura inglesa normalmente aceptada, al responsable del departamento
TIC se le denomina también CIO (Chief Information Officer).
3
Carr, N., «IT doesn’t matter», Harvard Business Review, 2003

INGRESOS
INGRESOS
Ingresos INNOVACION
INNOVACION
Innovación
Aportación
de valor
COSTES
COSTES
Costes SERVICIO
SERVICIO
Servicio
Figura 11.1. Modelo de aportación de valor de las TIC.
los indicadores relacionados pueden ser la tasa de renovación de sistemas, nue-

vas prestaciones incorporadas, nuevos productos y servicios que la empresa pue-
de prestar gracias a las TIC, o el número de aplicaciones basadas en tecnologías
que no estaban en la empresa el año anterior.
Servicio
Una vez aplicada la tecnología al negocio, su contribución está ligada a la cali-

dad del servicio que ofrecen a la organización. Algunos indicadores en este ám-
bito podrían ser los niveles de disponibilidad medios, interrupciones máximas,
calidad percibida, tasa de incidencias, etc.
Coste
A medida que el grado de madurez de una tecnología aumenta, el departamento

TIC deberá ser capaz de ofrecer servicios con un mayor grado de eficiencia en
costes. Los indicadores asociados serán el coste por transacción, el coste de un
puesto de trabajo, etc.
Generación de ingresos
En casos de poca capacidad de diferenciación de las TIC, debido en general a su

madurez relativa, el área de tecnología puede generar ingresos diferenciales para

la empresa. Posibles indicadores serán los ingresos de nuevos productos que se

venden a empresas del grupo o a terceros (servicios hosting, ASP, comercio elec-
trónico, etc.), venta o comercialización de soluciones desarrolladas para un pro-
blema específico, etc.
Estas cuatro fases se pueden ver de manera nítida en la adopción de Internet

en muchas empresas. En sus momentos iniciales, los departamentos TIC hicie-
ron esfuerzos importantes (herramientas, formación, plataformas específicas, de-
dicación de recursos internos,..) para explorar las posibilidades de la tecnología
para sus organizaciones, idearon algunos servicios básicos, desarrollaron pilo-
tos, etc. (contribución en innovación). Aceptada la tecnología como «útil» para
la organización se aplica de forma estructurada en el desarrollo de nuevos pro-
ductos y servicios al cliente. En esta fase (contribución en servicio) la prioridad
de TIC es la satisfacción de los usuarios con los nuevos sistemas (asegurar la
accesibilidad, velocidad de respuesta, estabilidad de la plataforma, incorpora-
ción gradual de nuevos usuarios,...). Una vez generalizado su uso y dejando de
ser estrictamente diferencial, el objetivo del área pasa a ser garantizar los niveles
de servicio pactados con los menores costes de operación (competencia en cos-
tes). Finalmente, disponer de plataformas o soluciones sectoriales o funcionales
y su know how específico puede facilitar su comercialización a empresas del
grupo o ajenas, es decir, se convierte en un posible generador de ingresos.
Algunas empresas, como por ejemplo Bankinter, consiguen extraer valor de
sus inversiones en TIC en las cuatro dimensiones simultáneamente: (1) ofrecen
productos innovadores y diferenciales basados en tecnología, (2) mejoran conti-
nuamente el nivel de servicio y satisfacción de los clientes, (3) aplican las TIC a
la mejora de los procesos internos, rebajando los costes a su mínima expresión, y
(4) venden sus plataformas a otras compañías con menor capacidad de desarrollo.
En definitiva, conciben su área de TIC como una completa unidad de negocio.
Dirigir las TIC adecuadamente, lo que se conoce como el Gobierno de las
TIC, es responsabilidad ineludible del comité de dirección, es decir, de los respon-
sables ejecutivos de la empresa. Un gobierno adecuado de las TIC asegura que:
z Los sistemas de información están alineados con la estrategia de nego-

cio. Es decir entregan las funcionalidades y servicios alineados con las
necesidades de la organización, facilitando que ésta pueda conseguir sus
objetivos de negocio.
z Las TIC y las nuevas tecnologías capacitan a la organización para llevar a
cabo actividades que antes no le eran posibles.
z La funcionalidad y servicios de TIC se entregan a la organización con el
máximo valor económico y de la manera más eficiente. Es decir, los re-
cursos se utilizan de forma responsable.
z Se conocen y gestionan los riesgos relacionados con las TIC. Los recur-
sos de TIC son fiables y seguros.
El resto de este capítulo está organizado de la siguiente manera. En primer

lugar se discute la relación del departamento de sistemas respecto a los demás
departamentos de la empresa: ¿debe estar al máximo nivel en el organigrama o
puede depender de otra unidad organizativa? La sección siguiente describe posi-
bles instrumentos de gestión, como el cuadro de mando y los planes de carrera

del personal. Después se aborda cómo gestionar las relaciones del departamento
de sistemas con el resto de la empresa, incluyendo el concepto de clientes inter-
nos y las relaciones con los mismos. El capítulo concluye con unas reflexiones
sobre el perfil del responsable del departamento.
LOS ÓRGANOS DE GOBIERNO DE LAS TIC

En función del área de actividad de la empresa y de la importancia de la tecno-
logía en la generación de ventajas competitivas, el nivel de definición y desarro-
llo de los instrumentos de dirección será, sin duda, variado. Es evidente que
éstos no serán iguales para una entidad financiera con implantación internacio-
nal o un operador global de telefonía (fuertemente intensivos en tecnologías de
la información) que para una empresa dedicada a la explotación de aparcamien-
tos. La siguiente lista presenta los órganos de gobierno más habituales y sus
roles. Toda empresa, independientemente de su tamaño, debiera pensar en desa-
rrollarlos.
Comité ejecutivo (o de dirección) de la empresa
Como máximo órgano de decisión de la empresa, el comité ejecutivo debe ser la

máxima autoridad en temas de TIC. La presencia del responsable de TIC ofrece
una visión sobre la contribución de la tecnología al desarrollo de los objetivos
estratégicos de la firma. Además, permite recabar el apoyo de la alta dirección
en las decisiones de mayor trascendencia económica o tecnológica. Aún cuando
el responsable de TIC no forme parte del comité ejecutivo, debería unirse a él en
las sesiones en las que se debate y toman decisiones en relación a la tecnología
de la información.
Las responsabilidades del comité ejecutivo en relación a las TIC se pueden
resumir en el cuadro de la Figura 11.2.
Comité de TIC
Foro de evaluación de las decisiones de desarrollo tecnológico en sentido estric-

to (decisiones sobre arquitectura de sistemas, plataformas y sistemas operativos,
etcétera). Se compone de profesionales del área TIC y de los directores funcio-
nales más implicados en estas tecnologías. Éstos pueden ir variando en el tiem-
po en función de los diferentes proyectos y énfasis estratégicos de la empresa.
Comité de innovación
Orientado de forma exclusiva a promover la innovación tecnológica. Deberá ase-

gurar la existencia de un proceso formal de innovación, desde la generación de la
idea hasta su transformación en una propuesta de negocio y de los mecanismos
que permitan involucrar las áreas de negocio hasta su implantación. Evaluará las
propuestas de innovación y asignará los recursos internos para su desarrollo y

Responsabilidades Definición
Políticas de alto nivel acerca de cómo se utilizan las TIC

Principios estratégicos
en el negocio
Estrategias básicas de dimensionado de TIC, tanto

Estrategia de infraestructuras técnico como humano, dimensionado de servicios
compartidos,..
Políticas y reglas de gobierno en el uso de las TIC, que

Arquitectura marcan el camino en el que los negocios se realizarán
(a nivel de datos, tecnologías, aplicaciones)
Conjunto de aplicaciones que deberán ser adquiridas

Necesidades de aplicaciones de negocio
o desarrolladas internamente
Decisiones sobre cuánto y cómo invertir en TIC

Priorización inversiones (incluyendo modelos de justificación y aprobación
de proyectos)
Figura 11.2. Responsabilidades TIC del comité de dirección.

(Fuente: Adaptado del MIT Sloan Center for Information Systems Research,
2002.)
realizará un seguimiento del proceso para asegurar el cumplimiento de los objeti-

vos definidos. En empresas medianas y pequeñas, este rol puede ser asumido por
el comité TIC, pero debe hacerse de manera formal si la empresa desea de veras
que el departamento TIC sea una fuente de innovación.
ESTRUCTURA ORGANIZATIVA DEL DEPARTAMENTO TIC

La estructura organizativa del departamento TIC se definirá en función de su
misión y tamaño. En general se deben separar las responsabilidades de nuevos
sistemas de las de explotación, dando preponderancia en la organización a
aquellas actividades con más importancia estratégica. Por ejemplo, si la cali-
dad de la atención al usuario está siendo cuestionada, puede hacerse de esta
capacidad una prioridad del departamento, y crear una unidad específica de
Help Desk con sus propios sistemas de control e incentivos que dependa direc-
tamente del CIO.
La estructura debe definir de forma formal y explícita los ámbitos de responsa-
bilidad de cada unidad, así como sus objetivos a corto y medio plazo. Debe incluir
también los elementos de control y los incentivos alineados con dichos objetivos.
La definición de los ámbitos de responsabilidad y su agrupación en la estruc-
tura deberá considerar también el conjunto de actividades externalizadas y las
propias del ámbito de las TIC. Las actividades que se hayan subcontratado debe-
rán controlarse con los instrumentos detallados en el Capítulo 7, pero hay que

asignar un responsable en la organización para hacer su seguimiento y asumir la

responsabilidad de su desempeño.
La Figura 11.3 presenta una organización típica para una empresa mediana o
grande que distingue entre diseño de la arquitectura de la instalación, proyectos
especiales y sistemas de información propiamente dichos. Además, como fun-
ción de apoyo a la dirección del departamento y fuera de la línea se sitúan las
funciones de planificación y control.
Como ilustración, el Cuadro 11.1 ilustra la organización del departamento
TIC de Caja Madrid. Indica la misión y los ámbitos de responsabilidad de cada
una de las unidades funcionales en que está organizado.
En empresas pequeñas, en las que debido a que no se requiere un responsable
a tiempo completo en el comité de dirección las TIC no están al máximo nivel
organizativo, el departamento TIC (denominado a menudo «área informática»)
suele depender de la dirección administrativo financiera. La Figura 11.4 presen-
ta esta situación.
INSTRUMENTOS DE GESTIÓN DEL DEPARTAMENTO DE TIC

De los posibles instrumentos a disposición del responsable de TIC para gestionar
su unidad, cabe destacar los modelos de asignación de costes, los acuerdos de
Director TIC
Planificación y
control
Arquitectura Proyectos
Sistemas I. especiales
Desarrollo aplicaciones Explotación Soporte sistemas
Figura 11.3. Organización del departamento TIC en una empresa grande.


Dirección TIC
Dirección general
Dirección Finanzas Dirección Producción Dirección Comercial Otras direcciones
Área Informática
Diseño y
Explotación
desarrollo
Figura 11.4. Estructura organizativa con las TIC dependiendo de la dirección

financiera y una estructura interna propia de una empresa mediana/pequeña.
nivel de servicio y su seguimiento, las herramientas de seguimiento de proyectos,

los informes (modelos de reporting) y los sistemas de participación e informa-
ción.
Modelos de asignación de costes
La posibilidad de asignar los costes del departamento de sistemas a las áreas fun-
cionales que reciben los servicios, permite generar una dinámica de relación con
las mismas basada en la percepción del valor aportado y el coste incurrido. Estos
aspectos han sido tratados con amplitud en el Capítulo 9. Como filosofía de ges-
tión, conviene conocer la repercusión de las decisiones y de los requerimientos de
servicio que la unidad de TIC presta a las unidades de negocio. Es siempre buena
práctica que las unidades funcionales sean conscientes de los costes que sus deci-
siones implican.
Acuerdos de nivel de servicio (SLA)
Los acuerdos de nivel de servicio no son únicamente un instrumento imprescindi-

ble para la gestión de los proveedores externos, sino que su definición y la fijación

Estructura organizativa de la unidad de organización y sistemas de Caja

Madrid
En 2004, Caja Madrid fue una de las primeras entidades financieras de

España en solvencia, eficiencia, calidad de riesgo, capacidad de creci-
miento, productividad y rentabilidad.
La unidad de organización y sistemas de Caja Madrid está orientada a
dar servicio a los más de seis millones de clientes de la entidad, a través
de unos 1.900 centros de trabajo (entre oficinas y servicios centrales),
sus 3.869 puntos de autoservicio y sus canales complementarios –pri-
mordialmente banca telefónica e Internet–, dando soporte y cobertura a
más de 12.000 empleados.
Su estructura organizativa está enfocada a garantizar la cobertura de
las demandas y niveles de servicio de los clientes externos e internos
(usuarios, unidades de negocio, soporte o alta dirección).
La Figura 11.5 presenta la estructura organizativa de la unidad de orga-
nización y sistemas de Caja Madrid (Febrero 2003) según su memoria anual.
Con objeto de ilustrar el reparto de responsabilidades entre las distin-
tas unidades de su organización, a continuación se describen las misio-
nes definidas para cada una de ellas, así como los ámbitos de responsa-
bilidad de las áreas más relevantes.
z Planificación e innovación tecnológica: liderar el desarrollo de los pla-

nes tecnológicos del grupo y realizar su seguimiento presupuestario y
el seguimiento de los niveles de servicio y de acciones correctoras.
Organización y
sistemas
Área planificación e
Innovación Tec.
Gerencia de
sistemas
Área de
Área de Área de Área de Área de Área de Área de Área de
relación
desarrollo arquitectura información producción operaciones organización canales
unidades
Figura 11.5. Organización TIC de Caja Madrid, 2002.

(Fuente: Elaboración propia a partir de la memoria de Caja Madrid.)
Cuadro 11.1. Estructura organizativa del departamento TI de Caja Madrid.

z Gerencia de sistemas: gestionar el desarrollo coordinado de la arqui-

tectura, de los procesos operativos y de los sistemas de información
del grupo, así como la integración en éstos de los sistemas.
z Desarrollo: diseñar, desarrollar y mantener las aplicaciones de sopor-
te a los procesos operativos del negocio.
z Arquitectura: diseñar, desplegar y mantener la metodología y herra-
mientas de desarrollo, así como la arquitectura de aplicaciones y da-
tos del grupo.
z Gestión de información: diseñar, desarrollar y mantener los sistemas
de información de gestión necesarios para el grupo.
z Producción: definir, desarrollar y gestionar el soporte técnico y funcio-
namiento de los sistemas del grupo. Forman parte de su ámbito de
responsabilidad los departamentos de sistemas operativos, adminis-
tración y bases de datos, comunicaciones y redes, explotación, impre-
sión y distribución e instalaciones y atención a usuarios.
z Operaciones: suministrar soporte operativo centralizado al grupo, en
todos aquellos procesos administrativos en que existen economías
de escala, incurriendo en el menor coste posible.
z Organización: definir y adaptar la organización y estructura de todas
las unidades del grupo, liderando su organización.
z Servicio de Canales: gestionar el servicio telefónico del grupo y colabo-
rar con las unidades de negocio del grupo en el desarrollo e impulso
del autoservicio y de nuevos dispositivos técnicos.
z Relación con unidades: coordinar con las unidades usuarias la identifi-
cación y definición de las especificaciones de sus necesidades de
sistemas, y supervisar el grado de ejecución, avance y calidad de los
proyectos en marcha.
Dadas las dimensiones de la entidad y del papel relevante que las TIC
juegan en el desarrollo de la estrategia de negocio de Caja Madrid y de
generación de ventajas competitivas, es especialmente relevante desta-
car el cometido y alcance del área de relación con unidades. Sus funcio-
nes están dirigidas a apoyar a las áreas de negocio en la detección de
necesidades orientadas a potenciar el desarrollo del negocio y la mejora
de la eficiencia interna; la definición de los requisitos y especificaciones
asociados a las mismas; gestionar su cartera de peticiones y apoyar su
priorización de acuerdo con la disponibilidad de recursos; supervisar y
asegurar la calidad de la implantación de las nuevas soluciones; y realizar
labores de consultoría tecnológica para las unidades. Por otra parte, debe
asumir la responsabilidad de integración tecnológica y operativa de terce-
ros en los sistemas del grupo.

de valores objetivo deben formar parte, a su vez, del modelo de relación con los
clientes internos. En el Capítulo 7 se discutió en detalle el concepto de acuerdos
de nivel de servicio en el contexto de la subcontratación de proveedores de servi-
cio. Un departamento de sistemas interno debiera demostrar el mismo, o incluso
mayor, nivel de compromiso con la calidad del servicio prestado que un provee-
dor externo.
Herramientas de gestión y seguimiento de proyectos
Destinadas a conseguir que los proyectos de desarrollo se lleven a cabo en plazo y

coste presupuestados manteniendo las funcionalidades acordadas con los usua-
rios. Se discutieron de forma somera en el Capítulo 10.
Instrumentos de participación e información
El desarrollo de las intranets ha facilitado la puesta en marcha de múltiples

entornos orientados tanto a compartir información, como al desarrollo del traba-
jo colaborativo (por ejemplo, solución de problemas en el entorno de la propia
empresa). Es importante que el departamento TIC disponga de un entorno foro
en su intranet en el que los usuarios o grupos definidos de usuarios relacionados
tengan la posibilidad de plantear dudas o problemas de índole técnica en busca
de una solución «interna», que evite la necesidad de solicitar apoyo externo.
Estas soluciones no sólo favorecen la cohesión interna del departamento TIC,
sino que además generan beneficios tanto en términos de agilidad de respuesta
como de ahorros de costes y del reconocimiento explícito de existencia de cono-
cimiento interno. El desarrollo de una plataforma específica para compartir esta
información evita además los correos electrónicos a todos los miembros del de-
partamento solicitando ayuda para cuestiones específicas.
Cuadros de mando
Desarrollados de forma específica más adelante en el presente capítulo, son la

herramienta fundamental para que el responsable del departamento –y por ex-
tensión sus subordinados directos y los responsables de la empresa–, conozcan
de forma resumida y adecuada para la toma de decisiones, el desempeño del
departamento en un período determinado.
Las relaciones con los clientes internos
Una de las dimensiones más importantes del modelo de gestión es la propuesta

de servicio ofrecida al resto de la empresa, y deberá incluir todos los aspectos
relacionados con políticas y procesos de relación con clientes internos. Su obje-
to es mejorar el conocimiento del área de TIC por el resto de la organización,
establecer los mecanismos más eficaces de comunicación, hacer partícipes a los
usuarios del desarrollo y evolución de las TIC, sensibilizarlos respecto de las

inversiones y costes del uso de las tecnologías y conseguir que el departamento

TIC se perciba como un área al servicio del negocio que proporciona valor aña-
dido de forma diferencial.
La formalización del modelo de relación con los clientes internos facilitará
la fijación de objetivos generales de mejora, de planes de acción generales y la
identificación de prioridades de desarrollo de planes específicos para clientes o
grupos de clientes, a partir de los cuales será posible identificar los requisitos
internos para su logro, en términos de refuerzos metodológicos, necesidades de
formación (capacidades de negociación/conducción de equipos, modelos de asig-
nación de costes, etc.) y de necesidades de información.
Un aspecto especialmente relevante, cualquiera que sea el modelo de rela-
ción con los clientes internos, es acordar las métricas de seguimiento y control
de la actividad del área de TIC por la dirección, orientadas básicamente a eva-
luar la aportación de valor añadido por el área a la compañía.
El esquema de la Figura 11.6 puede contribuir a desarrollar un modelo de
relación con clientes internos, que podrá aplicarse en toda su extensión en fun-
ción de la importancia del área de TIC en la organización.
Las seis fases propuestas son las siguientes:
1. Identificar y enumerar las posibles áreas de mejora en materia de gestión

de la relación o de los proyectos relacionados con el cliente.
2. Elaborar el mapa de los clientes internos: unidades o departamentos de
negocio, áreas de servicios centrales y áreas técnicas próximas al cliente
o usuario final.
3. Valorar la relación en base a parámetros objetivos y comparables (presu-
puestos asignados, cartera de proyectos pendientes actual, historial de la
relación, criticidad del servicio prestado,...).
4. Medir la percepción del cliente respecto de los servicios recibidos, a tra-
vés de entrevistas seleccionadas o encuestas de evaluación y seguimiento
de la misma, que podrán integrarse en procesos centralizados de segui-
miento de la calidad desarrollados a nivel de la compañía.
5. Definir los mecanismos de comunicación y participación de los usuarios y
clientes en los procesos relacionados con las TIC (tipología –planifica-
ción, definición de necesidades de negocio, innovación, etc.–, frecuencia,
contenidos, participantes, información para el seguimiento y control).
I II III IV V VI
Identificación Levantar Medir

áreas Valorar la Plan de
mapa de percepción Comunicar
mejora relación acción
relaciones del cliente
Figura 11.6. Desarrollo de un modelo de relación con los clientes.


6. Establecer planes de acción a nivel de clientes específicos (acciones, res-

ponsables, hitos, parámetros de satisfacción...), de mejora del ciclo de
gestión de los clientes (categorización de clientes, interacciones desea-
das, información de gestión,...), y de desarrollo de refuerzos metodo-
lógicos, tanto a nivel de gestión de proyectos como de clientes.
Aunque el desarrollo de un modelo de relación como el descrito más arriba

pueda parecer complejo e innecesario, disponer de él representa una vocación
inequívoca al servicio al resto de la compañía, e instala en el departamento de
sistemas la cultura de unidad de servicio que en muchas ocasiones se echa en
falta.
EL CUADRO DE MANDO INTEGRAL

En conjunción con lo sistemas de cálculo de costes del Capítulo 9, uno de los
instrumentos de gestión más importantes de los que dispone el responsable de
TIC es el cuadro de mando. En su definición tradicional, el Cuadro de Mando
Integral (CMI) es un sistema de indicadores, derivados de la estrategia de la
compañía, organizados en base a cuatro perspectivas: (1) financiera, (2) clientes,
(3) procesos internos y (4) aprendizaje y crecimiento. Bien diseñado, el CMI de
una empresa debe:
z Alinear todos los recursos de la organización a todos los niveles en el

logro de los objetivos desarrollados en planes estratégicos.
z Identificar los procesos clave que han de realizarse de manera excelente
para que la estrategia de la organización tenga éxito.
z Superar el enfoque tradicional financiero a corto plazo, proporcionando
medidas del desempeño del pasado, presente, y sobre todo apuntando las
tendencias para el futuro.
z Enfocar las acciones de la organización hacia aquellas que tienen un mayor
impacto en la ejecución de la estrategia y en la creación de valor convir-
tiéndose además en un excelente canal de comunicación de la estrategia a
todos los niveles de la organización y una herramienta de análisis de des-
viaciones en el logro de los objetivos fijados.
El diseño de un CMI implica definir indicadores de resultados en las cuatro

dimensiones de forma jerarquizada según niveles organizativos, de acuerdo con
el mapa estratégico y de las relaciones causa-efecto particulares de cada empre-
sa. Desde el punto de vista del departamento TIC, el desempeño enfocado a la
realización de los objetivos de negocio acostumbra a ser medido en consonancia
con las acciones que éste puede desarrollar. Por ejemplo, si una entidad finan-
ciera tiene como objetivo la calidad de servicio, se debería reflejar en el cuadro
de mando el tiempo de respuesta medio y máximo de los sistemas de atención al
público y la disponibilidad de los mismos. Si la empresa realiza encuestas de
satisfacción de los clientes en relación a los sistemas, este índice debería formar
parte también del conjunto de medidas a reportar. La Figura 11.7 presenta a
modo de ejemplo la estructura completa de un cuadro de mando integral de una
empresa de distribución farmacéutica según las cuatro dimensiones menciona-

¾Crecimiento de la cifra de negocio

¾Rentabilidades por zona, producto, canal
¾Rentabilidad financiera, económica, …
¾Costes unitarios
¾Ventas por empleado
¾Flujos de caja generados
¾ROI, PMR de las inversiones en I+D
¾Incremento en la cuota de mercado ¾Productividad de los procesos

Financiera
• Por área terapéutica ¾Eficacia de los procesos de venta
• Por área geográfica
• Por país ¾Eficacia de los procesos de acción
• Por visitador Visión y Proceso comercial
Cliente
• …. estrategia interno
¾Eficacia de procesos de fabricación
¾Imagen
¾Posicionamiento frente ¾Eficacia de los procesos logísticos
a la competencia Aprendizaje y ¾Eficacia en el lanzamiento de un
¾Ventas por canal crecimiento nuevo producto
¾Esfuerzo y resultado obtenidos

de la investigación
¾Caducidad de licencias/ patentes
¾Desarrollo de nuevos productos
• Desarrollo por la compañía
• Co-desarrollos
• Alianzas/acuerdos (licencias-promoción)
¾Formación /promoción interna /rotación
¾Satisfacción de los empleados
Figura 11.7. Esquema de un cuadro de mando integral de una empresa de

distribución farmacéutica.
das. De su estructura y de la información necesaria para confeccionarla dependerá

la estructura del cuadro de mando del departamento TIC.
En muchas ocasiones es conveniente representar en forma gráfica las rela-
ciones de precedencia e influencia entre los diferentes objetivos de la empresa
que va a acabar definiendo medidas concretas en el cuadro de mando, ello per-
mite que todos los estamentos desde el comité de dirección de la empresa, hasta
los técnicos, pasando por el CIO, sean conscientes del efecto que desviaciones
en los objetivos concretos del CMI tiene en desempeño de la empresa en su
conjunto. La Figura 11.8 presenta el diagrama de precedencias para los objeti-
vos de la compañía de distribución cuya estructura de cuadro de mando se pre-
sentó en la Figura 11.7.
Los parámetros concretos que deben incluirse en el CMI dependerán de cada
empresa. La siguiente es una lista indicativa de uso común cuando se particula-
riza al ámbito de las TIC.
Financiera
Son los indicadores primarios del modelo y reflejan el impacto económico deri-
vado de las siguientes perspectivas a través de las relaciones causa-efecto defini-
das entre los distintos parámetros del modelo. Algunos indicadores relevantes en
este ámbito podrían ser: costes de TIC sobre ventas, seguimiento presupuestario,

Creación de valor
Eje
mp
lo I
lus
cer Op t rat
Cre ti m ivo
iza
r
Incremento Disminución Más ventas Incremento Reducción Dimensión financiera
ventas PMR por persona margen coste distribución
Estrategia productividad
Estrategia crecimiento
Más
Incremento Dimensión cliente
reconocimiento
cuota mercado
del producto
Tiempo de
puesta en Eficiencia en Eficiencia en Dimensión procesos
mercado proceso venta proceso logístico
Incremento
patentes Incremento
Investigación Motivación Mecanización
en I+D co-promoción visitadores de tareas Aprendizaje y crecimiento
Figura 11.8. Esquema de precedencias de objetivos de una empresa

de distribución farmacéutica.
ROI de los proyectos ejecutados e implantados, índices comunes en el sector (por

ejemplo el índice de eficiencia en el sector bancario), etc. Si se dispone de infor-
mación sectorial, es importante además presentar la información de la empresa
clasificada en los mismos conceptos a fin de poder establecer comparativas con el
grupo de referencia. La Figura 11.9 presenta un ejemplo ilustrativo de este tipo de
comparaciones.
Apertura de gasto de TIC y comparación con Benchmarks
IL
2,4 U ST
Gastos generales/Otros
2,3
RA
TI
Personal interno de TIC
32,1 VO
23,3
12,2
Redes y telecomunicaciones
23,3
14,8
Proveedores de servicios externos
11,6
19,1
Software
4,7
19,4
Hardware
34,9
0 10 20 30 40
Porcentaje
Compañía Benchmark Internacional
Figura 11.9. Ejemplo de comparación de gastos TIC con el sector.

Clientes
Debe medir el grado de satisfacción de los usuarios internos y clientes externos

con las TIC. El desarrollo de los canales «no presenciales» como Internet y la
telefonía ha hecho que una parte creciente de la relación del cliente con la com-
pañía se realice a través de la tecnología, dando a esta dimensión del cuadro de
mando una gran importancia. Las medidas relativas al tiempo de espera de las
llamadas entrantes, tanto de clientes externos como internos, tiempo medio de
resolución de problemas, y encuestas de calidad de servicio son los elementos
tradicionales en esta dimensión. También aquí es aconsejable disponer de una
comparativa con el grupo de referencia (benchmark) que permita saber la posi-
ción relativa de la empresa a sus competidores. En muchos sectores existen or-
ganizaciones que realizan estas comparativas de forma sistemática. La Figura
11.10 presenta un ejemplo que compara cómo los clientes ven la banca por In-
ternet de una entidad española con el resto del sector.
Organización interna
Las unidades de medida deben enfocarse hacia la evaluación sobre cómo la or-
ganización TIC (estructura, perfiles profesionales, capacidades, etc.) es capaz
de afrontar con éxito los retos de futuro, tanto los puramente tecnológicos como
los de negocio. Las capacidades clave a analizar estarán relacionadas con la
capacidad de gestionar las relaciones con clientes y la de proveer servicios (de-
sarrollo de soluciones, gestión de la tecnología, soporte a usuarios, etc.). Ejem-
plos de los parámetros a seguir son: capacidad de gestión de clientes y grado de
satisfacción, capacidad de seguimiento de los parámetros de nivel de servicio
pactados, entendimiento de las necesidades de los negocios y establecimiento de
100
84,73 85,68
80
71,64
65,39 67,39
59,33
Porcentaje
60
40
20
0
Calificación general Navegación y diseño At. Cliente
Compañía Mejor
Figura 11.10. Ejemplo de comparación del servicio de Internet.

las prioridades de los proyectos, identificación de oportunidades de mejora, ges-

tión de proyectos (costes, plazos, calidad...), y gestión de proveedores externos.
Procesos internos
Perspectiva orientada a medir el nivel de rendimiento del área de TIC, identifi-

cando posibles áreas de mejora y aplicando planes específicos de actuación.
Indicadores típicos asociados al ámbito de procesos serían: número de llamadas
al help desk resueltas en primer contacto, número de incidencias de los sistemas
en período crítico, tiempo y calidad de recuperación ante «desastres», costes de
mantenimiento de aplicaciones sobre nuevos desarrollos, tiempo medio de solu-
ción de incidencias, número de procesos batch sobre total de procesos, plazo de
puesta en marcha de nuevas soluciones, etc.
La presentación de la información en el cuadro de mando debe estar jerarqui-

zada y ser lo suficientemente clara para que sea posible ver en la primera hoja un
resumen de los puntos más importantes, que se amplían en detalle en hojas si-
guientes. Un sistema de semáforos puede ser útil para llamar la atención hacia
los parámetros que presenten problemas. Supongamos por ejemplo que una me-
dida de la calidad del servicio es el tiempo de respuesta del sistema a las transac-
ciones online. La primera página puede mostrar que el tiempo de respuesta du-
rante el período de referencia, por ejemplo un mes, ha sido de 0,5 segundos, pero
estar en rojo porque al revisar el detalle en la página correspondiente demuestra
que durante un día el tiempo máximo llegó a los cinco segundos.
LA GESTIÓN DE LAS PERSONAS: PLAN DE CARRERA,

DESARROLLO DE CAPACIDADES Y RETRIBUCIÓN
Una dimensión fundamental de la gestión del responsable de las TIC en la em-
presa es el desarrollo de las capacidades de las personas en el departamento. El
buen gobierno de las TIC obliga al análisis tanto de las capacidades a desarrollar
en el futuro como el de las capacidades no utilizadas y que pueden generar
descontento entre los empleados.
El proceso formal de elaboración del plan de carreras, entendido como la
sucesión de niveles profesionales y puestos de trabajo a desempeñar por un cola-
borador a lo largo de su vida laboral, es un instrumento eficaz de diagnóstico y
dimensionado de las necesidades de recursos internos.
El plan de carrera deberá orientarse al logro de los siguientes objetivos:
z Identificar las necesidades actuales y futuras de colaboradores y de sus

niveles de capacitación profesional.
z Mantener actualizados sus conocimientos técnicos, sus habilidades y ap-
titudes.
z Proporcionar incentivos para aumentar su efectividad y rendimiento en el
puesto de trabajo.
z Ayudar a los profesionales a descubrir nuevas oportunidades y retos pro-
fesionales.

z Mantener vivo su entusiasmo, limitando los efectos asociados a niveles de

rotación no deseados.
z Aumentar la satisfacción de los profesionales con su puesto de trabajo y
mejorar su calidad de vida laboral.
El plan de carrera profesional de cada empleado debe contemplar además de

la evolución prevista de la persona dentro (y fuera) del departamento, el plan de
compensación, ligado a la evaluación del desempeño, y el plan de formación.
El plan de formación deberá cubrir tanto los contenidos puramente técnicos
(sistemas operativos, BBDD, nuevos sistemas y tecnologías, etc.) como los diri-
gidos al aumento de conocimientos y habilidades de gestión (tales como herra-
mientas de planificación, control de calidad, gestión de recursos humanos, ges-
tión económica, etc.) que limiten los déficit internos identificados y faciliten
una mayor optimización en la utilización de los colaboradores.
Al igual que en las demás actividades del departamento TIC, para una ade-
cuada planificación de recursos se requiere disponer de la estrategia de futuro de
la compañía, con información específica sobre qué productos y servicios y a qué
clientes se va a dirigir y, por tanto, a través de sus implicaciones en las TIC, qué
tipos de trabajo y capacidades profesionales serán necesarias e identificar y di-
vulgar las oportunidades de promoción interna.
El punto de partida de la gestión de las personas es el análisis de los puestos
de trabajo, que permitirá definir los conocimientos, habilidades y actitudes re-
queridos para desempeñar las responsabilidades con eficiencia y eficacia, y ade-
más dibujar la trayectoria profesional del personal. Es importante además tener
en cuenta que en muchas organizaciones, las capacidades y los conocimientos
desarrollados por empleados del departamento TIC, en particular aquellos rela-
cionados con el diseño de sistemas de información, pueden ser de gran utilidad
o unidades funcionales de la empresa, y por tanto es esencial pensar en la posi-
bilidad de promoción horizontal fuera de la unidad de TIC.
Los modelos de retribución deben poder incorporar de forma gradual es-
quemas de trabajo flexibles, trabajo en casa, incentivos por participación en
foros, etc. Además, deben contemplar un porcentaje de compensación varia-
ble. Como ejemplo de posibles dimensiones del desempeño se pueden citar las
siguientes:
z Productividad (plazos y costes de implantación de nuevas soluciones).

z Calidad del servicio (rendimiento y tiempo de respuesta de los sistemas,
disponibilidad, adecuación a las necesidades de los usuarios, nivel de
usabilidad, etc.).
z Nivel de satisfacción de los clientes internos y externos (accesibilidad, ni-
veles de integración de los sistemas, adaptación a los procesos de nego-
cio,...).
z Responsabilidades asociadas a actividades o tareas críticas de TIC.
La compensación va directamente ligada a un sistema de evaluación del ren-

dimiento que, basado en parámetros objetivos y medibles, asegure la capacidad
de generar un feedback adecuado tanto hacia la firma como hacia los profesiona-
les, identificando los pasos a seguir para un adecuado nivel de desarrollo profe-
sional.

Por otro lado, tal como se discute y analiza en detalle en el Capítulo 7 sobre
outsourcing y BPO, algunas grandes empresas están empezando a aprovechar
las oportunidades que los mercados laborales con mano de obra cualificada que
terceros países ofrecen, acrecentando las inquietudes de los profesionales de
TIC locales. La realidad hasta la fecha es que, si bien el offshore sourcing (ex-
ternalización a países con mano de obra más económica) es una oportunidad de
la que se habla a menudo, y está tomando cuerpo en cuanto a la subcontratación
por grandes empresas del desarrollo de sistemas completos, pocas organizacio-
nes tienen un número significativo de empleados de TIC situados en terceros
países.
Finalmente, las capacidades de las personas externas se deben evaluar con un
rigor equivalente al del personal interno, ya que su impacto en la calidad de los
servicios prestados por la unidad de TIC es equivalente. En caso de error, nadie
se va preguntar si la responsabilidad es de personal propio o externo. Aunque la
relación con un externo se pueda reducir a una serie de SLA (véase Capítulo 7),
en muchas ocasiones la empresa tiene interés en que la empresa proveedora
tenga disponibles, por si son necesarias, una serie de capacidades, por lo que se
deben poner los medios necesarios para asegurarse que el contratista tiene tal
disponibilidad.
DIRECCIÓN DEL ÁREA TIC: EL PAPEL DEL RESPONSABLE

DEL ÁREA, EL CIO
Como consecuencia del mayor peso del área de TIC en el logro de los resultados
de la empresa, las funciones del responsable del área se han ido ampliando gra-
dualmente. Integrando en sus ámbitos de responsabilidad tradicionales otras res-
ponsabilidades de carácter transversal, de manera que cada vez más juegan un
papel estratégico y claramente enfocado al cliente. Además, requieren mayores
capacidades de gestión, tanto de las personas como de los procesos de transfor-
mación de los negocios, y de solución de problemas. Entre los argumentos sub-
yacentes que favorecen esta tendencia está el hecho de que los ejecutivos del
departamento de sistemas de información tienen una visión completa de los pro-
cesos de negocio que les puede convertir de facto en auténticos gestores de los
procesos de cambio.
Esta transformación interna del puesto no se mantendrá estática en el tiem-
po. Antes bien, es posible anticipar un cambio continuo en la medida en que los
procesos de externalización se aceleren al mismo ritmo que las empresas com-
prendan que el valor real de las TIC no reside tanto en la propia tecnología como
en la capacidad que ésta tiene para soportar y generar información imprescindi-
ble para la toma de decisiones de negocio.
Por tanto, la figura del CIO actual requiere de una fuerte capacidad de lideraz-
go, tanto para asegurar la construcción de un buen equipo interno (capacidad para
atraer, desarrollar y retener a profesionales de TIC altamente cualificados) como
para participar activamente en el proceso de transformación del negocio. Además,
debe incorporar la capacidad de definir y transmitir un modelo de gestión y una
propuesta convincente de sistemas de información asociada al mismo y de gene-
rar una visión compartida de los retos de futuro de la empresa, así como de movi-
lizar a los distintos estamentos involucrados en el proceso de transformación.

Entre las habilidades reconocidas para ser un buen CIO se pueden nombrar:
z Evolución profesional reconocida, incluyendo la gestión de las personas.

z Experiencia en alinear y apoyarse en la tecnología para generar ventajas
competitivas.
z Conocimientos técnicos.
z Liderazgo, capacidad de influencia y persuasión, necesarias para la con-
ducción de equipos.
z Creatividad.
z Capacidad de relación y facilidad de comunicación.
z Motivación y pasión por las TIC.
z Experiencia y/o conocimiento de la industria específica/negocio.
z Capacidad para generar y liderar el cambio.
z Capacidad de negociación y de gestión.
z Resistencia a la frustración.
z Sensibilidad por el servicio y la calidad.
En resumen, el CIO debe ser un ejecutivo capaz de gestionar uno de los

recursos más críticos de la empresa, relacionándose con sus colegas de las áreas
de negocio a las que debe servir con la máxima calidad posible, a la vez que ha
de mantener un equipo de personas de alta calificación motivado velando por un
riguroso control de costes. Esta ardua tarea requiere de dedicación y compromi-
so, complementados con un conocimiento profundo de la tecnología y de la
empresa en que desempeñe su labor.

Los instrumentos de gobierno del departamento TIC no difieren conceptualmen-
te de los de los demás departamentos de servicios de la empresa. Este capítulo
ha presentado de forma resumida los más comunes, siendo quizá la decisión más
compleja la de dónde ubicar el departamento en la estructura organizativa. Esta
decisión dependerá del papel de las TIC en la empresa, pero en cualquier caso,
un directivo de máximo nivel debe representarlas en los máximos órganos de
gobierno. Aunque el responsable directo de las TIC no forme parte del comité
ejecutivo, el máximo responsable de las mismas debe ser consciente que es su
cometido aportar el punto de vista tecnológico a las discusiones que allí se lle-
ven a cabo, y no debiera dudar en apoyarse en el director del departamento si no
se siente totalmente confortable con este rol.

Epílogo 229
Epílogo
A MODO DE CONCLUSIÓN
Gestionar adecuadamente las tecnologías de la información en la empresa es
una tarea compleja que requiere habilidades e instrumentos apropiados. Esta
obra ha analizado de manera sistemática los conceptos necesarios para que los
responsables de la organización puedan afrontar el reto con mejores garantías de
éxito. Como se ha ido viendo, el conocimiento tecnológico que la alta dirección
debe tener es mínimo, aunque ello no implica que pueda hacer «dejación de
funciones» y delegar completamente las decisiones relacionadas con las TIC en
el responsable técnico o, peor aún, en un directivo «no técnico» (habitualmente
el responsable de las áreas de administración y control). Hay decisiones que por
sus implicaciones en las capacidades competitivas de la empresa se convierten
en trascendentales, y por tanto caen plenamente en el ámbito de responsabilidad
de la alta dirección.
Si bien las herramientas tecnológicas se van convirtiendo paulatinamente en
elementos genéricos (es difícil diferenciarse competitivamente mediante un or-
denador personal o una red de comunicaciones) las prácticas empresariales que
se pueden desarrollar sobre los mismos no son en ningún caso genéricas, y es en
su desarrollo donde los responsables empresariales deben enfocar sus esfuerzos.
Desafortunadamente, las oportunidades de dotarse de estas prácticas diferencia-
les vienen condicionadas en gran medida por decisiones tomadas de antemano
referentes a la infraestructura y a los sistemas «de base», tipo ERP y CRM. Es
por ello que gestionar de forma adecuada las posibilidades de diferenciación
asociadas a la aplicación de las TIC es también responsabilidad de los niveles
más elevados de la organización.
Sin descuidar las dimensiones más estratégicas, esta obra ha dedicado varios
capítulos a la gestión del recurso TIC. Las decisiones de inversión, aproximacio-
nes al cálculo de valor aportado, las ventajas e inconvenientes de los sistemas
integrados ERP, SCM y CRM, las decisiones de subcontratación, y los instru-
229

mentos de control del departamento TIC han ocupado la mayor parte de este
texto.
A lo largo del libro se han presentado una serie de mensajes recurrentes que
se reproducen aquí a modo de conclusión.
1. Las TIC están en constante evolución; sus costes por «unidad de produc-
ción» decrecen de forma excepcional, pero el uso que se hace en las em-
presas es cada vez mayor, con lo que los presupuestos destinados a las
TIC crecen, y es esencial disponer de mecanismos de gobierno que ade-
más de ayudar a controlar los costes hagan explícito el impacto de las
TIC en los parámetros de negocio. Los Capítulos 3, 8, 10 y 11 exploran
diferentes aspectos de esta problemática.
2. Las decisiones de inversión en TIC han de ser consistentes con los objeti-
vos de negocio, y los sistemas que se implanten no solamente han de
apoyar explícitamente la estrategia de la compañía, si no que han de con-
tribuir en lo posible al desarrollo de ventajas competitivas diferenciales.
Los Capítulos 3 y 8 han estudiado los diferentes aspectos de estas necesi-
dades y han apuntado tanto a procedimientos de «alineamiento» de las
TIC con estrategias empresariales predefinidas como de integración de la
planificación estratégica con la de sistemas, usando las posibilidades que
éstas pueden ofrecer.
3. Muchas de las soluciones que se implantan en las empresas pasan por la
adopción de paquetes (sistemas pre-definidos) que se convierten en plata-
formas sobre las que se desarrollan los sistemas de información. De es-
tos, los ERP, SCM y CRM constituyen las familias más populares, y sus
particularidades, ventajas e inconvenientes, incluyendo los de los desa-
rrollos propios frente a los paquetes integrados son objeto de estudio en
los Capítulos 4, 5, y 6.
4. El Siglo XXI se está caracterizando por una fragmentación continua de
los negocios, con empresas cada vez más enfocadas en unas pocas activi-
dades que dan servicio a muchas otras. Las TIC no son ajenas a este
fenómeno y muchas empresas han decidido subcontratar a terceras partes
cada vez mayores operaciones TIC. El outsourcing tiene múltiples venta-
jas y también inconvenientes. El Capítulo 7 ha estudiado este fenómeno,
presentando un marco conceptual para ayudar a detectar actividades
subcontratables y ayudar a la gestión del proceso, tanto de actividades
típicas de TIC como otras relacionadas.
5. Los costes «completos» de las TIC son muy difíciles de medir debido a
los múltiples componentes del coste de los sistemas, que abarcan desde
los puramente contables de inversión y gasto, a los debidos a la falta de
flexibilidad y dependencia de un proveedor concreto del que la empresa
no se puede salir con facilidad. Los beneficios de estas inversiones no son
tampoco obviamente medibles, con lo que en muchas empresas se ha
optado por un procedimiento de evaluación y seguimiento de desempeño
simplificado. El Capítulo 9 ha repasado con bastante detalle el estableci-
miento de un «cuadro de mando» de las TIC encaminado a solventar
estas deficiencias.
6. Muchas empresas se plantean dónde ubicar en la organización el departa-
mento TIC. La respuesta a esta pregunta depende del tamaño de la misma

Epílogo 231
–con implicaciones directas sobre el volumen de trabajo del responsa-

ble– y de la importancia de las TIC en la estrategia. Ideas concretas sobre
cómo analizar este problema, cómo organizar el departamento interna-
mente, y la gestión de las carreras de los profesionales, se han explorado
en el Capítulo 10.
7. Los proyectos TIC deben gestionarse de manera específica a sus particu-
laridades, ya que involucran no solamente a personal del departamento
TIC, si no que además deben comprometer a los usuarios, a los que se les
van a pedir recursos (normalmente de tiempo) para que apoyen de mane-
ra explícita a los desarrolladores de los sistemas y llegado el momento se
conviertan en usuarios «comprometidos». Errores en la involucración de
los usuarios y en los procesos de implantación levan a un estado de sub-
utilización de los sistemas que puede poner en peligro no sólo la rentabi-
lidad de la inversión realizada si no incluso generar problemas operativos
graves en la empresa. La gestión de los proyectos TIC ha sido objeto de
estudio en el Capítulo 11.

Glosario básico de términos de las tecnologías de la información... 233
Glosario básico de términos

de las tecnologías
de la información
y de la comunicación
SOFTWARE
.NET Microsoft .NET es un conjunto de tecnologías de software desarrolladas
por Microsoft que incorpora aplicaciones, herramientas y servicios en una mis-
ma entidad. Punto Net fue concebido como una forma de hacer que el software
de Microsoft esté disponible y permita la interacción entre todo tipo de disposi-
tivo, incluyendo ordenadores, teléfonos celulares y organizadores portátiles. Para
el desarrollo y ejecución de aplicaciones en este nuevo entorno tecnológico Mi-
crosoft proporciona el conjunto de herramientas conocido como .NET Framework
SDK, e incluye el desarrollo de software de programación como Microsoft C#,
Visual Basic.NET, Managed C++ y JScript.NET, todos ellos diseñados específi-
camente para crear aplicaciones que funcionen en Punto Net.
.NET PASSPORT .NET PASSPORT es un servicio en línea de Microsoft que

permite utilizar la dirección de correo electrónico y una única contraseña para
iniciar sesión en cualquier servicio o sitio web colaborador de .NET Passport.
Con esta tecnología se evita tener que recordar un nombre de inicio de sesión y
una contraseña diferentes para cada sitio Web accedido.
AVI Acrónimo de Audio Video Interleave. Es un formato de audio y vídeo

comúnmente usado sobre los PC (los otros son MPEG y QuickTime). Este for-
mato fue desarrollado específicamente para Microsoft Windows y permite en-
viar en forma intercalada la información de vídeo y de audio a una tasa de 15
imágenes por segundo proporcionando una resolución de 320x256 en millones
de colores.
BAUDIO Unidad de medida de la velocidad de transmisión de una señal

digital. Número de cambios de estado de una señal por segundo. En general se
pueden asimilar los baudios de una transmisión al número de bits por segundo.
Se utiliza para medir la velocidad de transmisión de un MODEM.
233

BIT Acrónimo de Binary Digit. Mínima unidad de medida en informática,

cada bit puede ser un 1 (impulso positivo) o 0 (negativo). Una combinación de
bits puede indicar un carácter alfabético, un dígito, una señal, un modificador u
otras funciones.
BYTE Abreviatura de Binary Term, representa una unidad de almacenamien-

to capaz de guardar un carácter (número, letra o símbolo). Un byte está formado
por 8 bits. Normalmente se utiliza para referirse a la capacidad de almacena-
miento en disco duro o la memoria RAM de un ordenador.
C Lenguaje de programación de alto nivel desarrollado por Dennis Ritchie y

Brian Kernighan a principios de los años setenta. Este lenguaje se hizo popular
en los años ochenta, y es uno de los más usados actualmente para programar
sistemas operativos y aplicaciones. C es uno de los lenguajes preferidos por los
programadores para PC porque su compilador es relativamente pequeño y por-
que requiere menos memoria que otros lenguajes.
C# C# es el nuevo lenguaje de propósito general orientado a objetos creado por

Microsoft para su plataforma .NET. Microsoft.NET es el conjunto de nuevas
tecnologías en las que esta empresa ha estado trabajando estos últimos años con
el objetivo de mejorar tanto su sistema operativo como su modelo de componen-
tes (COM) para obtener una plataforma con la que sea sencillo el desarrollo de
software en forma de servicios web. C# combina los mejores elementos de múl-
tiples lenguajes de amplia difusión como C++, Java, Visual Basic o Delphi. De
hecho, su creador Anders Heljsberg fue también el diseñador de muchos otros
entornos de programación como Turbo Pascal, Delphi o Visual J++. C# combina
la potencia de lenguajes como C++ con la sencillez de otros programas como
Visual Basic.
C++ Es un lenguaje orientado a objetos creado por Vejaren Stroustrop en Bell

Labs en los años ochenta. C++ es el sucesor de C y es uno de los programas más
utilizados para el desarrollo de aplicaciones gráficas en entornos Windows y
Macintosh.
CRM Es el acrónimo de Customer Relationship Management, y se refiere al

conjunto de programas de software específicamente dedicados a gestionar la
interacción entre una empresa y sus clientes. Normalmente se usa para denomi-
nar paquetes de software integrados, e incluye tanto las aplicaciones encamina-
das a la gestión de la fuerza de ventas como las encaminadas a interactuar con
los clientes y personalizar sus experiencias, normalmente on-line. Esta relación
con los clientes se puede materializar en distintas herramientas: Help Desk, un
centro de llamada para consultas y operaciones, o vía internet con diversas apli-
caciones.
EDI Acrónimo de Electronic Data Interchange. Es un estándar mundial de

intercambio electrónico de documentos que permite la realización de transac-
ciones comerciales entre diferentes organizaciones. Estos «documentos electró-
nicos» fueron desarrollados en los años setenta auspiciados por la ONU. Actual-
mente dentro de EDI existen dos estándares: ANSI X-12 para Estados Unidos y

EDIFACT para Europa. Dentro del concepto EDI cada agrupación sectorial ha
desarrollado los estándares de codificación que permiten solucionar las especifi-
cidades de cada uno. El propósito inicial de EDI es la reducción de costes en
base a la eliminación de errores y la agilización de los procesos en base a la
comunicación electrónica de sistema a sistema con la mínima intervención hu-
mana. Existen empresas certificadoras dedicadas a corroborar que un determi-
nado documento se envió de una empresa a otra.
ERP Acrónimo de Enterprise Resource Planning, o planificación de los

recursos de la empresa. Es un software de aplicación, proporcionado de forma
preprogramada por proveedores especializados, que se utiliza para la gestión de
información de una empresa, que facilita el flujo de datos entre las distintas
áreas que conforman la organización. Básicamente funcionan con una base de
datos centralizada, los datos se ingresan sólo una vez y el sistema está preparado
para consolidar los mismos en distintos niveles de agregación. Normalmente los
ERPs se dividen en módulos (recursos humanos, finanzas, logística, etc.) y ac-
tualmente los proveedores de ERP ofrecen sistemas adaptados a cada industria.
El líder de mercado en software ERP es la empresa alemana SAP, seguida por
Oracle y JD Edwards.
HTML Acrónimo de Hyper Text Markup Language: Lenguaje simple de

texto utilizado para crear documentos y links (enlaces) en la World Wide Web
(www). Este lenguaje es interpretado por todos los softwares preparados para
navegar en Internet (navegadores). Su facilidad de uso ha contribuido a la proli-
feración de cientos de miles de páginas webs en todo el mundo.
HTTP Acrónimo de Hyper Text Transfer Protocol, el protocolo de comuni-

cación usado para transferir páginas de hipertexto entre ordenadores. Es el la
base que ha permitido la popularización de la Internet como la conocemos, con
páginas conteniendo texto, gráficos y películas que a su vez pueden ser enlaces
a otras páginas en el mismo o diferentes servidores.
J2EE Es la sigla de Java 2 Platform Enterprise Edition. Es una plataforma

independiente, basada en el lenguaje de programación Java de Sun Microsyste-
ms, para el desarrollo de aplicaciones multitareas para empresas, que funciona a
través de Internet.
JAVA Java es un lenguaje de programación de alto nivel desarrollado por Sun

Microsystems que se originó en un experimento por conectar dispositivos elec-
trónicos dentro de un hogar. Java es muy sencillo de utilizar y es interpretado
por el ordenador en el momento de la ejecución. Java puede funcionar en cual-
quier dispositivo independientemente del sistema operativo o procesador que
utilice, siempre que disponga del intérprete (denominado Java Virtual Machine)
y por sus características de funcionamiento e instalación es uno de los lenguajes
más seguros. Posee una amplia aceptación, tanto para la adición de funcionali-
dades a páginas web como para desarrollos más complejos de bases de datos y
aplicaciones de ecommerce. Sun Microsystems ha puesto de forma gratuita el
lenguaje Java a disposición de quien quiera realizar con el mismo nuevos desa-
rrollos. De esta forma hay múltiples plataformas de diferentes fabricantes que

interpretan Java, ya sea el propio Sun Microsystems u otras empresas, incluyen-

do Microsoft, Apple o Linux.
LINUX Linux es un sistema operativo multiusuario, multitarea y multiproceso

que corre en diferentes plataformas de hardware. Inicialmente desarrollado por
Linus Trovals, este Sistema Operativo representa el paradigma del software li-
bre. Su desarrollo se ha continuado a través de comunidades de programadores
que trabajan en forma colaborativa. Empresas del calado de Amazon y Google
han elegido Linux como sistema operativo dada su robustez y su capacidad para
manejar miles de usuarios en forma simultánea sobre cientos de ordenadores
trabajando en paralelo. Además, como es un software libre, su precio es irrisorio
comparado con otras alternativas. Los detractores de Linux argumentan que en
las grandes corporaciones no sólo se necesita un buen sistema sino también so-
porte técnico permanente, y dada sus características, Linux no las puede dar y se
debe recurrir a terceras empresas para conseguirlo.
MP3 Es una sigla formada por MPEG Layer 3 y es un formato para la graba-
ción digital de música y sonidos con una calidad cercana a la de un Compact
Disc. Un MP3 es un archivo codificado y comprimido para su distribución elec-
trónica. En el proceso de compresión se eliminan sonidos (que ocupan espacio)
no perceptibles por el oído humano, con lo cual se reduce el tamaño del archivo
sin perder calidad aparente. Se estima que un archivo de sonido sin compresión,
como por ejemplo un formato WAV de Windows, un minuto de música puede
ocupar 50 megabytes. Esa misma melodía en un formato MP3 no ocupa más de
4 megabytes. MP3 es el formato preferido por los internautas para el intercam-
bio de música en los sistemas P2P.
MPEG Acrónimo de Motion Picture Experts Group grupo de la ISO (Inter-

national Standards Office) dedicado a la aprobación y endorso de estándares de
codificación digital de vídeo. La capa de audio del primer estándar MPEG es el
conocido MP3.
OPEN SOURCE Genéricamente, Open Source (fuente abierta) se refiere a los

programas cuyo código fuente, es decir el original escrito en un lenguaje inteli-
gible por las personas, se encuentra disponible para el público en general o para
su uso o modificación desde su versión original. En general los programas que
utilizan esta metodología se crean a través de esfuerzos colectivos, entre varias
comunidades de programadores con el objeto de ir perfeccionando la aplicación
o sistema operativo. El icono Open Source ha nacido como contrapartida al soft-
ware propiedad de las empresas, en los que no revela su código fuente para
preservar la propiedad intelectual. En la actualidad el caso más paradigmático
de contraposición entre software libre y propiedad de una empresa es Linux
frente a Windows de Microsoft.
QUICKTIME Es el nombre de un sistema de vídeo y animación desarrollado

por Apple Computer. Si bien Quick Time es utilizado principalmente con el
sistema operativo Macintosh, los ordenadores basados en arquitectura Intel tam-
bién pueden utilizarlo instalando el reproductor adecuado. Quick Time soporta
gran variedad de formatos, incluyendo JPEG, MPEG.

SOFTWARE Conjunto de programas, instrucciones y reglas informáticas para

ejecutar ciertas tareas en un ordenador u otro dispositivo electrónico digital. En
general cabe distinguir entre sistemas operativos, encargados de coordinar y rea-
lizar las principales tareas en un ordenador o dispositivo, y aplicaciones, que son
programas diseñados para ejecutar una determinada tarea, por ejemplo redactar
una carta, modificar una fotografía o calcular un presupuesto.
UNIX Es un sistema operativo multitarea y multiusuario desarrollado en Bell

Labs a principio de la década de los setenta. En sus inicios fue diseñado para ser
un lenguaje de pocas prestaciones y flexible para ser utilizado por programado-
res. Bell Labs distribuyó el sistema operativo en universidades con el código
fuente abierto, por lo que en pocos años se transformó en un sistema operativo
muy popular. Debido a su portabilidad, flexibilidad y robustez Unix en sus múl-
tiples versiones se ha convertido en un sistema operativo muy usado en servido-
res y estaciones de trabajo de alta gama.
HARDWARE
CPU Acrónimo de Central Processing Unit. Es el microprocesador o circuito
integrado que interpreta y ejecuta las instrucciones que los programas le envían.
Es por definición el cerebro del ordenador. En ocasiones el término se hace
extensivo además del microprocesador a la memoria e incluso a la consola para
distinguirlo de los dispositivos periféricos.
CRT Es la abreviatura de Cathode-Ray Tube. Es la tecnología usada en los

televisores y en los monitores de los ordenadores. El tubo de rayos catódicos es
un tubo al vacío en el que los electrones emitidos por un cátodo caliente se
forman en un rayo angosto, acelerado a alta velocidad y dirigido hacia una pan-
talla especialmente preparada en la que los electrones producen un impacto fluo-
rescente.
FIREWIRE Es un protocolo de comunicación desarrollado por Apple Com-

puter, que soporta tasas de transferencia de hasta 800 mbps (millones de bits por
segundo), y permite conectar hasta 63 periféricos. Es la interfaz preferida para
dispositivos de vídeo y audio digital, así como para discos duros externos y otros
periféricos de alta velocidad. A grosso modo puede enviar los datos de más de
un CD cada diez segundos.
HARDWARE Conjunto de los componentes que integran la parte material de

un ordenador y sus periféricos: impresoras, MODEM, scanner, lectora de CD,
DVD, etc.
LAPTOP Conocido también como ordenador portátil o notebook. Es un orde-

nador mas pequeño que el tradicional PC y tiene el monitor y el teclado unidos
a la CPU, en una misma entidad física. Los ordenadores portátiles tienen igual
capacidad de procesamiento de información y funcionan con los mismos siste-
mas operativos y aplicaciones que los PC. Su ventaja principal radica en su
portabilidad, puede ser utilizado en cualquier sitio no sólo por su tamaño sino

porque al disponer de batería puede funcionar sin necesidad de electricidad ex-

terna por unas horas.
LCD Liquid Crystal Display o pantalla de cristal líquido, es un monitor

utilizado frecuentemente en relojes y en ordenadores portátiles. Tiene la ventaja
de concentrar la imagen en un monitor plano y pequeño, de ahí su uso generali-
zado en los ordenadores portátiles. Existen actualmente dos tipos de pantallas de
cristal líquido: La matriz pasiva, en la que el usuario puede visualizar la pantalla
en la medida en que se encuentre de frente al ordenador. Por contra, la tecnolo-
gía matriz activa (también conocida como TFT) se puede visualizar desde casi
cualquier ángulo.
MODEM Es una sigla que significa Modulador- Demodulador. El MODEM

es un dispositivo que permite conectar el ordenador a la línea telefónica para el
intercambio de datos. Su función es la de transformar las señales digitales con
las que trabaja el ordenador en analógicas (modulación) para que el sistema
telefónico tradicional las pueda transportar igual que transporta una conversa-
ción tradicional. El MODEM receptor de la señal la vuelve a transformar en
digital (demodulación) para que la pueda interpretar el ordenador correspon-
diente.
PDA Siglas de Personal Digital Assistant, se refiere a un dispositivo electró-

nico que tiene funcionalidades propias de un ordenador (sistema operativo y
software) de tamaño suficientemente pequeño como para caber en la palma de
la mano. Normalmente no dispone de teclado, los datos se introducen mediante
su pantalla sensible usando un lenguaje simbólico específico parecido a la es-
critura manuscrita. Las primeras PDA tenían únicamente funciones de agenda,
y han evolucionado a convertirse en verdaderos ordenadores y teléfonos celu-
lares.
SCSI La palabra SCSI es el acrónimo de Small Computer System Interface

(Sistema de Interconexión de Microordenadores). El bus SCSI es un sistema o
norma de conexionado de periféricos, incluyendo unidades de disco. Una de sus
principales ventajas es que se pueden conectar multitud de periféricos en serie.
La aparición de un estándar de conexión como SCSI ha permitido el intercambio
de unidades de disco de diferentes fabricantes, influyendo decisivamente en la
presión bajista de los precios.
TABLET PC Es un ordenador portátil en el que su pantalla es sensible y en la

que el usuario puede escribir con un lápiz especialmente diseñado para ello.
Dotado de un software de reconocimiento de escritura, permite prescindir del
teclado para la entrada de datos.
TDT Acrónimo de Televisión Digital Terrestre, consiste en usar el espectro

radioeléctrico asignado a la televisión analógica terrestre actual para transportar
canales en formato digital. Al ser la señal digital, se utiliza el espectro mucho
más eficientemente y se puede disponer de mayor número de canales de televi-
sión, de mejor calidad de imagen y sonido. Es una televisión sin ruidos, interfe-
rencias, ni doble imagen, con formato panorámico (16/9) y convencional (4/3) y

múltiples idiomas y subtítulos. Para poder verse con los televisores analógicos
es necesario un «traductor» de señal digital a analógica.
USB Abreviatura de Universal Serial Bus. El puerto USB permite conectar

hasta 127 periféricos al ordenador. La velocidad de transferencia actual es de 12
mbps (millones de bits por segundo), que aún siendo mucho menor que Firewire
es más que suficiente para periféricos como teclados, ratones, impresoras y es-
cáners. El estándar USB-2 permite alcanzar velocidades parecidas al Firewire.
COMUNICACIONES
802.11 802.11 es una familia de especificaciones (con el apósito b o g) desarro-
lladas por el Instituto de Ingenieros Electrónicos y Eléctricos (IEEE) de EE.UU.
para las redes locales basadas en tecnologías inalámbricas, donde el medio de
transmisión es la radiofrecuencia. Para el caso particular del 802.11b, la veloci-
dad de transmisión de la red inalámbrica es de 11mbps y para la potencia de
emisión habitual utiliza una frecuencia no regulada, por lo que no se requiere
ningún tipo de permiso para su instalación.
ADSL Es el acrónimo de Asymetric Digital Subscriber Line. ADSL permite

un acceso a Internet mediante la línea telefónica existente con un ancho de ban-
da superior al del acceso telefónico tradicional a través de MODEM analógico.
Debido a que usa una frecuencia muy superior a la usada para las conversaciones
telefónicas, la instalación de una conexión ADSL puede coexistir con el uso del
teléfono sin ningún tipo de perjuicio. La denominación de asimétrico se refiere
a la diferencia entre la capacidad de llegada de datos (bajada) y la de envío
(subida). Dado que en general los usuarios consumen más datos de los que gene-
ran, es decir utilizan más ancho de banda para consultar o bajar información,
que para enviarla a otro usuario, el sistema ADSL se adapta a esta conducta y
para la mayoría de los usuarios utiliza el ancho de banda total disponible más
eficientemente.
ANCHO DE BANDA Formalmente es una medida del rango de frecuencias

ocupado por un dato cuando pasa a través de un canal de comunicación. Cuanto
más grande es el rango de frecuencias, más cantidad de datos pueden ser trans-
mitidos en un mismo tiempo. El ancho de banda es pues una medida de la capa-
cidad de un canal de comunicación. Las unidades de medida son los bits que se
pueden transmitir por segundo, con sus múltiplos kbps (kilo bits por segundo) y
mbps (mega bits por segundo).
ASP Acrónimo de Application Server Provider. Los ASP son organizaciones

que ofrecen sus aplicaciones a sus clientes en alquiler a través de una red, prin-
cipalmente a través de Internet. Con esta tecnología los clientes pueden «terceri-
zar» sus necesidades informáticas, tener soporte permanente y mantener actualiza-
dos sus productos informáticos.
BACKBONE Es una línea con una enorme capacidad de tráfico de información,

generalmente con alcance internacional. Normalmente este tipo de líneas son crea-

das y administradas por los ISP más grandes del mundo. Los proveedores de inter-
net más pequeños se conectan a estas líneas a través de puntos de acceso a la red
denominados NAP (del inglés Network Access Points).
BANNER Soporte publicitario propio de Internet. Recuadros de imagen con

texto y animaciones con un enlace a la página del anunciante a la que se envía al
navegante al hacer clic en ella.
BLUETOOTH Es un conjunto de especificaciones para las comunicaciones

inalámbricas que consiste en un pequeño transmisor de radiofrecuencia que per-
mite conectar entre sí todo tipo de dispositivos electrónicos (teléfonos, ordena-
dores, impresoras, faxes, etc.) situados dentro de un radio limitado de 10 metros
(ampliable a 100, aunque con mayor distorsión) sin necesidad de utilizar cables.
El transmisor está integrado en un pequeño microchip de 9x9 milímetros y opera
en una frecuencia de 2,4 GHz (utilizada en muchos países para usos médicos y
científicos) que asegura la compatibilidad universal. Los dispositivos que incor-
poran Bluetooth se reconocen y se hablan de la misma forma que lo hace un
ordenador con su impresora. El transmisor permite enviar voz y datos a una
velocidad máxima de 700 Kb/seg. y consume un 97% menos que un teléfono
móvil. Además, es inteligente: cuando el tráfico de datos disminuye el transmi-
sor adopta el modo bajo de consumo de energía.
BROWSER El Browser o Navegador es el término aplicado a los programas

que permiten acceder al servicio WWW. El más popular es Internet Explorer de
Microsoft, siguiéndole en popularidad Firefox, Netscape y Safari.
BTB/B2B Acrónimo de Business-to-Business (Empresa a Empresa o entre em-

presas). Modalidad de comercio electrónico en el que las operaciones comerciales
se realizan entre empresas (por ejemplo, una empresa y sus proveedores) y no con
los usuarios finales. Algunos autores utilizan el acrónimo español EAE.
BTC/B2C Acrónimo de Business-to-Consumer (Empresa a Consumidor). Mo-

dalidad de comercio electrónico en el que las operaciones comerciales se realizan
entre una empresa y sus usuarios finales. El acrónimo español EAC es muy poco
utilizado.
BUCLE LOCAL Conocido también como «última milla». Es el vínculo

entre la conexión telefónica del usuario con el conmutador de líneas telefóni-
cas más cercano a su domicilio. Cada línea es dedicada, es decir pertenece a un
solo cliente. La mayoría de estas líneas han sido diseñadas para el intercambio
de voz, y por tanto su estructura general es de cables de cobre. Con el desarro-
llo de Internet las empresas de telecomunicaciones han comenzado a reempla-
zar esta infraestructura con fibra óptica y con dispositivos para la transmisión
digital de datos. «La última milla» es una fase crítica de las infraestructuras de
comunicaciones ya que por su elevada capilaridad requiere inversiones muy
elevadas.
COOKIE Conjunto de caracteres que se almacenan en el disco de un usuario

cuando accede a las páginas de determinados sitios web. Se utilizan para que el

servidor al que se ha accedido pueda identificar la máquina (no necesariamente al

usuario) al volver éste a conectarse.
DIRECCION IP Dirección del Protocolo Internet. Número de 32 bits que

identifica de manera única a un ordenador conectado a Internet y que permite la
transferencia de mensajes siguiendo el IP. Se expresa en el formato de cuádruplo
punteado, por ejemplo 192.10.13.1, los tres primeros conjuntos identifican la
red, subred y zona a la que está conectada el ordenador, el último número iden-
tifica al ordenador específico.
EMAIL Correo electrónico. Aplicación mediante la cual un ordenador puede

intercambiar mensajes con otros usuarios de ordenadores (o grupos de usuarios)
a través de la red. El correo electrónico es uno de los usos más populares de
Internet.
ETHERNET Tecnología de red de área local (LAN) más utilizada; también se

conoce como 10/100 Ethernet. Ethernet transmite información entre ordenado-
res a velocidades de entre 10 y 100 millones de bits por segundo.
FIBRA OPTICA Cable con propiedades ópticas que permite la transmisión

de información a base de enviar pulso de luz en lugar de corriente eléctrica. Se
caracteriza por un elevado ancho de banda, y por tanto una alta velocidad de
transmisión, y poca pérdida de señal.
FIREWALL Literalmente «pared de contención de fuego». Se trata de un

software, hardware o combinación de ambos que protege a una red de los «ata-
ques» desde otra red. Un firewall es una herramienta de seguridad que impide
que ciertos comandos o paquetes de datos «anormales» penetren en el sistema,
detectando ataques o entradas forzadas en los puertos del sistema de comunica-
ciones de una red.
GPRS Es el acrónimo de General Packet Radio System. Es un servicio que

permite enviar y recibir información utilizando una red de telefonía móvil. Con
esta tecnología la transmisión de datos se realiza a 115kbps que supera amplia-
mente los 9,6kbps del actual GSM. Al utilizar tecnología de «intercambio de
paquetes», los recursos sólo se utilizan cuando el usuario está recibiendo o en-
viando información. Esta utilización eficiente de la infraestructura permite que
varios usuarios compartan el mismo ancho de banda, y que por tanto la red tenga
más capacidad percibida de transporte.
GPS Acrónimo de Global Positioning System (Sistema de localización global).

Sistema de localización geográfica vía satélite capaz de dar la localización de una
persona u objeto dotado de un receptor GPS con una precisión mínima de 10 me-
tros. Es un sistema desarrollado y operado por el Departamento de Defensa de
EE.UU. Rusia tiene un sistema propio y la Unión Europea está desarrollando el
suyo, denominado Galileo.
GSM Abreviatura de Global Sytem for Mobile Communications. Es un están-

dar para los teléfonos móviles digitales que se utiliza en Europa y en Asia. GSM

permite transmitir datos a una velocidad de 9,6kbps lo que permite enviar y recibir
email a través del móvil y navegar por páginas con poco «peso»
I-MODE Es una tecnología de acceso a aplicaciones y servicios a través de

teléfonos móviles diseñada por la empresa japonesa NTT DoCoMo, que cuenta
con más de 30 millones de suscriptores en Japón. I-MODE también permite el
acceso a la Internet tradicional, y tiene varios aspectos destacables. Funciona
con tecnología de intercambio de paquetes, lo que permite estar conectado a la
red todo el tiempo pero únicamente usar recursos cuando se recibe o envía infor-
mación. Sobre esta tecnología se han desarrollado varios modelos de negocio
que consisten en terceras compañías que proveen servicios que son cobrados por
la operadora quedándose ésta un porcentaje de la facturación.
IAP Acrónimo de Internet Access Provider se refiera a una empresa que

provee servicios de acceso a Internet a sus clientes.
INTERNET Es la mayor red informática del mundo. Nacida en 1969 en

EE.UU. como el proyecto de comunicaciones militar ARPANET se convirtió en
la Internet abierta de hoy en día en 1974. Están conectadas a la misma centena-
res de millones de personas, organismos y empresas en todo el mundo, mayori-
tariamente en los países más desarrollados, y cuyo rápido desarrollo está tenien-
do importantes efectos sociales, económicos y culturales, convirtiéndose de esta
manera en uno de los medios más influyentes de la sociedad de la información.
Es la autopista de la información por excelencia.
IP Internet Protocol. Es el protocolo desarrollado para la identificación y

comunicación entre ordenadores adoptado en Internet.
ISP Acrónimo de Internet Service Provider, es una organización que además

de proveer conectividad entre un usuario e Internet (IAP) proporciona otros ser-
vicios como servidores de aplicaciones, almacenamiento de datos, correo elec-
trónico, etc.
LAN Acrónimo de Local Area Network. Red de ordenadores y otros disposi-

tivos compartidos (como impresoras, módems, grandes discos duros) y disper-
sos en un área limitada a una organización o empresa, conectados por enlaces de
comunicaciones (denominados routers) que permiten a un dispositivo interac-
tuar con cualquier otro en la red.
MMS Es la sigla de Multimedia Message Service. Es un método que se

utiliza para la transmisión de archivos gráficos, de vídeos y sonidos, e incluso
mensajes de texto cortos a través de redes de telefonía celular utilizando el pro-
tocolo europeo para el intercambio de datos en móviles (WAP o GPRS.
NODO NEUTRO Punto de enlace de todos los proveedores de acceso y co-

nexión a Internet en un país. Con este nodo las conexiones entre hosts locales se
hacen sin que los paquetes tengan que salir del territorio nacional, lo cual es una
ventaja ya que no hay que pagar ancho de banda internacional para la conmuta-
ción de paquetes entre servidores locales.

PAQUETE Cantidad mínima de datos que se transmite en una red o entre dispo-
sitivos. Tiene una estructura y longitud distinta según el protocolo al que perte-
nezca. Unidad de datos que se envía a través de una red. En Internet la información
transmitida entre dos puntos es dividida en paquetes que pueden recorrer caminos
distintos y que son reagrupados al ser recibidos en su destino.
ROUTER Dispositivo intermediario en una red de comunicación que acelera

y facilita la entrega de paquetes de datos. El router decide cómo y dónde enviar
los paquetes de información. En una operación normal, el dispositivo lee la in-
formación en la cabecera de cada paquete y elige la mejor ruta para enviarlo a su
destino final. Los routers tienen sus propios registros de redes disponibles y del
tráfico en las mismas para determinar la ruta más efectiva de envío.
SERVER Ordenador que suministra espacio de disco y recursos a otros orde-

nadores llamados clientes y conectados a él a través de una red.
SMS Es la sigla de Short Message Service, y consiste en un servicio de

mensajes cortos a través de móviles.
SWITCH Es un dispositivo que se utiliza para la transmisión de datos entre

redes. El switch tiene características parecidas al router pero su ámbito de ope-
ración es más simple, tomando decisiones sobre el siguiente destino del paquete
de datos que dirige. No tiene capacidad para planear complejas rutas de transmi-
sión de datos como lo hace el router.
TCP/IP Acrónimo de Transmission Control Protocol / Internet Protocol.

Protocolo desarrollado para la comunicación entre ordenadores en el que se basa
Internet.
UMTS Abreviatura de Universal Mobile Telecommunications Systems. Es

una tecnología para móviles de tercera generación que permitirá enviar informa-
ción a una velocidad aproximada a los 2 megabits por segundo. Esto significa
que con UMTS se podrá enviar audio y vídeo a dispositivos inalámbricos de la
misma manera en que hoy se establecen conversaciones con la tecnología GSM.
WAN Acrónimo de Wide Area Network. Se identifica con una red de ordena-
dores que se extiende en un ámbito geográfico relativamente grande. Normal-
mente una WAN consiste en la unión de más de dos LAN, y estas LAN se conec-
tan a través de redes públicas.
WAP Acrónimo de Wireless Application Protocol - Protocolo de aplicación

de telefonía inalámbrica basado en GSM. Protocolo que permite a los usuarios
de teléfonos móviles el acceso a servidores web especializados, visualizando la
información en el visor del teléfono.
WiFi/WIRELESS LAN La Wireless LAN es una red local que utiliza como
medio de transmisión la radiofrecuencia. Esta tecnología ofrece conectividad
comparable a la del cable dentro del radio de acción de las estaciones de trans-
misión. El protocolo de comunicación se denomina 802.11 y utiliza una banda

de frecuencias de libre acceso, no siendo necesario ningún permiso para su utiliza-

ción. Una zona con cobertura WiFi se denomina en muchas ocasiones un Hot Spot.
WWW Acrónimo de World Wide Web (Telaraña mundial). La Web es la parte

de Internet a la que se accede a través del protocolo http, que se materializa en
páginas o «sitios» web a las que se accede a través de navegadores como Netsca-
pe, Firefox y Explorer. Es un sistema de información basado en hipertexto crea-
do a principios de los años noventa por Tim Berners-Lee, investigador en el
CERN, Suiza, y hoy en el MIT. La información puede ser de formato texto,
gráfico, audio, imagen fija o en movimiento.


Sieber Valor Porta - Los Sistemas de Inf

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sieber Valor Porta - Los Sistemas de Inf

Încărcat de

Drepturi de autor:

Formate disponibile

La empresa virtual i

MADRID • BOGOTÁ • BUENOS AIRES • CARACAS • GUATEMALA • LISBOA

McGraw-Hill ha solicitado los permisos oportunos para la realización y el desarrollo

LOS SISTEMAS DE INFORMACIÓN EN LA EMPRESA ACTUAL

No está permitida la reproducción total o parcial de este libro, ni su tratamiento

Copyright © 2006 por Sandra Sieber, Josep Valor, Valentín Porta

Diseño de cubierta: Luis Sanz Cantero

IMPRESO EN ESPAÑA - PRINTED IN SPAIN

Prólogo .......................................................................................................... vii

Capítulo 1. Introducción .............................................................................. 1

Capítulo 2. Conceptos básicos de sistemas y tecnologías

Capítulo 3. Compitiendo con los sistemas de información ....................... 31

Capítulo 4. Sistemas para la gestión integrada de los recursos

Capítulo 5. Sistemas de información para la gestión de la cadena

Capítulo 7. La externalización de los servicios de TIC

Capítulo 8. La toma de decisiones de inversión en tecnologías

Capítulo 9. Medición y control de costes ................................................... 173

Capítulo 10. Gestión de proyectos de tecnologías de la información

Capítulo 11. Gobierno del departamento de tecnologías

Epílogo .......................................................................................................... 229

Glosario básico de términos de las tecnologías de la información

Los Sistemas de Información (SI), de la mano de las Tecnologías de la Informa-

Tomar decisiones sobre las Tecnologías de la Información y las Comunicaciones

portantes del diseño organizativo, lo que impide a la alta dirección de la empresa

CONTENIDO DEL LIBRO

¿A QUIÉN VA DIRIGIDO ESTE LIBRO?

z Gestionar el recurso TIC desde el punto de vista de la dirección de la

z Conocer un marco conceptual integrador de todos los aspectos que un di-

Antes de entrar en el estudio de los sistemas y las tecnologías de la información en

¿QUÉ ES UN SISTEMA DE INFORMACIÓN? 1

utilizada por actividades concretas, no pertenece a ninguna en particular sino a la

Características de un sistema de información eficaz

z La estructura y funciones del SI de una empresa deben ser coheren-

Cuadro 2.1. Características de un sistema de información eficaz.

TECNOLOGÍA Y SISTEMAS DE INFORMACIÓN

020 - VALOR - Los sistemas de información en 10

Pedido 4-7 días Mismo día

Entrega 14-21 días Siguiente día

Facturación 4-7 días Mismo día

Pago 45-60 días 45-60 días

Figura 2.1. Tiempos de procesamiento de transacciones, 1960 y 2000.

miento de agua para su refrigeración. Los mainframes satisfacen las necesidades de

020 - VALOR - Los sistemas de información en 11

020 - VALOR - Los sistemas de información en 12

Figura 2.2. La "Ley de Moore" en acción.

“Disco” de 10K, 1953 Disco de 1G (1.000.000 K), 1997

Memorias permanentes, 2003 Disco de 181G, 2001

Figura 2.3. Discos de diferentes épocas y capacidades.

020 - VALOR - Los sistemas de información en 13

56,9 kbps con módem tradicional

Cable coaxial Hasta 200 Mbps

Cable de fibra óptica De 100 Mbps a 2 Gbps

Radio (broadcast) Hasta 2 Mbps

Radio (microondas) 45 Mbps

9.600 bps con GSM

Satélite Hasta 100 Mbps

Bluetooth Hasta 2,1 Mbps

(Nota: velocidades conocidas en marzo de 2005, evoluciones de la tecnología

Figura 2.4. Velocidades de transmisión de datos en diferentes medios.

El software, o programas, son el conjunto de instrucciones que ejecutadas por los

020 - VALOR - Los sistemas de información en 14

memoria, espacio de almacenamiento y ancho de banda tanto de entrada como de

020 - VALOR - Los sistemas de información en 15

Presupuesto en TIC por categoría (%) 2002 2003