Dirección y Gestión de Proyectos e

COSIM TI – CAPACITACION PROFESIONAL – BIBLIOTECA VIRTUAL
Dirección y Gestión de
Proyectos e-Business
Capítulo 1.- Teoría del proyecto
tecnológico
OBJETIVOS
- Comprender la noción de proyecto.
- Conocer y comprender las dimensiones de un proyecto informático
- Reconocer la importancia de una Teoría de Proyectos.
- Comprender la complejidad de un proyecto e-Business desde una perspectiva teórica.
1.1 Introducción
Los proyectos no son nuevos. Las pirámides egipcias, el Partenón griego, la
gran muralla china, son ejemplos de la empresa humana ejecutadas en la
forma de proyectos. Aún más, la Creación del Mundo es un proyecto ejecutado
en 6 días, medido en días, con recursos supuestamente ilimitados y con un
resultado dejado en manos y juicio de los usuarios... Adán y Eva.
La lista anterior puede aumentarse con cosas más cotidianas. Terminar este
texto, terminar el mes dentro de ciertos gastos, un estudio de doctorado. Por
supuesto están los llamados formalmente proyectos de ingeniería, proyectos de
arte, proyectos educativos, y muchos otros tipos, de entre los cuales los
proyectos e-Business son de interés debido a que permiten hacer un análisis
de negocios y tecnológico para un proyecto tecnológico. Se quiere hacer ver
que conceptualmente un proyecto e-Business permite distinguir los dos
elementos centrales a cualquier proyecto tecnológico: la dimensión de negocio
y la dimensión tecnológica.
Nota:
El término e-Business fue popularizado a partir de un eslogan lanzado por IBM como parte de
una de sus estrategias. El día 7 de octubre de 1997, Louis Gerstner, CEO de IBM decía que
1
IBM buscaba posicionar como empresa líder y promover una nueva imagen.
e-Business es lo que ocurre cuando una empresa conecta sus sistemas informáticos a sus
clientes, empleados, distribuidores y proveedores, a través de intranets, extranets o Internet.
IBM tomo la propiedad del término en minúscula (trademark) "e," pero el tiempo ha
mostrado que una definición de e-Business no debería depender de un signo singular o
el particular mensaje de mercadeo promovido por una compañía.
Sin embargo, este concepto tan sencillo se convierte rápidamente en algo muy eficaz. En el
momento en que todos los clientes, empleados, proveedores y distribuidores están conectados
a los sistemas de la empresa y obtienen la información que necesitan, está claro que e-
Business conlleva una transformación de la empresa.
Por este motivo, lo que se buscaba, más allá de una definición de e-Business potencialmente
supeditada a una estrategia y por ello notoriamente susceptible a interpretación retrospectiva,
era algo que no debería ser un sueño que el 95% de las compañía no pudiesen conseguir. La
cuestión no era si usar la "e" o no usar la "e" como un esquema de clasificación. Se buscaba
poder llegar a una definición que debería ser tan válida 10 años antes de Internet y 10 años de
Internet cuando ya sea obsoleta. Esto implica que la "e" debe ser aplicable a cualquier
empresa, independiente de su escala, tal que pueda cualificar como un e-Business.
Fuerte principal: Alter, Steven. (2001). "Does the trend Toward e-Business Call for Changes in
the Fundamental Concepts of Information Systems? A Debate". Communications of the AIS,
5(10). April. http://cais.aisnet.org. [Leído: 23 de Junio de 2006, 11.00h GMT-5].
Un proyecto e-Business puede definirse como el esfuerzo de examinar una iniciativa o solución
e-Business y anticipar su potencial impacto en las personas, los procesos de negocios, la
organización y las inversiones en Tecnologías de la Información (TI). El resultado de un
proyecto e-Business es una aplicación, o conjunto de aplicaciones, e-Business, esencialmente
tecnológica, cuya existencia se justifica solamente en la medida de dar soporte a la iniciativa e-
Business dentro del marco o escenario de negocios o mercado al cual una organización aspira
(figura 1.1).
Figura 1.1: Proyecto e-Business.
Para comprender esta definición, es necesario presentar varios conceptos

generales, cuya claridad conceptual permitirá comprender las diferentes
dimensiones de un proyecto e-Business.
Por tal motivo, primero se revisa el concepto de proyecto. Luego se revisan los
diferentes tipos de proyecto informáticos según variados criterios. A
continuación, y para proveer una base de discusión más amplia, se explica el
concepto de Teoría de Proyectos destacando una de ellas. De esta manera, se
expone finalmente una Teoría del Proyecto e-Business a partir de la noción de
proyecto presentada inicialmente. El detalle de tal planteamiento se ve
cimentado en una presentación extensa sobre los proyectos informáticos.
1.2 Proyectos: una visión teórica
2
Para llegar a entender lo que es un proyecto cualquiera, resulta conveniente

empezar conociendo lo que se entiende por un proyecto, por tratarse de un
término que, pese a ser de uso común, puede tomar significados diferentes y
no siempre se emplea en el mismo sentido o con la precisión conveniente.
Proyecto, desde una perspectiva general y teórica, se puede definir como la acción
intencionada de hombres y/o mujeres hacia la consecución de un resultado o, el medio o la
acción organizacional mediante la cual una organización, empresa o negocio, busca respuesta
a un problema o conflicto. Tal acción da lugar a una solución instrumental, en la forma de un
producto o servicio.
Otra definición de proyecto puede ser "... un conjunto planificado de acciones tendientes a
resolver exitosamente -mediante una cantidad de recursos humanos y materiales, un
presupuesto y un tiempo para su realización- una situación problemática o una demanda
planteada". Completar con el éxito del proyecto significa cumplir con los objetivos, dentro de las
especificaciones técnicas, de costo y de plazo de terminación.
Un proyecto siempre da lugar a una solución. Esta solución tiene varias

particularidades:
• Es habitualmente injertada en la misma organización que la requirió, por

lo cual la solución ha de ser coherente con la organización, tanto en el
ámbito tecnológico como en el humano.
• Surge instrumentalmente por un acuerdo entre proyectistas y clientes en
razón de tiempo, costo, ganas y satisfacción en resolver un conflicto.
• En sí misma requiere de una empatía y un equilibrio entre lo que se
pide, desea o anhela, y lo que se puede con los medios humanos y
tecnológicos.
Proyecto, desde un punto de vista más concreto, se concibe como una

operación de envergadura y complejidad notables, singular, con unas fechas
definidas de inicio y finalización. Es un trabajo no repetitivo, que ha de
planificarse y realizarse según unas especificaciones técnicas determinadas,
con un presupuesto preestablecido y una organización temporal con la
participación de varios departamentos de la empresa que se desmantela
cuando termina el proyecto, y que incluye, tal vez, la colaboración de terceros.
Este concepto emerge de observar que las tareas humanas se organizan bajo
ciertas condiciones, cuyo manejo y aprovechamiento pre-figuran las cualidades
que afectan todo proyecto.
• Persecución de uno o varios objetivos. Las actividades aisladas no

constituyen por sí solas, un proyecto. Para que exista un proyecto, debe
existir una coordinación de actos orientados a la consecución de uno o
varios objetivos, integrados entre sí y estructurados, tanto de índole
técnica como económica. En general, el objetivo general de un proyecto
es satisfacer un conjunto de requisitos a un coste dado en las
condiciones más eficientes.
• Actividades planificadas, ejecutadas y supervisadas. La
coordinación de actividades es condición sine-qua-non para que a las
mismas, en su conjunto, se les pueda calificar de proyecto. De hecho, un
3
proyecto exige que exista vinculación entre las actividades, puesto que
persiguen un objetivo común. Esa vinculación debe plasmarse en forma
de planificación (técnica, temporal y económica) cuya correcta ejecución
supervisada es clave para el éxito o fracaso del proyecto.
• Disponibilidad limitada de recursos. El proceso proyectual implica la
búsqueda de la eficiencia en el uso de los recursos para obtener el
resultado perseguido. Si los recursos son ilimitados, desaparece el
concepto de eficiencia y con él la naturaleza proyectual de las
actividades.
• Limitación de tiempo. Un proyecto debe estar acotado en términos del
principio y el fin mismo. El final de un proyecto se alcanza cuando se
cumplen los objetivos pre- fijados, o cuando se hace evidente que dichos
objetivos no pueden alcanzarse (fracaso del proyecto). Por otro lado,
aunque el proyecto tenga que estar acotado en el tiempo, no sucede lo
mismo con sus resultados, que pueden perdurar con carácter indefinido
(por ejemplo, una catedral).
Así, se puede llegar a decir que los proyectos se caracterizan en general por:
• Tener objetivos específicos;

• Deben completarse dentro de un periodo determinado;
• Tener inicios y términos bien definidos;
• Deben completarse dentro de las restricciones de un presupuesto;
• Ser ejecutados por un equipo; y,
• Ser únicos.
1.2.1 Definición
Las acepciones previas pueden considerarse extremas dentro de un amplio

abanico de definiciones de 'proyecto'. Por tanto, la pregunta es: ¿qué es un
proyecto?
Esta pregunta ha llevado a diversas definiciones, o más bien, formas en que se

entiende un proyecto, todas ellas válidas, cuyo conocimiento permite mostrar
visiones sesgadas de un mismo fenómeno.
- Es un esfuerzo conjunto de muchas personas -hombres y mujeres- que

buscan el máximo beneficio en conseguir una solución razonable a un
problema que se espera tenga la solución ideal.
- El proyecto es una operación que se expresa como una experiencia práctica

cooperativa y colaborativa en la cual:
- se usan conceptos abstractos (por estar en dominios de conocimiento

transversales) junto a conceptos técnicos (por estar en dominios aplicados
concretos) que se manifiestan en documentos (por ser medio de expresión
natural y persistente de las personas).
4
- Es el conjunto de acciones destinadas a resolver o vulnerar un problema ya

identificado, priorizado y explicado en el momento de investigación de
problemas críticos.
- Es un conjunto autónomo de inversiones, políticas y medidas institucionales y

de otra índole, diseñadas para lograr un objetivo específico (o serie de
objetivos). Se puede definir como un modelo para las asignaciones de
recursos, que tienen un tiempo de ejecución y se logran resultados medibles.
También se identifica, como la menor unidad de actividades, que puede ser
planificada y ejecutada aisladamente de la planificación de operación y
sostenimiento de los servicios de Salud. Constituye la unidad operativa más
pequeña que desde el punto de vista lógico, se presta para la planificación, el
financiamiento y la ejecución como unidad independiente dentro de un plan o
programa de desarrollo local.
- Es un proceso para obtener recursos, destinado a convertir una idea surgida

de los planes nacionales, de las necesidades locales e institucionales y de las
situaciones de emergencia, con el fin de frenar el deterioro o continuar el
desarrollo de los servicios sociales.
- Es un conjunto específico de actividades en las que se invierten escasos

recursos con la esperanza de obtener beneficios.
- Es el conjunto de acciones o actividades que se realiza a partir de una

situación actual para obtener una situación futura o esperada.
- Es la unidad operativa más pequeña que puede ser ejecutada en forma

independiente o autónoma, constituida por un conjunto de actividades o tareas
encadenadas en un orden lógico, destinadas a cumplir un fin específico a
incidir en la magnitud de una o más variables, determinada por la realidad a la
que se orienta.
- Es una información estructurada con valor agregado que permite la

articulación de recursos humanos de diferentes estructuras de la organización y
de diferentes disciplinas y funciones.
- Es una empresa planificada con un conjunto de actividades para alcanzar un

objetivo, con un presupuesto y un tiempo previamente determinado, que como
la mayoría de los procesos humanos tiene carácter cíclico, y la clave de su
dinámica es la transformación de la realidad y el avanzar hacia un estadio
superior del desarrollo.
- Es un proceso cuyo objetivo es transformar una idea en un producto

terminado, constituido por bienes o servicios que serán los medios para
producir otros bienes o servicios, y consta de 3 características fundamentales:
- Es un proceso finito, es decir, que se cuenta con un período de tiempo

determinado para alcanzar el objetivo.
- Cuenta con un presupuesto preestablecido para alcanzar el objetivo.
5
- Es un proceso único (no repetitivo) en que las actividades van ligadas por
requerimientos de secuencias y por tanto en cada etapa las actividades son
diferentes.
- Es un conjunto no vacío de tareas estructuradas, que se desarrollan en un

plazo de tiempo finito y acotado, con objetivos bien definidos acordes con su
misión y que se alcanzan con la integración de las soluciones parciales de las
tareas, a partir de un diseño con enfoque sistémico y en función de la visión, en
el que se combinan los recursos con criterios de optimización, de acuerdo con
sus requerimientos y restricciones, tomando en cuenta y evaluando los riesgos.
- Es un proceso único, consistente en un conjunto de actividades controladas,

con fecha de inicio y finalización, llevadas a cabo para lograr un objetivo
conforme con requisitos específicos, incluidas las limitaciones de tiempo, costo
y recursos.
- El proyecto es una operación de ingeniería que involucra pasar de un sistema

deseado a un sistema a ofrecer (ver figura 1.3), lo cual implica:
- ir de una idea inmaterial y difusa proveniente de un problema o necesidad a

un ordenamiento técnico formal y estructurado de tareas que regulan las
acciones de hombres y mujeres para conseguir objetivos predeterminados.
Estas definiciones incluyen varios atributos (ver figura 1.2) pero es mejor
agrupar estas definiciones en dos grupos:
• Proyecto como producción de artefactos; y,

• Proyecto de acción.
Figura 1.2: Atributos principales asociados a la definición de proyecto.
6
Figura 1.3: Generalización del concepto de Proyecto.
a. Producción de artefactos
Un proyecto se comprende habitualmente como un medio para obtener un

artefacto, un resultado material concreto. De entre las múltiples definiciones
que plantea el proyecto en estos términos, es posible distinguir dos acepciones,
ambas similares, pero apuntando a distintas finalidades según quien tiene la
misión de dirigirles. Así se puede hablar de:
- Proyecto como programa a seguir. En este caso el 'proyecto' es

equivalente a cumplir plazos y fechas, y entregar documentación.
- Proyecto (según el Diccionario de la Lengua Española de la Real Academia

Española):
"Planta y disposición que se forma para un tratado, o para la ejecución de una

cosa de importancia, anotando y extendiendo todas las circunstancias
principales que deben concurrir para su logro".
- Projecte, según el Diccionari de la Llengua Catalana del Intitut d'Estudis

Catalans, es:
"Allò que hom pensa portar a acompliment; pla propossat per a realitzar-ho;
estudi detallat d'una cosa realitzar".
- Project (según el Diccionario Oxford):
"Hacer planes para ('Make plans for')".
- Proyecto como consecución de objetivos. En este caso el 'proyecto' es

equivalente a alcanzar objetivos.
- Para Ribera:
"Un proyecto es una secuencia única de actividades complejas e

interconectadas que tienen un objetivo o propósito que debe ser alcanzado en
7
un plazo establecido, dentro de un presupuesto y de acuerdo con unas

especificaciones".
- Según el Project Management Institute:
"Un proyecto es un esfuerzo temporario realizado para crear un producto,

servicio o resultado único." ('A Project is a temporary endeavor undertaken to
create a unique product, service, or result'.)
- Según Jurison:
"Ensamblaje de recursos para solucionar un problema de un determinado tipo

('Assemblage of resources to solve a one-of-a-kind problem')".
b. Proyecto de acción
En un proyecto de acción el fin no es producir un artefacto, sino encontrarlo y

definirlo. En este caso, existe una componente de aprendizaje para, 'aprender'
a resolver problemas.
- Proyecto, para Blasco, es:
"La operación de ingeniería que nos lleva a conseguir un objetivo material

predeterminado por modificación de la realidad exterior mediante unas
acciones humanas que han sido seleccionadas y ordenadas con anticipación
de acuerdo con unos criterios".
- Para Dahlbom y Mathiassen, proyecto es una acción donde se:
- se interviene, debido al cambio en el entorno que se produce por la propia

existencia del proyecto como por el resultado que se genera y se pone en el
medio;
- se evoluciona, debido a buscar la solución de un problema que no es fijo ni

estable, sino que se va dando conforme el proyecto está en ejecución; y,
- se construye, por desarrollar una solución técnica que es la respuesta a un

problema.
1.2.2 Tipología de proyectos
Las visiones previas muestran que un proyecto involucra dos proyectos de

enunciado teórico: proyecto para construcción de artefactos y proyecto de
acción, cada uno de los cuales, según su relevancia y su grado integración
mutuo, han llevado a que clasificar un proyecto no sea una labor sencilla. Más
bien es una labor compleja, pues su variedad y diversidad es alta. Sin
embargo, es posible sugerir una tipología general dependiendo de algunos
criterios.
La tipología general aquí presentada utiliza criterios de distinción:
8
• Por objeto, o por el objeto que esta tratando el proyecto;

• Por actividad, o dependiendo de alguna fase en el ciclo de vida de un
producto;
• Por rol del usuario, por el contexto en el cual se desarrolla el proyecto;
• Por campo de ingeniería, o por la disciplina, ciencia y/o técnica que
predomina en el proyecto;
• Por naturaleza del resultado, o por el tipo de producto a obtener.
1.2.2.1 Taxonomía de proyectos
Debe aclararse que estos criterios ni son todos ni son determinantes.
a. Por objeto
- Proyecto clásico. Se aborda la realización de una serie de documentos que

define la obra o trabajo a realizar para su ejecución en un futuro. El alcance
comprende la identificación, evaluación, organización y valoración de las
actividades que faltan para conseguir o culminar el resultado perseguido, pero
en su alcance no está comprometida la realización de las mismas. El resultado
es una memoria, unos planos, un pliego de condiciones y un presupuesto y, a
lo sumo, un prototipo o maqueta del objeto en cuestión.
- Proyecto de investigación. Su objetivo es aportar en su conclusión un

conjunto de conocimientos nuevos en una disciplina y materia concreta, a
menudo desconocida al comienzo de los trabajos. Su fin es que otros se vean
beneficiados, sea en entornos industriales o académicos. El resultado es una
memoria de investigación donde, aparte del planteamiento del problema a
resolver y la descripción del estado del arte, se reseñan los trabajos realizados,
los resultados de los mismos y las conclusiones pertinentes, junto con las
líneas de investigación futuras propuestas en esa disciplina concreta.
b. Por actividad
- Estudios y análisis. En ocasiones el alcance de un trabajo concreto se limita

a analizar o estudiar la información disponible acerca de los aspectos técnicos,
económicos, ambientales y sociales de un determinado problema. En este caso
el proyecto recibe el nombre de estudio (comprensión o conocimiento del
problema o análisis (examen del problema para comprender los principios del
mismo).
- Estudios de viabilidad. Los estudios de viabilidad deben proporcionar la

base- técnica, económica y comercial para la decisión de invertir en un
proyecto industrial. En estos estudios se deben definir y analizar los elementos
críticos relacionados con la fabricación de un producto dado, junto con otros
enfoques posibles a tal producción. Un estudio de este tipo debe dar por
resultado un proyecto con capacidad de producción definida en un
emplazamiento seleccionado, utilizando una o varias tecnologías determinadas
en relación con materiales e insumos específicos con costes de inversión y
producción identificados, e ingresos por concepto de ventas que produzcan un
rendimiento determinado respecto de la inversión.
9
c. Por rol del usuario
- Proyecto externo. Los proyectos externos a la organización son aquellos en

los que el cliente es ajeno a la empresa, que hace los trabajos. Se rige
fundamentalmente por criterios de mercado, incluyendo competitividad y
eficacia.
- Proyecto interno. Los proyectos internos a la organización, son aquellos en

los que el cliente es de la misma empresa que desarrolla los trabajos.
d. Por campo de ingeniería
Por campo de ingeniería, se tienen proyectos diversos:
- Productos naturales. Ingeniería agronómica, oceanográfica, forestal y

minera. La obtención de productos naturales requiere unos proyectos muy en
contacto con el medio que se va a tratar, con mucho trabajo de campo y la
necesidad de un gran soporte documental, pero con escasa interrelación entre
los equipos y máquinas necesarios, lo que evita la necesidad de una definición
minuciosa de los mismos que condicione las fases posteriores del trabajo.
- Infraestructuras y edificaciones. Ingeniería civil, construcción. La

construcción de infraestructuras y edificaciones de todo tipo se apoya en
disciplinas fundamentales como topografía, geotecnia y resistencia de
materiales, y exige proyectos detallados con profusión de cálculos y planos,
pero cuya ejecución es prácticamente independiente, en el tiempo, de los
documentos que configuran el proyecto.
- Productos manufacturados. Ingeniería industrial, mecánica, electrónica,

automática, química, aeronáutica, naval. Los productos manufacturados exigen
unos proyectos muy complejos, con muchas disciplinas implicadas y
numerosos equipos, máquinas y aparatos interconectados, que exigen gran
atención y abundantes especificaciones.
- Servicios/sistemas ligados a ingeniería eléctrica, energía,

telecomunicación, informática. En este caso hablamos de productos cuya
esencia es intangible, por su naturaleza inmaterial que dificulta su manipulación
corpórea.
e. Por naturaleza del resultado
- Proyecto de ingeniería. En este caso estamos ante un proyecto de acción,

donde esencialmente se persigue resolver un conflicto definiendo cual sería el
potencial sistema solución.
- Proyecto industrial. A diferencia de los proyectos clásicos, los proyectos

industriales comienzan y terminan en sí mismos, dando lugar a un producto o
servicio terminado (sin que ello sea obstáculo para que otros proyectos
comiéncen posteriormente desde los resultados del primero). Involucra una
planificación en la ejecución de actividades orientadas a un fin concreto (el bien
10
o servicio) por lo que una vez finalizado el mismo, la replicación de los

resultados no constituiría un proyecto en sí mismo.
Este tipo de proyectos, por su relevancia y generalidad se detallan a

continuación.
1.2.2.2 Proyectos a destacar
a.- Proyecto de ingeniería
Por su relevancia, en este apartado se profundiza en los proyectos de

ingeniería. Los Proyectos de Ingeniería tienen una serie de características
comunes que se citan a continuación:
• Complejidad. Una serie de factores, como el trabajo requerido para su

realización, el tamaño de la inversión, todo el tiempo necesario para
llevarlo a cabo más las importantes responsabilidades que van
asociadas a ello hacen complejo un proyecto de ingeniería. Por su
enorme complejidad es preferible dividirlo en partes mucho más
pequeñas que pueden ser estudiadas más profundamente.
• Integrabilidad. La mayoría de los proyectos que se realizan en la
actualidad se caracterizan por la necesidad de cubrir todas las etapas
desde el principio (proyectos completos o integrales), cuando sólo existe
una idea de algo que queremos materializar hasta el final, cuando se ha
transformado en una realidad. No obstante, a veces se tiene la
impresión que se suprimen algunas etapas intermedias. Esto no es del
todo cierto, lo que ocurre simplemente es que se utilizan otras vías,
recurriendo a informaciones ya existentes o simplificaciones.
• Multidisciplinariedad. Los proyectos que a veces se llevan a cabo son
de tal envergadura que se necesita un amplio equipo de profesionales
cada uno de ellos expertos en una disciplina, con amplios conocimientos
técnicos. Por ello, una tercera característica para proyectos de ingeniería
complejos e integrales es la disponibilidad de conocimientos
multidisciplinares.
b.- Proyecto industrial
Los proyectos industriales se diferencian de los otros en la menor importancia

que se atribuye a las características del terreno donde se localiza desde el
punto de vista técnico, además se exige una definición precisa de todos los
equipos y máquinas que componen el sistema de producción. En este tipo de
proyectos la fase documental se puede desarrollar independientemente de
equipos y máquinas hasta un determinado momento, pero a partir del cual es
imprescindible la definición y selección de éstos. Los equipos y máquinas
pueden quedar obsoletos o sufrir variaciones importantes en sus costes o
prestaciones.
Una clasificación bastante representativa de los proyectos industriales, con

independencia de su origen, podría ser:
11
- Grandes proyectos de inversión. Realmente este tipo no se puede

considerar un proyecto, sino más bien es un estudio económico que lo
acompaña, tanto desde el punto de vista de la demanda prevista como de los
costes de producción y de sus consecuencias sociales y políticas: creación de
empleo, desarrollo regional, etcétera. Dependiendo de sus resultados indica si
el proyecto tiene o no futuro en el mercado. Si sus resultados son negativos,
los proyectos suelen morir sin ver la luz y si son positivos, se utilizan como
base para las posteriores etapas del proyecto, que habitualmente implica
grandes inversiones.
- Instalaciones y plantas industriales. La realización de estos proyectos

constituye el capítulo más amplio e importante dentro de la ingeniería industrial
y para ello es necesario la construcción de plantas e instalaciones, que
constituye un proyecto completo con todas sus fases y aspectos.
Los sectores, instalaciones y plantas más típicos son los que se enumeran a
continuación:
- Industria electrónica.
- Robótica y automática.
- Industria de transformación.
- Plantas de proceso (refinerías, petroquímicas, fertilizantes, química

inorgánica).
- Industria de la alimentación.
- Farmacia.
- Pasta, papel y cartón.
- Cemento.
- Centrales eléctricas (hidráulicas, térmicas, nucleares).
- Siderurgia y metalurgia.
- Industria aeronáutica y espacial.
- Industria naval.
- Líneas y unidades de producción.
- Unidades y líneas de producción. El estudio y diseño de las unidades y

líneas de producción de los edificios e instalaciones que forman las grandes
plantas industriales constituyen por sí mismos proyectos independientes que,
en muchas ocasiones están interconectados.
12
- Máquinas, equipos y sus elementos. El estudio de las máquinas y equipos

que forman parte de cualquier instalación industrial, e incluso algunos
elementos de éstos constituyen también por sí mismos un proyecto.
Otra clasificación de los proyectos industriales podría ser: según la naturaleza

del proyecto (especialidad), el volumen de la inversión, el objeto del proyecto y
el proceso que utiliza.
- Por la naturaleza del proyecto. Por su naturaleza o especialidad, hay que

recurrir a la clasificación de los distintos sectores industriales. Esta clasificación
coincide con la lista enumerada anteriormente en el punto "instalaciones y
plantas industriales".
- Por el volumen de la inversión.
- Pequeño.
- Mediano.
- Grande.
- Por el objeto del proyecto.
- Nueva instalación.
- Ampliación (Modificaciones de proceso, Nuevas líneas, Nuevos productos,

Cuellos de botella).
- Mejora:
- Económica: Aumento de calidad, Reducción de costes.
- Social: Seguridad, Protección ambiental.
- Mantenimiento.
- Traslado.
- Por el proceso que utiliza.
- Su naturaleza (mecánico, físico, físico-químico).
- Su origen (propio, de terceros).
- Propietario del proceso.
- Empresa de ingeniería licenciada.
- Suministradores de equipos principales.
13
1.3 Teoría de proyectos

Quienes estudian los 'proyectos' han distinguido que existe un inmenso mar de
aportaciones teóricas y prácticas las cuales pueden clasificarse en tres tipos:
teóricas, metodológicas y aplicaciones.
• Herramientas. Aquí se distinguen, por ejemplo, algunos software como

MS Project, técnicas de diseño como QFD o de diagramación como los
flujogramas, y herramientas de evaluación económica.
• Metodologías. Se consideran aquí diversos planteamientos
metodológicos o métodos de índole general para Project Management y
Dirección de Proyectos o métodos más específicos de ejecución de
proyectos, como las metodologías de desarrollos de sistemas de
información.
• Teorías. Grupo donde se aglutinan las aportaciones más abstractas y
conceptuales, que intentan dar un marco integrador a las herramientas y
metodologías.
a. Teoría de Proyectos
Una Teoría de Proyectos es un núcleo de bases teóricas y conceptuales con

las cuales se sostiene un punto de vista particular respecto de lo que es un
proyecto. El fin de una Teoría de Proyectos es fortalecer y mejorar el aspecto
práctico.
Una de estas teorías es la formulada por Blasco, quien usa un punto de vista
de sistemas par explicar un proyecto. Según esta teoría, en un proyecto
pueden distinguirse dos tipos de subsistemas conceptuales.
b. Subsistemas conceptuales
El proyecto es un sistema dentro del cual se intenta conseguir la solución a un

conflicto. Esta solución se consigue gracias a la presencia en un tiempo y en
espacio común y bien definidos dos subsistemas de naturaleza conceptual más
que real:
- El sistema proyectar destinado a encontrar la solución.
- El sistema proyectado que será la solución al conflicto.
En ambos sistemas se manifiestan actividades mentales y de trabajo físico

(materiales), tanto para tomar decisiones como para ir construyendo la
solución. Estas actividades pueden usarse para varios fines, dando lugar así a
dos distinciones importantes en un proyecto: los subproyectos y las
dimensiones.
c. Subproyectos
14
En un sistema proyecto las actividades mentales y materiales se pueden usar

para tareas de resolución de un problema, con lo cual se da lugar a:
- Un proyecto de acción. Aquí se habla del designing, el proceso creativo de

encontrar la solución con actividades creativas como el brainstorming y con
actividades de trabajo físico como la generación de diagramas.
- Un proyecto productor del artefacto (o la solución). Aquí se habla del proyecto

técnico, el proceso de concretar la solución, en la cual se incluyen actividades
creativas como la división funcional del producto en un Work Breakdown
Structure (WBS) y como actividad física la construcción de una maqueta o el
mismo artefacto.
d. Dimensiones
Cuando las actividades mentales y materiales se agrupan para distinguir

labores de administración y de construcción, se tienen dos dimensiones, una
de gestión y otra de construcción. En este caso, la literatura habla de procesos
de gestión de proyectos y de procesos orientados al producto.
- Los Procesos de Gestión de Proyectos describen, organizan y ayudan a

completar el trabajo de un proyecto.
- Los Procesos Orientados al Producto especifican y crean el producto o

servicio del proyecto. Este tipo de proceso se define por el ciclo de vida de un
proyecto y varía por área de aplicación.
No existe una relación clara estos dos tipos de procesos, depende de cada
proyecto. Lo habitual es intentar hacer un paralelismo entre ellos, no obstante,
en proyectos grandes, cada fase de construcción se gestiona como un
proyecto.
1.4 Teoría del proyecto tecnológico

Teóricamente, un proyecto tecnológico no es distinto de cualquier otro, salvo en
su objeto: un cambio organizacional que afecta el ámbito de negocios por la
influencia y uso conveniente y oportuno de las tecnologías de la información.
Y, como tal, la operación de un proyecto de e-Business comprende la ejecución

de una serie de actividades de gestión y de construcción tendientes a proveer
una determinada solución tecnológica a una estrategia de negocios.
Este planteamiento teórico y operacional de un proyecto e-Business muestra la

multi- dimensionalidad de este tipo de proyectos, reflejado en la figura 1.4. En
un proyecto e-Business distinguimos la concurrencia de:
• Dos dimensiones: la dimensión de gestión y la dimensión de

construcción.
• Dos visiones: visión de negocios y la visión tecnológica.
15
Figura 1.4: Elementos en un proyecto e-Business.
Según esto último, en el proyecto e-Business concurren una serie de

conocimientos. La figura 1.5 destaca los tipos de conocimientos a considerar:
Figura 1.5: El proyecto e-Business.
16
De esta manera, las dimensiones permiten construir la iniciativa o solución

tecnológica en una organización (figura 1.6) como un conjunto de aplicaciones
de base tecnológica (figura 1.7), operando dentro de los sistemas de trabajo
bajo una óptica de negocios y tecnológica.
Figura 1.6: La solución e-Business.
Figura 1.7: Alcance de aplicaciones e-Business.
1.4.1 Visión de negocios y tecnológica
De una u otra manera, un proyecto e-Business comprende una visión de

manejo integrado de la información organizacional, cuya puesta en escena
puede abordarse como un proyecto de sistemas de información. En este caso
se distingue la visión de negocios y la visión tecnológica.
• La visión de negocios aporta e introduce el marco organizacional y

estratégico dentro del cual se enmarca todo el proyecto e-Business, vale
decir, es la visión que sostiene la iniciativa o solución tecnológica. La
17
implantación de esta visión se traduce en un proyecto de negocios,

entendido como todo el proceso gracias al cual una idea de negocios se
concreta.
• La visión tecnológica aporta al proyecto tecnológico un habilitador y un
facilitador tecnológico. Por ejemplo, en un proyecto e-Business, la visión
tecnológica aporta elementos, tanto para el propio proyecto (por
ejemplo, herramientas para un e-Project donde usar desarrollos RAD
cuya gestión se sustenta en un software MS project) como para la
solución e-Business (Internet, redes WAN, etc.).
1.4.2 Dimensiones de gestión y de construcción
Como todo proyecto, un proyecto e-Business requiere identificar una dimensión

de gestión y otra de construcción.
• La gestión del proyecto aporta un conjunto de instrumentos que permiten

conseguir los objetivos de un proyecto cualquiera. Como parte de la
gestión, se debe considerar la visión de negocios y la utilización de
tecnología.
• La construcción del proyecto, expresada de mejor manera como la
metodología de un proyecto e-Business, permite conducir el proyecto
integrando la visión de negocios que lidera la idea organizacional y la
visión tecnológica que sustenta la estrategia de negocios.
Capítulo 2.- Gestión de proyectos
OBJETIVOS
- Comprender la noción de proyectos y el rol que ocupa el PMBOK en la constitución de un

cuerpo doctrinal internacional de gestión de proyectos.
- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de

proyectos.
- Conocer el rol de los modelos de madurez de gestión de proyectos y comprender la

importancia del aprendizaje incremental de prácticas de gestión.
2.1 Introducción
Gestión de Proyectos es una dimensión dentro de un proyecto y no es en sí el
proyecto (figura 2.1). Esto muestra, por una parte, la dependencia de la
gestión de proyecto al tipo de proyecto dentro del cual participa y, por otra
parte, la existencia de una serie de limitaciones debidas a la existencia y
oportunidad de determinados recursos, imposiciones y condiciones del medio,
18
y compromisos y restricciones organizacionales. Todo en su conjunto produce

un paquete de documentación, el cual contiene y refleja la historia del proyecto
en todas las áreas en que se haya desenvuelto, y la evolución del resultado
finalmente obtenido con la metodología de e-Business.
Figura 2.1: La gestión de proyectos en un proyecto.
En particular, la gestión de proyectos para un proyecto e-Business se enfoca

en buscar un marco estructurado para la gestión exitosa, buscando aportar un
completo conjunto de herramientas y técnicas para integrar la propia filosofía e-
Business, la gestión de proyectos, la calidad y el desarrollo de sistemas
informáticos en un todo coherente.
Por este motivo este capítulo parte revisando la noción de gestión de proyectos
según los diversos tipos de proyectos considerados en el capítulo anterior para
introducirse luego en mostrar la guía PMBOK, documento estándar
internacional sobre el tema.
Por último, se revisan una serie de modelos de madurez de gestión de

proyectos, los cuales permiten tener un marco de referencia que ayuda a
superar la falta de habilidades y competencia y además un medio de ir
mejorando la calidad en gestión de proyectos.
2.2 Noción de gestión de proyectos

Gestión de Proyectos es una dimensión dentro de un proyecto y no es en sí el
proyecto. Por ello es conveniente revisar de qué manera el proyecto
englobador cambia la visión a tener respecto de cómo usar la gestión de
proyectos.
La gestión de proyectos intenta conseguir una planificación coherente con los

objetivos de una organización y del propio proyecto, igualmente que el
desarrollo del proyecto se acerque a lo planificado y supere las vicisitudes del
medio y del día a día.
19
Se encarga de planificar, dirigir y controlar el desarrollo de un sistema

aceptable con un costo mínimo y dentro de un período de tiempo especifico.
Como una manera de proveer un lenguaje universal y común entre los

profesionales de proyectos, el Project Management Institute ha desarrollado el
PMBOK, un documento con el cual se espera que la práctica de gestión de
proyectos se convierta en un cuerpo doctrinal y referencial para los
profesionales del área. Por esta razón se presenta la gestión de proyectos
desde el punto de vista del PMBOK.
En el capítulo 1 se planteó que el concepto de proyectos difiere según diversas

visiones, además que un proyecto es un sistema dentro del cual coexisten dos
dimensiones, la de gestión y la de construcción. Según esto, la gestión de
proyectos es un sistema que debe construirse y ser adaptado al punto de vista
de proyecto que se maneje.
• Proyecto como producción de artefactos. Aquí por gestión se

entiende la programación de actividades y ver que se cumplan.
• Proyecto como consecución de objetivos. Aquí el proyecto es un
conjunto de actividades concretas para un determinado resultado, y la
gestión intenta que tales actividades cumplan con las necesidades
presupuestas de antemano, siendo en esencia una anticipación a un
objetivo o a un estado de realidades predefinidas.
• Proyecto de acción. Aquí el proyecto persigue finalidades, sin
necesidad de seguir un plan de trabajo. El proyecto es actuar siguiendo
finalidades o fines y la gestión es poder anticiparse a las
transformaciones o cambios de estado del proyecto y del entorno que se
producen conforme la finalidad se va alcanzando o alejando.
Para ilustrar las diferencias entre el tipo de gestión de proyectos que uno u otro
tipo de proyecto requiera, se puede decir lo siguiente:
20
• en los primeros dos casos, el gestor de proyectos parte de que conoce

qué conseguir y para ello busca y se nutre de varios cómos, cuándos,
quiénes y cuántos; y,
• en el último caso, el gestor de proyectos debe ayudar a buscar el qué se
desea, para lo cual dispone de varios cómos que le ayudan a conseguir
el qué.
Sin embargo, aceptando cierto grado de formalización respecto de la gestión

de proyectos asociada al proyecto como productor de artefactos, debido a que
es más sencillo controlar y regular recursos respecto cuando hay una meta
clara, que cuando ella no existe (en este caso la meta es conseguir una meta),
Kerzner sugiere que gestión de proyectos es 'la planificación, organización,
dirección y control de los recursos de una empresa para un objetivo de relativo
corto plazo que ha sido establecido para completar y conseguir metas y
objetivos específicos'.
Siguiendo con esta primera acepción, Kirsch señala que gestión de proyectos
es la aplicación de técnicas, métodos, herramientas y heurísticas formales e
informales, las cuales emplea un gestor de proyectos en la motivación y guía
de un equipo de personas para llevar un proyecto dentro de un conjunto dado
de restricciones.
Visto así, la gestión de proyectos pone a disposición de los gestores de

proyectos un conjunto de instrumentos de trabajo que le permiten asumir un
proyecto y superar sus vicisitudes tal que: se anticipe a los problemas, mejore
el hacer futuro, y actúe de forma adecuada ante eventos no presupuestados.
En todo caso, debe tenerse claro que la gestión de proyectos es un medio a

disposición del gestor para construir una solución dentro de las mejores
condiciones para quienes están dentro del proyecto y para quienes se
beneficiarán del uso del producto o servicio resultante.
Por este motivo, el gestor de proyectos es una persona cuyo fin es hacer uso
armonioso de una serie de recursos intelectuales (conocimiento, creatividad) y
corpóreos (trabajo físico, esfuerzo mental), con especial cuidado y atención a
las personas. Es una labor donde especialistas actúan con libertad como parte
de un todo (figura 2.2).
21
Figura 2.2: El fin de la gestión del proyecto.
El gestor de proyectos se destaca como la figura clave en la planificación,

ejecución y control del proyecto y es el motor que ha de impulsar el avance del
mismo mediante la toma de decisiones tendentes a la consecución de los
objetivos. El gestor de proyectos es un verdadero jefe, es decir, tiene poder
ejecutivo y autoridad para mandar y tomar decisiones dentro del ámbito y
objetivos del proyecto. No es un mero coordinador o animador, como en
algunas ocasiones se piensa. De la misma forma, tampoco sería correcto
pensar que el gestor de proyectos tiene un poder absoluto y dictatorial sobre el
mismo, ya que se encuentra inmerso en la estructura y organización de la
empresa.
Las relaciones básicas del gestor de proyectos con otras unidades o personas
dependen, en gran medida, de la estructura organizativa que posea la
organización (figura 2.3).
22
Figura 2.3: El fin de la gestión del proyecto.
Generalizando un poco, la gestión de proyectos se debe entender como un

cúmulo de información sobre instrumentos y prácticas que se pone a
disposición de personas para hacer un uso óptimo y robusto de recursos bajo
su responsabilidad frente a restricciones y contingencias para el cumplimiento
de metas trazadas de antemano. Todo lo anterior relacionado con tres
parámetros clásicos de gestión: tiempo, coste y desempeño, para mejorar la
calidad y conseguir un riesgo cero.
No obstante, el valor agregado de esta información dependerá de la utilidad

que le otorgue el gestor del proyecto: conseguir lo que se le pide, resolver un
conflicto, aprender del hacer haciendo y, salir airoso de las vicisitudes diarias.
Esto dependerá de la habilidad que adquiera, tanto por capacidad personal
como resultado de un proceso de formacional.
Por último, existe el caso de una gestión orientada a dar un valor especial al
gestor como evaluador de opciones futuras, tal como se ilustra en la figura 2.4,
ante vicisitudes.
23
Figura 2.4: La gestión y sus vicisitudes.
2.3 La gestión de proyectos según el

PMBOK
La forma de organizar los esfuerzos y experiencia de gestión de proyectos se
han llevado adelante mediante el arte de las personas en el rol de gestor de un
proyecto o varios (programa). Organizar todo aquello en un cuerpo doctrinal
formal se ha visto dificultado por dos razones:
• No se ha manifestado un cuerpo o núcleo central al cual ceñirse los

gestores para recabar experiencias y tener un dominio común de
discusión.
• La gestión de proyectos es cultural, pues depende de las características
y singularidades del grupo de personas que constituye y se relaciona
con el proyecto.
24
Estas razones han hecho que hoy en día existan diversas asociaciones
dedicadas al estudio de proyectos tales como:
• AEIPRO. Asociación Española de Ingeniería de Proyectos.

• AFITEP. Association Francophone de Management de Project.
• IPMA. International Project Management Association.
• PMI. Project Management Institute.
• SMP. Société suisse de Management de Project.
Project Management Institute. El Project Management Institute (PMI) es una

organización internacional orientada a la difusión y determinación de las
mejores prácticas de gestión de proyectos. En este afán, produce documentos
que describen prácticas generalmente aceptadas de gestión de proyectos.
PMBOK. El más importante de los documentos publicados en la actualidad por

el PMI es el PMBOK, A Guide to the Project Management Body of Knowledge.
El propósito de esta guía es describir el conocimiento y las prácticas usadas en

varios tipos de proyectos. Durante veinte años se han estado revisando y
discutiendo cuáles son los proyectos cuyo conocimiento y estudio aporta valor
y utilidad a la práctica de proyectos. Este esfuerzo se ha traducido en identificar
prácticas de gestión de proyectos generalmente reconocidas como buenas
prácticas, aplicables a la mayoría de proyectos, la mayoría del tiempo.
La importancia del PMBOK, por sobre toda compilación y mejora de prácticas,

es que provee una base formal para fundar proyectos, guiando y orientando a
gestores de proyectos sobre la forma de llevar adelante la construcción de
resultados. Para ello, no obstante, es menester adaptar los contenidos del
PMBOK al dominio técnico de cada proyecto en particular. Cada equipo de
trabajo será responsable de determinar la utilidad del contenido de esta guía
para cada proyecto asignado.
Gracias al Programa de Estándares para Gestión de Proyectos promovido por

el Project Management Institute, el PMI es reconocido por el ANSI (American
National Standards Institute) como una institución desarrolladora de
estándares. Además, el PMBOK actualmente es el estándar ANSI/PMI 99-001-
2004 aprobado por el ANSI, es reconocido como estándar por el IEEE (Institute
of Electrical and Electronical Engineerings) y sirve como referencia para el
manejo de proyectos informáticos para la ISO (International Organization for
Estandarization). Esto hace pensar que las prácticas incluidas en el PMBOK
son bien aceptadas a nivel mundial, y su utilidad se refleja en cualquier ámbito.
Gestión de proyectos según el PMBOK. Según el PMBOK, gestión de

proyectos es la aplicación de conocimiento, herramientas y técnicas a
actividades de un proyecto con el fin de satisfacer los requerimientos del
proyecto. Todo este conocimiento, habilidades, herramientas y técnicas se
distribuye y usa a lo largo de varios procesos de gestión de proyectos.
25
Cada proceso de Gestión de Proyectos pertenece a un Área de Conocimiento

de Gestión de Procesos y se asocia a un Grupo de Procesos de Gestión
(figura 2.5).
Figura 2.5: Componentes del PMBOK y sus relaciones.
El gestor del proyecto es la persona responsable de cumplir con los objetivos

del proyecto. Para lograrlo, es necesario ejecutar las siguientes actividades:
• Identificar requerimientos.
• Establecer objetivos claros y verdaderamente logrables.
• Equilibrar las demandas de calidad, alcance, tiempo y coste.
• Adaptar las especificaciones, planes, y enfoque de acuerdo a las
diversas preocupaciones y expectativas de las personas implicadas en
el proyecto.
2.3.1 Áreas de conocimiento de gestión de proyectos
Las nueve áreas de conocimiento, Project Management Knowledge Areas, se

describen en la tabla 2.1.
ÁREAS DE
DESCRIPCIÓN
CONOCIMIENTO
#4. Gestión de la Incluye los procesos requeridos para asegurar que todos los
Integración elementos del proyecto son coordinados adecuadamente.
Incluye los procesos requeridos para asegurar que el proyecto abarca

#5. Gestión del
y considera solamente el trabajo necesario para completar el proyecto
Alcance
satisfactoriamente.
Incluye los procesos requeridos para asegurar el término temporal

#6. Gestión del Tiempo
preciso y adecuado del proyecto.
Incluye los procesos requeridos para asegurar que el proyecto se

#7. Gestión del Coste
concluye dentro del presupuesto aprobado.
#8. Gestión de la Incluye los procesos requeridos para asegurar que el proyecto
Calidad satisface las necesidades para las cuales fue definido.
#9. Gestión de Incluye los procesos requeridos para organizar y administrar los
Recursos Humanos equipos de trabajo para el proyecto.
Incluye los procesos requeridos para asegurar una generación,

#10. Gestión de las
recolección, diseminación, almacenamiento y disposición final en
Comunicaciones
tiempo y de forma apropiada, de la información del proyecto.
26
#11. Gestión del Incluye los procesos requeridos para identificar, analizar y responder
Riesgo a los riesgos del proyecto.
Incluye los procesos requeridos para adquirir los bienes y servicios

#12. Gestión del
que el proyecto necesita e incluye además procesos de
Abastecimiento
administración de contratos.
Tabla 2.1. Áreas de conocimiento de gestión de proyectos.
Figura 2.6: Vista general de Áreas de Conocimiento y Procesos de Gestión.
a.- Gestión de la integración
La gestión de integración del proyecto incluye los procesos y actividades

requeridos para asegurar que los diferentes elementos del proyecto son
coordinados adecuadamente. Se ocupa de encontrar el equilibrio entre los
objetivos posibles y sus alternativas, con el fin de satisfacer o colmar las
necesidades y expectativas de las entidades involucradas en el proyecto.
Mientras que todos los procesos de dirección de proyectos son de alguna
forma integradores, los de esta área lo son de manera fundamental. La figura
2.7 proporciona una visión general de los siguientes principales procesos.
La Integración implica tomar decisiones con respecto a la cantidad y el

momento en que se concentran los recursos y esfuerzos, al adelantarse a los
hechos; además de coordinar las tareas por el bien del proyecto.
27
Figura 2.7: Visión general de la Gestión de la Integración del Proyecto.
Sin embargo, para que un proyecto sea completado con éxito, también debe
producirse la integración de otras muchas áreas. Por ejemplo:
• El trabajo del proyecto debe ser integrado con las operaciones en curso
de la organización ejecutora, la metodología e-Business, por ejemplo.
• Deben integrarse el alcance del producto y del proyecto.
• Deben integrarse los resultados de las distintas especialidades
funcionales (como pueden ser las especificaciones de la arquitectura e-
Business o los planos eléctricos, mecánicos y civiles en un proyecto de
ingeniería).
b.- Gestión del alcance
28
La Gestión del Alcance del proyecto comprende los procesos requeridos (ver
figura 2.8) para asegurar que el proyecto contiene todo el trabajo necesario y
solamente el trabajo necesario, para completar el proyecto con éxito. Esta área
está relacionada principalmente con la definición y control de lo que está o no
está incluido en el proyecto. En esta área se amplía y detalla el alcance, a
manera de continuar con el alcance preliminar definido en el área de
Integración.
En el contexto del proyecto, la palabra 'alcance' puede referirse a lo siguiente:
• Alcance del producto: Son las características y funciones que deben

incluirse en la iniciativa o solución e-Business.
• Alcance del proyecto: Es el trabajo que debe llevarse a cabo para
entregar una aplicación e-Business con las características y funciones
especificadas.
La gestión del alcance debe considerar los siguiente:
• Los procesos, herramientas y técnicas empleados para dirigir el alcance

del producto son diferentes según sea el área de aplicación y
normalmente son definidos como parte del ciclo de vida del proyecto, el
cual puede ser la metodología e-Business y/o el modelo de desarrollo en
un proyecto informático.
Lo que debe tenerse cuidado, es que un proyecto consta de un único

producto, pero este producto puede tener elementos auxiliares, cada
uno de ellos con su propio alcance del producto, separado pero
interdependiente.
Por ejemplo, un nuevo sistema telefónico generalmente incluirá cuatro

elementos auxiliares: hardware, software, formación e instalación. En el
caso de una iniciativa e-Business, cuya solución es una aplicación e-
Business, ella constará de una serie de hardware, software y
procedimientos de trabajo vinculados a la manutención de la arquitectura
e-Business y de un conjunto de aplicaciones de software específicas y
procedimientos de operación ligados que permiten la operación de la
aplicación e- Business.
La comprobación de que se ha completado el alcance del producto se
realiza según los requerimientos del mismo, mientras que el alcance del
proyecto se realiza según el plan del proyecto. Estos dos tipos de
gestión del alcance deben estar perfectamente integrados para asegurar
que los trabajos del proyecto darán como resultado el producto
especificado.
29
Figura 2.8: Visión general de la Gestión de Alcance del Proyecto.
c.- Gestión del tiempo
La Gestión del Tiempo incluye los procesos necesarios para asegurar la

conclusión del proyecto en los tiempos establecidos. La figura 2.9 provee una
vista general de sus procesos.
En algunos proyectos, especialmente en los mas pequeños, la secuencia de

actividades, la estimación de la duración de las actividades y el desarrollo del
programa están tan íntimamente ligados que se consideran como un único
proceso (por ejemplo, pueden desarrollarse por una sola persona en un
período de tiempo relativamente corto). No obstante el PMBOK presenta estos
procesos separados y distintos porque las herramientas y técnicas para cada
uno son diferentes.
30
Con respecto a esta área, la única consideración es que no existe consenso

entre los profesionales de la gestión de proyectos es sobre la relación entre
actividades y tareas, pues:
• En muchas áreas de aplicación, se considera a las actividades

compuestas por tareas. Esto es lo más normal y lo más utilizado.
• En otras áreas, se considera a las tareas compuestas por actividades.
Sin embargo, la consideración más importante no es el término que se utilice,

sino si el trabajo a realizar es descrito de forma precisa y si es comprendido por
las personas que deben realizarlo, distinguiendo claramente cuando algo se
compone de otra cosa. Esta consideración es muy importante en un proyecto
e-Business, donde el trabajo interdisciplinario de diversos profesionales,
informáticos, economistas, administradores de empresa, electrónicos, etc.,
pueden manejar distintas acepciones de lo mismo. En este caso, lo prioritario
es fijar el glosario de términos oficiales del proyecto.
31
Figura 2.9: Visión general de la gestión del tiempo del proyecto.
d.- Gestión del coste
La Gestión de Coste del proyecto incluye los procesos inmersos en la

planificación, estimación, presupuesto y control de los costes, con el fin de
asegurar que el proyecto se finaliza dentro del presupuesto aprobado.
La figura 2.10 provee una vista general de los principales procesos

involucrados:
32
La Gestión de Costes del proyecto está relacionada con el coste de los

recursos necesarios para completar las actividades del proyecto. Sin embargo,
la gestión de costes del proyecto debería considerar también el efecto que
tiene la toma de decisiones del proyecto sobre los costes de utilizar el producto
del proyecto.
Por ejemplo, la limitación del número de revisiones del diseño puede reducir los
costes del proyecto, a expensas de un aumento en los costes operativos del
cliente. Esta visión más global de la gestión de costes del proyecto se suele
llamar coste del ciclo de vida.
Este tema es especialmente relevante en un proyecto e-Business, pues, por

una parte, la iniciativa e-Business es un cambio cultural respecto de cómo
enfrentar la gestión de un negocio y en cómo plantearse una organización de
fronteras virtuales y, por otra parte, la aplicación e-Business final es en sí
misma la incorporación a una organización de un tipo de tecnología en muchas
ocasiones nueva, además, de hardware y software cuya gestión requiere
tratamiento especial y de gran cuidado, con los costes que ello significa. Estos
costes involucran, por ejemplo, conseguir profesionales adecuados para
construir la aplicación e-Business y profesionales que luego puedan responder
a las contingencias de la operación de la aplicación e-Business.
Como parte de la Gestión del Coste:
• En muchas áreas de aplicación, la predicción y análisis del futuro

rendimiento financiero del producto del proyecto se realiza fuera del
proyecto. Cuando se incluyen estas predicciones y análisis, la Gestión
de Costes incluirá procesos adicionales y numerosas técnicas de
dirección general, como la tasa interna de retorno (TIR), el valor actual
neto (VAN), período de recuperación del capital y otros.
• Esta gestión considera las necesidades de información de las entidades
involucradas en el proyecto: diferentes entidades pueden medir los
costes del proyecto de diferentes maneras y en distintos momentos. Por
ejemplo, el coste de un artículo de un proveedor puede ser medido
cuando se ha autorizado su compra, cuando se ha pedido, cuando se ha
pagado o cuando se ha contabilizado.
• En algunos proyectos, especialmente en los mas pequeños, la
planificación de recursos, la estimación de costes y el presupuesto de
costes están tan íntimamente ligadas que se ven como un solo proceso
(por ejemplo, puede desarrollarlas una sola persona en un período de
tiempo relativamente corto). No obstante el PMBOK presenta estos
procesos separados y distintos porque las herramientas y técnicas para
cada uno son diferentes.
33
Figura 2.10: Visión general de la gestión de costos del proyecto.
e.- Gestión de la calidad
La Gestión de la Calidad del proyecto incluye los procesos necesarios para

asegurar que el proyecto satisfará las necesidades para las que se ha llevado a
cabo. Implementa un sistema de administración de la calidad a través de
políticas, procedimientos y procesos de planificación de calidad, aseguramiento
de calidad y control de calidad, junto con actividades continuas de
mejoramiento de procesos llevadas a cabo mientras sean necesarias. La figura
2.11 provee una vista general de los siguientes procesos principales de gestión
de la calidad del proyecto:
34
Figura 2.11: Visión general de la gestión de la calidad del proyecto.
El método básico de gestión de calidad a seguir debe ser compatible con el de

la Organización Internacional de Normalización (ISO por sus siglas en inglés).
Este enfoque generalizado también debería ser compatible con métodos de
gestión de la calidad vinculados a Deming, Juran, Crosby y otros, y otros como
la Gestión de la Calidad Total (TQM - Total Quality Management), Six Sigma,
Coste de Calidad (COQ - Cost of Quality) o la Mejora Continua.
La Gestión de la Calidad debe dirigirse tanto a la dirección del proyecto como al

producto del proyecto. Un fallo en el cumplimiento de las exigencias de la
calidad en alguna dimensión puede tener consecuencias negativas serias para
alguna o todas las entidades involucradas en el proyecto. Por ejemplo:
• Cumplir los requerimientos del cliente mediante un trabajo excesivo del

equipo del proyecto puede producir consecuencias negativas como un
incremento en la rotación de personal, errores o doble trabajo.
• Cumplir los objetivos de programación del proyecto, acelerando las
revisiones de la calidad planificadas, puede producir consecuencias
negativas cuando existan errores que no sean detectados.
Un aspecto crítico de la Gestión de la Calidad en el contexto del proyecto es la

necesidad de convertir los necesidades, deseos y expectativas implícitos en
necesidades evidentes requerimientos, a través de la Gestión del Alcance del
proyecto.
El equipo de dirección del proyecto debe tener cuidado de no confundir calidad

con grado. Grado es una categoría o rango dado a entidades que, teniendo el
35
mismo uso funcional, tienen diferentes requerimientos de calidad. La baja

calidad es siempre un problema; el bajo grado puede no serlo. De igual
manera, se puede hacer la misma comparación entre precisión y exactitud.
Unas mediciones precisas no son necesariamente exactas.
Determinar y conseguir los niveles adecuados de calidad y grado, y de

precisión y exactitud, son las responsabilidades del gestor del proyecto y del
equipo de dirección del proyecto.
El equipo de dirección del proyecto debe saber también que la gestión de la

calidad moderna complementa a la dirección de proyectos moderna. Por
ejemplo, ambas disciplinas reconocen la importancia de:
• La satisfacción del cliente: Entender, evaluar, definir y administrar las

expectativas del cliente, con el fin de cumplir con sus requerimientos.
• La prevención sobre la inspección: el coste de evitar los errores
siempre es mucho menor que el de corregirlos.
• Responsabilidad de la gestión: el éxito requiere la participación de
todos los miembros del equipo, pero permanece la responsabilidad de la
dirección de suministrar los recursos necesarios para lograrlo.
• Mejora Continua: El ciclo reiterativo planificar-ejecutar-comprobar-
actuar es la base para la mejora de la calidad. Además, las iniciativas de
mejora de la calidad llevadas a cabo por la organización ejecutora (por
ejemplo, TQM y Six Sigma), pueden y deben mejorar la calidad de la
dirección del proyecto, así como la calidad del producto del proyecto.
Modelos de mejora de procesos incluyen a Malcolm Baldrige, CMM y
CMMI.
Sin embargo, hay una diferencia importante sobre la que el equipo de dirección
del proyecto debe estar muy precavido: la naturaleza temporal de los proyectos
implica que las inversiones en mejora de la calidad del producto, especialmente
la prevención de defectos y las pruebas, deben frecuentemente soportarse por
parte de la organización ejecutora dado que el proyecto puede no durar lo
suficiente para recoger la recompensa.
f.- Gestión de recursos humanos
La Gestión de Recursos Humanos del proyecto incluye los procesos necesarios

(ver figura 2.12) para organizar y administrar el equipo de proyecto, el que
comprende al personal a quien ha sido asignado algún rol o responsabilidad
para completar el proyecto. Los miembros del equipo deben estar involucrados
en muchas de las planificaciones del proyecto y de la toma de decisiones. Esto
añade habilidades durante el proceso de planificación, y genera un mayor
compromiso para con el proyecto. Es usual referirse a los miembros del equipo
de proyecto como el "staff" del proyecto. El número y tipo de miembros puede
alterarse durante el desarrollo del proyecto.
Hay gran cantidad de literatura sobre las relaciones interpersonales en un

contexto operativo continuo. Algunas de las muchas ideas extendidas son:
36
• Liderazgo, comunicación, negociación y otras más aptitudes clave en la

dirección general.
• Delegación, motivación, enseñanza, apadrinamiento y otros temas
relacionados con el trato personal.
• Creación de equipos, resolución de conflictos y otros temas relacionados
con el trato en grupo.
• Análisis del grado de preparación., reclutamiento, retención, relaciones
laborales, seguridad e higiene en el trabajo y otros elementos
relacionados con la función de administración de recursos humanos.
La mayor parte de este material es aplicable al liderazgo y a la dirección de

personas en proyectos y el gestor del proyecto y el equipo de dirección del
proyecto deben estar familiarizados con estos conceptos. Sin embargo, deben
ser también sensibles a la aplicación de estos conceptos en el proyecto. Por
ejemplo:
• La naturaleza temporal de los proyectos supone que las relaciones

personales y de la organización serán, generalmente, temporales y
nuevas. El equipo de dirección del proyecto debe tener cuidado a la hora
de seleccionar técnicas que sean apropiadas para estas relaciones
temporales.
• La naturaleza y el número de entidades involucradas en el proyecto
cambiarán a menudo según el proyecto va pasando por las distintas
fases de su cielo de vida. Como consecuencia de esto, técnicas que son
aptas en una fase determinada, pueden no ser efectivas en otra fase. El
equipo de dirección del proyecto debe prestar especial atención en
utilizar las técnicas apropiadas a las necesidades actuales del proyecto.
• Las actividades administrativas de los recursos humanos son rara vez
una responsabilidad directa del equipo de dirección del proyecto. Sin
embargo, el equipo debe conocer suficientemente los requerimientos
administrativos para asegurar su cumplimiento.
37
Figura 2.12: Visión general de la Gestión de los Recursos Humanos del Proyecto.
La Gestión de Recursos Humanos del proyecto interactúa con otros procesos.

Sin embargo, existen algunas interacciones que requieren una planificación
adicional, por ejemplo:
• Luego de crear el WBS, puede ser necesaria la contratación de

miembros adicionales.
38
• Los nuevos miembros poseen un nivel de experiencia que afectará al

riesgo del proyecto, por consiguiente, será necesario replanificar la
gestión de riesgo.
• Cuando la duración de las actividades son estimadas antes de que se
conozcan a todos los miembros del equipo, las competencias adquiridas
por los mismos puede causar cambios en la duración o calendarización
de las actividades.
g.- Gestión de las comunicaciones
La Gestión de Comunicaciones del proyecto comprende los procesos

necesarios para, en el momento y manera adecuados, asegurar la elaboración,
recopilación, distribución, archivo y disposición definitiva de la información del
proyecto. Proporciona las conexiones clave entre personas, ideas e
información, que son necesarias para el éxito del proyecto. Esto se hace para
que cualquier persona implicada en el proyecto deba comprender cómo las
comunicaciones que se realizan entre personas afectan al proyecto en su
conjunto. La figura 2.13 provee una vista general de los siguientes procesos
generales:
Las habilidades comunicacionales están relacionadas a las comunicaciones de

la gestión del proyecto, pero no son lo mismo. El arte de la Comunicación es un
tema extenso y comprende una gran cantidad de aspectos. Por ejemplo:
• Modelos emisor-receptor (lazos de realimentación, obstáculos a las

comunicaciones, etc.).
• Elección del medio (cuándo comunicar por escrito y cuándo hacerlo
verbalmente, cuándo escribir un memorando informal y cuando hacer un
informe formal, etc.).
• Estilo de escritura (voz activa frente a voz pasiva, estructura de las
oraciones, elección de vocabulario, etc.).
• Técnicas de presentación (lenguaje del cuerpo, diseño de ayudas
visuales, etc.).
• Técnicas de dirección de reuniones (preparación de una agenda,
tratamiento de conflictos, etc.).
Esta área es de importancia ya que muchos proyectos fallan por problemas de

comunicación. Por esta razón, es responsabilidad del gestor de proyectos crear
un ambiente dentro del proyecto propicio para una efectiva comunicación intra
e inter- grupal que permita que todas las partes estén informadas de manera
fluida.
Lo importante es no dar sorpresas, menos al cliente. Por esto, las

comunicaciones no deben depender de informes aislados, sino que es bueno
aprovechar las reuniones para comunicar. No hay que olvidar que una buena
frase puede ser mejor que un cuidado informe de estado.
39
Figura 2.13: Visión general de la gestión de las comunicaciones del proyecto.
h.- Gestión del riesgo
La gestión de riesgos del proyecto incluye los procesos relacionados con la

planificación, identificación, análisis, respuesta, monitoreo y control a los
riesgos del proyecto. Los objetivos de esta gestión son los de maximizar la
probabilidad e impacto de eventos positivos, y de minimizar las consecuencias
40
de los eventos negativos al proyecto. La figura 2.15 provee una vista general
de los siguientes procesos principales:
El riesgo es un evento o condición incierta que, si ocurre, tiene un efecto

positivo o negativo en por lo menos un objetivo del proyecto, tal como tiempo,
costo, alcance o calidad. Un riesgo puede tener una o más causas y, si ocurre,
uno o más impactos.
Las diferentes áreas de aplicación utilizan, con frecuencia, diferentes nombres

para los procesos aquí descritos. Por ejemplo:
• La identificación y cuantificación de riesgos se tratan, en algunas

ocasiones, como un solo proceso y el proceso combinado puede
llamarse análisis o evaluación de riesgos.
• Al desarrollo de respuestas a riesgos se le denomina algunas veces
Planificación de respuestas o mitigación de riesgos.
• El desarrollo y el control de las respuestas ante el riesgo se tratan
algunas veces como un solo proceso, pudiendo ser denominarse dicho
proceso combinado gestión de riesgos.
Esta área, en muchos casos definida como función, es una de las más
importantes hoy en día debido al entorno cambiante en que se desenvuelven
los proyectos e-Business en particular, y cualquier proyecto en general.
Durante la fase de planificación, el gestor de proyecto necesita realizar una

valoración realista de riesgos y desarrollar un plan para controlarles. Para ello
debe considerar como factores de riesgo:
• el tamaño del proyecto;

• la estructura del proyecto; y,
• la experiencia con la tecnología.
Debe tenerse presente que los riesgos de un proyecto aumentan conforme

crece, es poco estructurado (es decir, los requerimientos no se definen bien y
probablemente cambien durante el proyecto) y hay menos experiencia del
equipo en la tecnología a usar.
En estos casos adoptar un enfoque de contingencia es una estrategia

adecuada de gestión de los diversos tipos de riesgo, para las cuales existen
diversos tipos de herramientas de integración externa, interna y de control y
planificación (figura 2.14).
41
Figura 2.14: Enfoque de contingencia de gestión de riesgo.
- Proyectos con una estructura pequeña se pueden beneficiar de herramientas

de integración externa para crear relaciones efectivas entre el equipo del
proyecto y los clientes de la organización. Por ejemplo:
- seleccionar al gestor del proyecto y a los miembros del equipo del proyecto
desde la misma organización que recibirá el producto;
- mantener una representación de clientes en todas, o casi todas, las reuniones

de revisión del proyecto; y/o,
- mantener una amplia difusión y distribución de los informes de estado del

proyecto dentro de la organización.
- Proyectos que involucran el uso de nueva tecnología deberían confiar más en

herramientas de integración interna, las cuales han sido diseñadas para
mejorar la competencia y operación técnica del equipo como una unidad
integrada. Por ejemplo:
- seleccionar o disponer de miembros experimentados;
- contar con un gestor del proyecto con gran dominio técnico y experiencia
probada en gestión de proyectos;
- mantener frecuentes reuniones de estado del proyecto con los miembros.
- Grandes proyectos, con una gran estructura deberían ser gestionados con
profusión de herramientas de gestión y de control. Estas herramientas,
representan un esfuerzo sistemático y disciplinado de planificación y control.
Por ejemplo, WBS, presupuestos, planes y procedimientos de seguimiento.
42
Figura 2.15: Visión general de la gestión de riesgos del proyecto.
Mientras la elección de un enfoque adecuado para gestionar el proyecto es de

gran importancia, es importante una valoración de los riesgos, lo cual incluye:
• El propósito de la identificación de riesgos es desarrollar una lista de

los riesgos que pueden afectar el proyecto y su producto.
• El análisis de riesgos consiste de valorizar la exposición al riesgo, la
probabilidad e impacto de cada uno de ellos.
• La priorización de los riesgos produce una lista de riesgos priorizados
según el impacto que un riesgo tiene en el proyecto y el producto.
Con esto se puede planificar según los riesgos de mayor impacto e incidencia,
planteando planes de contingencia para hacerles frente y monitorearles. Es
importante que los riesgos sean valorizados continuamente cuando se
monitorean para mantener actualizada una lista de, por ejemplo, los 10 riesgos
de mayor prioridad e incidencia.
i.- Gestión del abastecimiento
La Gestión del Abastecimiento del proyecto incluye los procesos requeridos

(ver figura 2.16) para la adquisición de bienes y servicios, o resultados
requeridos del exterior del equipo del proyecto, para poder ejecutar el trabajo
43
asignado. Existen dos perspectivas para definir el abastecimiento. La

organización puede ser compradora o proveedora del producto, servicio o
resultado definido bajo un contrato.
La gestión del abastecimiento incluye la administración del contrato y los

procesos de control de cambios requeridos para administrar los contratos u
órdenes de compra emitidas por miembros autorizados del equipo de proyecto.
También incluye la administración de cualquier contrato emitido por una

organización externa (el comprador) que está adquiriendo el proyecto de una
organización ejecutora (el vendedor), y la administración de las obligaciones
contractuales definidas en el contrato.
El proveedor dirigirá normalmente su trabajo como un proyecto. En tales casos:
• El comprador se convierte en cliente y es así, una entidad del proyecto

clave para el proveedor.
• El equipo de dirección de proyectos del proveedor debe estar interesado
en todos los procesos de dirección de proyectos, no sólo en aquellos de
esta área de conocimiento.
• Los términos y condiciones del contrato se convierten en un dato clave
para muchos de los procesos del proveedor. El contrato puede contener
realmente los datos (por ejemplo, entregas principales, hitos clave,
objetivos de coste) o puede limitar las opciones del equipo del proyecto
(por ejemplo, en los proyectos de diseño se requiere frecuentemente la
aprobación del comprador de las decisiones de asignación de personal).
44
Figura 2.16: Visión general de la gestión de abastecimiento del proyecto.
2.3.2 Procesos de gestión de proyectos
Los Procesos de Gestión de Proyectos son el eje de toda la propuesta del

PMBOK (tabla 2.2), constituyendo el centro de las mejores prácticas de gestión
de proyectos. En la codificación X.Y de cada proceso, la X indica el número de
área de conocimiento a la cual pertenece, mientras la Y es un correlativo.
A cada proceso se le asocian entradas y salidas y un conjunto de herramientas

y técnicas de gestión. Esta representación de la gestión de proyectos, ha sido
una de las principales aportaciones del PMBOK al mundo de la investigación y
de la profesión de proyectos, al mostrar de manera clara que existen, por una
45
parte, procesos de gestión y, por otra parte, herramientas y técnicas donde, los
primeros usan las segundas a conveniencia según necesidades y habilidades
del gestor y de los participantes.
Los procesos de gestión de proyectos son presentados como elementos que

contienen interfases definidas. Sin embargo, en la práctica los procesos
interactúan de diferentes maneras, lo que nos lleva a reconocer que hay más
de una manera de administrar un proyecto. La aplicación de estos procesos a
un proyecto es iterativa y muchos de los procesos son repetidos y revisados
durante el proyecto.
Un concepto importante para definir la interacción entre los procesos de gestión

de proyectos es el ciclo de plan-do-check-act (planificar-hacer-chequear-
actuar). En donde el resultado de una parte del ciclo se convierte en la entrada
de la siguiente parte. El ciclo se muestra en la figura 2.17.
Figura 2.17: Ciclo plan-do-check-act.
El ciclo mencionado anteriormente es muy sencillo para definir la naturaleza

integradora de los grupos de procesos, sin embargo puede aplicarse a las
interrelaciones entre los grupos, de forma extendida, como muestra la figura
2.18.
46
Figura 2.18: Ciclo plan-do-check-act aplicado a grupos de procesos.

PROCESO DE
# GESTIÓN DE DESCRIPCIÓN
PROYECTOS
Gestión de la Integración
Desarrollo del cuadro Desarrollar un plan de proyecto que autorice formalmente al

4.1
de proyecto (p charter) proyecto o una fase del proyecto.
Desarrollo de alcance Desarrollar el alcance del proyecto en una narrativa de alto

4.2
de proyecto preliminar nivel.
Documentar las acciones necesarias para definir, preparar,

Desarrollo del plan de
4.3 integrar y coordinar todos los planes subsidiarios en un plan de
gestión de proyecto
gestión de proyecto.
Dirección y Gestión de
4.4 la ejecución del Ejecutar las tareas definidas en el plan de gestión de proyecto.
proyecto
Controlar los procesos usados para iniciar, planificar, ejecutar y

Monitoreo y control de
4.5 cerrar el proyecto de manera que coincidan con los objetivos
tareas del proyecto
descritos en el plan.
Control de Cambios
4.6 Revisar todos los cambios solicitados, aprobados y realizados.
Integrado
Finalizar las actividades de todos los grupos de proceso, para

4.7 Cierre del proyecto
cerrar formalmente el proyecto o la fase de proyecto.
Gestión del Alcance
Desarrollar un plan de gestión del alcance que indique cómo

Planificación del
5.1 será definido, verificado y controlado, y cómo será creada la
alcance
WBS.
Desarrollar un informe escrito del alcance que sirva de base

5.2 Definición del alcance
para las futuras decisiones del proyecto.
Creación de un WBS
Subdividir las principales entregas del proyecto en
5.3 (Work Breakdown
componentes más pequeños y manejables.
Structure)
Aceptar formalmente que los entregables del proyecto han sido

5.4 Verificación del alcance
completados.
47
5.5 Control del Alcance Controlar los cambios en el alcance del proyecto.
Gestión del tiempo
Definición de Identificar las actividades específicas que se deben desarrollar

6.1
actividades para cumplir con las principales entregas del proyecto.
Secuenciación de las Identificar y documentar las distintas interrelaciones entre

6.2
actividades actividades.
Estimación de los
Estimar el tipo y cantidad de recursos necesarios para
6.3 recursos de las
desarrollar cada actividad.
actividades
Estimación de la
Estimar el número de jornadas laborales que se necesitarán
6.4 duración de las
para terminar cada actividad.
actividades
Analizar la secuencia de actividades, duraciones,

Desarrollo del
6.5 requerimientos de recursos y restricciones para elaborar el
programa
programa del proyecto.
6.6 Control del programa Controlar los cambios del programa del proyecto.
Gestión del Coste
Desarrollar una aproximación (estimación) de los costes de los

7.1 Estimación de costes recursos necesarios para completar las actividades del
proyecto.
Asignar la estimación general de costes a cada uno de los

7.2 Presupuesto de costes
elementos de trabajo para establecer u.n coste base.
Identificar los factores que generan variaciones de costes y

7.3 Control de costes controlar los cambios que se produzcan en el presupuesto del
proyecto.
Gestión de la Calidad
Planificación de la Identificar qué normas de la calidad son relevantes al proyecto

8.1
calidad y determinar cómo cumplirlas.
Ejecución del Aplicar las actividades planificadas para asegurar que el

8.2 Aseguramiento de la proyecto emplea todos los procesos necesarios para cumplir
calidad con los requerimientos de las normas.
Realizar un seguimiento de los resultados específicos del

Ejecución del Control proyecto para determinar si cumplen las normas más
8.3
de la calidad importantes sobre la calidad e identificar la manera de eliminar
las causas de un desarrollo no satisfactorio.
PROCESO DE
# GESTIÓN DE DESCRIPCIÓN
PROYECTOS
Gestión de Recursos Humanos
Identificar, documentar y asignar las funciones,

Planificación de los
9.1 responsabilidades y relaciones jerárquicas del proyecto, y crear
Recursos Humanos
el plan de gestión de personal.
48
Adquisición de equipo Reunir los recursos humanos que sea necesario asignar al
9.2
de proyecto trabajo del proyecto.
Desarrollo del equipo Desarrollar las aptitudes individuales y de grupo para mejorar
9.3
de proyecto el desarrollo del proyecto.
Hacer seguimiento del rendimiento de cada miembro del

Gestión del equipo de
9.4 equipo, cambiando y mejorando factores que mejoren el
proyecto
desarrollo del proyecto.
Gestión de las Comunicaciones
Planificación de Determinar las necesidades de información y comunicaciones

10.1
comunicaciones de las entidades involucradas en el proyecto.
Distribución de Poner a disposición de las entidades involucradas en el

10.2
información proyecto la información necesaria en el momento adecuado.
Recopilar y distribuir la información sobre el desarrollo del

10.3 Informe de realización proyecto. Esto incluye el informe de situación, la evaluación del
progreso y las previsiones.
Manejar las comunicaciones para satisfacer los requerimientos

Gestión de las
10.4 y resolver los factores relacionados con las entidades
Entidades
involucradas en el proyecto.
Gestión del Riesgo
Planificación de la Decidir el enfoque, plan y ejecución de las actividades de

11.1
gestión de riegos gestión del riesgo del proyecto.
Determinar qué tipo de riesgos es probable que afecten al

Identificación de
11.2 proyecto y documentar las características de cada uno de
riesgos
ellos.
Análisis cualitativo de Evaluar la probabilidad de ocurrencia e impacto de los riesgos

11.3
riesgos y priorizar los riesgos para su análisis o acción futura.
Análisis cuantitativo de Analizar numéricamente el efecto de los riesgos identificados

11.4
riesgos sobre los objetivos del proyecto.
Desarrollar procedimientos y técnicas para mejorar las

Planificación de las
11.5 oportunidades y reducir las amenazas respecto de los objetivos
respuestas a riesgos
del proyecto.
Monitorear los riesgos residuales, identificar nuevos riesgos,

Monitoreo y control de
11.6 ejecutar planes de reducción de riesgos y evaluar su
riesgos
efectividad a lo largo del ciclo de vida del proyecto.
Gestión del Abastecimiento
Planificación de
12.1 Compras y Determinar qué aprovisionar y cuándo.
Adquisiciones
Planificación de la Documentar los productos y servicios requeridos e identificar

12.2
contratación los potenciales suministradores.
Petición de respuestas
12.3 Obtener presupuestos, ofertas y propuestas adecuadas.
de proveedores
Selección de Revisar las ofertas, escoger a los posibles proveedores y

12.4
proveedores negociar un contrato escrito con cada uno de ellos.
49
Administración del Manejar el contrato y la relación entre el comprador y el

12.5
contrato vendedor.
Completar y establecer cada contrato, incluyendo la resolución

12.6 Cierre del contrato
de cualquier tema abierto, y finalizar la relación contractual.
Tabla 2.2. Procesos de gestión de proyectos.
2.3.3 Grupos de procesos de gestión
Los grupos de procesos de gestión, Project Management Process Groups, son

agrupaciones de procesos de gestión de proyectos relacionados con las cinco
fases de un proyecto: Iniciación (IP), Planificación (Pl), Control (CoP),
Ejecución (EP) y Cierre (ClP). Los grupos de procesos son independientes al
área de aplicación o enfoque de la industria en donde se desarrolle el proyecto;
sin embargo, tienen claras dependencias y se ejecutan en la misma secuencia
para cada proyecto.
El nivel de actividad de estos grupos de procesos durante el proyecto varía en

el tiempo tal como ilustra la figura 2.19.
Figura 2.19: La interacción de los grupos de procesos de gestión a lo largo del proyecto.
GRUPO DE
CÓDIGO DESCRIPCIÓN
PROCESOS
IP Iniciación Define y autoriza el proyecto o una fase del proyecto.
Define y refina objetivos, y planifica las acciones necesarias para

PP Planificación conseguir los objetivos y el alcance bajo el cual el proyecto fue
concebido.
Integra personal y demás recursos para llevar a cabo el plan de

EP Ejecución
gestión del proyecto en cuestión.
Ejecuta mediciones y monitoreos regulares del progreso,

identificando las variaciones con respecto al plan, para así tomar
CoP Control
acciones correctivas cuando sea necesario con el fin de lograr los
objetivos del proyecto.
50
Formaliza la aceptación del producto, servicio o resultado, y

ClP Cierre conduce al proyecto o fase de proyecto hacia un término
ordenado.
Tabla 2.3. Grupos de procesos de gestión.
2.3.4 Relación entre grupos, áreas y procesos
La relación entre grupos, áreas y procesos se presenta en la tabla 2.4. En esta

tabla, cada "x" indica la pertenencia de procesos de área de conocimiento en
un grupo de procesos.
Aunque los procesos en cada área pueden aparecer como elementos aislados
con conexiones bien definidas, en la práctica pueden solaparse e interaccionar
de una manera no detallada aquí.
Estos procesos interaccionan entre ellos, así como con los procesos en las
otras áreas de desarrollo. Cada proceso puede requerir esfuerzos de una o
más personas o grupos de personas, según sean las necesidades del proyecto.
Generalmente, cada proceso ocurre al menos una vez en cada fase del
proyecto.
IP PP EP CoP ClP
Gestión de la Integración X X X X X
Gestión del Alcance X X
Gestión del Tiempo X X
Gestión del Coste X X
Gestión de la Calidad X X X
Gestión de Recursos Humanos X X
Gestión de las Comunicaciones X X X
Gestión del Riesgo X X
Gestión del Abastecimiento X X X

Tabla 2.4. Relaciones entre grupos, áreas y procesos.
2.4 Modelos de Madurez de gestión

de proyectos
La gestión de proyectos habitualmente se espera sea aplicada a cabalidad
luego de leer un manual o sencillamente asistir a un curso. No obstante, en
este sentido, desde el área de gestión de proyectos, se ha planteado que las
prácticas de gestión han de usarse según las competencias que requiera un
proyectista conforme madura en su experiencia en gestión de proyectos.
51
En este sentido se han presentado en la literatura modelos llamados modelos

de madurez de gestión de proyectos, cuyo fin es proveer un marco que permita
reconocer qué tipo de competencia se requiere en diferentes estados de
madurez en gestión de proyectos.
Un modelo de madurez de gestión de proyectos, en el área de Proyectos,

aglutina y organiza en niveles de madurez un conjunto de criterios de gestión
con el fin de orientar las actuaciones de los proyectistas. Estos niveles, según
Ward, aparte de regular las competencias necesarias conforme el gestor de
proyectos aprende y asimila, actúan en sí mismos como metas a conseguir por
las organizaciones desde el punto de vista de la calidad de su gestión de
proyectos.
La literatura muestra que todos estos modelos de madurez han surgido o se

basan directamente en el Capability Maturity Model del Software Engineering
Institute (SEI) en Estados Unidos.
A continuación se presentará el CMM para luego pasar a revisar algunos

modelos de madurez en gestión de proyectos.
2.4.1 Capability Maturity Model (CMM)
A partir de noviembre de 1986 el SEI, a requerimiento del Gobierno Federal de

los Estados Unidos de América, desarrolló una primera definición de un modelo
de madurez de procesos en el desarrollo de software, que se publicó en
septiembre de 1987.
Para Paulk et al., el CMM es un marco que representa recomendaciones para

organizaciones de software que desean mejorar la calidad y capacidad de sus
procesos de software. En este sentido, el CMM describe las prácticas de
ingeniería de software y de gestión que caracterizan a las organizaciones
conforme mejora (madura) su proceso para desarrollar y mantener software.
Se añade en particular que un proceso de software se puede definir como un

conjunto de actividades, métodos, prácticas, y transformaciones que las
personas usan para desarrollar y mantener software y los productos asociados.
Para cada área de proceso define un conjunto de buenas prácticas que habrán
de ser:
• Definidas en un procedimiento documentado.

• Provistas (la organización) de los medios y formación necesarios.
• Ejecutadas de un modo sistemático, universal y uniforme
(institucionalizadas).
• Medidas.
• Verificadas.
A su vez estas Áreas de Proceso se agrupan en cinco "niveles de madurez", de

modo que una organización que tenga institucionalizadas todas las prácticas
incluídas en un nivel y sus inferiores, se considera que ha alcanzado ese nivel
de madurez.
52
a.- Niveles de madurez
La mencionada madurez se valoriza en función de cinco niveles de madurez.
Un nivel de madurez es una plataforma en el camino de conseguir una mejora

en un proceso de software. Cada nivel de madurez considera un conjunto de
objetivos de procesos que una vez satisfechos estabilizan una componente del
proceso de software. A continuación se describe cada uno de los niveles de
madurez del CMM.
• Inicial. Las organizaciones en este nivel no disponen de un ambiente

estable para el desarrollo y mantenimiento de software. Aunque se
utilicen técnicas correctas de ingeniería, los esfuerzos se ven minados
por falta de planificación. El éxito de los proyectos se basa la mayoría de
las veces en el esfuerzo personal, aunque a menudo se producen
fracasos y casi siempre retrasos y sobre costes. El resultado de los
proyectos es impredecible.
• Repetible. En este nivel las organizaciones disponen de unas prácticas
institucionalizadas de gestión de proyectos, existen unas métricas
básicas y un razonable seguimiento de la calidad. La relación con
subcontratistas y clientes está gestionada sistemáticamente.
• Definido. Además de una buena gestión de proyectos, a este nivel las
organizaciones disponen de correctos procedimientos de coordinación
entre grupos, formación del personal, técnicas de ingeniería más
detallada y un nivel más avanzado de métricas en los procesos. Se
implementan técnicas de revisión por pares (peer reviews).
• Gestionado. Se caracteriza por que las organizaciones disponen de un
conjunto de métricas significativas de calidad y productividad, que se
usan de modo sistemático para la toma de decisiones y la gestión de
riesgos. El software resultante es de alta calidad.
• Optimizado. La organización completa está volcada en la mejora
continua de los procesos. Se hace uso intensivo de las métricas y se
gestiona el proceso de innovación.
Las organizaciones que utilizan este modelo para mejorar sus procesos
disponen de una guía útil para orientar sus esfuerzos. Además, el SEI
proporciona formación a evaluadores certificados (Lead Assesors) capacitados
para evaluar y certificar el nivel CMM en el que se encuentra una organización.
Esta certificación es requerida por el US DoD, pero también es utilizada por
multitud de organizaciones de todo el mundo para valorar a sus subcontratistas
de software.
Se considera típico que una organización dedique unos 18 meses para

progresar un nivel, aunque algunas consiguen mejorarlo. En cualquier caso
requiere un amplio esfuerzo y un compromiso intenso de la dirección.
Como consecuencia, muchas organizaciones que realizan funciones de factoría

de software o, en general, outsourcing de procesos de software, adoptan el
modelo CMM y se certifican en alguno de sus niveles. Esto explica que uno de
los países en el que más organizaciones certificadas exista sea India, donde
53
han florecido las factorías de software que trabajan para clientes

estadounidenses y europeos.
CRÍTICAS SOBRE EL MODELO
Frecuentemente se critica al modelo CMM por no ser más específico en la definición de los
procesos. Para guiar a las organizaciones a definir y mejorar sus procesos indica qué
actividades han de realizar, pero nada sobre cómo hacerlo. Esto es así tanto en lo referente a
la ingeniería como a las herramientas o técnicas de gestión, aunque hace una curiosa
excepción en las revisiones por pares (peer reviews).
Del mismo modo, aunque insiste continuamente en la necesidad de las métricas, no da

ninguna guía concreta del tipo de métricas que son aceptables para una correcta práctica
profesional.
Los técnicos se quejan a menudo de la enorme carga de "papeleo" que impone el modelo,
viéndolo mas como un mecanismo de control por la dirección que una herramienta que les
ayude en su trabajo.
También resulta muy complejo, más todavía el CMMI, lo que hace que durante algún tiempo
resulte para mucha gente algo esotérico.
CAPABILITY INMATURITY MODEL
Con mucho sentido del humor, y bastante conocimiento de causa, Anthony Finkelstein
describió que hay organizaciones que no han alcanzado siquiera el nivel 1 de CMM (en el que
aunque sea de modo heroico se llega a producir software), proponiendo que existen niveles
negativos o de inmadurez. Este «Modelo de Incapacidad e Inmadurez», que fue refinado
posteriormente por Tom Schorsch, incluye tres niveles de idiotez:
0 Tonto. Organizaciones negligentes. Impiden cualquier desarrollo de software con éxito. Su

gran preocupación es la reutilización del software.
-1 Estúpido. Organizaciones obstructivas. Imponen procesos contra-productivos para impedir

cualquier avance. Se concentran en desarrollar entornos de desarrollo y repositorios.
-2 Lunático. Organizaciones desdeñosas. Desprecian cualquier institucionalización de buenas

prácticas. Su gran objetivo es la programación automática.
a.1.- Otros modelos CMM del SEI
a.1.1.- SE-CMM
El Modelo de Capacidad y Madurez en la Ingeniería de Sistemas fue publicado

por el SEI en noviembre de 1995. Está dedicado a las actividades de ingeniería
de sistemas.
Define 18 áreas de proceso divididas en tres grupos:
• Ingeniería (7).
• Proyectos (5).
• Organizativas (6).
54
No utiliza niveles de madurez generales sino que en cada área de proceso una
organización puede alcanzar un determinado nivel de madurez.
Al igual que el SW-CMM, ha sido integrado en el CMMI.
a.1.2.- IDP-CMM
El Modelo de Capacidad y Madurez para el Desarrollo Integrado de Productos

fue propuesto como un borrador por el SEI en 1997, pero quedó integrado en el
CMMI al publicarse este en el año 2000.
a.1.3.- P-CMM
Modelo de Capacidad y Madurez para Recursos Humanos.
a.1.4.- SA-CMM
Modelo de Capacidad y Madurez para la Adquisición de Software.
a.1.5.- El modelo CMMI
En diciembre de 2000, el SEI publicó un nuevo modelo, el CMMI o "Modelo de

Capacidad y Madurez - Integración", con el objetivo de realizar algunas mejoras
respecto al SW-CMM e integrarlo con el SE-CMM y el IPD-CMM, que pasaban
a ser considerados como "obsoletos".
El CMMI incluye cuatro disciplinas, en función de la amplitud de los procesos

que cubre:
- CMMI-SW: Software.
- CMMI-SE/SW: + Ingeniería de sistemas.
- CMMI-SE/SW/IPPD: + Desarrollo integrado de procesos y productos.
- CMMI-SE/SW/IPPD/SS: + Gestión de proveedores.
A su vez se presenta en dos posibles representaciones, "Por niveles" y

"Continua". En el primer caso permite evaluar el nivel de madurez de una
organización en todas las áreas de proceso, mientras que el segundo permite
evaluar el nivel en cada área independientemente.
Las principales diferencias con el SW-CMM, además de la inclusión de las tres

nuevas disciplinas para integrar los tres modelos antiguos, son:
- Pone un mayor énfasis en el uso continuo de métricas.
- Insiste en la necesidad de la trazabilidad desde los requerimientos al producto

final.
55
- Desglosa y detalla las áreas de proceso relativas a la ingeniería.
- Cambia el nombre a los niveles 2 y 4 que pasan a llamarse "gestionado" y

"gestionado cuantitativamente".
El SEI ha desarrollado también un nuevo método de evaluación de las

organizaciones según CMMI denominado SCAMPI.
a.1.6.- SSE-CMM
El System Security Engineering Capability Maturity Model o Modelo de

Capacidad y Madurez en la Ingeniería de Seguridad de Sistemas es un modelo
derivado del CMM y que describe las características esenciales de los
procesos que deben existir en una organización para asegurar una buena
seguridad de sistemas.
Ha sido desarrollado por la "International Systems Security Engineering

Association (ISSEA)", organización sin ánimo de lucro patrocinada por un buen
número de compañias dedicadas a la seguridad de sistemas.
Nació a partir de 1993 bajo los auspicios de la Agencia Nacional de Seguridad

(NSA) de los E.U.A., con la participación de numerosas compañías de los
sectores de tecnologías de la información, seguridad y defensa. La primera
versión data de 1997 y la actual (v3.0) fue publicada en junio de 2003.
Pretende servir como:
- Herramienta para que las organizaciones evalúen las prácticas de ingeniería

de seguridad y definan mejoras a las mismas.
- Mecanismo estándar para que los clientes puedan evaluar la capacidad de los
proveedores de ingeniería de seguridad.
- Base para la organización de un mecanismo de evaluación y certificación.
A diferencia del CMM original, las áreas de proceso no están agrupadas en

función de los niveles de madurez, sino que define 22 áreas para cada una de
las cuales se puede alcanzar un nivel en función del cumplimiento de unas
"características comunes".
Existen 11 áreas de procesos de ingeniería y otras 11 dedicadas a la gestión

de proyectos y organización.
El método de evaluación se denomina SSAM (SSE-CMM Appraisal Method).
b.- Arquitectura por niveles
A su vez, los niveles de madurez se componen de áreas de proceso claves

(Key Process Areas), que contienen prácticas clave (Key Practices)
organizadas a su vez en rasgos comunes (Common Features).
56
- Las Key Practices Areas (KPA) indican las áreas en que una organización
debería concentrarse para mejorar su proceso de software.
- Las Common Features (CF) son un conjunto de prácticas agrupadas dentro

de un área clave o necesidad.
- Las Key Practices (KP) son las actividades e infraestructura que contribuye de
manera más efectiva a la implementación e institucionalización de cada área
clave.
c.- La madurez por temas
El carácter organizador del CMM ha lugar a toda una serie de variaciones

ligadas al desarrollo de software como un producto. Por ejemplo, la versión de
CMM para la adquisición de software1, o aplicaciones más concretas acerca de
cómo mejorar la capacidad de gestión del conocimiento que sugieren
Baskerville y Pries-Heje.
No obstante el CMM presenta una peculiaridad que requiere ser mejorada

según el contexto de este trabajo. El CMM describe la madurez por niveles y
plantea un camino para conseguirlas. Sin embargo, como modelo es un patrón
que plantea lo que hay que medir por nivel, no distinguiendo si existen
mejoras parciales. Como instrumento de medición posee un carácter
excesivamente evaluativo más que formativo y, además, deja a las
organizaciones sin capacidad de mejoras parciales por temas, por procesos
críticos o más robustos.
SPICE es un modelo de madurez de origen europeo similar al CMM, pero con

la diferencia que las mejoras de capacidad del proceso se pueden conseguir
por temas o áreas. Por ejemplo, se puede alcanzar un nivel dos en
documentación y un nivel tres en el uso de métricas. Esta última cualidad es
considerada en muchos de los modelos de madurez de proyectos que a
continuación se presentan.
1
Ver recurso URL Software Acquisition Capability Maturity Model en:
Enlace web: http://www.sei.cmu.edu/arm/SA-CMM.html. [Leído: 16 de Marzo de 2005, 14.00h
GMT-5].
2.4.2 Modelos de madurez
Del área de gestión de proyectos se han considerado en este estudio los

siguientes modelos de madurez de proyectos, por su relevancia, impacto y
presencia:
• Trillium model,
• Project Management Assessment,
• Management Maturity Model, y
• Innovation Maturity Model.
57
2.4.2.1 Trillium model
El modelo Trillium es un producto usado por Bell Canadá para dar valor al
desarrollo de un producto y apoyar las capacidades de proveedores de
telecomunicaciones o productos basados en tecnologías de la información
existentes o futuros. El modelo ha sido diseñado para ser aplicado a sistemas
de software 'empotrados' tales como sistemas de telecomunicaciones, no
obstante buena parte del modelo puede ser aplicado a otros segmentos de la
industria del software como sería el área de Management Information Systems.
Con respecto al CMM, el modelo Trillium, se distingue en que:
- define roadmaps en lugar de áreas clave;
- tiene una perspectiva orientada al producto, haciéndolo más general y de

amplio uso;
- da amplia cobertura a los aspectos que inciden o impactan en la capacidad

del proceso; y,
- se enfoca al cliente en lugar del desarrollo mismo.
Esto consigue que se definan prácticas que guían al proyectista sobre cómo
conseguir lo que desea un usuario/cliente donde, en lugar de señalar
determinadas metas que se deben alcanzar con ciertas prácticas de diseño, se
buscan aquellas prácticas que habiliten la consecución de lo que desea el
usuario.
A semejanza del modelo CMM, el modelo Trillium presenta una escala de cinco
niveles de madurez:
• Nivel 1. Desestructurado. En este nivel el proceso de desarrollo es ad-

hoc. Los proyectos frecuentemente no pueden satisfacer objetivos de
calidad o de programación. El éxito posible se basa más en el trabajo de
los individuos que en la propia estructura e infraestructura
organizacional.
• Nivel 2. Repetible y orientado al proyecto. El éxito individual del proyecto
se consigue a través de una férrea planificación y control de gestión del
proyecto, dando especial énfasis a los requerimientos de gestión,
técnicas de estimación y configuración del cambio.
• Nivel 3. Definido y orientado al proceso. Aquí los procesos son definidos
y utilizados al nivel organizacional, no obstante se acepta que el
proyecto sea adaptado a las circunstancias. Los procesos son
controlados y mejorados. Se incorporan requerimientos ISO 9001, como
procesos de entrenamiento y auditoría interna.
• Nivel 4. Gestionado e integrado. La monitorización y análisis del proceso
son usados como mecanismos clave en la mejora. Procesos de gestión
58
del cambio y programas de prevención de defectos son integrados. Las

herramientas CASE se integran dentro del proceso.
• Nivel 5. Completamente integrado. Metodologías formales son
extensivamente usadas. Repositorios organizacionales son usados para
soportar y mantener la historia del proceso de desarrollo.
b.- Arquitectura del modelo
La arquitectura de Trillium igualmente plantea una descomposición pero con

una diferencia sustancial con el CMM: no se comienza la descomposición
desde los niveles de madurez, sino desde ocho áreas de capacidad (Capability
Areas), cada una de las cuales contiene varias roadmaps y estos últimos a su
vez contienen prácticas (Practices), usados paulatinamente por niveles de
madurez (figura 2.201).
Figura 2.20: Arquitectura del modelo Trillium.
De esta forma, la arquitectura de Trillium se caracteriza por poseer:
• Capability Areas: ocho áreas centrales de preocupación o prioritarias

para el modelo Trillium, cada una de las cuales se encuentra contenida
por prácticas;
59
• Roadmaps: conjunto de prácticas relacionadas, enfocadas sobre un

área o necesidad organizacional, o un elemento específico, dentro del
proceso de desarrollo del producto; y,
• Practices: acciones a desarrollar para conseguir una mejor capacidad
del proceso, cada una de las cuales se vincula a un nivel de madurez.
La tabla 2.5 detalla la relación entre los elementos de la arquitectura2.
TRILLIUM CAPABILITY # OF PRACTICES BY

ROADMAPS TOTAL
AREAS LEVEL
2 3 4 5
Quality Management
Organizational Process
10 20 5 0 35
Quality Business Process
Engineering
Human Resource Human Resource

Development and Development and 9 42 1 0 52
Management Management
Process Definition
Technology Management
Process 16 55 24 4 99
Process Improvement &
Engineering
Measurements
Project Management
Subcontractor Management
Customer-Supplier
Management 74 29 4 0 107
Relationship
Requirements Management
Estimation
Quality Systems Quality System 14 15 2 2 33
Development Process
Development Techniques
Internal Documentation
Development practices 41 49 15 5 110
Verification & Validation
Configuration Management
Re-Use
60
Reliability Management
Development Environment Development Environment 4 6 1 1 12
Problem Response System
Usability Engineering
Life-Cycle Cost Modelling

Customer Support 25 30 5 0 60
User Documentation
Customer Engineering
User Training
Total 193 246 57 12 508
Tabla 2.5. Arquitectura del modelo Trillium.
1
Tomada del recurso público de Trillium, Model Description,
Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html. [Leído: 23 de Junio de 2006,
11.00h GMT-5].
2
Tomada del recurso público de Trillium, Model Description, ubicado en el URL:
Enlace web: http://www.sqi.gu.edu.au/trillium/t3modc3.html el día 12/4/2001.
[Leído: 16 de Marzo de 2005, 11.00h GMT-5].
2.4.2.2 Project Management Assessment
El Project Management Assessment 2000 (PMA) es una metodología holística

y una herramienta de software para la mejora de procesos de gestión en un
medio ambiente de gestión de proyectos. Se ofrece para dar soluciones a
problemas de inflexibilidad, de tiempo, de "no saber hacer" y, de falta de una
mejora incremental.
Para Lubianiker, es un modelo donde deben integrarse prácticas genéricas

(herramientas, procedimientos y estándares comunes al ámbito de gestión de
proyectos tomados del PMBOK) y específicas de la propia organización, para lo
cual se cuenta con un software.
El software es un producto orientado a definir y especificar prácticas genéricas

tomadas del PMBOK y otras específicas de cada problema y unirlas siguiendo
el esquema de prácticas que ofrece el mismo PMBOK.
2.4.2.3 Project Management Maturity Model
El Management Maturity Model (PM3) se orienta a mejorar prácticas de gestión

de proyectos. Es un esfuerzo derivado de considerar la gestión de proyectos un
proceso crítico de la misión organizacional y de competencia vital a la
organización.
El modelo se ha construido a partir de encuestas a organizaciones que han

llevado, obviamente, proyectos, buscando definir las prácticas de gestión que
61
aplicaban. Según la última información disponible, el modelo se ha modificado

hasta alcanzar unas 300 lecciones sobre gestión de proyectos en el ámbito
corporativo.
Estas prácticas se han organizado en niveles de madurez. De estos niveles:

ad-hoc, abreviado, organizado, gestionado y adaptativo; se conocen 51
preguntas que permiten saber el nivel de una organización.
2.4.2.4 Innovation Maturity Model
El Innovation Maturity Model (IMM) no es un modelo como tal, sino una

propuesta para el desarrollo de productos. Es una visión sobre cinco niveles de
innovación: superficial (Superficial), mejoras en rasgos (Feature
Enhancements), mejoras en soluciones (Solution Enhancements), soluciones
impactantes (Breakthrough Solutions) y 'rompedora' (disruptive).
2.4.3 Implantación de la madurez
Todos los modelos previos de una u otra manera buscan medir o alcanzar un
determinado nivel de competencia en gestión de proyectos. Conseguir esta
competencia requiere algunas precisiones de mayor detalle.
En cuanto a detalle, Peterson propone un modelo de madurez basado

directamente en el PMBOK de ocho niveles de madurez, cuya cantidad
solamente se justifica en la medida de conseguir una competencia paulatina
incremental y más gradual. A grandes rasgos, tales niveles se caracterizan por
lo siguiente:
• Nivel I. No conocedor (non-awareness). No existe conocimiento

alguno sobre gestión de proyectos.
• Nivel II. Inicial. Se comienzan a introducir prácticas de gestión de
proyectos.
• Nivel III. Básico. Comienzan algunas tareas de gestión como
asignación de responsabilidades, documentación, hitos y manejo formal
de información.
• Nivel IV. Repetible. Se establecen algunos procesos de gestión y se
formaliza el uso de determinadas herramientas. Ya existe algún plan de
entrenamiento en gestión de proyectos y se llevan algunas auditorías.
• Nivel V. Avanzado. El entrenamiento y, las auditorías o seguimientos,
son totales, igualmente algunos procesos y herramientas son
incorporados en su totalidad.
• Nivel VI. Bien-definido. Los niveles de autoridad y experiencia son
completos, el entrenamiento es avanzado, los procesos se integran
introduciéndola documentación y el uso de métricas.
• Nivel VII. Gestionado. Se promueven los incentivos, se introduce la
certificación en gestión de proyectos. Se persigue un buen desempeño y
mejorar la eficiencia y efectividad.
• Nivel VIII. Optimizante. La mejora es continuada y sostenible.
62
Lo importante de esta propuesta es el Nivel VIII, al dejar explícito que alcanzar

los niveles de madurez no es un fin en sí mismo, sino un medio para garantizar
una mejora adaptativa y sostenida a lo largo del tiempo.
b.- Implantación
Respecto de la consecución de la competencia, White señala que una manera

de introducir técnicas de gestión que satisfagan los niveles de madurez del
CMM es siguiendo ciclos iterativos.
En este sentido, White propone un mecanismo para sensibilizar a los

proyectistas en la conveniencia de aprender a mejorar. Para ello White señala
que se deben seguir ciclos de mejora de forma paulatina, por ejemplo,
comenzar con un ciclo As-Is donde se presentan las primeras prácticas de
gestión, pasando luego a un ciclo de actualización de procesos e
infraestructura para alcanzar un nivel 2 y así, ejecutar un tercer ciclo orientado
a conseguir el nivel 3 del CMM (figura 2.21).
Figura 2.21: Implantación gradual.
Capítulo 3.- Ingeniería de software y

gestión de proyectos
OBJETIVOS
- Conocer las dimensiones de un proyecto informático.
- Conocer las fases de desarrollo de un proyecto informático.
- Conocer los modelos de desarrollo de un proyecto informático.
63
3.1 Análisis de proyectos por tipo de

dimensión
Los proyectos informáticos son un tipo particular de proyecto, los cuales, según
como se mire, podrían ser proyectos industriales en la medida de producir un
artefacto, o podrían considerarse proyectos de ingeniería en razón de buscar y
crear soluciones (proyecto de acción). No se quiere entrar en una discusión
taxonómica, pero si se puede afirmar que los proyectos informáticos se
distinguen por ser un universo por sí solos. Por este motivo y, como se verá
más adelante, al ser parte de un proyecto e-Business, este apartado se dedica
a describir la complejidad inherente a un proyecto informático.
Como se ha visto con anterioridad, un proyecto sólo puede distinguirse por

singularidades y criterios, por este motivo, se discuten aquí tipos de proyectos
informáticos según los siguientes criterios:
• dimensión del artefacto;

• dimensión de alcance;
• dimensión del trabajo;
• dimensión de desarrollo; y,
• dimensión organizacional.
3.1.1 Segun dimensión del artefacto
Esta dimensión cubre la naturaleza del principal producto físico a entregar,

atendiendo a la forma de la solución que se entrega. En este caso, puede ser
un estudio y/o un conjunto de componentes como:
• Informes sobre los beneficios de la solución informática.

• Software y sus versiones de desarrollo dispuestas en unidades de
almacenamiento, en una o varias copias.
• Personal requerido para la operación del software según indicaciones de
habilidades y aptitudes.
• Documentación y manuales del software de diverso índole y naturaleza
dependiendo de los lectores de tal material.
• TI asociadas al uso del producto material de software.
Lo anterior no evita que puedan distinguirse dos tipos de proyectos: proyecto

de software y proyecto de infraestructura informática.
a. Proyecto de software
Este es el proyecto más común y se caracteriza por que el producto es un
software en algún soporte físico.
Según Alter un proyecto de software es un sistema de trabajo de tiempo

limitado que busca satisfacer un requerimiento particular. Solucionar el
problema de Y2K es un ejemplo.
64
El proyecto comienza con algún software existente y su objetivo es remover

problemas desde tal software sin cambiar su función pretendida. El objetivo es
hacer cosas que no cambian el medio externo, como por ejemplo, la nueva
versión de un procesador de textos donde el resultado directo puede ser un
software a bajar (download) o un parche, en lugar de hacer cambios en un
sistema informático operacional dentro de una organización particular.
El gestor de este tipo de proyectos, en este caso, declara una victoria cuando
el software corre en un ordenador de la manera deseada, independiente de
quien le esté usando.
Se debe recordar que el proyecto como tal no existe, lo que se define como
proyecto son dos dimensiones que conforman una a la vez: Dimensión de
Gestión y Dimensión de Construcción.
Para gestionar un proyecto de software de la mejor manera hay que

comprender que puede ir mal, y como hacerlo bien. Existen diez señales que
indican que un proyecto esta en riesgo:
- No se comprende las necesidades del cliente.
- El ámbito esta definido pobremente.
- Los cambios están mal realizados.
- La tecnología elegida cambia.
- Las necesidades del negocio cambian
- Las fechas de entrega no son realistas.
- Los usuarios se resisten.
- Se pierden los patrocinadores.
- Se carece de personal.
- Los gestores evitan buenas prácticas y sabias lecciones.
Para evitar los problemas anteriormente mencionados, se sugiere lo siguiente:
- Empezar con el pie derecho, trabajar duro para comprender el problema a

tratar.
- Mantenerse, proporcionar incentivos para conseguir una rotación del

personal.
- Seguimiento del progreso, el progreso se sigue mientras se realizan los

productos de trabajo (código fuente, especificaciones de trabajo, conjunto de
casos de prueba, etc.)
65
- Tomar decisiones inteligentes, asigne mas tiempo del que pensaba necesitar
para tareas arriesgadas o complejas.
- Realizar un análisis después de haber terminado el proyecto.
- Los participantes de todo proyecto de software son los siguientes:
- Gestores superiores: que definen los aspectos de negocios que a menudo

tienen una significativa influencia en el proyecto.
- Gestores (técnicos) del proyecto que deben planificar, motivar, organizar y

controlar a los profesionales que realizan el trabajo de software.
- Profesionales que proporcionan las capacidades técnicas necesarias para la

ingeniería de un producto o aplicación.
- Clientes que especifican los requisitos para la ingeniería del software y otros
elementos que tienen menor influencia en el resultado.
- Usuarios finales que interaccionan con el software una vez que se ha

entregado para la producción.
Un proyecto de software puede ser parte de un proyecto de sistema de

información o de un proyecto de un sistema de trabajo (un sistema humano-
máquina de trabajo). Si es así, el esfuerzo no es completo hasta que finalmente
el proyecto de software opera como se pretende dentro del sistema de
información o el sistema de trabajo.
Dentro de esta definición tienen cabida todos los proyectos informáticos

vinculados al diseño lógico, implantación, etc. o cualquier otra actividad que
finalmente conduce a software operando en hardware.
b. Proyecto de infraestructura informática
Estos proyectos son poco frecuentes, pero no por ello ausentes en esta
dimensión. Estos proyectos, según Steiner, son casos especiales en que no
hay necesariamente un desarrollo de software, sino se encuentran
caracterizados por la elección de hardware para una mayor aplicación,
consolidar servidores o rediseñar redes de telecomunicaciones.
3.1.2 Según dimensión de alcance
Los proyectos pueden definirse en función del alcance pretendido. En este

caso se distinguen proyectos de sistemas de información y proyectos de
ingeniería de software.
a. Proyecto de sistema de información

Según Alter un proyecto de sistema de información es un sistema de trabajo de
tiempo limitado cuyo objetivo es crear o modificar un sistema de información
para que opere según un conjunto de requerimientos y sea mantenible.
66
Un ejemplo de proyecto de sistema de información es construir un nuevo

sistema de seguimiento de ventas. La esencia del sistema de trabajo es
vender, pero el sistema de información le provee un soporte. El gestor de
proyectos declara la victoria cuando el sistema de información está operando
de la manera deseada, independiente de si las ventas se hacen o no
efectivamente.
Debe aclararse aquí que sistema de información se entiende en un sentido

amplio, lo cual involucra entidades humanas e infraestructura TI. En este
sentido el sistema de información se compone de un sistema informático,
también llamado sistema de información basada en ordenador, aparte de un
sistema no computacional.
Alter distingue aquí la visión de TI ('IT vision') y la visión de negocio ('business

vision').
a. Proyecto de sistema de información: visión de TI
Según Alter un proyecto de sistema de información, desde la visión de TI es un proyecto cuyo

objetivo inmediato es construir o modificar software. La victoria se declara cuando el software
satisface requerimientos y es aceptado por los usuarios y/o sus directivos.
b. Proyecto de sistema de información: visión de negocios
Según Alter un proyecto de sistema de información, desde la visión de negocios, es un

proyecto cuyo objetivo inmediato es mejorar un sistema de trabajo. La victoria se declara
cuando el sistema de trabajo satisface objetivos de negocio y cuenta con un mecanismo para
continuar cambios de manera exitosa.
b. Proyecto de ingeniería de software
Según Thayer los proyectos de Ingeniería de Software son frecuentemente
partes de proyectos mayores que incluyen equipamiento (hardware), servicios
(facilities), personal y procedimientos. Ejemplos son sistemas de vuelo,
sistemas de contabilidad, sistemas de radar, sistemas de control de inventarios
y sistemas de control ferroviario.
Thayer añade que este tipo de proyectos puede considerarse un proyecto de

software cuando el producto del proyecto es un software; aunque también
debemos considerar el software como producto y vehículo de entrega al mismo
tiempo.
3.1.3 Según dimensión del trabajo
Aquí el proyecto se distingue por el tipo de trabajo a realizar sobre los

materiales, el cual puede ser a medida o una adaptación.
a. Proyecto para construir algo nuevo o a medida
Aquí se elabora una solución que se plasma en un software y/o infraestructura

hecho a la medida o nuevo. Un ejemplo de este tipo es el desarrollo de un
sistema de información para una actividad organizacional específica o para un
área vertical de servicios como lo es sanidad.
67
b. Proyecto de adaptación
Aquí se elabora una solución que involucra la adaptación de un software y/o

infraestructura. Por ejemplo, aquí tienen cabida los desarrollos de aplicaciones
ERP que requieren adaptación de código fuente.
3.1.4 Según dimensión de desarrollo
Esta dimensión permite caracterizar el proyecto según la actividad de

desarrollo que se ejecuta o el modelo de desarrollo que se sigue.
Las actividades son fases del desarrollo, las cuales se organizan u ordenan en
procesos descritos en la literatura como modelos o paradigmas1 de desarrollo.
1
Un paradigma de desarrollo de software o de sistemas de información, puede decirse, es un
arquetipo o modelo de ciclo de vida de un software, el cual sirve para construir un producto
informático. Existen varias formas, en todas las cuales cambia la forma de ejecutar etapas de
análisis, diseño, construcción, programación y manutención.
3.1.4.1 Fases de desarrollo
A continuación se describen las fases de desarrollo, para luego mostrar luego

algunos de los paradigmas o modelos más distintivos.
Las fases de desarrollo habituales o más frecuentes son:
b. Diseño;
c. Implementación;
d. Prueba;
e. Entrega y Mantenimiento.
A continuación cada una de ellas se describe brevemente.
a.- Análisis de requerimientos
El análisis de requerimientos pretende resolver la pregunta ¿cuál es el

problema?, o 'el qué', cuya respuesta debe permitir identificar:
- las funciones a desarrollar y el dominio de información a manejar;
- las posibles ampliaciones;
- el monto y tipo de documentación;
- las características y funciones de desempeño, comportamiento, rendimiento y

las interconexiones lógicas; y,
68
- el estudio de Factibilidad Técnico, Social, Económico y Político.
Figura 3.1: Análisis como puente entra la ingeniería y el diseño de software.
Las tareas y documentos (o información) a generar son:
- Reconocer el Problema: Necesidades, Alcance general, Plan del problema,

Análisis de riesgos, Especificación del Problema.
- Evaluación y Síntesis: Alcance detallado, Flujos de información,

Restricciones, Prototipos.
- Modelamiento del Proyecto: Criterios de validación, de acuerdo a las

alternativas se escoge una y se realiza un modelamiento extensivo sobre ella.
- Especificación: Modelamiento del sistema, donde se especifica todo lo que

se requiere.
- Revisión: Ajustes, detalles o errores, Necesidades nuevas del usuario,

Ajustes de calendarización de riesgos, Monitoreo y Control.
Puede dividirse en cinco áreas de esfuerzo:
• Reconocimiento del problema.

• Evaluación y síntesis.
• Modelado.
• Especificación.
• Revisión.
El modelo de análisis debe lograr tres objetivos primarios:
• Describir lo que requiere el cliente.

• Establecer una base para la creación de un diseño de software.
69
• Definir un conjunto de requisitos que se pueda validar una vez que se

construye el software.
Figura 3.2: Los elementos del modelo de análisis.
Podemos notar que en el centro se encuentra el diccionario de datos que es un

almacén que contiene definiciones de todos los objetos de datos consumidos y
producidos por el software.
Tres diagramas diferentes rodean al núcleo:
El diagrama de entidad-relación DER representa las relaciones entre los

objetos de datos, actividad de modelado de datos; los atributos de cada objeto
de datos se pueden describir mediante una descripción de objetos de datos.
El diagrama de flujos de datos DFD sirve para:
• Proporcionar una indicación de cómo se transforman los datos a

medida que se avanza en el sistema.
• Representar las funciones que transforman el flujo de datos,
proporcionan información adicional.
El diagrama de transición de datos DTE indica como se comporta el sistema

como consecuencia de sucesos externos.
b.- Diseño
El diseño es una fase intensiva en conseguir responder la pregunta ¿cuál es la

solución?, solución que se representa con detalle y precisión en un modelo del
sistema que permita ver de qué manera se resuelven los problemas del
usuario. Básicamente se traducen los requisitos de software a un conjunto de
70
representaciones adecuadas a su posterior programación en lenguaje de

máquina.
La documentación incluye:
• Estructura de datos.
• Arquitectura del software.
• Interface humano-ordenador.
• Procedimientos algorítmicos.
La tarea de diseño también produce:
• El diseño de datos que transforma el modelo del dominio de información

que se crea durante el análisis en las estructuras de datos que se
necesitarán para implementar el software.
• El diseño arquitectónico que define la relación entre los elementos
estructurales principales del software, los patrones de diseño que se
pueden utilizar para lograr los requisitos que se han definido para el
sistema, y las restricciones que afectan a la manera en que se pueden
aplicar los patrones de diseño arquitectónicos.
• El diseño de la interfaz, que describir la manera de comunicarse el
software dentro de sí mismo, con sistemas que interoperan dentro de el
y con las personas que lo utilizan.
• El diseño a nivel de componentes, que transforma los elementos
estructurales de la arquitectura del software en una descripción
procedimental de los componentes del software.
c.- Implementación
En esta fase se desea responder la pregunta ¿cómo se construye la solución?.

La respuesta se consigue con la transformación del diseño en una aplicación
ejecutable, proceso que consiste básicamente en la traducción de las
representaciones de software a formas comprensibles por las máquinas.
Para esto se utilizan lenguajes de programación que generan el código fuente,

siendo necesario hacer la inspección del código, como:
• uniformidad en la escritura;
• carencia de ambigüedades;
• pureza sintáctica;
• semántica del problema y no de la tecnología;
• compactación del código en unidades lógicas distinguibles (librerías,
rutinas, procedimientos);
• localización precisa del código que satisface un requerimiento; y,
• linealidad o seguimiento de un flujo lógico y coherente.
Otras características necesarias son:
• facilidad de traducción (diseño-código);

• eficiencia de compilación;
71
• portabilidad;
• disponibilidad de herramientas y ambientes de desarrollo; y,
• facilidad de manutención: lenguajes de programación.
d.- Prueba
La Fase de prueba pretende responder la pregunta ¿ha sido resuelto el

problema?, lo cual significa determinar si la solución que ha sido construida
coincide con los requerimientos.
Los principios de una prueba son:
• A todas las pruebas se les debería poder hacer un seguimiento hasta los
requisitos del cliente.
• Las pruebas deberían planificarse mucho antes de que empiecen.
• Las pruebas deberían empezar primero 'por lo pequeño' y luego
progresar hacia 'lo grande'.
• Deberían ser conducidas por un equipo independiente.
Los tipos de prueba son: prueba de caja blanca, prueba de caja negra, prueba
de unidad y prueba de validación.
- Prueba de caja blanca
La prueba de caja blanca es un método de diseño de casos de prueba que usa

la estructura de control del diseño procidemental para obtener los casos de
prueba. Mediante los métodos de prueba de caja blanca, el ingeniero del
software puede obtener casos de prueba que:
Garantice que se ejerciten por lo menos una vez todos los caminos
independientes de cada módulo.
- Se ejerciten todas las decisiones lógicas en sus vertientes verdadera y falsa.
- Se ejecuten todos los bucles en sus límites y con sus límites operacionales.
- Se base en el minucioso examen de los detalles de los procedimientos.
- Prueba de la caja negra
La prueba de Caja negra se centra en los requisitos funcionales del software.

Permite al ingeniero del software obtener conjuntos de condiciones de entrada
que ejerciten completamente todos los requisitos funcionales de un programa.
La prueba de caja negra no es una alternativa a las técnicas de prueba de caja
blanca. Más bien se trata de un enfoque complementario que intenta descubrir
diferentes tipos de errores que los métodos de caja blanca
Intenta encontrar errores de las siguientes categorías:
- Funciones incorrectas o ausentes.
72
- Errores de interfaz.
- Errores en estructuras de datos o en accesos a bases de datos externas.
- Errores de rendimiento.
- Errores de inicialización y terminación.
- Prueba de unidad
Centra el proceso de verificación en la menor unidad del diseño del software: el

módulo. Está orientada a caja blanca y este paso se puede llevar a cabo en
paralelo para múltiples módulos. Las pruebas que se dan como parte de la
prueba de unidad son:
- La prueba de interfaz del módulo para asegurar que la información fluye de

forma adecuada hacia y desde la unidad de programa que está siendo
probada.
- La prueba de estructuras de datos locales para asegurar que los datos que se
mantienen temporalmente conservan su integridad durante todos los pasos de
ejecución del algoritmo.
- Se prueban las condiciones de límite para asegurar que el módulo funciona

correctamente en los límites establecidos como restricciones de
procesamiento. Se ejercitan los caminos independientes de la estructura de
control con el fin de asegurar que todas las sentencias del módulo se ejecutan
por lo menos una vez.
- Finalmente, se prueban todos los caminos de manejo de errores.
- Prueba de validación
La validación se consigue cuando el software funciona de acuerdo con las

expectativas razonables del cliente. Se llevan a cabo dos pruebas:
- La prueba Alfa se realiza en el lugar de desarrollo pero por un cliente. Se usa

el software de forma natural con el desarrollador como observador del usuario y
registrando los errores y problemas de uso.
- La prueba Beta se lleva a cabo por los usuarios finales del software en sus
respectivos lugares de trabajo. Como el desarrollador normalmente no está
presente, la prueba beta es una aplicación en vivo del software en un entorno
que no puede ser controlado por él. Es el cliente quien registra los problemas y
los informa al desarrollador.
- Prueba del sistema
73
Su propósito primordial es probar profundamente el sistema, verificando que se

hallan integrado adecuadamente todos los elementos del sistema y que se
realizan las funciones apropiadas.
e.- Entrega y mantenimiento
Mientras la entrega pretende que el cliente pueda usar la solución y tenga

garantías de que es operativo, la Fase de mantenimiento busca responder la
pregunta ¿se necesitan mejoras /cambios? del tipo:
- Correctivo, para reparación de errores;
- Adaptivo, para modificar el software adaptándolo a los cambios del ambiente

de trabajo;
- Perfectivo, para proveer nuevas funcionalidades de nuevos requerimientos;

y/o,
- Preventivo, para mejorar la manutención del sistema y anticipar errores.
Existen los siguientes tipos de mantenimiento:
- Mantenimiento Correctivo: Diagnostica y corrige errores. Representa altos

costos.
- Mantenimiento Adaptativo: Se presenta cuando es necesario un cambio de

ambiente plataforma de trabajo.
- Mantenimiento Perfectivo: Se realiza cuando se quieren hacer

mejoramientos y adición de nuevas capacidades.
- Mantenimiento Preventivo: Para el mejoramiento de la mantenibilidad futura.
En el mantenimiento se presentan problemas cuando:
- no se documentan los cambios;
- no se comprende el trabajo ajeno;
- falta documentación;
- el diseño es inadecuado;
- hay mala actitud hacia la manutención misma; y/o
- todas las fases del desarrollo deben considerar la mantenibilidad, con el costo
que ello implica.
74
3.1.4.2 Modelos de desarrollo
La elección de la forma de desarrollo tiene un efecto significativo en el éxito del

proyecto. El paradigma es un proceso, cuya adecuación puede conducir a una
rápida completación, costo reducido, calidad mejorada y riesgo bajo. Un
proceso inadecuado o malo conduce a esfuerzos de trabajo duplicados,
problemas en la programación y creación continua de problemas de gestión.
El proceso es una serie de pasos que se deben seguir para lograr objetivos.
Específicamente, el proceso del software es un marco de trabajo de las tareas
que se requieren para construir software de alta calidad.
Es necesario hacer diferencia entre "proceso" e ingeniería de software. Un

proceso de software define el enfoque a tomar cuando el software es tratado
por la ingeniería. La ingeniería de software también comprende las tecnologías
que tiene el proceso -métodos técnicos y herramientas automatizadas.
Surgidos a finales de los años 60 e inicios de los 70, los paradigmas de

desarrollo son hoy por hoy el marco más usado de referencia para describir el
proceso de desarrollo de un proyecto informático o la construcción de la
solución informática. También llamados modelos de ciclo de vida del software,
describen los pasos a seguir, los puntos de terminación, los subproductos a
entregar y fases a seguir.
Lo que se persigue con estos modelos de proceso de software es que producto

o solución informática sea:
• Comprensible, claro y bien definido en sus detalles y en el trabajo

realizado.
• Bien construido, se encuentre desarrollado con herramientas
automatizadas que permitiesen el trabajo de 'oficina' y den espacio al
trabajo más creativo.
• Confiable, al permitir detectar errores a tiempo o se minimice su
presencia.
• Robusto, en el sentido que puede seguir operando bajo condiciones de
fallo o error.
• Mantenible, o que se pueda ajustar a cambios futuros con facilidad.
• 'Barato', es decir, construido en el tiempo adecuado y dentro de
presupuestos convenientes.
A continuación, algunos de los modelos más característicos:
- Modelo de Cascada.
- Modelos de Procesos Incrementales:
- Modelo Incremental.
- Modelo RAD.
75
- Modelos de Procesos Evolutivos:
- Prototipado.
- Modelo Espiral.
- Modelo de Desarrollo Concurrente.
- Modelos de Procesos Especializados:
- Desarrollo a base de Componentes.
- Modelo del Método Formal.
- Desarrollo de software Orientado a Objetos.
- Proceso Unificado.
Luego, se destaca el e-Project como un caso especial de alta relevancia a e-

Business.
a.- Modelo en cascada
Es el más básico de todos los modelos de ciclo de vida y de hecho sirve de

base para otros modelos. Fue originalmente documentado por Royce en el año
1970, lo que lo convierte en el paradigma de ingeniería de software más
antiguo. El modelo de cascada ve el desarrollo como una secuencia simple de
fases (figura 3.3) que empieza con la especificación de requerimientos y
prosigue con la planificación, modelamiento, construcción y desarrollo,
culminando en el soporte del software completo.
En cada fase se debe realizar un proceso de verificación y validación (V&V,

Validación: ¿estamos construyendo correctamente el producto?; Verificación:
¿estamos construyendo el producto correcto?).
Este modelo de trabajo se basa en los siguientes principios básicos:
• Plan de Proyecto antes de embarcarse en él.

• Definición del comportamiento externo del sistema deseado.
• Documentación de los resultados de cada actividad.
• Diseño del sistema previo a la codificación.
• Prueba del sistema antes de su construcción.
Figura 3.3: Modelo en cascada.
76
El modelo original incluía además bucles de retroalimentación; sin embargo, la

mayoría de las organizaciones que aplican este modelo de procesos lo utilizan
secuencialmente y de forma lineal.
Este modelo funciona cuando los requerimientos del problema son razonables
y bien comprendidos, y el riesgo de inestabilidad es bajo. En los últimos
tiempos se ha cuestionado la eficiencia del modelo en cascada. Algunas de las
razones son las siguientes:
• Los proyectos reales raramente siguen un orden secuencial.

• Usualmente es difícil lograr que el cliente otorgue requerimientos
explícitos a alto nivel.
• El cliente debe ser paciente y esperar a ver resultados al final del
proceso. Se produce un caos cuando un error grave es detectado en
una etapa muy avanzada del proyecto de software.
b.- Modelos incrementales
En situaciones en las que los requerimientos iniciales están bien definidos, pero
que según el alcance del proyecto existe la posibilidad de que el desarrollo no
sea linear, se provee de un modelo de procesos que está diseñado para
producir software por incrementos. Para ello, limitan la funcionalidad del
software para que pueda ser revisado por el cliente y que éste a su vez lo
refine para tenerlo listo en la siguiente fase del proyecto.
b.1- Modelo incremental
El modelo incremental combina los elementos del modelo de cascada,

aplicándolo de forma iterativa. Aplica secuencias lineares a modo de fases,
como progresos de tiempo calendario. Cada secuencia linear produce
"incrementos" entregables del software.
El modelo de procesos incremental es iterativo por naturaleza. Sin embargo,

este modelo se enfoca en la entrega de un producto operacional con cada
incremento.
El desarrollo incremental es particularmente útil cuando el personal no está

disponible para hacer una implementación completa para la fecha acordada
con el cliente. Los incrementos de etapa temprana pueden ser ejecutados por
una menor cantidad de personas.
77
Figura 3.4: Modelo incremental.
b.2.- Modelo RAD
Es un modelo de proceso en cascada que enfatiza un ciclo de desarrollo

extremadamente corto.
Figura 3.5: Modelo RAD.
El Modelo RAD es una adaptación a alta velocidad del modelo lineal secuencial
en cascada, en el que se enfatiza un ciclo de vida extremadamente corto
(figura 3.5), utilizando un enfoque de construcción basado en componentes o
de módulos reutilizables, y haciendo especial hincapié en el uso de entornos
4GL1 e IPSE2, bibliotecas de componentes o módulos, orientación al objeto,
etc.
78
Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el

proceso RAD permite al equipo de desarrollo crear un sistema completamente
funcional dentro de períodos cortos de tiempo, como por ejemplo en un período
de 60 a 90 días.
No es adecuado en entornos tecnológicos nuevos o en entornos que requieran

interoperatividad con aplicaciones existentes pues, por ejemplo, no se dejará el
tiempo suficiente para pruebas de integración.
Cuando se lo utiliza principalmente para aplicaciones de sistemas de

información este enfoque comprende las siguientes fases.
• Modelado de Gestión. El flujo de información entre las funciones de

gestión se modela de forma que responda a las siguientes preguntas:
- ¿Qué información conduce el proceso de gestión?
- ¿Qué información se genera?
- ¿Quién la genera?
- ¿A dónde va la información?
- ¿Quién la procesa?
• Modelado de Datos. El flujo de información definido como parte de la

fase de modelado de gestión se refina como un conjunto de objetos de
datos necesarios para apoyar la empresa. Se definen las características
de cada uno de los objetos y las relaciones entre estos objetos.
• Modelado de Proceso. Los objetos de datos definidos en la fase de
modelado de datos quedan transformados para lograr el flujo de
información necesario para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir, o
recuperar un objeto de datos.
• Generación de Aplicaciones. El RAD asume la utilización de técnicas
de cuarta generación. En lugar de crear el software con lenguajes de
programación de tercera generación por ejemplo, un lenguaje de
programación), el proceso RAD trabaja para volver a utilizar
componentes de programas ya existentes cuando esto es posible, o se
crean componentes reutilizables cuando es necesario. En todos los
casos se utilizan herramientas automáticas para facilitar la construcción
del software.
• Pruebas y entrega. Como el proceso RAD enfatiza la reutilización, ya
se han comprobado muchos de los componentes de los programas. Esto
reduce el tiempo de pruebas. Sin embargo, se deben probar todos los
componentes nuevos y se deben ejercitar todas las interfaces a fondo.
c.- Modelos evolutivos
79
Se sabe de antemano que el software al igual que todos los sistemas

complejos, evoluciona con el tiempo. En el modelo lineal secuencial se asume
que el sistema va a entregarse completo una vez que la secuencia lineal se
haya finalizado, así mismo en el modelo de construcción de prototipos se
diseña con la especifica idea de ayudar al cliente a comprender los requisitos,
en ninguno de estos modelos se toma en cuenta la naturaleza evolutiva del
software.
Los modelos evolutivos se caracterizan por desarrollar versiones cada vez mas
completas del software.
c.1.- Modelo en espiral
El Modelo en espiral surge como medio para enfrentar grandes sistemas

compuestos de muchos subsistemas, en cuyo caso se puede seguir un
prototipado para especificaciones de alto riesgo y un modelo en cascada para
desarrollos claros.
Proporciona el rápido desarrollo de versiones increméntales de software, estas

versiones se pueden considerar como un prototipo. En este modelo el radio
representa el costo, una distinción importante es que el producto estará
terminado al finalizar el espiral, no al terminar cada ciclo.
El Modelo en espiral fue propuesto por Bohem como un modelo híbrido

caracterizado por:
• combinar la naturaleza iterativa de construcción de prototipos con los

aspectos controlados y sistemáticos del modelo en cascada;
• no se fijan fases, las fases las decide el gestor del proyecto;
• el producto surge en una serie de versiones incrementales;
• el modelo se divide en tareas; y,
• pueden existir áreas o regiones de tareas (entre 3 y 6).
80
Figura 3.6a: Modelo en espiral.
Figura 3.6b: Modelo en espiral.
Tales áreas son:
• Comunicación con el cliente.

• Planificación y re-planificación para (re)definir recursos, tiempos, etc.
• Análisis de riesgos técnicos y de gestión.
• Ingeniería para construir representaciones de la aplicación, software o
solución informática.
81
• Construcción y adaptación, prueba y soporte al usuario.

• Evaluación y análisis de reacción del cliente.
Según la figura anterior, se progresa del centro de la espiral en el sentido de

las agujas del reloj, especificando progresivamente subproductos y/o versiones
mejoradas y más sofisticadas del producto final, construyendo prototipos para
garantizar el trabajo futuro.
El modelo se basa en los principios de:
• flexibilidad;
• eliminación temprana de errores;
• integración de desarrollo y mantenimiento; y,
• reutilización.
c.2.- Modelo de construcción de prototipos
Un paradigma de construcción de prototipos puede ofrecer un mejor enfoque

cuando:
• Un cliente define un conjunto de objetivos generales para el software,

pero no identifica los requisitos detallados de entrada, procesamiento o
salida.
• El responsable de desarrollo del software puede no estar seguro de la
eficacia de un algoritmo, de la capacidad de adaptación de un sistema
operativo, o de la forma en que debería tomarse la interacción hombre-
máquina.
82
Figura 3.7: Modelo de construcción de prototipos.
• El desarrollador y el cliente encuentran y definen los objetivos globales

para el software, identifican los requisitos conocidos, y las áreas del
esquema en donde es obligatoria más definición.
• Se realiza un diseño rápido. Este diseño se centra en una
representación de esos aspectos del software que serán visibles para el
usuario/cliente como por ejemplo los enfoques de entrada y formatos de
salida.
• Luego el diseño rápido lleva a la construcción de un prototipo el cual es
evaluado por el cliente/usuario y utilizado para refinar los requisitos del
software a desarrollo.
• Finalmente, la interacción ocurre cuando el prototipo satisface las
necesidades del cliente, a la vez que permite que el desarrollador
comprenda mejor lo que se necesita hacer.
• En la mayoría de los casos, el primer sistema por lo general es
demasiado lento, grande o torpe en su uso por lo cual la mayoría opta
por desecharlo y comenzar el desarrollo de uno nuevo, corrigiendo las
deficiencias encontradas en el primer prototipo, que surgieron durante
las evaluaciones con el cliente / usuario.
1
4GL, Fourth generation language: Lenguaje de alto nivel, usualmente no procedural, que
permite a usuarios sin mucha experiencia programar aplicaciones de bases de datos. Por
ejemplo, el lenguaje SQL (Structured Query Language).
2
IPSE, Integrated Project Support Environment: Término usado para designar un conjunto de
herramientas técnicas y de gestión destinadas a dar soporte al desarrollo de un software,
usualmente dentro de marco integrado y coherente de trabajo.
83
3.1.4.3 Modelo e-Project
Este tipo de proyectos requiere especial atención dada su relevancia en un

proyecto e-Business. Por definición, un e-Project es un proyecto de naturaleza
informática que involucra crear o cambiar código fuente desplegado sobre
Internet. Esto incluye trabajar con contenidos en HTML o applets en Java y
ActiveX. Los proyectos que entran en esta categoría marcan un efecto
significativo en la manera en que las empresas manejan sus negocios.
McKinsey & Inc. han mostrado que aquellos proyectos completados a tiempo y
con presupuesto excedido de un 50%, han resultado ser un 25% más rentables
que proyectos completados dentro de los presupuestos pero 6 meses más
tarde. Gracias a e-Business, estos resultados se amplifican moviéndose a la
velocidad del tiempo Internet ('Internet time'). Esta comprensión del tiempo,
marcada además por presiones de mercado, es un reto para los directores de
proyecto.
Un e-Project se distingue de otros proyectos por:
• La frecuencia de liberación de un resultado es menor, típicamente días o

pocos meses.
• El alcance del producto entregado es más pequeño, por ejemplo,
cambiar una sola aplicación o corregir un bug.
• El proceso seguido es iterativo.
La tabla 3.1 muestra otras diferencias.
Diferencias entre un proyecto tradicional y un e-Project
Proyecto tradicional e-Project
Recogida de
Riguroso Limitado
requerimientos
Especificaciones
Robusto Descriptivo
técnicas
Duración del proyecto Años Días, semanas o meses
Esfuerzo por
Prueba y calidad Enfoque en control del riesgo
conseguir objetivos
Gestión del riesgo Explícito Inherente
Vida media del producto

18 meses o más 3 a 6 meses o menos
entregado
Proceso de entrega Riguroso Expedito
Requiere un esfuerzo Obtenido automáticamente de la

Servicio post-entrega
proactivo interacción con el usuario
Tabla 3.1. Diferencias entre un proyecto tradicional y un e-Project.
Existen tres tipos de e-Project:
84
• Nueva construcción.
• Remodelamiento.
• Manutención.
Estos proyectos se distinguen entre sí, tanto por su duración y la naturaleza de

lo que se hace en ellos, como por las actividades a realizar. Sobre esto último
se debe destacar que por ser proyectos más rápidos y a trabajar sobre
problemas, situaciones o productos más pequeños, requieren menos tareas a
cumplir, no obstante se clama que es mejor no seguir proceso alguno.
a.- Project de nueva construcción
En este tipo de proyectos de tamaño medio podrían incluirse como ejemplos la

construcción de una casa o un análisis costo/beneficio, entre otros. En este tipo
de proyectos toma pocos meses completar la implementación inicial. Por
ejemplo, un e- Shop o un B2B.
Respecto del proceso a seguir es conveniente una implantación acelerada, por

este motivo, en caso de seguir fases, pasos o etapas, estos deben ser pocos y
efectivos. La figura 3.8 Muestra las etapas de e-Project: descubrimiento,
diseño, desarrollo y despliegue.
• La fase de descubrimiento se enfoca al análisis del negocio del proyecto.

Por ejemplo, un análisis de requerimientos, un análisis de negocio o una
re-ingeniería.
• La fase de diseño es usada para crear el documento de requerimientos,
especificaciones técnicas y criterios de aceptación.
• La fase de desarrollo es para la programación, diseño gráfico,
implantación técnica y criterios de calidad.
• La fase de despliegue incluye actividades de marketing y otras
actividades de post- entrega como servicio al cliente y operaciones.
Figura 3.8: e-Project de nueva construcción.
b.- Project de remodelamiento
Son proyectos de cambio, sea añadir, quitar y/o modificar. Se caracterizan

porque los cambios se realizan, mientras se mantiene el servicio on-line. Estos
proyectos pueden durar semanas.
85
El proceso a seguir en el remodelamiento debe ser acelerado y, por

consiguiente, incluir pocas fases. Usualmente el descubrimiento y el despliegue
son asociadas al proyecto como un todo, a excepción de nuevos
requerimientos, salvo que tenga un impacto mayor que requiera una nueva
construcción.
La figura 3.9 muestra el proceso a seguir, el cual involucra principalmente

diseño y desarrollo.
Figura 3.9: e-Project de remodelamiento.
• La fase de diseño se dedica a cambiar documentación para introducir,

eliminar y/o cambiar especificaciones y/o diseños.
• La fase de desarrollo se dedica a generar nuevos programas y
probarlos, cambiar diseños gráficos, implantación técnica y, consecución
de criterios de calidad existentes y creación de nuevos criterios.
c.- Project de manutención
Son proyectos de mantenimiento similares a cualquier otro, no obstante, se

distinguen porque son en tiempo real. Aquí se incluyen trabajos para eliminar
bugs fijos o hacer mejoras menores a un software, cambios de contenido u
otras tareas cotidianas. Estos proyectos duran pocos días.
El proceso de manutención no sigue un patrón formal de ejecución como en los

casos anteriores, más bien debe contar con procesos de liberación de
productos que sean breves, rápidos y eficientes, pero lo suficientemente
rigurosos que posibiliten una rápida gestión de la configuración1.
Esta liberación de productos, que principalmente son correcciones, puede

conseguirse con páginas o templates de mantenimiento en los cuales los ítems
descriptivos de un mantenimiento queden registrados en bases de datos para
efectuar su seguimiento. Tales ítems pueden ser:
• fecha de la liberación,
• nombre del solicitante,
• nombre de los involucrados en el mantenimiento,
• número de versión,
• descripción de la tarea realizada,
• detalle de la tarea realizada,
86
• páginas de mantenimiento previas afectadas,

• esfuerzo estimado,
• esfuerzo real,
• urgencia,
• fecha de inicio,
• fecha de término,
• fecha de actualización (upload),
• firma de calidad, y
• visto bueno del director de proyecto o responsable designado.
1
Gestión de la configuración. Por definición la gestión involucra identificar y definir las partes
del sistema, controlar los cambios a los largo del ciclo de vida, registrar e informar el estado de
las partes y los requisitos de cambio, y verificar la completitud y correctitud de las partes o
componentes. En términos de control de la configuración, después de establecer la
configuración del sistema informático, es el proceso de evaluar y aprobar cambios a la
configuración y a las interrelaciones entre los componentes del sistema.
3.1.5 Según dimensión organizacional
Esta dimensión permite distinguir un proyecto según las diferentes formas

organizacionales que se ven involucradas en un proyecto. En esta dimensión
se distingue la estructura organizacional de un proyecto, la cual posee una
estructura de equipo.
a.- Estructura organizacional
La estructura organizacional frecuentemente condiciona la disponibilidad o los

términos en los que se puede disponer de los recursos para el proyecto. Las
estructuras organizacionales de un proyecto cubren un amplio espectro que va
desde la estructura funcional a la organización por proyectos, con distintos
tipos de estructuras matriciales entre ambas. La tabla 3.2 detalla las
características clave de los principales tipos de estructuras de organización
reseñadas.
Estructura de la
Matricial
Organización Orientada a
Funcional
proyectos
Características Matricial Matricial Matricial
del proyecto Débil Equilibrada Fuerte
Autoridad del
Poca o Baja a Moderada a Alta a casi
director del Limitada
ninguna moderada alta total
proyecto
Disponibilidad de Poca o Baja a Moderada a Alta a casi

Limitada
recursos ninguna moderada alta total
Quien controla el
Gerente Gerente Director del Director del
presupuesto del Combinación
funcional funcional proyecto proyecto
proyecto
Rol del director Dedicación Dedicación Dedicación Dedicación Dedicación

del proyecto parcial parcial completa completa completa
Personal Dedicación Dedicación Dedicación Dedicación Dedicación
87
administrativo de parcial parcial parcial completa completa

la dirección de
proyectos
Tabla 3.2. Características de estructuras organizacionales1.
a.1.- Estructura organizacional funcional
La organización funcional clásica mostrada en la figura 3.10 es jerárquica, en

la que cada empleado tiene un superior definido. El personal está agrupado por
especialidades, como producción, marketing, ingeniería y finanzas en el nivel
más alto; con la ingeniería dividida además en mecánica y eléctrica.
Las organizaciones funcionales todavía tienen proyectos, pero lo que perciben

de dichos proyectos se restringe a lo que son sus funciones: el departamento
de ingeniería de una organización funcional hará su trabajo
independientemente de los departamentos de fabricación o marketing.
Por ejemplo, cuando se lleva a cabo el desarrollo de un nuevo producto en una

organización puramente funcional, la fase de diseño se denomina
frecuentemente proyecto de diseño e incluye únicamente personal del
departamento de ingeniería. Si aparecen dudas o preguntas sobre la
fabricación, éstas se trasladan al jefe del departamento, quien las consulta con
el jefe del departamento de fabricación. El jefe del departamento transmite
después la respuesta al director del proyecto de ingeniería.
Figura 3.10: Estructura organizacional funcional.
a.2.- Estructura organizacional por proyectos
En el lado contrario del espectro está la organización por proyectos mostrada

en la figura 3.11. En una organización por proyectos, los miembros del equipo
están a menudo asignados permanentemente. La mayoría de los recursos de
la organización intervienen en las labores del proyecto y los directores de
88
proyecto tienen una gran independencia y autoridad. Las organizaciones por

proyectos tienen frecuentemente unidades de organización denominadas
departamentos, pero estos grupos, o informan directamente al director del
proyecto o proporcionan servicios de apoyo a los distintos proyectos.
Figura 3.11: Estructura organizacional por proyectos.
a.3.- Estructura organizacional matricial
Las organizaciones matriciales, como las mostradas en la figura 3.12 y la

figura 3.13 son una mezcla de las organizaciones funcionales y por proyectos.
Las matrices débiles mantienen muchas de las características de una
organización funcional y el papel del director del proyecto es más el de un
coordinador o activador, que el de director. Del mismo modo, las matrices
fuertes tienen muchas de las características de las organizaciones por
proyectos directores trabajando totalmente para el proyecto con considerable
autoridad y un equipo administrativo dedicado totalmente al proyecto.
Figura 3.12: Estructura organizacional matricial débil.
89
Figura 3.13: Estructura organizacional matricial equilibrada.
Figura 3.14: Estructura organizacional matricial fuerte.
a.4.- Estructura organizacional mixta
Figura 3.15: Estructura organizacional mixta o compuesta.
90
Las organizaciones más modernas comprenden todas estas estructuras a

distintos niveles, como muestra la figura 3.15. Por ejemplo, incluso una
organización fundamentalmente funcional puede crear un equipo especial para
dirigir un proyecto concreto. Ese equipo puede reunir muchas de las
características de un proyecto en una organización por proyectos; puede incluir
incluso personal proveniente de diferentes departamentos funcionales, puede
desarrollar sus propios procedimientos operativos y puede funcionar fuera de la
estructura normal en lo relativo a información.
b.- Equipo de trabajo
Los equipos en un proyecto son organizados de muchas maneras, cada una de

las cuales tiene un efecto en la eficiencia de su desempeño. Una estructura de
proyecto inadecuado puede conducir a tiempos de desarrollo extensos, costos
altos, calidad pobre, mala comunicación y moral baja, además de una alta
rotación, todo lo cual puede conducir a la cancelación o término del proyecto.
No existen estructuras apropiadas a todos los proyectos informáticos, una

estructura de equipo responde a un orden y una organización única para un
determinado tipo de proyecto y para un determinado producto o servicio a
generar. Su re-usabilidad en otro proyecto podría ser desastrosa.
A continuación se muestran cuatro tipos habituales de estructuras de equipos

para proyectos:
• Isomórfico.
• Especialistas.
• Democrático.
• Programador líder.
b.1.- Equipo de proyecto isomórfico
Un equipo isomórfico se organiza según la estructura de los principales

módulos de software (figura 3.16). Cada miembro del equipo es asignado a un
módulo de software específico de inicio a fin. Las ventajas de esta estructura
son:
- es organizacionalmente simple;
- muchas tareas son desarrolladas de forma paralela; y
- las tareas pueden ser claramente definidas y comprendidas.
91
Figura 3.16: Equipo de proyecto isomórfico.
- Los equipos isomórficos son adecuados para proyectos donde los módulos de
software son relativamente independientes de cada otro.
- La mayor desventaja de este tipo de equipo es que puede conducir a

dificultades en la integración de módulos, por problemas de comunicación entre
desarrolladores.
b.2.- Equipo de proyecto de especialistas
En este tipo de estructura, cada miembro del equipo se dedica a resolver

asuntos y temas relativos a su área de conocimiento o experticia a lo largo de
todos los módulos o tareas a cumplir en un proyecto (figura 3.17).
La VENTAJA de este tipo de proyecto es que permite aprovechar al máximo el

potencial y la eficiencia de cada experto.
La DESVENTAJA es que surgen dificultades de integración, carencia de

unidad en el módulo (cada experto a lo suyo), y problemas de monitoreo y
seguimiento con relación a lo que aporta cada especialista.
Figura 3.17: Equipo de proyecto de especialistas.
b.3.- Equipo de proyecto democrático
Este tipo de estructura de equipo, llamado en ocasiones auto-gestionado,

posee una estructura relativamente informal (figura 3.18). Sus cualidades son:
92
- la toma de decisiones es compartida entre los miembros; y,
- la estructura promueve y fortalece la comunicación e interacción entre los

miembros.
Figura 3.18: Equipo de proyecto democrático.
La VENTAJA de este tipo de equipo es que trabaja bien para proyectos de

desarrollo mal definidos (ill-defined), esencialmente pequeños, donde la
innovación y la creatividad son más importantes que el cumplimiento de plazos
estrictos.
La DESVENTAJA es que no son efectivos. Sus fallas surgen debido a que sus
miembros, particularmente personas de gran talento, tiene un alto ego,
produciéndose conflictos más bien personales. Otro problema con estos
equipos es que tienden a evolucionar sin un liderazgo debido a su ausencia.
b.4.- Equipo de proyecto de programador líder
Esta estructura se crea para proyectos informáticos de gran complejidad. La

estructura, propuesta por IBM, es diametralmente opuesta a la democrática.
Con esta propuesta todas las decisiones importantes son realizadas por un
programador líder asistido por varios especialistas realizando funciones
detalladas de apoyo asignadas por el mismo líder (figura 3.19).
Figura 3.19: Equipo de proyecto de líder de programación.
93
Este planteamiento es conceptualmente similar a un equipo médico de cirugía,

donde el cirujano realiza la cirugía sobre el paciente asistido por un equipo de
asistentes especializados. En un desarrollo de software el programador líder es
respaldado por un asistente de líder, quien trabaja de manera cercana al líder y
es capaz de reemplazarle.
En este caso, el gestor de proyecto es un administrador y un proveedor de

recursos.
c.- Roles involucrados
En un proyecto existen diversos tipos de roles involucrados, algunos ligadas

directamente al hacer del proyecto y otros como agentes externos.
- Componentes considerados en el equipo del proyecto. En el primer grupo

tenemos, tomando de referencia a Pastor:
- Jefe de proyecto.
- Diseñadores lógicos.
- Diseñadores tecnológicos.
- Personal de control de calidad y de mejora del proceso de software.
- Personal informático enviado por contratistas.
- Personal informático impuesto o enviado por la organización cliente.
- Expertos (sean enviados por la organización cliente o no).
- Usuarios.
- Agentes externos al proyecto. En el segundo grupo se cuenta con la

presencia de:
- El cliente.
- El dueño.
- El promotor (sponsor).
- Los financieros.
- Consultores y asesores.
- Auditores.
- Directores o jefaturas organizacionales.
94
- Director de Sistemas de Información o Informática.
- Proveedores de hardware y software y abastecedores de insumos.
- Contratistas.
Uno nota sobre los proyectos y su constitución comunicativa
Para comprender un proyecto lo primero que hay que tener presente es que evoluciona según las necesidades
de adaptación que le impone el medio. Esto le lleva a buscar continuamente nuevas estructuras
organizacionales que le permitan subsistir a las diversas fases de desarrollo y a los cambios del medio, además
de buscar continuamente nuevos estados de sinergia que le permitan aprovechar al máximo los recursos con
que cuenta.
Con esto, las

diversas fases
de desarrollo
(o
construcción),
a la par de las
diversas fases
o etapas de
gestión que se
verán en el
siguiente
capítulo
(iniciación,
planificación,
control,
ejecución,
cierre),
incluyen
actores
diversos que
aparecen o
desaparecen
en las diversas
tareas y
actividades
consideradas
a discreción y
por
conveniencia
al proyecto, en
roles de
protagonista o
como un actor
secundario.
Según los
grados de
participación,
los actores se
posicionan
dentro de la
estructura
organizacional
del proyecto
que sea
conveniente al
95
momento, y se
relacionan
entre ellos
según la
configuración
de equipo de
trabajo que se
considere
pertinente.
Reconocer a
priori cuál será
la organización
del proyecto
por cada fase
no es sencilla.
Solamente se
puede tener
conciencia y
relativa
certeza que en
ciertas fases
determinados
actores son
necesarios con
un
determinado
grado de
participación o
actividad.
Según
nuestras
previsiones de
las tareas que
cada actor
cumplirá, y
considerando
que a lo largo
del proyecto
nuevos y más
actores
intervendrán, Evolución longitudinal de la estructura organizacional del proyecto.
la figura
siguiente,
puede ilustrar
la complejidad
de lo que
involucra el
proyecto.
96
Esta situación
solamente
refleja la
estructura
organizacional
del proyecto.
Pero,
conforme un
proyecto es un
transitorio, una
instancia
temporal y
situada de
esfuerzo
humano por
conseguir un
resultado
concreto a la
solución de un
conflicto social
y/u
organizacional,
los actores
partícipes del
proyecto en
ocasiones son
parte
intrínseca del
proyecto, o
sea,
contratados a
tiempo y
dedicación
total y absoluta
al proyecto, Integración transversal de organizaciones e individuos a la estructura organizacional del
mientras otros, proyecto.
y comúnmente
ocurre así,
provienen de
otras
organizaciones
tal como ilustra
la figura
siguiente.
97
Mientras la
evolución
longitudinal
obliga a tratar
con la
complejidad
del cambio
continuo, la
integración
transversal
obliga a
resolver el
problema
continuo de
mantener la
cohesión del
proyecto
especialmente
cuando hay
actores que
pueden
mantener
compromisos
con las
organizaciones
de donde
provienen.
Esta situación
obliga a
precisar
entonces que
un proyecto es
una sucesión
de encuentros
de personas a
lo largo del
tiempo,
encuentros El proyecto como un esfuerzo comunicativo.
que son ni
más ni menos
que reuniones
de trabajo
donde los
actores, sea
cara-a-cara o
a distancia,
exponen sus
avances,
resuelven
problemas y
comparten
experiencias.
98
Con esto, se
intenta dejar
en claro que el
proyecto
finalmente es
un esfuerzo de
comunicación
cuyo fin es la
cohesión e
integridad
estructural del
grupo
constitutivo del
proyecto.
Y, con esto, se
tiene en claro
que el principal
problema del
jefe o director
de proyecto es
crear, sostener
y apoyar los
lazos de
comunicación.
Fuentes:
Torrealba, Alvaro. (2000). La organización del proyecto. En Cuadernos de Ingeniería de Proyectos III: Dirección,
Gestión y Organización de Proyectos. Universidad Politécnica de Valencia. Valencia-España: UPV. 238 pp.
Estay, Christian; y, Blasco, Jaume. (2000). El universo de proyectos: una epistemología sistémica para
proyectos. En V International Congress of Project Engineering. LLeida, España. 4-6 Octubre.
Blasco, Jaume; Cisteró, Manuel-Jordi; Cremades, Lazaro V.; Estay, Christian A.; García, Águeda; Gracia,
Santos; y, Masarnau, Joan. (2001). Experiencia docente presencial-no presencial colaborativa en la formación
de Proyectos. En III Jornadas Multimedia Educatiu. Barcelona, España. 25-26 Junio.
1
PMBOK 2004 Fuente: "Guía de los Fundamentos de la Dirección de Proyectos". Project
Management Institute. Standards Committe. Asociación Española de Ingeniería de Proyectos.
1998, 162 pp; p. 17. Nota: Esta información debe considerarse referencial, pues cada proyecto
puede tener sus propias singularidades.
3.2 El problema del desarrollo

informático
3.2.1 No silver bullet... aclarar el problema de la ingeniería de
software
El software se ha convertido en un elemento clave en la evolución de los

sistemas y productos basados en computadoras y es una de las tecnologías
más importantes del mundo actual. En los últimos 50 años el software ha
99
evolucionado de ser una herramienta para resolver problemas especializados y

de análisis de información, a ser una industria en sí mismo. Sin embargo, aún
se tienen problemas para desarrollar software de alta calidad dentro del tiempo
y presupuesto establecido. El propósito de la ingeniería de software es el de
proveer un marco de referencia para construir software de alta calidad.
Actualmente el software ejecuta el rol de producto y vehículo para distribuir un

producto, a la vez. El producto que distribuye es el más importante de nuestro
tiempo, la información: transforma datos, administra la información de un
negocio, o provee una entrada hacia las redes de información a nivel mundial.
Junto con el rol protagónico del software, durante los últimos 50 años también
ha habido mejoras dramáticas en lo que respecta al rendimiento del hardware.
Sistemas complejos y sofisticados pueden generar resultados magníficos,
siempre y cuando sean exitosos, aunque representen un problema para
quienes los construyen.
La industria de software se ha convertido en un factor dominante en las

economías del mundo industrializado. El programador solitario ha sido
reemplazado por equipos de especialistas en software. Sin embargo, aún se
generan las mismas preguntas en el momento de desarrollar aplicaciones
complejas:
• Por qué toma tanto tiempo para terminar el software?

• Por qué los costos de desarrollo son tan altos?
• Por qué no se encuentran todos los errores antes de entregar el
producto al cliente?
• Por qué se tarda tanto tiempo y esfuerzo en mantener programas
existentes?
• Por qué existe dificultad en medir el progreso mientras el software es
desarrollado y mantenido?
a.- La naturaleza cambiante del software
Hasta el día de hoy, existen siete categorías de software que representan un

reto para los ingenieros de software:
• Software de sistema. Es una colección de programas escritos para

servir otros programas. Se caracterizan por tener una alta interacción
con el hardware, gran uso de múltiples usuarios, operaciones
concurrentes, distribución de recursos, estructuras de datos complejas e
interfases externas múltiples.
• Aplicación de software. Programas independientes que resuelven una
necesidad específica de negocio. Además del procesamiento
convencional de datos, es usado para controlar las funciones del
negocio en tiempo real.
• Software de ingeniería/científico. Antiguamente caracterizados por sus
algoritmos numéricos, estas aplicaciones van desde la astronomía a la
vulcanología, o desde la biología molecular a la manufactura automática.
100
Con el tiempo, los algoritmos numéricos están siendo reemplazados por

aplicaciones interactivas.
• Software incrustado. Es usado para implementar y controlar
características y funciones para el usuario final del producto o sistema
en el que reside, o para el sistema mismo.
• Software de línea de producción. Es diseñado para proveer de una
capacidad específica para el uso de muchos consumidores diferentes.
• Aplicaciones Web. En su forma más simple puede ser algo más que un
grupo de archivos de hipertexto que presentan información usando texto
y gráficos. Sin embargo, mientras el e-Commerce y las aplicaciones B2B
adquieren importancia, las aplicaciones web han evolucionado en
ambientes sofisticados que también se integran con las bases de datos
empresariales y las demás aplicaciones existentes en el negocio.
• Software de inteligencia artificial. Hace uso de algoritmos no
numéricos para resolver problemas complejos que no son disponibles
para un análisis computacional. En esta área se incluyen la robótica, los
sistemas expertos, el reconocimiento de datos, las redes neurales
artificiales, entre otros.
Millones de ingenieros de software son reacios a trabajar en proyectos que

pertenezcan a una o muchas de las categorías anteriores. En muchos casos,
las aplicaciones existentes están siendo corregidas, adaptadas o mejoradas, en
un ciclo que puede repetirse después de años de construido el software.
Otro tipo de retos que han aparecido a través de los años son los siguientes:
• Computación ubicua. El rápido crecimiento de las redes inalámbricas

pronto establecerá una computación distribuida real. El reto para los
ingenieros de software será el de desarrollar sistemas que permitan
comunicarse a través de enormes redes de datos a computadoras
personales, sistemas empresariales y dispositivos pequeños.
• Netsourcing. La World Wide Web se ha convertido rápidamente en una
máquina computacional además de un proveedor de contenido. El reto
para los ingenieros de software es el de diseñar aplicaciones simples y
sofisticadas que provean beneficios para usuarios finales en todo el
mundo.
• Código abierto. Una tendencia que ha crecido es la de distribuir código
fuente para aplicaciones de sistema, de manera que los consumidores
puedan realizar modificaciones locales. El reto para los ingenieros de
software es el de construir código fuente que sea auto descriptivo, y más
que nada, desarrollar técnicas que permitan al consumidor y al
desarrollador conocer los cambios que han sido hechos y las
consecuencias de su uso.
• La nueva economía. Los desastres financieros causados por las
compañías punto com a inicios de la década del 2000 ha hecho creer a
muchos que la nueva economía está muerta. Sin embargo, la nueva
economía está viva, evolucionando con lentitud. El reto para los
ingenieros de software es el de construir aplicaciones que faciliten la
comunicación y distribución de productos en masa, utilizando conceptos
que recién se están creando.
101
b.- La evolución del software
A través del tiempo, es inevitable que el software evolucione. El cambio

(referido como mantenimiento de software) conduce este proceso y ocurre
cuando se corrigen errores, se hacen adaptaciones para nuevos ambientes,
cuando el usuario solicita cambios funcionales, y cuando se realiza una
reingeniería de la aplicación para modernizarla.
En los últimos 30 años, Manny Lehman y sus colegas han efectuado análisis
detallados de la industria del software, con el fin de desarrollar una Teoría
Unificada para la Evolución del Software. Para ello establecieron algunas leyes
útiles para referencia:
• La ley del cambio continuo (1974). Sistemas e-Type1 deben ser

continuamente adaptados, o se convertirán menos satisfactorios
progresivamente.
• La ley de la complejidad incrementada (1974). A medida que un
sistema e-Type evoluciona, su complejidad también lo hace, a menos
que se haya tomado alguna medida para mantenerla o reducirla.
• La ley de la auto regulación (1974). La evolución de los sistemas e-
Type es auto regulada con la distribución de productos y medidas de
procesos cerca de lo normal.
• La ley de la conservación de la estabilidad organizacional (1980). El
promedio del índice de actividades globales efectivas en un sistema e-
Type en evolución es invariable sobre el tiempo de vida del producto.
• La ley de la conservación de la familiaridad (1980). A medida que un
sistema evoluciona, todos los elementos asociados a él deben mantener
el dominio de su contenido y comportamiento, para poder lograr una
evolución satisfactoria. El crecimiento incremental promedio se mantiene
invariable a medida que el sistema evoluciona.
• La ley del crecimiento continuo (1980). El contenido funcional de un
sistema e-Type debe ser incrementado continuamente, para mantener la
satisfacción del usuario durante el tiempo de vida del sistema.
• La ley del decrecimiento de la calidad (1996). La calidad de los
sistemas e-Type empezará a declinar a menos que los sistemas sean
rigurosamente mantenidos y adaptados a los cambios del ambiente.
• La ley del sistema de retroalimentación (1996). Los procesos
evolutivos constituyen sistemas de retroalimentación multiniveles,
multilazos, y multiagentes y deben ser tratados como tales para adquirir
una mejoría significativa.
Las reglas antes descritas son una parte inherente de la realidad de un

ingeniero de software. Es por ello que se deben implementar prácticas y
técnicas que conduzcan a mantener la calidad mientras el software evolucione.
1
Los sistemas e-Type son software que se han implementado en un contexto computacional
del mundo real y por lo tanto evoluciona con el tiempo.
102
3.2.2 Gestión de proyectos en informática
Sin ser una bala de plata, la gestión de proyectos en informática ha cobrado

relevancia frente al reto del cambio de siglo (problema conocido como Y2K), el
cambio al euro o la simple globalización. Ante ello se exige que un gestor de
proyectos sea capaz de abordar cualquier tipo de proyecto informático,
manejando equipos multidisiciplinarios en su pluralidad curricular, cultural,
social y psicológica.
No obstante, la gestión de proyectos desde la perspectiva formal del PMBOK

es una desconocida en la Informática. A pesar de esto último, la Ingeniería de
Software intenta proveer métodos, técnicas y herramientas de desarrollo,
dentro de las cuales se incluyen algunas orientadas o consideradas de la
gestión. En tal sentido, este apartado presenta el significado que adquiere la
gestión de proyectos en informática.
3.2.2.1 Los problemas comunes en Informática
Para entender el rol de la gestión de proyectos en la Informática es conveniente

comenzar comprendiendo los problemas que existen en los proyectos
informáticos.
a.- Tipos de problemas comunes
Podemos decir que hay tres 'problemas comunes', dos de ellos habituales y, un
tercero, de índole social.
a.1.- Necesidades no satisfechas o no identificadas
En el caso de las necesidades no satisfechas o no identificadas, el error puede

aparecer debido a que se omiten datos durante el desarrollo del proyecto, es
por esto que es muy importante no saltar ninguna etapa del ciclo de vida del
desarrollo de sistemas.
Otra causa de insatisfacción de necesidades es la mala definición de las

expectativas de un proyecto en sus orígenes, ya que si no están bien definidos
los requerimientos máximos y mínimos que el proyecto debe satisfacer desde
el comienzo, los desarrolladores verán afectado su trabajo por el "síndrome de
las necesidades que crecen" el cual les dejara hacer cambios en el proyecto en
cualquier momento sin detenerse a pensar si esos cambios serán buenos para
el proyecto como un todo (por supuesto todos estas modificaciones acarrearan
alteraciones en los costos y en los tiempos de entrega).
a.2.- Los habituales: atrasos y costes
Uno de los rasgos característicos y síntoma de "normalidad informática" es que

los proyectos informáticos se atrasan y se exceden en los presupuestos
económicos. Decir que el tiempo y dinero se duplican, triplican o cuadruplican
ya no tiene sentido, es un hecho y tradición del vulgo. Esto sucede debido a
que un proyecto generalmente exige un estudio de viabilidad en el cual muchas
103
veces no se incluyen datos completamente precisos de la cantidad de recursos

que cada tarea consumirá, y es en base a este estudio que se hacen
estimaciones de los recursos totales que el proyecto va a necesitar.
En cuanto al atraso, generalmente se debe a que los gestores del proyecto no

son buenos gestionando los tiempos de entrega de cada una de las diferentes
tareas que el proyecto involucra, es así que cuando tienen un retraso no son
capaces de alterar los plazos de entrega finales creyendo que podrán
recuperar el tiempo perdido. En general esta es una muy mala política de
trabajo porque no siempre es posible acelerar otras tareas para ahorrar tiempo
en la entrega final.
Por ejemplo, Glass señala que el 40% de los proyectos informáticos son
cancelados por estos excesos; mientras, un 33% se enfrentan a cambios de
tiempo, costes y alcance.
Sin embargo, esta imagen no es propia de la informática, por ejemplo Ribera,

nos muestra algunos ejemplos dignos de mención:
• El proyecto del Opera House de Sidney pasó de 7 millones de dólares a

107 millones de dólares.
• El proyecto de desarrollo del avión F-22 Raptor que ha superado un
coste del billón de dólares.
• El proyecto del túnel del Canal de la Mancha, cuyo coste inicial de 7,5
billones a llegado a los 17,5 billones de dólares, y se terminó en 1994 en
lugar de 1992.
Pero no es necesario pensar en esas grandes empresas humanas, cuya

complejidad puede justificar cualquier superación de estimaciones. Se puede
pensar en el simple atraso en la construcción de un edificio, algo tan habitual y
corriente que se nos pasa desapercibido. Lo que queremos decir es que fuera
de la Informática los proyectos también se atrasan y cuestan más caros por
motivos tan diversos y variopintos como los que se escuchan en informática.
Lo que es preocupante es que dentro de la Informática estos problemas se

manifiestan tanto a gran escala (como los ejemplos dados por Ribera) como a
escala "casera", viéndose afectado por tanto todo el tejido socio-económico,
incluyendo aspectos como el crecimiento organizacional, los planes de
empresa, o el presupuesto de una PyME.
a.3.- El social: la imposición de los resultados
Aparte de esos comunes problemas de tiempo y coste, está en lo que podría

llamarse el problema de 'adopción por decreto'.
En muchas ocasiones los productos informáticos son impuestos por las

jerarquías administrativas sin una asimilación y/o aceptación del personal o los
trabajadores. Según ciertas culturas este tema resulta conflictivo y un problema
a ser resuelto. Un caso de cultura que rechaza esta situación es la
104
escandinava, así, Iivari y Lyytinen destacan que los productos informáticos

son artefactos surgidos y definidos por quienes les usarán, los trabajadores.
El problema es básicamente de los principios ligados a la historia de la

ingeniería, donde ella busca ser generadora de soluciones a las necesidades
de la humanidad, aportando artefactos con un valor agregado y márgenes de
ganancia social siempre positivos para el 'hombre de la calle'.
Esta visión se contradice con la costumbre informática de imponer soluciones

según el último avance en el área, la última tendencia o lo que sencillamente
hay que tener. Al final, ocurren ajustes de trabajo de índole tayloristas que
imponen aparentes mejores niveles de eficiencia, confundiendo: procesos de
negocios más eficientes con aumento de velocidad computacional, y/o mejoras
de la eficacia en base a nuevas prácticas laborales con simples
automatizaciones de prácticas de trabajo.
En una sociedad del conocimiento este tipo de actitudes no son permitidas,

pues es necesaria la participación libre y colaborativa de todas las personas
involucradas en un proceso de construcción de productos informáticos, sean
tanto diseñadores de sistemas como usuarios finales.
b.- Las consecuencias de los 'problemas comunes'
Hoy en día los proyectos informáticos se asumen que son un riesgo a correr, lo
cual no evita que al final de un proyecto informático se puedan plantear tres
consecuencias:
b.1.- Desconfianza en el producto
Una aparente desconfianza en el producto se nota en expresiones tales como:

"al final se hizo a la ligera", "sencillamente... se remató", "apágalo, funcionará
cuando lo prendas", o sencillamente "bueno, al final en software siempre salen
cosas que algo hacen en pantalla".
Si bien pueden ser sencillamente comentarios de paso, si es cierto que en los

resultados informáticos en la forma de software, infraestructuras y/o sistemas
de información, todavía no es posible erradicar el oscurantismo de una
profesión que entrega productos con funcionamientos en ocasiones misteriosos
y plenos de 'bugs'.
b.2.- Desconfianza en la profesión
La desconfianza en la profesión la sufren los practicantes de la informática

cuando se les pide evaluar un producto, calcular un coste o sencillamente
dimensionar algún resultado. No se le puede pedir a un ingeniero informático
calcular o estimar un producto cuando las actuales herramientas no son
seguras ni fiables. Esto ocurre en otras disciplinas, pero sencillamente la
informática está, diríamos aún en pañales, llevando a justificar como válido el
multiplicar por dos, al menos, los costes y los tiempos planificados. En extenso,
105
la consultoría informática puede llegar a ser un factor negativo al momento de

la promoción profesional.
b.3.- La crisis del usuario
Pero hay otra consecuencia relevante. No es una desconfianza en lo que

resulta del trabajo informático o en lo que produce la formación informática, es
la crisis del usuario.
Se debe aceptar que la sociedad occidental postmoderna es una sociedad del

riesgo. No una sociedad que vive experiencias al límite, sino una sociedad que
acepta en situaciones concretas márgenes de riesgo como algo cotidiano y
éticamente aceptable.
Esta concepción del mundo es ideal para la Informática, donde aún los
proyectos son empresas de riesgo. No solamente en el ámbito de desarrollo
(por ejemplo un software) o de adaptación (por ejemplo aplicaciones ERP), sino
en el ámbito de negocios (por ejemplo en e-Business). Es más, puede resultar
incluso curioso que frente a los problemas comunes de atrasos, sobre costes y
productos no aceptados, los clientes aceptan este fenómeno.
Pero no por estar en una sociedad que tolera el riesgo, la profesión informática
deba encaminarse hacia caminos donde la falla, el error y la incerteza sean
aceptables y aún más, rasgo distintivo de la profesión.
Hablamos de una crisis del usuario en analogía a la crisis del software1 (según
Gibbs). Mientras la última pregonaba los problemas de construir software, la
primera alude a los problemas de quien debe soportar usar los resultados de
los proyectos informáticos. Esta crisis se debe a que quien recibe y usa el
producto informático, que debería estar mejor que antes, a veces no lo está
tanto, al pasar, por ejemplo, un proceso manual robusto y probado, por un
software con fallas y un sistema de mantenimiento deficiente.
Lo importante es que la visión escandinava de pensar en el trabajador debe

estar presente. Pero si a alguien no le gusta esta concepción del trabajo
profesional, se puede tomar la línea clásica de gestión de la calidad, la cual
señala que es importante dar prioridad al sistema requirente.
En una consultoría informática esto requiere el fuerte compromiso de resolver

problemas, sensibilizándose el profesional de los problemas del usuario y
atendiendo siempre a que su misión es resolver un problema sin añadir otros.
c.- Las causas de los 'problemas comunes'
Entre posibles causas de los problemas "comunes", se pueden señalar

(Jurison):
- naturaleza del producto; y,
- problemas de gestión.
106
c.1.- La naturaleza del producto
Según Jurisson y Pressman, el principal producto informático, el software, se

caracteriza por ser:
- intangible;
- invisible;
- complejo;
- volátil de requerimientos;
- socio-técnico; y,
- difícil de medir.
A continuación hablaremos de cada uno de ellos.
- Intangible. Pues claramente el resultado es un software el cual no se puede

moldear manualmente, sino mentalmente, sin restricciones de leyes físicas o
límites del proceso de manufactura. Lo cual, además, produce que sea difícil
detectar y prevenir errores.
- Invisible. Pues la solución que se provee es básicamente un funcionamiento

que toma prestadas funcionalidades de un hardware, sin que el hardware sea
componente del sistema software. De hecho el hardware, incluso otro software
o persona, solamente en tiempo real, y según sus presentes condiciones de
operación garantizan o no prestar lo que el software les pida.
- Complejo. Pues un desarrollo involucra muchas acciones y el producto

comprende también muchas tareas, cuya comprensión supera las capacidades
humanas.
- Volatilidad de requerimientos. Lo cual es sencillo de detectar por cuanto el

desarrollo está siempre sujeto a presiones de cambio y que por ser software, el
cambio es un estilo de vida.
- Socio-técnico. Un producto informático no tiene sus fronteras en la pantalla

ni en un usuario que teclea, o incluso un cliente que paga. Un sistema de
información involucra varias piezas relacionadas conformando un sistema de
trabajo donde encontramos que operadores manteniendo el sistema, software
siguiendo algoritmos y hardware aportando infraestructura, interactúan con
otras personas, software y hardware. En este sentido, pensar que un producto
informático es sólo hardware y software es un error, salvo excepciones muy
concretas, pero la generalidad no muestra esta realidad, menos cuando se
desean sistemas que soporten una solución e-Business.
107
- Difícil de medir. Por las otras cualidades señaladas y por la juventud de la

Informática, se hace difícil tener hoy en día tener técnicas efectivas que
permitan medir, y las que existen están aún en calibración.
c.2.- Problemas de gestión
Entre los problemas de gestión aparecen mencionados entre otras cosas:
• objetivos y especificaciones pobremente definidas;

• falta de un plan de proyecto;
• presupuestos y plazos poco realistas; e
• inhabilidades de relaciones sociales.
Haciendo una revisión de la literatura encontramos diversos problemas de

gestión, los que se muestran comparativamente en la tabla 3.3. Los problemas
de gestión se presentan clasificados según las áreas de conocimiento de
gestión de proyectos del PMBOK y paralelizados según ciertas similitudes entre
ellos.
Para la lista de McConnell y Purba et al., entre paréntesis se indica la categoría

en que estos autores clasifican sus problemas. Debemos recalcar que lo
mostrado en la tabla es meramente referencial y no comprende todo el dominio
de problemas existentes.
TIPO DE PROBLEMA DE
McCONNELL GLASS PURBA et al. REDMILL
GESTIÓN
GESTIÓN DE Exceso de
INTEGRACIÓN requerimientos
(producto)
Incapacidad
de los
usuarios en Poca claridad
Usuarios
Planificación comunicar en los
que resisten
requerimientos requerimientos
(elemento
humano)
Abandono de
tiempo en el Promotor
inicio está perdido
(proceso)
Pérdida de
Ejecución tiempo en el
inicio
Política
Política antes
organizacional
que desarrollo
(aspectos
(personas)
políticos)
Cambiar de Cambios Falla en el uso

herramientas a tecnológicos de metologías
mitad del elegidos del desarrollo
108
proyecto
(tecnología)
Diseño
inadecuado
(proceso)
Convergencia
prematura o
excesivamente
frecuente
(proceso)
Equip.
políticos
Falta de (aspec.
participación políticos)
del usuario
(personas) Política indiv.
(aspec.
políticos)
Añadir más
personal a un
proyecto
retrasado
personas)
Mejores Mala gestión

Tiras y aflojas
prácticas y de las fases
en la Mala
lecciones de desarrollo
negociación especificación
son (elemento
(producto)
olvidadas humano)
Pruebas
insuficientes
(error
humano)
Falta de
control
automático del
código fuente
(tecnología)
Cambios Cambios en
Falta de
son las
control de
Control pobremente prestaciones
cambios
gestionados (producto)
Incapacidad
de acomodar
Cambios
cambios a
en las
requerimientos
necesidades
de negocios
de negocio
(elemento
humano)
TIPO DE PROBLEMA
DE GESTIÓN
109
GESTIÓN Desarrollo
DEL orientado a la
ALCANCE investigación
(producto)
Iniciación
Falta de un
proyecto efectivo
del proyecto
(personas)
Incapacidad de
Gestores no los usuarios en
comprenden comprender las
las implicaciones de
necesidades los requerimientos
de los de negocios
usuarios (elemento
humano)
Planificación Mala planificación

Alcance mal
insuficiente (elemento
definido
(proceso) humano)
Expectativas poco
Expectativas poco
realistas
realistas
(elemento
(personas)
humano)
Planificación Síndrome de la
panacea
(tecnología)
Estrategia de
implementación
débil (elemento
humano)
Mejoras
prácticas y
lecciones son
olvidadas
Sobreestimación
de las ventajas del
empleo de nuevas
herramientas o
métodos
(tecnología)
Limitaciones
técnicas
Ejecución Políticas de la
unidad informática
de la organización
(aspectos
políticos)
Mejoras
Control prácticas y
lecciones son
olvidadas
110
Control
insuficiente de la
directiva (proceso)
TIPO DE PROBLEMA DE
GESTIÓN
Omitir tareas
Tiempo y
necesarias en la
presupuesto
estimación
inadecuado
(proceso)
Estimaciones Estimaciones
erradas erradas
Planificación
No se hace
GESTIÓN estimación
DE COSTES
Escatimar en las
actividades
iniciales
(proceso)
Recursos
insuficientes
Control
(elemento
humano)
Tiempo y
Omitir tareas
presupuesto
necesarias en la Plazos
inadecuado.
estimación irreales
Planificación (proceso) Estimaciones
erradas
No se hace
GESTIÓN estimación
DEL
TIEMPO Planificar
poniéndose al
día más
adelante
Control (proceso)
Programa a
destajo
(proceso)
Se carece
del personal
Planificación con las
habilidades
GESTIÓN adecuadas
DE LA
CALIDAD Oficinas repletas
Ejecución y ruidosas
(personas)
Control Escatimar en el
111
control de
calidad
(proceso)
Ilusiones
(personas)
Planificación Motivación débil Se carece Insuficientes

(personas) de personal habilidades
Personal con técnicas
mediocre habilidades (elemento
(personas) adecuadas humano)
Empleados Pobres
problemáticos desarrolladores
incontrolados (elemento
(personas) humano)
GESTIÓN
DE Política
Desarrolladores
RECURSOS individual
meticulosos
HUMANOS (aspectos
(producto)
políticos)
Ejecución Hazañas
(personas)
Fricciones entre
los clientes y los
desarrolladores
(personas)
Falta de
participación de
los implicados
(personas)
TIPO DE PROBLEMA DE GESTIÓN McCONNELL GLASS PURBA et al. REDMILL
Insuficientes
habilidades
técnicas
GESTIÓN DE (elemento
COMUNICACIONES Planificación humano)
Estrategia de
implementación
débil (elemento
humano)
Mejores
prácticas y
Ejecución lecciones
son
olvidadas
Control Se carece
del
personal
con las
112
habilidades
adecuadas
Tiras y
aflojas en la
negociación
(personas)
Cierre
Falta de
participación
del usuario
(personas)
Gestión de
riesgo
Planificación
insuficiente
GESTIÓN DEL (proceso)
RIESGO
Tiras y
aflojas en la
Control
negociación
(personas)
Incapacidad
para tratar con
Fallos en los
contratistas y
Planificación contratados
vendedores
(proceso)
(elemento
humano)
Incapacidad
para tratar con
contratistas y
Ejecución
vendedores
GESTIÓN DEL (elemento
APROVISIONAMIENTO humano)
Recursos
insuficientes
Control
(elemento
humano)
Se carece
del
personal
Cierre
con las
habilidades
adecuadas
Tabla 3.3. Diversos tipos de problemas de gestión clasificados según el PMBOK.
1
Identificada con entregas tardías, presupuestos superados con creces y fallas en
satisfacer las necesidades de los clientes.
3.2.3 Formas de evitar estos problemas
Para evitar todos estos posibles problemas, se debe tener al mando del
proyecto un buen gestor que conozca muy bien las herramientas de diseño y
análisis de sistemas además de una buena formación en las funciones básicas
de dirección.
113
El director de proyectos no es simplemente un analista experimentado que se

hace cargo del proyecto, sino más bien debe aplicar un conjunto de técnicas y
conocimientos diferentes de los que aplica un analista.
Las funciones básicas de un gestor de proyectos han sido analizadas y

diseccionadas por teóricos de la gestión durante muchos años. Entre estas
funciones, se incluyen la planificación, la selección de personal, la
organización, la definición de calendarios, la dirección y el control.
a.- Planificación de las tareas de proyecto y selección del equipo de

proyectos
Un buen director siempre tiene un plan. El director evalúa las necesidades de

recursos y formula un plan para llegar al sistema objeto. Ello se basa en el
conocimiento que tiene el director de los requisitos del sistema objeto en cada
momento del desarrollo. Un plan básico para el desarrollo de un sistema de
información es el suministrado por el ciclo de vida del desarrollo de sistemas.
Muchas empresas tienen su propio ciclo de vida estándar, y algunas de ellas
tienen también normas sobre métodos y herramientas que han de usarse.
Así ha de planificarse cada una de las tareas requeridas para completar el

proyecto:
• ¿Cuánto tiempo se requerirá?

• ¿Cuántas personas serán necesarias?
• ¿Cuánto costara la tarea?
• ¿Qué tareas deben terminarse antes de empezar otras?
• ¿Pueden solaparse algunas de ellas?
Estas son cuestiones propias de la planificación. Algunas de ellas pueden

resolverse con ayuda de un gráfico PERT (Proyect Evaluation and Rewiev
Technique) que fue desarrollado a finales de la década de 1950 - 1959 para
planear y controlar los grandes proyectos de desarrollo armamentístico del
ejercito estadounidense. Fue desarrollado para evidenciar la interdependencia
de las tareas de los proyectos cuando se realiza la planificación de los mismos.
En esencia, PERT es una técnica de modelos gráficos interrelacionados.
Los gestores de los proyectos son, frecuentemente, los encargados de

seleccionar a los analistas y los programadores de un equipo de proyecto. El
gestor debería tener muy en cuenta los conocimientos técnicos y de empresa
que pueden ser necesarios para terminar un proyecto con éxito. La clave de
esta misión es saber elegir adecuadamente a las personas que habrían de
desarrollar las tareas requeridas e identificada como parte de la planificación de
proyecto.
b.- Organización y definición de calendarios para el proyecto
Dados el plan y el equipo de proyecto, el gestor de proyectos es el responsable

de la organización y la definición del calendario del mismo. Los miembros del
equipo de proyecto deberán conocer su cometido y sus responsabilidades
114
concretas, así como su relación de dependencia con el respecto al gestor del

proyecto.
El calendario de proyecto debería desarrollarse con un conocimiento preciso de

los requisitos de tiempo, las asignaciones de personal y las dependencias de
unas tareas con otras. Muchos proyectos tienen un límite a la fecha de entrega
solicitada. El gestor debe determinar si puede elaborarse un calendario factible
basado en dicha fecha. Si no fuera así, debería retrasarse el limite o
reajustarse el ámbito del proyecto.
c.- Dirección y control del proyecto
Una vez iniciado el proyecto, el gestor del proyecto se convierte en su máximo

responsable. Como tal, dirige las actividades del equipo y hace evaluaciones
del avance del proyecto. Por consiguiente, todo gestor de proyectos debe
demostrar ante su equipo cualidades de dirección, como son saber motivar,
recompensar, asesorar, coordinar, delegar funciones y reconocer el trabajo de
los miembros de su equipo. Además, el gestor debe informar frecuentemente
del avance del proyecto ante sus superiores.
Tal vez, la función más difícil e importante del gestor sea controlar el proyecto.
Pocos planes hay que puedan llevarse a la practica sin problemas y retrasos.
La labor del gestor de proyectos es hacer un seguimiento de las tareas, los
plazos, los costes y las expectativas, con el fin de controlar todos los estos
elementos. Si el ámbito del proyecto tiende a crecer, el gestor del mismo debe
tomar una decisión: ¿habría que reducir el ámbito del proyecto para respetar el
presupuesto y los plazos, o revisar dicho presupuesto y dichos plazos? El
gestor del proyecto debería ser capaz de presentar alternativas, y sus
implicaciones, a los plazos y presupuestos para saber responder a las
expectativas.
3.2.4 Estados de una mala gestión de proyectos
Los errores mostrados en la tabla 3.3 y muchos otros más, ocurren y han sido
reportados profusamente en la literatura. No obstante, se han podido
determinar algunos estados que indican una gestión de proyectos inefectiva o
de que es prudente plantearse usarla. Estos estados de un proyecto son:
• modo ajustado (crunch mode);

• marcha mortal (death march); y,
• fuera de control (runaway).
3.2.4.1 Modo ajustado
El modo ajustado, para Glass, describe un proyecto que se encuentra

extremadamente ajustado a la programación. Se habla que existen fuertes
presiones que sienten los participantes del proyecto. Es el estado cuando el
proyecto anda por los límites del programa de trabajo, más bien superándolo.
En este estado, dentro del proyecto informático comienza a notarse que:
115
- "las semanas tienen siete días y los días 24 horas";
- "los días son cortos y las noches largas";
- empiezan las primeras fugas;
- hay una 'ralentización' de la motivación;
- se suceden las re-planificaciones de forma frecuente;
- etc.
3.2.4.2 Marcha mortal
La marcha mortal, según Glass, describe un estado en que el proyecto tiene

una programación difícil de conseguir. Se habla que "hay olor a fracaso" ("esto
huele mal") entre los participantes. Para Yourdon, un proyecto en marcha
mortal posee una valoración de riesgo de falla sobre el 50 por ciento
(incluyendo riesgos técnicos, del personal, legales, políticos, etc.).
Según Ribera este estado es un Modo Imposible de trabajo debido a que:
- "El plazo es inferior a la mitad de lo que racionalmente se precisa";
- "El personal asignado es inferior a la mitad que habitualmente se asignaría a

un proyecto de estas características";
- "El presupuesto se ha recortado a la mitad", y,
- "La funcionalidad, requisitos, y otros aspectos técnicos son superiores al

doble de lo normal".
El mismo Ribera acota, que es estas situaciones surgen preguntas como:

"¿Qué hace un chico como yo en un proyecto como éste" o "¿Cómo puedo
sobrevivir a este proyecto sin perder mi salud física y mental y mi dignidad?".
3.2.4.3 Fuera de control y escalada
Un proyecto fuera de control, o "Runaway", describe un estado o un estado de

cosas manifestadas cuando un proyecto está cerca o después de su término.
Sencillamente, el proyecto está fuera de sus límites, o ya no tiene límites,
hablándose, según Glass, que el proyecto falló o está pronto a fracasar.
Cuando se está fuera de control, se puede decir que estamos ante una bola de
nieve, la cual resulta de una escalada de errores por motivos, que según Keil y
Mixon, se deben a factores psicológicos, sociales y organizacionales. Estos
errores son consecuencia de una gestión inadecuada, fallida o nula, que pone
al personal y especialmente a gestores, ante una variedad de problemas que
supera sus capacidades de gestión y de resolución de problemas. Esta
situación hace que un error lleve a otro, produciéndose una cadena creciente,
116
una escalada de problemas de gestión, debido al cansancio, fatiga y

desorientación que supone la tensión de la situación.
Lo anterior es lo que se llama escalada y romperla requiere una alta capacidad

de superar el estrés físico y mental que supone un rescate, hundimiento o
salvamento parcial del proyecto.
3.2.5 Razón de la gestión de proyectos
Se ha dicho que la gestión de proyectos es una manera de hacer frente a

problemas y retos. También hemos añadido los estados de un proyecto que
presenta problemas de gestión. Ahora se presentan razones más concretas
que justifican la gestión de proyectos en un proyecto en general y en un
proyecto de base tecnológica. Ellas son:
- actuación predictiva; y,
- recuperación.
3.2.5.1 Actuación predictiva
Para varios autores, una forma de actuar predictivamente en los problemas de

gestión, es anticiparse a ellos con una completa y adecuada gestión de
proyectos, la cual puede medirse si con la gestión se garantizan alcanzar los
siguientes Factores Críticos de Éxito (planteados por Jurison):
• Objetivos claramente definidos.

• Apoyo claro y total de la dirección.
• Presupuesto adecuado y realista.
• Programa coherente, racional y realista.
• Participación y confianza real del cliente y usuarios.
• Buen liderazgo del proyecto.
• Revisiones continuas, constructivas y positivas del proyecto.
• Gestión y control eficiente y eficaz del cambio.
• Buenas comunicaciones entre integrantes del proyecto.
• Anticiparse y solucionar los problemas que surjan con una gestión de
contingencias.
3.2.5.2 Recuperación
Otros autores señalan que la gestión de proyectos permite determinar el

momento y las acciones de recuperación de un proyecto, igualmente de que
estas acciones se lleven delante de manera adecuada. En este caso se habla
de una de-escalación y/o la convocación de un caballero blanco.
a.- De-escalar
En una de-escalación se toman acciones que permitan superar los diversos

problemas de gestión ante una escalada. Para Ribera recuperarse de una
escalada puede ser:
117
- recortar la envergadura del proyecto;
- aumentar la productividad mediante mejoras a corto plazo; y/o,
- asumir que el proyecto no terminará a tiempo, atrasar el plan y adoptar

medidas de control de daños.
Lo que para Glass se traduce en tomar acciones en el siguiente orden de

preferencia:
- extender las fechas;
- usar mejores procedimientos de gestión;
- más personal;
- más fondos;
- reducción en alcance del proyecto;
- mejores metodologías de desarrollo;
- cambiar tecnología; y,
- abandonar el proyecto.
Acciones que, para Montealegre y Keil, no tendrían ningún efecto si no se

apela a la colaboración y cooperación de los participantes involucrados en el
proyecto o, sencillamente, des-institucionalizar el proyecto, dejando la de-
escalación como un problema interno de gestión a superar internamente.
b.- El caballero blanco
Una forma posible de superar los problemas de gestión es contratar a un

experto en salvar proyectos, aquella persona milagrosa que viene a salvar todo
mal funcionamiento y a intentar recuperar el proyecto: el caballero blanco
(white knight).
En este tipo de solución debe considerarse la asesoría y la consultoría en

proyectos como un medio válido de conseguir algún caballero blanco.
Capítulo 4.- Ejemplo de proyecto

tecnológico: implantación proyecto
e-Business
118
OBJETIVOS
- Exponer una metodología e-Business como forma de mostrar un proyecto tecnológico en su

dimensión de negocios y tecnológica.
- Conocer una metodología de implantación de una solución e-Business.
- Conocer y describir las etapas en la implementación de una solución e-Business.
4.1 Introducción
Un proyecto e-Business tiene dos dimensiones, una de gestión y una de
construcción. Mientras la dimensión de gestión puede considerarse genérica,
la de construcción es más específica al dominio técnico del proyecto.
Este capítulo presenta la dimensión de construcción bajo la forma de una

metodología de implementación de un proyecto e-Business. Esta
implementación toma la iniciativa e-Business como idea generatriz y la
transforma en una propuesta coherente con la organización y sus procesos y
su estrategia. Esta propuesta se sustenta en una solución informática donde
debe tener cabida una arquitectura e-Business y una serie de sistemas
informáticos e-Business construidos a la medida y/o adquiridos desde la oferta
del mercado informático y e-Business (figura 4.1).
Figura 4.1: Metodología de implementación de una solución e-Business.
Antes de iniciar el esfuerzo de construcción de una iniciativa e-Business es

bueno preguntarse:
• ¿Cómo podemos transformar nuestra empresa en soluciones e-

Business?
119
• ¿Cómo puede ayudarnos el hecho de aprovechar una solución e-

Business a maximizar el valor de nuestra inversión en tecnología de la
información?
• ¿Cómo nos ayudará a reducir los costes y a aumentar los beneficios?
• ¿Existe un convencimiento similar en toda la organización sobre la
utilidad de una solución e-Business?
• ¿La transformación de la empresa cuenta con la colaboración de sus
expertos en negocios y los expertos en tecnología?
• ¿Se disponen de los expertos necesarios para convertir esta idea en una
realidad?
• ¿Tenemos algún modelo de implantación que permita un rápido
despliegue?
• ¿Tenemos capacidad de traspasar las aplicaciones a otras plataformas
que se puedan necesitar?
• ¿Se pueden aprovechar las inversiones en los sistemas realizados hasta
la fecha?
• ¿Sabemos los sistemas que tenemos?, ¿son adaptables?
• ¿Nuestros sistemas actuales ofrecen la disponibilidad que requieren
usted y sus clientes?
• ¿Tenemos capacidad de gestionar un entorno e-Business de manera
eficientemente?
• ¿Nuestra empresa y proveedores tiene experiencia en seguridad
electrónica? ¿Ha sido exitosa?
• ¿Estamos dispuestos al cambio?
• Etc.
Son muchas las preguntas que en un proyecto e-Business pueden darse. De

muchas de ellas no tenemos respuesta ahora, no obstante es posible encontrar
respuestas siguiendo la metodología de implantación que en este capítulo se
propone.
La implementación debe entenderse como el camino mediante el cual una

organización canaliza sus acciones para explotar las ventajas de la Economía
en Red a través de una estrategia definida. Esta estrategia en muchos casos
está ausente en varias organizaciones que tienen negocios en y/o sobre la red.
Por tal motivo se plantea que es conveniente tener un camino claro que ayude
a obtener la implementación de la solución e-Business.
Este camino es un proceso genérico que puede y debe ser acomodado a los
requerimientos de negocios y entorno de una organización.
Tal camino surge de un ciclo e-Business compuesto de cuatro etapas (figura

4.2), entre los cuales no existe ningún orden o jerarquía. Debe aclararse que no
todas las empresas que utilizan soluciones e-Business y han alcanzado el éxito
han empezado siempre por el mismo punto del ciclo.
120
Figura 4.2: Ciclo e-Business.
Las etapas son:
• Transformación. Las empresas que han alcanzado el éxito en el

entorno e-Business utilizan las posibilidades que ofrecen la Web, las
intranets y las extranets para transformar los procesos centrales de la
empresa. El cambio fundamental es en la manera de hacer los negocios.
Estas empresas tienden a:
- ser muy abiertas al cambio de los procesos centrales, y
- tener una visión de cómo dicha transformación puede mejorar la

empresa.
• Creación de Nuevas aplicaciones. Consiste en la creación de nuevas

aplicaciones de manera rápida y fácil. Además no existe la necesidad de
reinventar la rueda; más bien se parte de los sistemas y las aplicaciones
que ya se poseen y/o existan en el mercado.
• Obtención de un entorno adecuado. En la tercera etapa, centrada en
la obtención de un entorno de sistemas adaptables, disponibles y
seguros, las empresas deben establecer una infraestructura de
hardware y de software que pueda crecer fácilmente al ritmo de la
empresa. Además, debe existir una gestión adecuada para: el entorno
de redes informatizado que se genera y mantener su seguridad.
• Diseñar la estrategia. El diseño busca capitalizar la información y
experiencia acumuladas y aplicar los nuevos conocimientos conforme
aparecen. Se pretende que el conocimiento esté al alcance de toda la
empresa y cualquiera pueda comprender lo que implica y significa la
solución e-Business.
Desde un punto de vista metodológico y de negocios, el ciclo e-Business debe

ampliarse para dar cabida a todos los elementos necesarios que permitan
pasar de la iniciativa a la aplicación e-Business.
En este sentido se deben plantear las siguientes etapas (figura 4.3):
121
• Definir la estrategia. Articular una clara y consistente estrategia e-

Business acorde a cómo la organización desea usar los recursos de la
red. Implica la creación de una visión, la determinación de objetivos, el
diseño de una estrategia. También define el alcance general del sistema
e-Business en el soporte de los procesos de negocio.
• Definir la aplicación e-Business. Un conjunto de soluciones
potenciales que permitan implementar la estrategia de negocios, lo cual
incluye el análisis de los sistemas existentes y de la opción de comprar
sistemas e-Business existentes. Igualmente definir una arquitectura que
provea la infraestructura, servicios de desarrollo e implantación de
aplicaciones que den soporte al portafolio de aplicaciones e-Business, el
conjunto de sistemas computacionales que dará soporte a los procesos
de negocios dentro de la solución e-Business.
• Desarrollo y despliegue. Crear un plan técnico que muestre cómo las
aplicaciones y la arquitectura han de ser implantadas. Implantar cada
aplicación y refinar la arquitectura y plan táctico basado en las lecciones
aprendidas.
• Uso y evolución. Esta etapa existe cuando los sistemas e-Business han
sido desplegados por la organización, lo cual requiere aprender de su
uso y recapitular sobre la experiencia de conseguirlos.
Figura 4.3: Ciclo de vida e-Business.
El capítulo se organiza a continuación presentando estas cuatro etapas.
4.2 Definir la estrategia

Para llegar a ser una empresa e-Business y ofrecer un mejor servicio al cliente,
la empresa debe ante todo desarrollar una estrategia a largo plazo para la
integración de sus procesos. Más del 55% de empresas (todas con soluciones
e-Business ya implantadas) reconocen que inicialmente sólo pensaron en
necesidades aisladas y a corto plazo, sin definir sus objetivos e-Business a
largo plazo, ni desarrollar una verdadera estrategia e-Business.
122
Las empresas que elaboran este tipo de estrategia posteriormente, durante la

fase de desarrollo y despliegue, señalaron que sus soluciones iniciales
probablemente hubiesen sido otras, o implantadas de otra manera, si hubiera
existido una visión e-Business. Sin un plan claramente definido a largo plazo,
estas soluciones puntuales, a pesar de resultar exitosas individualmente, en
conjunto constituyeron una serie de iniciativas costosas y desarticuladas que
obstaculizaron la integración total y racional de los procesos empresariales. En
general es la escasa rentabilidad de la inversión lo que causa mayor
frustración. En estos casos, después de implantar varias soluciones parciales y
poco optimizadas, las empresas se ven forzadas a definir una estrategia con el
objetivo de articular sus dispares programas e-Business sobre un eje común: la
mejora del servicio al cliente.
Por el contrario, empresas que desde el principio apoyan la implantación en un

verdadero proyecto a largo plazo, se benefician de una ventaja significativa a la
hora de ofrecer un mejor servicio a sus clientes, con resultado más satisfactorio
en la inversión en e-Business. En el 42% de estas empresas, la inversión en e-
Business resulta muy positiva o ha cambiado radicalmente la fisionomía de su
negocio (un porcentaje más de dos veces superior al de las empresas sin
estrategia a largo plazo), y ninguna se muestra insatisfecha con los resultados
de sus proyectos e-Business.
Esta diferencia se explica principalmente por el hecho de que las soluciones e-

Business que optimizan procesos o sistemas individuales -sin tener en cuenta
el entorno global- sólo conducen a mejoras puntuales. En cambio, un plan e-
Business que abarque la totalidad de los procesos aportará resultados
significativos en términos de valor añadido, tanto para la empresa como para
sus clientes, colaboradores y proveedores, ofreciendo ventajas significativas en
el plano de la competitividad y de la satisfacción del cliente.
Formular la estrategia de negocios para el uso efectivo de la solución e-

Business debería:
• Definir la misión para el uso de la solución e-Business.

• Establecer objetivos alineados con la misión y con los objetivos
corporativos.
• Diseñar una estrategia que ayude a la organización a lograr sus
objetivos.
• Identificar cómo la estrategia será implantada dentro de la
transformación de procesos de negocio.
Todo esto da lugar al documento estratégico, procurando mostrar un alto nivel

de detalle y completitud en varios aspectos (por ejemplo, ver Apéndice I).
4.2.1 Definir la misión
El éxito en el mercado online requiere una comprensión detallada de cómo la

organización planea usar Internet. Aunque esto pueda sonar trivial,
frecuentemente el producto a ser ofrecido en la red requiere un dominio del
espacio donde se ha de ofrecer y donde se ha de negociar.
123
Esto hace dificultoso determinar cómo el producto es posicionado en el

mercado y cómo la organización puede medir el éxito en su esfuerzo en la red.
Por ejemplo, muchas organizaciones usan el método ABC (Activity Based

Costing) para localizar costos en departamentos individuales. La técnica
tradicional de implantación de ABC no trabaja en una Economía en Red porque
la organización gasta gran cantidad de recursos construyendo productos y
servicios que son dejados gratis en la red. Para comprender este concepto,
podemos tener en mente compañías como Yahoo o Infoseek, las cuales
proveen motores de búsqueda.
El servicio/producto ofrecido por Yahoo e Infoseek es la capacidad de buscar

información en la web. Millones de clientes acceden a sus sitios (web sites)
diariamente y de manera gratuita. Nuevos servicios tales como Gestores de
Portafolio Personal (Personal Portfolio Managers) y capacidades de búsqueda
personalizadas están disponibles en estos sitios.
Así, ante la pregunta ¿cómo subsisten estos negocios?, la respuesta es simple:

el principal flujo de retorno o ganancia para estas compañías proviene de
avisadores que desean publicitar sus productos y servicios, y de
organizaciones que desean conducir tráfico a sus sitios y no de clientes que
usan los motores de búsqueda.
Por tanto, el producto que ofrece concretamente Yahoo e Infoseek es el acceso

a millones de clientes que desean usar un motor de búsqueda, donde el éxito
en el medio ambiente que provee el sitio a través de sus páginas web está
medido en la capacidad de atraer gente al sitio a usar el motor de búsqueda y
que vuelva de nuevo.
Un caso análogo lo constituye la televisión. En este caso, buena parte de sus

ingresos y ganancias provienen de la calidad de sus contenidos, los cuales
atraen a entidades interesadas en hacer publicidad.
Debe recalcarse que esto no significa que una iniciativa e-Business equivale a
solamente publicar información de la empresa. Por ejemplo, no es sólo crear
una página web para consulta general, poner una intranet para los empleados,
o una extranet para sus colaboradores.
Lo que importa es construir una comunicación bidireccional: cuando se integran

web, extranet o intranet con los sistemas existentes en la empresa, se crean
nuevas oportunidades para que los clientes, empleados, proveedores y
distribuidores interactúen en cualquier momento y en cualquier lugar. De esta
forma, la comunicación se hace más eficiente. En lugar de trabajar a través de
intermediarios, las principales partes implicadas obtendrán la información que
necesitan directamente y podrán realizar sus transacciones con la empresa de
forma electrónica.
De esta manera, conforme los empleados, proveedores, distribuidores y los

clientes disponen de mayor acceso a los datos y son capaces de interactuar
directamente con los sistemas centrales de la empresa, éstas descubren
124
nuevas posibilidades sobre cómo utilizar sus recursos. De hecho, los datos que
se producen como resultado de una interacción más directa con las principales
partes implicadas son en sí mismas un recurso. Permiten aprovechar la
experiencia y el conocimiento de la institución para llevar a cabo un cambio
fundamental en la forma de conducir la empresa. Esto es lo realmente
importante de e-Business. Paradójicamente, los cambios en los aspectos
tecnológicos de una empresa pueden llevar a modificar en última instancia los
procesos centrales de la empresa, aspectos de una empresa que no tienen
nada que ver con la tecnología.
4.2.2 Establecer objetivos
Las empresas consideran que existen numerosos obstáculos que pueden

frenar la implantación inicial y la ampliación de sus proyectos e-Business. El
principal obstáculo para una mayor inversión en e-Business es el alto coste de
implantación (coste real y recursos internos necesarios). Sin embargo, la idea
de que el e-Business "es excesivamente oneroso y exige un gran número de
recursos" ha sido totalmente desmentida por la mayor parte de las empresas
que han atravesado con éxito la "terrible" fase inicial.
Las empresas que han realizando su proyecto e-Business basándose en una

sólida estrategia, y han perseverado el tiempo suficiente para cosechar sus
frutos, se maravillan del bajo coste de dichas soluciones con respecto a los
beneficios que pueden aportar. El análisis de la rentabilidad de la inversión es
sólo uno de los componentes de la ecuación del valor del e-Business. Existen
otros factores, de tipo cualitativo, que se deben tener en cuenta: estabilidad de
las nuevas relaciones que se establecen con los clientes, eficacia óptima de los
empleados, mayor fidelidad de los proveedores, aumento potencial del volumen
de ingresos gracias a la optimización de los procesos, sin olvidar la ventaja
competitiva proporcionada por la mayor rapidez de reacción de la empresa.
Un análisis detallado y riguroso de los beneficios estratégicos y comerciales

resulta indispensable para vencer los obstáculos que impiden la adopción e
implantación del e-Business. De hecho, más allá de los aspectos puramente
tecnológicos, los obstáculos principales desaparecerán ante la total
comprensión del valor operativo y de los considerables beneficios financieros
inherentes a la transición hacia el e-Business.
Por este motivo es conveniente hacer una definición de objetivos claros,

concisos y, muy importante, medibles del tipo estratégico y financiero.
a.1.- Objetivos estratégicos
Estos objetivos tiene que ver con, primero, cómo la organización busca ser
reconocida en el mercado y, segundo, con respecto a su competencia.
Por ejemplo, pueden señalarse como objetivos estratégicos:
- Ser un reconocido líder del mercado.
125
- Incrementar posición en el mercado.
- Proveer un mejor servicio al cliente.
- Tener una estructura de costos más baja que la competencia.
- Tener una alta capacidad de respuesta frente a los cambios del mercado.
- Ofrecer productos de alta y reconocida calidad.
CASO: E-BUSINESS VALE LA PENA. Y MUCHO
En un estudio llevado a cabo por The McKenna Group (empresa consultora de Silicon Valley) e
IBM, se examinaba la importancia de e-Business en empresas de fabricación, de ventas al por
menor, aseguradoras, de telecomunicaciones y de viajes. En cada uno de estos sectores, se
encontró un valor significativo tanto en términos de crecimiento de los ingresos como en ahorro
de costes.
e-Business crea oportunidades significativas para aumentar los ingresos y mejorar la

satisfacción de los clientes. En el estudio se encontraron numerosos ejemplos de empresas
que experimentaron un crecimiento de los beneficios de dos e incluso tres dígitos a partir del
momento en que realizaron la transición al entorno e-Business.
Estas empresas consideran que e-Business les ha permitido captar nuevos clientes y ofrecer
un mejor servicio a los clientes habituales.
b.1.- Objetivos financieros
Estos objetivos identifican los resultados financieros que la organización esta

buscando alcanzar con el esfuerzo en e-Business.
Por ejemplo, pueden señalarse como objetivos financieros:
- Incrementar los márgenes de ganancia.
- Contribuir a acelerar el crecimiento de los ingresos.
- Reducir gastos aumentando la eficiencia de los procesos de negocio.
CASO: LAS SOLUCIONES E-BUSINESS TAMBIÉN PERMITEN RECORTAR COSTES
La dirección de una empresa de componentes electrónicos diversificado que ha puesto en

marcha un extranet segura para comunicarse con los proveedores de suministros no
relacionados con la producción reconoció que estaban derrochando millones de dólares en
compras colectivas porque dichas compras se dispersaban entre las distintas divisiones de la
empresa. Debido a que la adquisición de los productos no relacionados con producción no
estaba estandarizada, la empresa no podía seguir la pista de las múltiples transacciones que
podían constituir una única compra ni analizar el historial de compras para poder mejorar.
La empresa eligió una solución extranet basada en la Web conectada a los sistemas ya
existentes. De este modo, se obtiene un acceso estandarizado para todos los suministradores,
un medio para conectar los diversos sistemas de aprovisionamiento de cada división y se evita
126
la utilización de redes de interconexión dedicada, más caras, para la transmisión de datos.
¿El resultado? El fabricante estima, siendo conservador, que los costes anuales en las
transacciones de aprovisionamiento se reducirán en un 75%, y que ahorrarán 60 millones de
dólares al año al consolidar su poder adquisitivo con los proveedores habituales.
4.2.3 Diseñar una estrategia
Una estrategia de negocios puede ser definida como los movimientos e

intentos de una organización para producir un desempeño exitoso acorde al
negocio. Es destacable que el aspecto central de la estrategia de negocios es
cómo construir una posición competitiva de largo plazo. Por último, puede
decirse, que la estrategia de negocios es poderosa si ella produce una ventaja
competitiva considerable y, además, sostenible.
Las empresas que ya trabajan en el entorno e-Business con éxito, tienden a ver
el cambio como una oportunidad y no como un desafío. Esto es importante
porque las soluciones e-Business se desarrollan en entornos cambiantes. La
tecnología evoluciona a un ritmo rápido. Las normas de la competitividad están
cambiando. El poder relativo y la influencia de los clientes, proveedores y
distribuidores está cambiando en todos los sectores. Los clientes también
tienen una visión diferente de la capacidad de respuesta que puede ostentar
una empresa hoy por hoy; la tecnología digital, el mundo interconectado en que
vivimos hace que esperemos una respuesta inmediata y que los servicios se
encuentren disponibles las 24 horas.
CONSIDERACIONES ESTRATÉGICAS
Como parte de la estrategia es conveniente analizar determinados aspectos que pueden

considerarse estratégicos, tanto de negocios como tecnológicos. Estos aspectos son:
Ofrecer un contenido en la red de buena calidad, de tal manera que un "click" en nuestra
página invite a ser visitada nuevamente.
El diseño gráfico debe ser atractivo, buscando una armonía entre lo visual y el texto, entre
color, imagen y dinámica.
La comunicación que ofrezca el sitio web debe ser eficaz. Esto quiere decir, que se deben
entregar mensajes claros para el mercado escogido, en su propio lenguaje y con sus propios
signos.
La interacción debe ser fluida. Esto significa que el usuario debe tener a su disposición
herramientas que le permitan seleccionar información y navegar por el sitio según sus
necesidades.
La navegación debe ser lógica. Hay que pensar en el usuario, en el tipo de cliente escogido,
para ofrecerle un tipo de navegación que le resulta familiar con sus estilos habituales de
trabajo, de conversación, de uso de Internet.
La programación computacional debe prevenir errores. Sencillamente que la página o las

páginas del sitio funcionen sin errores, sin sobresaltos, sin pérdida de información.
127
Actualización frecuente. Una página web no es un documento en el olvido, es nuestro rostro, el

cual debe continuamente ser cuidado con mucha atención para ofrecer una imagen y un
contenido adecuado.
La promoción de nuestro sitio web debe ser continuo y real. El sitio web es nuestra personal y
privada invención, por lo tanto, debemos avisar que ella existe. Notas de prensa, publicidad,
presencia en medios, indexaciones en buscadores, son medios para mostrar su existencia,
anunciar cambios, nuevos productos y promociones, etc.
Mantener la fidelidad. Fidelizar no es solamente capturar datos, sino informar sobre novedades,
nuevas promociones, etc., por este motivo debemos construir un vínculo personal con el
usuario afiliado a nuestro negocio.
** Burgos, Daniel. (2001). "Claves para aumentar el tráfico de un site. e.sphera". 4:16.
Mayo.
Para conseguir una estrategia de negocios adecuada, se deben considerar los

siguientes aspectos:
• Coherencia con el negocio principal.

• Análisis de fuerzas externas.
• Análisis de mercado.
a.1.- Coherencia con el negocio principal
Para aprovechar el potencial de las soluciones e-Business, es imperativo para

una organización establecer clara y consistentemente una estrategia de
negocios alineada con la estrategia corporativa de la empresa y, además,
tomando en consideración los objetivos de negocios que han sido definidos
previamente. Una gran parte de la estrategia de negocios consiste en identificar
cómo la organización desea competir en el mercado.
Este enfoque puede hallarse basado en los siguientes criterios:
- Competir basado en la calidad. Ser reconocido por la calidad de los

productos.
- Tiempo de respuesta al mercado. Ser rápidamente reconocido como un

innovador.
- Mejor servicio. Proveer el mejor servicio al cliente.
- Costes bajos. Ser reconocido como el proveedor de costo más bajo.
- Mejor seguimiento del servicio provisto. Ser reconocido por la calidad y

completitud de la gestión del seguimiento.
CASO: VINOS GANCIA
Con una plantilla de 150 trabajadores y unos ingresos de 70 millones de dólares al año, Gancia
(www.gancia.it) tiene mucho en común con otras empresas italianas que han alcanzado el
128
éxito: sus raíces son locales, pero su mercado es global. Fundada en 1850 en las montañas
piamontesas del norte de Italia, la empresa exporta sus vinos a cerca de 60 países de todo el
mundo.
El éxito de Gancia siempre se ha basado en una esmerada mezcla entre tecnología y tradición,
y comprendió casi de inmediato los beneficios que una solución e-Business podía aportar.
Gancia necesitaba una solución de TI que le ayudara a hacer más eficientes las operaciones
del mercado doméstico y le diese el soporte necesario para gestionar el creciente mercado
internacional, un área de importancia estratégica para la empresa. Así lo cuenta el gerente de
Gancia: "Somos una de las primeras marcas de Italia, pero el futuro de la compañía es el
mercado global. Por ello necesitamos un mejor acceso al mercado internacional".
Los especialistas en e-Business analizaron detenidamente el flujo de información a través de

las cadenas empresariales de la compañía y su probable evolución en el futuro. La primera
solución propuesta fue la creación de una solución preparada para el año 2000 para las
necesidades de contabilidad básica y de gestión de Gancia.
Previamente, los pedidos que llegaban a la oficina de ventas de la empresa por fax generaban
una gran cantidad de papel que requería la dedicación exclusiva de varios empleados. Estos
pedidos llegaban sin un formato estándar, lo que obligaba a interpretarlos y, a menudo,
descifrarlos se convertía en un juego de adivinanzas. Nuestro socio informático ABC diseñó
una pagina web que permite a los agentes presentar sus pedidos rellenando un simple
formulario. El enlace con Internet se ofrece a través de un servidor Lotus Domino, que se
encuentra enlazado con Internet con el sistema de contabilidad y gestión de la empresa, que
funciona en un servidor AS/400.
Además de la red de agentes, Gancia necesitaba un enlace con 7 almacenes de depósito

repartidos por toda Italia desde donde se distribuye a los clientes. Anteriormente, la
comunicación con estos almacenes generaba un intenso intercambio de papeleo, un flujo
constante para arriba y debajo de notas de entrega, pedidos e información sobre facturas. Gran
parte de los documentos se enviaban por fax, creando aún más trabajo administrativo y mayor
probabilidad de retrasos. Para tratar este problema, se creó una solución Lotus Notes que
enlazaba los almacenes con las oficinas centrales de Gancia mediante una extranet. Los datos
de entrega de los almacenes se pasan automáticamente al sistema de contabilidad central de
Gancia, de manera que se puede emitir la factura correcta.
La solución reduce el tiempo de dedicación a la gestión administrativa de los pedidos recibidos

por fax y reduce drásticamente los problemas generados por errores o pérdidas de los
documentos. La plantilla de Gancia que antes se encargaba de atender el fax, ahora sólo
dedica un 10% de su tiempo en el control del sistema y el resto lo pueden dedicar a otros
trabajos más productivos para la empresa. Otra ventaja de recibir los pedidos en línea es que
los datos de ventas están siempre disponibles para su análisis. De esta forma, Gancia puede
controlar las tendencias de ventas por área y producto utilizando datos del momento.
Los agentes y los almacenes de depósitos de Gancia también se benefician del descenso de
las tareas administrativas. Al mismo tiempo que el trabajo de los agentes y de los almacenes
es más efectivo, se consolidan las relaciones entre ellos y la empresa, lo que constituye una
parte importante de los activos de Gancia.
Actualmente, el sistema se utiliza para los pedidos que se cursan en Italia, pero Gancia pronto
lo abrirá a los agentes internacionales de 60 países. Mediante interfaces de usuario
personalizadas, se salva el gran abanico de diferencias culturales y problemas de
comunicación. Por ejemplo, un importador japonés podrá colocar sus pedidos utilizando un
formulario que esté en su idioma, Butterworth dice: "Hemos crecido dos dígitos en Japón. Se
trata de un país con otra lengua, otra zona horaria y otra cultura. Necesitamos la tecnología
para resolver nuestros problemas de comunicación y mantener dicho mercado en crecimiento".
b.1.- Análisis de fuerzas externas
129
Un segundo aspecto de la estrategia de negocios identifica las fuerzas externas

que impactan la organización. Las fuerzas que pueden destacarse son:
- Competencia.
- Potenciales nuevos proveedores.
- Regulaciones de gobierno.
- Implicaciones culturales.
Estas fuerzas surgen del enfoque para la planificación de la estrategia

corporativa propuesto en 1980 por Michael E. Porter en su libro "Competitive
Strategy: Techniques for Analyzing Industries and Competitors".
El punto de vista de Porter es que existen cinco fuerzas que determinan las
consecuencias de rentabilidad a largo plazo de un mercado o de algún
segmento de éste. La idea es que la corporación debe evaluar sus objetivos y
recursos frente a éstas cinco fuerzas que rigen la competencia de un sector.
Además Porter consideró una serie de barreras que dificultan la entrada de una
empresa a un determinado sector.
MODELO DE LAS CINCO FUERZAS DE PORTER
FUERZAS:
Amenaza de entrada de nuevos competidores. Falta de atractivo si las barreras de entrada

son fáciles o no de franquear por nuevos participantes que puedan llegar con nuevos recursos
y capacidades para apoderarse de una porción del mercado. Por ejemplo, el uso masivo y
barato de web-hosting por parte de competidores.
La rivalidad entre los competidores. Problemas de competencia si en un mercado o en uno

de sus segmentos los competidores estén muy bien posicionados, sean muy numerosos y los
costos fijos sean altos, pues existe alto riesgo de guerra de precios, campañas publicitarias
agresivas, promociones y entrada de nuevos productos. Por ejemplo, competir hoy en día en
venta de libros on-line.
Poder de negociación de los proveedores. Un mercado o segmento del mercado no será

atractivo cuando los proveedores estén muy bien organizados gremialmente, tengan fuertes
recursos y puedan imponer sus condiciones de precio y tamaño del pedido. La situación será
aún más complicada si los insumos que suministran son claves para nosotros, no tienen
sustitutos o son pocos y de alto costo. Por ejemplo, el coste del uso de telecomunicaciones
fijado por empresas de telefonía.
Poder de negociación de los compradores. Poder de clientes bien organizados, en cuyo

caso el producto tiene varios o muchos sustitutos, el producto no es muy diferenciado o es de
bajo costo para el cliente, lo que permite que pueda hacer sustituciones por igual o a muy bajo
costo. Por ejemplo, exigencia actual de tener una canasta de compra flexible y rápida.
Amenaza de ingreso de productos sustitutos. Un mercado o segmento no es atractivo si

existen productos sustitutos reales o potenciales. La situación se complica si los sustitutos
están más avanzados tecnológicamente o pueden entrar a precios más bajos reduciendo los
márgenes de utilidad de la corporación y de la industria. Por ejemplo, las alternativas a la venta
on-line, como lo es el uso del fax.
130
Figura 4.4: Modelo de cinco fuerzas de Porter.
BARRERAS DE ENTRADA:
Economías de Escala. Supone al que las posea, debido a que sus altos volúmenes le
permiten reducir sus costos, dificultar a un nuevo competidor entrar con precios bajos. Por
ejemplo, la caída de las barreras geográficas y la reducción del ciclo de vida de los productos,
obliga y hace vulnerable un negocio a competidores más ágiles que operan globalmente.
Diferenciación del Producto. Asume que si la corporación diferencia y posiciona fuertemente

su producto, la compañía entrante debe hacer cuantiosas inversiones para reposicionar a su
rival. Por ejemplo, el riesgo en la facilidad de copia de una página web, donde un mínimo
cambio hacia una mejor presentación es difícil de demostrar.
Inversiones de Capital. La idea es que aquellos con fuertes recursos financieros tendrán una
mejor posición competitiva frente a competidores más pequeños, le permitirá sobrevivir más
tiempo que éstos en una guerra de desgaste, invertir en activos que otras compañías no
pueden hacer, tener un alcance global o ampliar el mercado nacional e influir sobre el poder
político de los países o regiones donde operan.
Desventaja en Costos independientemente de la Escala. Sería el caso cuando compañías

establecidas en el mercado tienen ventajas en costos que no pueden ser emuladas por
competidores potenciales independientemente de cual sea su tamaño y sus economías de
escala. Esas ventajas podían ser las patentes, el control sobre fuentes de materias primas, la
localización geográfica, los subsidios del gobierno, su curva de experiencia, su conocimiento o
acceso a información privilegiada.
Acceso a los Canales de Distribución. En la medida que los canales de distribución para un
producto estén bien atendidos por las firmas establecidas, los nuevos competidores deben
convencer a los distribuidores que acepten sus productos mediante reducción de precios y
aumento de márgenes de utilidad para el canal, compartir costos de promoción del distribuidor,
comprometerse en mayores esfuerzos promocionales en el punto de venta, etc, lo que reducirá
las utilidades de la compañía entrante. En el caso de e-Business, el canal de distribución tiene
un bajo coste, no obstante construirlo con los clientes es el problema.
Política Gubernamental. Las políticas gubernamentales pueden limitar o hasta impedir la

entrada de nuevos competidores expidiendo leyes, normas y requisitos. Los gobiernos fijan, por
ejemplo, normas sobre el control del medio ambiente o sobre los requisitos de calidad y
seguridad de los productos que exigen grandes inversiones de capital o de sofisticación
tecnológica y que además alertan a las compañías existentes sobre la llegada o las intenciones
de potenciales contrincantes. Hoy la tendencia es a la desregularización, a la eliminación de
subsidios y de barreras arancelarias, a concertar con los influyentes grupos de interés político y
económico supranacionales y en general a navegar en un mismo océano económico donde los
131
mercados financieros y los productos están cada vez más entrelazados.
c.1.- Análisis de mercado
Finalmente, para completar la estrategia, la organización debería definir su

mercado objetivo. Esto incluye identificar clientes potenciales y determinar si el
producto será ofrecido en el mercado a un amplio rango de clientes u ofrecido a
un nicho específico de mercado.
Esto también incluye definir cómo la organización planea representarse a sí

misma en la Red o, en otras palabras, cómo promover la organización y el
producto o servicio a sus clientes.
DEMOGRAFÍA DE LA WEB
Un análisis de mercado en un proyecto e-Business requiere estudiar la demografía de la Web

del mercado o segmento a abarcar. Esto permite tener una visión del mercado potencial de
usuarios conectados. A modo de ejemplo puede mostrarse que la población conectada crece
continuamente, igualmente el número de servidores web, conformando todo esto una masa
crítica innegable.
Figura 4.5: Usuarios conectados a la web1.
132
Figura 4.6: Servidores en Internet2.
1
Fuente: Giga Information Group. Enlace web: www.gigaweb.com. [Leído:16 de Marzo de
2005, 14.00h GMT-5].
2
Fuente: Giga Information Group. Enlace web: www.gigaweb.com. [Leído:16 de Marzo de
2005, 14.00h GMT-5].
4.2.4 Transformación de los procesos de negocio
En el mundo de la interconexión, el trabajo se puede realizar mediante varias

líneas de comunicación, sorteando distintas fronteras y jerarquías. Al utilizar las
tecnologías que ofrece Internet para transformar los procesos de la empresa,
también se modifican las relaciones que se tenían con los clientes, empleados,
proveedores o distribuidores.
• Clientes. El entorno e-Business permite pasar del marketing de masas a

la personalización en masa, dirigida a clientes individuales. También
ayuda a establecer relaciones a largo plazo con los clientes que tienen
tipos de negocios que se repiten durante toda la vida. A su vez, el
entorno e-Business permite trasladar las funciones del proceso de
transacción hasta el despacho del cliente, con la consiguiente reducción
de costes, ciclos más cortos y mayor fidelidad del cliente.
• Empleados. e-Business ayuda a que cada uno de los empleados esté
tan preparado como el que más. Permite que los empleados dispongan
de la información que necesitan cuando la necesitan. Ayuda a maximizar
la comunicación entre colaboradores y ofrece un mundo de información
disponible para toda la empresa.
• Proveedores/Distribuidores. e-Business refuerza las asociaciones a
través de la cadena de suministros y permite interactuar con los
proveedores de un modo que era impensable hace sólo unos pocos
años. Permite a la empresa trabajar más estrechamente con sus
proveedores gracias a la extensión de los sistemas a través de Internet y
a la creación de aplicaciones que hacen más eficiente la cadena de
suministros ahorrando tiempo y dinero.
133
3 HISTORIAS, 3 EJEMPLOS
Un centro hospitalario americano ha implantado un sistema basado en la Red a fin de poder

recuperar a distancia los expedientes clínicos destinados a un servicio de urgencias. Esto le
permite un ahorro anual superior a 1 millón de dólares y un posible aumento en los ingresos de
3 ó incluso 4 millones de dólares, debido a una mayor fidelidad de los pacientes y a un
aumento del número de médicos afiliados gracias a la excelente reputación conseguida...
Un fabricante alemán de cables industriales instala en la Red un sistema de pedidos para sus
clientes, integrándolo con sus sistemas de abastecimiento, gestión de Inventarios y fabricación.
Esto agiliza en un 75% la rotación de los pedidos y reduce en más de 500.000 dólares los
costos administrativos anuales...
Un banco de cobertura nacional americano de gran envergadura establece en la Red una

solución que permite a sus 16 millones de clientes presentar y pagar sus facturas. Recientes
resultados, indican que la probabilidad de que los clientes cambien de banco es cinco veces
menor, los saldos de sus cuentas son tres veces mayores y su rentabilidad es 2,6 veces
superior en un cliente promedio que utiliza servicios bancarios online...
En función del sector, existen distintos procesos de la empresa que pueden ser
considerados como los más importantes y que influyen directamente en una
mayor recuperación de la inversión a lo largo de la transacción de una empresa
tradicional a e-Business. En la banca, por ejemplo, los sistemas de soporte al
cliente son importantes, así como el pago puntual y los cobros de las facturas.
En la distribución al por menor, por otro lado, las mejoras eficaces en la
adquisición de clientes, el aprovisionamiento y los sistemas de gestión de las
existencias proporcionan la mejor recuperación de la inversión.
Sin embargo, prácticamente todos los sectores afrontan un conjunto de retos

comunes. Y aunque los términos pueden ser distintos de sector a sector, los 3
procesos claves que proporcionan la mayor recuperación de la inversión en un
entorno e-Business son:
• Gestión de las relaciones con el cliente.

• Gestión de la Cadena de Suministros.
• Comercio electrónico.
a.- Gestión de las relaciones con el cliente (CRM: Customer Relationship

Management)
Asegurarse de que los clientes estén satisfechos, ofrecerles aquello que

desean y en el momento que lo desean. Este proceso es la transformación de
pasar del cliente puntual al cliente de por vida.
CRM es básicamente la respuesta de la tecnología a la creciente necesidad de

las empresas de fortalecer las relaciones con sus clientes.
Las herramientas de gestión de relaciones con los clientes (Customer

Relationship Management CRM) son las soluciones tecnológicas para
conseguir desarrollar la "teoría" del marketing relacional. El marketing
relacional se puede definir como "la estrategia de negocio centrada en
134
anticipar, conocer y satisfacer las necesidades y los deseos presentes y

previsibles de los clientes".
Actualmente, gran cantidad de empresas están desarrollando este tipo de

iniciativas. Según un estudio realizado por Cap Gemini Ernst & Young de
noviembre del año 2001, el 67% de las empresas europeas ha puesto en
marcha una iniciativa de gestión de clientes (CRM).
En el proceso de remodelación de las empresas para adaptarse a las

necesidades del cliente, es cuando se detecta la necesidad de replantear los
conceptos "tradicionales" del marketing y emplear los conceptos del marketing
relacional:
• Enfoque al cliente: "el cliente es el rey". Este es el concepto sobre el

que gira el resto de la "filosofía" del marketing relacional. Se ha dejado
de estar en una economía en la que el centro era el producto para pasar
a una economía centrada en el cliente.
• Inteligencia de clientes: Se necesita tener conocimiento sobre el
cliente para poder desarrollar productos /servicios enfocados a sus
expectativas. Para convertir los datos en conocimiento se emplean
bases de datos y reglas.
• Interactividad: El proceso de comunicación pasa de un monólogo (de la
empresa al cliente) a un diálogo (entre la empresa y el cliente). Además,
es el cliente el que dirige el diálogo y decide cuando empieza y cuando
acaba.
• Fidelización de clientes: Es mucho mejor y más rentable (del orden de
seis veces menor) fidelizar a los clientes que adquirir clientes nuevos. La
fidelización de los clientes pasa a ser muy importante y por tanto la
gestión del ciclo de vida del cliente.
• El eje de la comunicación es el marketing directo enfocado a clientes
individuales en lugar de en medios "masivos" (TV, prensa, etc.). Se pasa
a desarrollar campañas basadas en perfiles con productos, ofertas y
mensajes dirigidos específicamente a ciertos tipos de clientes, en lugar
de emplear medios masivos con mensajes no diferenciados.
• Personalización: Cada cliente quiere comunicaciones y ofertas
personalizadas por lo que se necesitan grandes esfuerzos en
inteligencia y segmentación de clientes. La personalización del mensaje,
en fondo y en forma, aumenta drásticamente la eficacia de las acciones
de comunicación.
• Pensar en los clientes como un activo cuya rentabilidad muchas veces
es en el medio y largo plazo y no siempre en los ingresos a corto plazo.
El cliente se convierte en referencia para desarrollar estrategias de
marketing dirigidas a capturar su valor a lo largo del tiempo.
Realmente, el marketing relacional es algo que se ha venido haciendo durante

siglos. Si no, piense en el tendero de la esquina. Cuando va a comprar siempre
le reconoce, le saluda por su nombre y le aconseja (le hace ofertas
personalizadas) en función de sus últimas consultas y compras.
135
El reto actual es conseguir conocer a los clientes y actuar en consonancia

cuando en lugar de tener 50 clientes como tiene el tendero, se tienen 1.000,
5.000, 50.000 o 500.000.000. Esta posibilidad la ofrece la tecnología. Hasta
que no han existido las soluciones de CRM y las bases de datos, era inviable
conocer y personalizar mensajes a 50.000 clientes.
Los objetivos del marketing relacional y las soluciones CRM son:
• Incrementar las ventas tanto por incremento de ventas a clientes

actuales como por ventas cruzadas.
• Maximizar la información del cliente.
• Identificar nuevas oportunidades de negocio.
• Mejora del servicio al cliente.
• Procesos optimizados y personalizados.
• Mejora de ofertas y reducción de costes.
• Identificar los clientes potenciales que mayor beneficio generen para la
empresa.
• Fidelizar al cliente, aumentando las tasas de retención de clientes.
• Aumentar la cuota de gasto de los clientes.
En este contexto, es importante destacar que Internet, sin lugar a dudas, ha

sido la tecnología que más impacto ha tenido sobre el marketing relacional y
las soluciones de CRM. A continuación, se desarrolla la contribución de Internet
al marketing relacional:
• Importante disminución de los costes de interacción.

• Bidireccionalidad de la comunicación.
• Mayor eficacia y eficiencia de las acciones de comunicación.
- Inteligencia de clientes.
- Públicos muy segmentados.
- Personalización y marketing 1 to 1.
• Capacidad de comunicar con cualquier sitio desde cualquier lugar.

• Mejora de la atención al cliente. Funcionamiento 24 horas, 365 días.
• Mejora de los procesos comerciales.
Sin embargo, aunque la tecnología sea la herramienta para el desarrollo de la

filosofía, nunca puede dejarse un proyecto CRM en manos de ella. Es muy
importante destacar que para alcanzar el éxito en este tipo de proyectos se han
de tener en cuenta los cuatro pilares básicos en una empresa: estrategia,
personas, procesos y tecnología. Estos conceptos se desarrollan a
continuación:
• Estrategia: Obviamente, la implantación de herramientas CRM debe

estar alineado con la estrategia corporativa y estar en consonancia de
las necesidades tácticas y operativas de la misma. El proceso correcto
es que CRM sea la respuesta a los requerimientos de la estrategia en
136
cuanto a la relaciones con los clientes y nunca, que se implante sin que
sea demasiado coherente con ella.
• Personas: La implantación de la tecnología no es suficiente. Al final, los
resultados llegarán con el correcto uso que hagan de ella las personas.
Se ha de gestionar el cambio en la cultura de la organización buscando
el total enfoque al cliente por parte de todos sus integrantes. En este
campo, la tecnología es totalmente secundaria y elementos como la
cultura, la formación y la comunicación interna son las herramientas
clave.
• Procesos: Es necesaria la redefinición de los procesos para optimizar
las relaciones con los clientes, consiguiendo procesos más eficientes y
eficaces. Al final, cualquier implantación de tecnología redunda en los
procesos de negocio, haciéndolos más rentables y flexibles.
• Tecnología: También es importante destacar hay soluciones CRM al
alcance de organizaciones de todos los tamaños y sectores aunque
claramente la solución necesaria en cada caso será diferente en función
de sus necesidades y recursos.
b.- Gestión de la cadena de suministros (SCM: Supply Chain

Management)
Trabajar estrechamente con los proveedores para estar seguros de que

tenemos suficientes productos para vender. Facilitar a los proveedores la visión
de las aplicaciones internas de gestión de recursos de la empresa, puede que
nos ayude a que los proveedores se anticipen mejor a nuestras necesidades.
Este proceso se encuentra en la línea de reducción de costes, a la vez que
también mejora la satisfacción del cliente, ya que obtiene lo que desea y en el
momento que lo precisa.
Debido a los avances en la fabricación y la distribución, está disminuyendo el

coste del desarrollo de nuevos productos y servicios y se está acelerando el
tiempo de comercialización. Esto ha supuesto un aumento de las demandas de
los clientes, de la competencia local y global y de la presión en la cadena de
suministros.
Para seguir siendo competitivas las empresas deben reinventarse a sí mismas,

de forma que la cadena de suministros -abastecimiento y adquisición,
planificación de producción, cumplimiento de pedidos, gestión de inventarios y
atención al cliente- ya no sea un ejercicio de trastienda basado en los costes,
sino una operación flexible diseñada para enfrentarse de forma efectiva a los
desafíos actuales.
Internet está demostrando ser una herramienta eficaz en la transformación de

las cadenas de suministros de todas las industrias. Proveedores, distribuidores,
fabricantes y vendedores trabajan ahora más estrecha y eficazmente que
nunca. La cadena de suministros actual, controlada por la tecnología, permite a
los clientes gestionar sus propias experiencias de compra, aumentar la
coordinación y conectividad entre los socios de suministro y ayudar a reducir
los costes operativos de cada una de las compañías de la cadena.
137
b.1.- Desafío
El incremento de las demandas de los clientes, la competencia y la subida de

los costes de desarrollo están cambiando la cara de los negocios en la
economía de Internet. Las empresas están intentando ahora reinventarse a sí
mismas para satisfacer los plazos de entrega cada vez más reducidos y
satisfacer las cada vez mayores expectativas de los clientes.
En el pasado, los activos eran un componente crucial en el éxito de la gestión

de la cadena de suministros. En el mercado actual, sin embargo, una
orientación centrada en el cliente es clave para conservar la ventaja
competitiva. Existen varios puntos que hay que tener en cuenta a la hora de
crear una cadena de suministros exitosa centrada en el cliente:
• Recibir pedidos es sólo una parte de atender las necesidades del cliente.
Los negocios deben cumplir la promesa que hacen a los clientes
suministrando los productos y la información bajo petición, y no cuando
sea de interés para la empresa hacerlo.
• El tiempo de comercialización es una ventaja competitiva clave (Time to
Market). Las compañías deben garantizar un suministro ininterrumpido y
la información acerca de las demandas y actividades de los clientes es
esencial para cumplir este requerimiento.
• El coste es un factor importante. Las empresas necesitan reducir el
coste de los procesos internos para que los productos finales sean
menos caros.
• La reducción de los tiempos durante el ciclo de diseño es crítica ya que
permite a las compañías difundir sus productos más rápidamente para
satisfacer la demanda de los clientes.
b.2.- Solución
El desarrollo e implementación de una cadena de suministros flexible y en red

que integre a todos los socios-fabricantes, minoristas, proveedores,
transportistas y vendedores- junto a una unidad sin fisuras es el primer paso
para satisfacer las demandas actuales de los clientes y mantener un perfil
competitivo. El emprender este paso es crucial para las compañías que buscan
tomar mejores decisiones de estimación en tiempo real, reducir su inventario y
los costes asociados y acelerar la entrega de productos y servicios. Al hacerlo,
las compañías transforman su cadena de suministros desde un ejercicio de
trastienda basado en los costes a una operación flexible diseñada para
enfrentarse de manera eficaz a los desafíos actuales.
La evolución de una cadena de suministros en red implica los siguientes pasos:
• Compartición de información estática o dinámica, incluyendo niveles de

inventario, planificaciones, previsiones y documentos de diseño, entre
compañías y socios mediante la integración de la Web con sistemas
especializados como la planificación de recursos empresariales (ERP).
138
• Realización de transacciones, incluyendo el intercambio de órdenes de

pedido, facturas, información de envío, etc., a través de una red como
Internet o una red privada virtual (VPN).
• Establecimiento de comunidades de negocio, como portales, mercados
Web financieros y comunidades de subastas y licitaciones, para permitir
el desarrollo de los negocios y la integración a las empresas.
A través estos cambios, las empresas y sus asociados pueden verse a sí

mismos como una única organización virtual. Los envíos se realizan bajo
demanda y justo a tiempo, y el ciclo de pago se simplifica. Como resultado, las
compañías cambian la forma de dirigir su negocio y cómo los clientes pueden
recibir rápidamente los productos de los proveedores.
b.3.- Ventajas
Mediante la implementación de un sistema de gestión de la cadena de

suministros, integrado y en red, las empresas pueden reducir costes, aumentar
los ingresos, mejorar el servicio, acelerar el tiempo de comercialización del
producto y utilizar sus activos eficazmente.
Las compañías innovadoras que implementan técnicas de gestión de la cadena

de suministros se están dando cuenta de sus muchas ventajas, entre las que
se incluyen:
• Reducción de costes en la gestión del inventario, transporte,

almacenamiento y embalaje.
• Incremento de la satisfacción de los clientes a través de la entrada y
configuración de los pedidos en línea.
• Mejora del servicio a través de técnicas como la entrega puntual y la
fabricación bajo pedido.
• Aumento de los ingresos, gracias a la disponibilidad y la personalización
del producto.
• Reducción de los tiempos del ciclo del producto.
• Aumento de la cuota de mercado debido a la reducción de los tiempos
del ciclo de ingeniería a producción.
• Flexibilidad para diseñar, comercializar y retirar productos de la forma
más rápida.
• Capacidad de mantener la calidad del producto mientras se
subcontratan las partes principales del proceso de ejecución.
CASO: FLYMO
La empresa Flymo (www.flymo.com) se conoce por ser los inventores del "cortacésped"
flotante. Sin embargo, a pesar de su éxito doméstico, la empresa temía por el aislamiento de su
red de pequeños y medianos distribuidores. Mientras que los grandes almacenes DYI mantenía
estrecho contacto con ellos y realizaban sus transacciones electrónicamente mediante
Electronic Data InterChange (EDI), los pequeños distribuidores se sentían abandonados.
Incluso Flymo no estaba satisfecha con la manera en que ella misma llevaba este asunto. Se
percataron de los enormes gastos de procesar documentos de papel o fax, de los dolores de
139
cabeza de la administración para poder descifrar la información y del derroche que suponía
haber colocado una plantilla cualificada para realizar un trabajo de oficinista.
Era obvio que algo había que hacer, sin embargo encontrar una solución inmediata no era fácil.
Flymo había visto varios sistemas de pedidos y facturación en línea, hicieron indagaciones
sobre la posibilidad de trabajar con Internet e investigaron el uso de los CD-ROM como
catálogo digital de piezas. Sin embargo, nada parecía capaz de solventar el problema que se
presentaba.
Fue entonces cuando Flymo se puso en contacto con su proveedor estratégico ABC, una
conocida empresa informática, y juntos resolvieron los aspectos principales e idearon un plan
de acción. El director de soporte técnico en la operación de Servicios de Información de Flymo,
así lo cuenta: "El plan estaba basado en las posibilidades de Internet y lo que se podía hacer
con ellas, al tiempo que abría la posibilidad de que la tecnología ya existente en la empresa se
pudiera utilizar como una extranet. También analizamos los problemas con los que se
enfrentaba la empresa y ABC nos ayudó a identificar los problemas claves y a buscar la mejor
forma de resolverlos utilizando las tecnologías de Internet. El resultado ha sido excepcional".
Uno de nuestros principales distribuidores, con 42 centros en Gran Bretaña fue cauteloso al
principio y sólo probó con un centro piloto. Ahora ya han desplegado la extranet a través de los
41 centros restantes. De no tener nada hace 1 año, ahora estamos presenciando grandes
mejoras, a la vez que hemos conseguido una estrecha relación con todos nuestros
distribuidores".
"Ahora los distribuidores pueden conectarse en cualquier momento del día o de la noche, sin
tener que ponerse al extremo de un teléfono ni tener que mecanografiar un pedido antes de
mandarlo por fax. Las preocupaciones por escribir un número incorrecto, saber si el pedido se
ha recibido o no o si se está procesando han desaparecido. Desde nuestro punto de vista, ya
no necesitamos personal que gestione todos los fax y demás documentos que se reciben, que
descifre la información y que, potencialmente, también puede equivocarse. Este personal está
ahora libre para atender las llamadas de los clientes finales o de los distribuidores con
problemas técnicos. De manera que con este proceso global hemos resuelto un asunto de vital
importancia para nuestros clientes".
c.- Comercio electrónico
Los clientes pueden realizar sus compras a través de la Red. Se trata de

ofrecer la posibilidad de que ellos mismos procesen sus propios pedidos, como
las demandas en una empresa aseguradora o los pagos en una entidad
bancaria o financiera. Este cambio es de un enorme potencial.
Se pueden considerar estos tres procesos prioritarios como partes de un

modelo de proceso simple. Ahora, si se consideran los sistemas de
planificación de recursos de la empresa (ERP, Enterprise Resource Planning)
de una compañía, como la parte central de este modelo, entonces los sistemas
de gestión de las relaciones con el cliente habilitados para la Red o para
extranet ofrecen una interfaz para las comunidades de clientes (figura 4.7). Un
ejemplo son los sistemas de autoayuda para clientes.
140
Figura 4.7: Modelo de procesos de negocio de una solución e-Business.
En el otro extremo del modelo están los sistemas de gestión de la cadena de

suministros a través de la Red, que permiten mejorar la comunicación con los
proveedores, distribuidores y demás colaboradores de la empresa. Los
sistemas de comercio electrónico, que permiten realizar pagos a través de la
web, así como otro tipo de transacciones con toda seguridad, resultan claves
tanto para las relaciones de empresa a cliente como de empresa a empresa.
CASO: REI
REI (www.rei.com) es un minorista internacional de productos de alta calidad para los

entusiastas de las actividades al aire libre. Cuando REI decidió abrir un almacén virtual en
Internet, la empresa eligió los sistemas IBM RS/6000 para los servidores web y el software
Firewall de IBM para seguridad. Sin embargo, REI tuvo que aprender el duro camino de las
limitaciones de algún software de comercio electrónico. Tras instalar el servidor Merchant de
Netscape, REI se dio cuenta de que el sistema no ofrecía las prestaciones ni la flexibilidad que
necesitaba. REI empezó a rediseñar su sitio web para superar estas deficiencias. Pronto se
dieron cuenta de que pasaban más tiempo intentando actualizar sus páginas que buscando la
manera de mejorar sus ventas de equipos y ropa para actividades al aire libre.
REI decidió que necesitaban cambiar sus sistemas de comercio electrónico. Tras evaluar los
principales proveedores de software comercial, REI eligió Net.Commerce de IBM pro su
capacidad de integrarse con sistemas ya existentes, sus posibilidades de búsqueda y
comercialización, y su facilidad de uso y flexibilidad. Hoy, REI es una de las tiendas de la
compañía con mayor producción. Más de un cuarto de los compradores virtuales de los
almacenes son nuevos para REI. Sus páginas han permitido que REI consiga nuevos clientes
de todo el mundo y que comercialice sus productos en francés, alemán, japonés y español,
141
aparte del inglés.
Además de haber elegido el sistema adecuado a sus necesidades y objetivos, REI descubrió
que la implicación de todo el personal de la empresa es fundamental para el éxito de sus
iniciativas electrónicas. REI utiliza recursos de todas sus divisiones en lugar de disponer de una
unidad separada de comercio electrónica para gestionar la operación. De esta forma se alienta
a cada grupo de ventas al por menor para que pongan todo su empeño y sean cada vez
mejores, a la vez que ha creado un sentimiento de propiedad y un soporte de toda la empresa
de incalculable valor para el éxito de REI.
4.2.5 Factores críticos de éxito para una estrategia e-Business1
• Un norte claro. Crear una idea de hacia dónde se quiere llegar con las
soluciones e- Business. Esta idea se centra más en la mejora de los
procesos centrales que en la adquisición de las tecnologías más
populares del momento. Los ejecutivos están comprometidos con esta y
son sus mejores defensores dentro de la empresa.
• El proyecto es de toda la organización. Las personas alrededor de la
empresa se ven implicadas en la transformación. No se trata de un
proyecto aislado de ti. Los expertos y técnicos de la empresa colaboran
para cambiar fundamentalmente el modo de hacer las cosas.
• Hay que unir visión de negocios y visión tecnológica. Se requieren
expertos y estas empresas reconocen que la transformación de los
procesos centrales de la compañía necesita más que un webmaster. Se
requieren las cualidades de expertos, especialistas en bases de datos,
gente que conozca los sistemas vigentes, gestores de proyectos y
veteranos en el proceso de la empresa. Cuando sus recursos internos
no disponen de la experiencia necesaria, dichas empresas se asocian
con expertos de fuera de la empresa.
1
Factores Críticos de Éxito (Critical Success Factors, CSF). CSF se definen como áreas en las
cuales los resultados, si son satisfactorios, asegurarán un desempeño competitivo a la
organización. En esencia son áreas de actividad bajo continuo cuidado y atención de la
gestión. Como se puede intuir, esta definición es bastante amplia y, como el mismo Rockart lo
plantea, no es posible garantizar que el CSF de una organización sea el adecuado para otra.
Fuente: Rockart, J.F. (1979). "Chief executives define their own data needs". Harvard Business
Review, 57 (2): 238-241.
4.3 Definir la aplicación e-Business

La aplicación e-Business es el medio para implantar la solución e-Business.
Esto implica identificar cual o cuales aplicaciones serán necesarias y definir la
arquitectura informática que les dará el soporte computacional necesario.
4.3.1 Identificar potenciales aplicaciones
Para conseguir el máximo potencial de la solución e-Business es importante

desarrollar una visión de e-Business compartida y, basados en los factores
críticos de éxito de la empresa, identificar y priorizar las oportunidades e-
Business. Es importante tener presente en este análisis que el valor de las
142
aplicaciones e-business requiere evaluar por igual, tanto los costes

tecnológicos y los beneficios como aspectos de riesgo y de seguridad.
• Por una parte, hay que definir la aplicación o las aplicaciones e-

Business, aquél sistema que responde de manera efectiva a las
necesidades de la estrategia y que abarca un conjunto de procesos de
negocio (figura 4.8).
• Por otra parte, es necesario identificar las soluciones e-Business nuevas
y ejecutables que ayuden a implementar efectivamente la estrategia
(figura 4.9). Estas soluciones pueden ser: interfaces de web, gestores
de contenido u otros productos comerciales.
Figura 4.8: Identificación y definición de aplicaciones.
Figura 4.9: Alcance de las soluciones e-Business.
a.- Aplicaciones e-Business
143
Cada empresa debe determinar cómo generar y maximizar su valor añadido

durante todo el periodo de despliegue del proyecto e-Business. En
consecuencia, los planes de implantación de los procesos variarán según las
empresas y los sectores de actividad, adecuándose a la manera en que cada
una pueda mejorar la calidad y la eficacia de su servicio al cliente, y en función
de dónde radiquen las verdaderas oportunidades de negocio. Esto lleva a
definir aplicaciones de varias maneras.
• Un banco cuya estrategia se centre en las relaciones con sus

clientes agrupará una serie de productos y servicios estratégicos
para proponerlos como una oferta unificada. En este caso, el plan de
valorización e-Business comienza por el soporte al cliente y la
ampliación del servicio, continúa con la conquista de nuevos clientes y la
implantación de facturación y pagos online, para finalmente extenderse a
los procesos de seguimiento y de generación de informes, que a su vez
sirven para modificar los procesos administrativos y las ofertas.
• Un banco cuya estrategia esté enfocada principalmente en sus
productos intentará desarrollar productos financieros de masa
personalizables, a fin de satisfacer necesidades precisas de los
clientes: tarjetas de crédito, préstamos, consulta de saldo, etc. Su
plan de implantación de procesos será muy diferente: enfocado
inicialmente en cómo conquistar nuevos clientes de forma más rentable
y eficaz, evolucionará hacia la optimización e interconexión de los
procesos internos de comunicación y operaciones de sus agentes
comerciales. Se extenderá posteriormente hacia el soporte al cliente,
tanto para el usuario final como para el revendedor online, continuando
con las herramientas de business intelligence para el seguimiento
comercial y los informes de ayuda a la decisión, para llegar finalmente al
desarrollo de nuevos productos.
Al trabajar con clientes de todo el mundo las 24 horas del día, las
aplicaciones e- Business que han alcanzado el éxito comparten una
serie de características comunes.
• Datos centralizados. Tienden a tener un servidor central de manera
que proporcionan acceso a todo el sistema una amplia variedad de
clientes (browsers, Personal Data Assistant o PDA, sistemas telefónicos,
etc.). Las aplicaciones se integran en procesos claves, especialmente la
gestión de las relaciones con el cliente, la cadena de suministro y, de
forma creciente, el comercio electrónico.
• Las aplicaciones e-Business aprovechan las aplicaciones y
soluciones ya existentes. Amplían las principales aplicaciones,
incrementando su alcance y, en última instancia, su valor. Las
aplicaciones se diseñan sobre lo que ya tienen, por lo que pueden
aprovechar sus sistemas centrales de la empresa. Simplemente los
amplían, aprovechando las aplicaciones y los datos de que ya disponen,
sin preocuparse de la forma en qué se encuentran. Diseñan sobre sus
inversiones, no las sustituyen.
• Permiten optimizar la carga de trabajo para cualquier servidor. Esto
es posible porque se utilizan técnicas de programación basadas en
estándares y las aplicaciones se pueden trasladar de un sistema a otro
144
sin tener que preocuparse por las compatibilidades del sistema

operativo. Esto permite satisfacer sus necesidades de integración,
adaptabilidad y capacidad de uso.
• Crecen con la empresa. Es difícil predecir cuántas personas visitarán
un sitio web en un momento dado y es importante que la aplicación sea
capaz de adaptarse. La gente no esperará en sus páginas más de lo que
espera en un número 900. Probablemente menos. Por eso la
adaptabilidad, junto con la disponibilidad y la seguridad de la aplicación
son más importantes que nunca.
• Son fáciles de desarrollar y utilizar. Son dinámicas. Cambiar conforme
la empresa cambia y se despliegan a los nuevos usuarios que desean
un funcionamiento intuitivo y eficaz.
b.- Soluciones e-Business
Para identificar las soluciones e-Business se requiere un proceso de análisis

del mercado de las soluciones e-Business, el cual requiere generar, para cada
una de ella, una lista de beneficios esperados y sus factores críticos de éxito.
Aparte, es conveniente desarrollar métricas o criterios mensurables del éxito de
estas soluciones.
En una gran empresa, las soluciones e-Business, compradas y/o desarrolladas,

pueden ayudar a competir del mismo modo que otras empresas más pequeñas
y más ágiles, facilitando una mayor capacidad de respuesta y una
comunicación más directa con los clientes. Si es una pequeña empresa, las
soluciones e-Business finalmente ayudan a parecer más grande un negocio al
proporcionarle más presencia y acceso a clientes de todo el mundo.
c.- Análisis de la aplicación
Por la complejidad del proceso, debería hacerse uso de un esquema que

represente las aplicaciones de negocios y los objetivos tecnológicos de la
empresa, de tal manera de establecer la prioridad relativa de cada aplicación.
Con el fin de analizar de que manera las soluciones tecnológicas subyacentes

a las soluciones e-Business existentes satisfacen efectivamente a las
aplicaciones y procesos de negocios (ver figura 4.10), se usa método el n-
cube. En este tipo de representación, existe un eje de aplicaciones, otro de
procesos de negocio y un tercero de soluciones e-Business.
145
Figura 4.10: Dimensión de las soluciones e-Business.
Figura 4.11: n-cube1.
Gracias a esta representación, se puede decir que una aplicación abarca uno o
varios procesos de negocio, mediante la utilización de una o varias soluciones
e-Business. En otras palabras, las aplicaciones y los procesos de negocio que
necesitan ser desarrollados y soportados tecnológicamente están en el frente
del cubo y cada cara adicional representa los diferentes y variados
componentes tecnológicos que se necesitan por cada aplicación o, lo que es lo
mismo, el alcance de aportación de la solución en sostener determinado
aspecto de la aplicación.
Muchas organizaciones tienen un registro bastante amplio de aplicaciones que

superan con creces presupuestos y capacidad de la empresa. Por este motivo
146
es importante establecer prioridades para la implantación de estas

aplicaciones, dependiendo de dos tipos de factores:
• Factores internos como presupuestos, fuerza de trabajo, disponibilidad

de recursos y disposición organizacional.
• Factores externos como regulaciones gubernamentales, presión
competitiva, ser el primero en el mercado, etc.
Por último, para asegurar el éxito de estas aplicaciones, la organización debe

construir un consenso y mejorar la comprensión y el compromiso del portafolio
de aplicaciones, involucrando u haciendo participar a ejecutivos y
departamentos.
d.- Factores críticos de éxito de una aplicación e-Business
• Claridad en los objetivos de negocios. Un objetivo de negocio

relaciona áreas a las cuales se busca incrementar ganancias y disminuir
los gastos, o donde hacer que las cosas funcionen de manera más
adecuada, guiando en todo momento el diseño de la aplicación.
• Añadir valor. Un proyecto e-Business debe concentrarse en áreas
donde se espera obtener beneficios y ganancias. En este caso la
tecnología debe verse como un habilitador y un facilitador del cambio, en
ningún caso como conductor del cambio.
• Retroalimentación rápida y continua. La acelerada velocidad en la
introducción de nuevas tecnologías requiere que el proyecto e-Business
tenga rápidamente resultados para generar métricas de análisis.
• 'Cerrar las puertas por donde entra el agua'. En un proyecto e-
Business es imprescindible que las tareas realizadas sean bien
concluidas evitando volver a ellas. Esto evita cuellos de botella.
• Flexibilidad. Casi condición sine qua non, la flexibilidad en un proyecto
e-Business es imperativa para enfrentar los continuos cambios
tecnológicos.
• Fijar hitos económicos. Aparte de los hitos de gestión, es conveniente
establecer hitos de naturaleza económica con contratistas y
proveedores.
• Contar con pequeñas victorias. La presión del trabajo rápido requiere
que se puedan tener pequeñas victorias para mantener la energía en
alto.
• Creación de un cambio cultural. Un proyecto de e-Business es una
acción cuya obra resultante es un cambio en la manera de observar el
negocio con el consecuente cambio de cultura.
Existe un conductor. Habitualmente un CEO (Chief Executive Officer), es

conveniente que un directivo sea un líder del proyecto de e-Business, alguien
que presta atención al proyecto y da el ejemplo. Este conductor puede ser o no
el gestor del proyecto.
CASO: NORWEST
La empresa Norwest Mortgage, con base en Des Moines, Iowa, utiliza el servidor de
147
aplicaciones WebSphere Application Server, Standard Edition y WebSphere Studio para

desarrollar y desplegar aplicaciones hipotecarias de autoservicio. La línea de productos
WebSphere permite que los especialistas en hipotecas de Norwest puedan enviar información
sobre préstamos y verificar el estado de un préstamo desde el Web site de Norwest Mortgage,
las 24 horas del día, los 7 días de la semana.
Una vez que un préstamo se pone en marcha, los especialistas pueden verificar su estado. Un
gran número de las llamadas que se reciben en Norwest Mortgage son para consultar el estado
de los préstamos. El ofrecer la verificación del estado en línea a modo de autoservicio ha
reducido los costes de Norwest en los contactos empresa-cliente. Los gestores pueden generar
informes sobre las estadísticas de productividad individual de los corretajes y los
correspondientes gestores bancarios. El sistema Alliance de Lender genera informes de
seguimiento del estado de los bancos correspondientes frente a sus compromisos mensuales
de generación de préstamos.
Puesto que la solución se basa enteramente en servlet, no se necesita software de cliente. Los
servlets de Norwest son módulos de programa acoplados al servidor y escritos en Java con
VisualAge para Java de IBM para ampliar la funcionalidad del servidor Web. Estos módulos se
cargan y funcionan dentro del servidor web y utilizan los servidores http para recibir y
responder las consultas de los exploradores web de los sistemas cliente. El servidor de
aplicaciones WebSphere permite desplegar y gestionar los Java servlets y JavaBeans en un
entorno de plataforma cruzada fácil de utilizar.
Los Business partners solo necesitan una inversión mínima para acceder al sistema: cualquier
tipo de sistema (Macintosh, PC, Network Computer), un explorador web y cualquier tipo de
conexión a Internet. La presencia omnipresente de Internet en las empresas actuales garantiza
que la mayoría dispongan de un proveedor de servicio Internet. Para aquellos que no disponen
de él, el bajo costo de una tarifa plana permite igualmente un acceso ilimitado sin suponer
impedimento alguno. Los usuarios acceden al web site para los miembros de Norwest con su
ID de registro y la contraseña. Para proteger la confidencialidad de la información que circula
por Internet, la página soporta browsers que utilizan mensajes cifrados de 40 ó 128 bits.
Después del período de implantación y análisis de códigos, los creadores expertos en Java de
Norwest codificaron la aplicación en 2 meses, más 3 semanas de pruebas beta sobre el
terreno. El soporte de WebSphere para los estándares abiertos permitió que Norwest pudiera
diseñar sus aplicaciones a partir de su inversión de hardware y de software ya existente y
desplegar una aplicación basada en la Red con un mínimo coste. Norwest espera recuperar los
gastos de desarrollo de WebSphere en 3 o 6 meses tras sustituir el intercambio manual de
información existente por la aplicación web de autoservicio. Un grupo seleccionado de
empresas asociadas utiliza actualmente la solución. Cuando ésta se encuentra totalmente
implementada, todos los agentes hipotecarios de Norwest y los bancos correspondientes
podrán acceder al sistema.
WebSphere minimizó los gastos de desarrollo y permitió una rápida implantación al ofrecer a
Norwest la posibilidad de convertir las aplicaciones existentes en una solución e-Business de
autoservicio. Las posibilidades electrónicas de consulta de datos e intercambio de documentos
de la solución permiten compartir la información de forma rápida, eficaz, precisa y asequible
entre Norwest y sus empresas asociadas. Los agentes hipotecarios y los bancos
correspondientes utilizan la disponibilidad de 24 horas al día de la aplicación de Internet para
recuperar datos e iniciar préstamos por su cuenta, reduciendo el volumen de trabajo de los
empleados de Norwest. La transmisión de los documentos hipotecarios en formato PDF a
través de Internet no sólo ahorra los costes de impresión, envío y entrada de datos, sino que
además pone los documentos más importantes de la empresa en manos de aquellos que los
necesitan más rápidamente que nunca. Como resultado, los socios de Norwest pueden cerrar
más negocios con menos esfuerzo y Norwest puede procesar más préstamos sin personal
adicional.
1
Fuente: IBM.
148
4.3.2 Definir arquitectura
Definir la arquitectura tecnológica que soportará las aplicaciones presentes y

futuras de la organización es la forma concreta de crear las oportunidades que
se espera de la solución.
a.1.- Proceso de definición
Muchas organizaciones, con la ayuda de vendedores y proveedores, tratan de

ir más allá de este paso identificando y seleccionado un conjunto de productos
y tratando de armar en conjunto una arquitectura que soporte las aplicaciones.
No obstante, el proceso es más complejo, requiriéndose:
- Crear, desplegar e integrar aplicaciones y sistemas e-Business rápidamente.

La velocidad en el desarrollo permite aprovechar los cambios tecnológicos y la
experiencia de crecimiento de la empresa.
- Buscar oportunidades de ampliar las aplicaciones o sistemas existentes, en

lugar de deshacerse de los sistemas y datos que ya tienen. Esto permite
aprovechar las inversiones de TI existentes. Se diseñan aplicaciones que
pueden funcionar en múltiples plataformas para poder disponer de la
flexibilidad necesaria para utilizar distintas plataformas de hardware conforme
varían las necesidades de capacidad.
- Desarrollar aplicaciones y sistemas basados en estándares para crear

interfaces de usuario que resultan familiares y fáciles de usar.
Trabajar con vendedores y/o proveedores no es una mala estrategia, no

obstante la empresa está limitada a lo que le ofrecen, en cuyo caso, puede
ocurrir, que la arquitectura finalmente seleccionada esté pobremente
planificada, sea inflexible y no permiten un escalamiento que soporte las
cambiantes y evolutivas necesidades de procesamiento de la empresa, debido
a no haber seguido un proceso de selección y definición más completo y que
haya considerado todo el mercado de aplicaciones informáticas y de e-
Business existentes.
a.1.1.- Entorno ampliable, disponible y seguro
Cuando se trabaja con aplicaciones e-Business, tanto si se crean como si se

compran e integran, se desea que todas las plataformas funcionen como una
plataforma única, de manera que los usuarios no noten ninguna diferencia en la
capacidad de respuesta, fiabilidad, funcionalidad o interfaz. Simplemente que
se den cuenta que la aplicación funciona con más eficacia.
Todos deseamos que nuestros sistemas se puedan ampliar. Añadir capacidad

adicional conforme las visitas a las páginas web aumentan o añadir capacidad
según la demanda, de tal manera que si las necesidades cambian
dramáticamente de hora en hora, aún se pueda continuar haciendo negocios.
149
Deseamos que la gestión sea lo más fácil posible. Y que los sistemas sean
seguros de principio a fin.
Las oportunidades son numerosas. Gestión fácil, entornos seguros y, como

punto de partida, un entorno más rentable.
a.1.2.- Desarrollo y ejecución flexibles
Al desarrollar y poner en marcha las aplicaciones e-Business, se necesitan

varios tamaños de procesadores.
Es conocida la historia de los servidores en ordenadores personales. Aunque

algunos incluso ofrecen una disponibilidad del hardware del 99%, hay sistemas
PC que tienden a funcionar con alrededor del 97% de disponibilidad. Esto está
bien para un entorno de trabajo en grupo o de desarrollo. Sin embargo, cuando
una aplicación debe servir a un gran número de usuarios y se esperan niveles
de transacción aún superiores, la cosa cambia.
Aquí es cuando la calidad y la fiabilidad del servicio que ofrecen los sistemas
de empresa y de gama media adaptables se convierten en algo sumamente
importante. Ampliar la capacidad de las aplicaciones añadiendo un servidor PC
tras otro crea sistemas cada vez más complejos. Estos sistemas pueden ser
menos fiables y necesitan un soporte más caro.
Cambiar a un servidor de gama media adaptable como, por ejemplo, un

AS/400, puede proporcionar más capacidad de almacenamiento, más potencia
de procesamiento y la posibilidad de ejecutar múltiples aplicaciones de forma
simultánea. La disponibilidad media de estos servidores de gama media llega
hasta el 99,97%. En un entorno de producción, esto supone una enorme
mejora.
Para cierto tipo de aplicaciones, un mainframe puede ser la mejor solución. Por
ejemplo, con un S/390, las aplicaciones se pueden ejecutar en el servidor
manejando un gran número de transacciones y con un grado casi perfecto de
disponibilidad y de fiabilidad del 99,997%. Y en muchos casos, el S/390
ofrecerá el menor coste por unidad, dependiendo del volumen de transacciones
que manipule el sistema.
Así que cuando se desee crear aplicaciones en servidores PC e incluso

desplegarlas inicialmente en los PC, deseará que sean lo bastante flexibles
como para poderlas trasladar más tarde a un servidor de mayor volumen si la
situación lo requiere.
b.1.- La arquitectura e-Business
La arquitectura a definir debe soportar las aplicaciones en Web, intranet y

extranet que provean ciertos servicios básicos, de tal manera de proveer y
soportar un servicio al cliente 24 horas al día los 365 días al año, además de
accesos eficientes a los clientes habituales y a los millones de nuevos de
clientes potenciales en cualquier momento y en cualquier lugar.
150
Para ello se propone una arquitectura que cuente con servicios de tres tipos,
los cuales pueden implementarse en tres capas (layers) según la función que
cumplen. Estas capas son (figura 4.12):
• Capa de servicios de infraestructura.

• Capa de servicios habilitadores.
• Capa de servicios de aplicación.
Figura 4.12: Arquitectura lógica para arquitecturas e-Business.
b.1.1.- Capa de servicios de infraestructura
Esta capa provee los servicios básicos requeridos para implementar

aplicaciones dentro de la organización. Consiste en:
- Servicios de redes basados en protocolos TCP/IP.
- Servicios básicos provistos por el sistema operativo para gestión de recursos

de hardware y software.
- Servicios de Gestión de Sistemas Distribuidos que ayudan a proveer un

mecanismo consistente y consolidado de manutención y soporte de los
recursos de computación distribuidos.
- Servicios de Directorio que ayudan a localizar recursos en el ambiente

distribuido.
151
- Servicios de Seguridad que controlan el acceso a recursos distribuidos y

protegen los recursos de la organización de accesos no autorizados, tanto
internos como externos.
EJEMPLO: CACHE/PROXY Y ALMACENAMIENTO
Las presiones por proveer servicios que disminuyan la carga y provean seguridad en
ambientes distribuidos por naturaleza, como lo es una aplicación e-Business, ha llevado a
determinados proveedores a configuraciones como la que aquí se muestra (Novell's Internet
Cache Systems, ICS).
La complejidad de un sistema cache, lo cual involucra diversos elementos técnicos, es una

tarea compleja, más aún cuando se ven involucrados variables de costo y experiencia de
usuarios y desarrolladores.
Una tendencia en almacenamiento son las redes de almacenamiento (Storage Area Network,
SAN), integrando tecnología de canal de fibra y los medio ambientes heterogéneos de
almacenamiento. La finalidad es distribuir el almacenamiento a través de diversos medios y
formatos.
Figura 4.13: Arquitectura Cache Proxy (incremento del desempeño del servidor web y ftp)1.
152
Figura 4.14: Opciones de cache múltiple2.
Figura 4.15: Redes de almacenamiento3.
- Servicios de Ficheros que proveen una visión unificada para el uso y

manutención de dispositivos de almacenamiento distribuido como discos duros,
CD-ROM y cintas.
- Ambientes de Computación Distribuida (DCE, Distributed Computing

Environment) como CORBA de OSF (Open Software Foundation4) o DCOM
(Distributed Component Object Model5) de Microsoft que ayudan a los
desarrolladores a construir, probar e implantar aplicaciones de computación
distribuidas.
EJEMPLO: SEGMENTACIÓN DEL MERCADO DE SERVIDORES DE APLICACIONES
153
Al desarrollar un conjunto de propuestas de selección de herramientas, los gestores del

proyecto e-Business deben enfocarse en proveer a sus desarrolladores un rango de soluciones
que permita una selección adecuada. Por ejemplo, seleccionar soluciones construidas sobre
una arquitectura de componentes común (Java/Enterprise JavaBeans, EJB/J2EE) versus
Component Object Model (COM) o CORBA lo cual facilitará la integración entre aplicaciones y
simplificará la migración de aplicaciones entre herramientas, si fuese necesario.
Figura 4.16: Segmentación del mercado de Servidores de Aplicaciones6.
b.1.2.- Capa de servicios habilitadores
Esta capa provee los servicios requeridos para soportar las aplicaciones
desarrolladas dentro de la arquitectura. Consiste de:
Gestores de correo electrónico que proveen los servicios de correo y gateways

que permiten la comunicación con otros sistemas de correo electrónico.
Servicios de Workgroup, los cuales incluyen funciones de manutención de

calendario, compartir dispositivos y recursos, grupos de discusión, boletines y
otras funciones que permiten la colaboración dentro de los workgroups.
- Gestor de Workflow, el cual ayuda a configurar los procesos de negocios

como secuencias de tareas interelacionadas que requieren ser ejecutadas en
una secuencia predefinida.
- Monitor de Transacciones que gestiona las transacciones7 en un medio

distribuido y ayuda a mantener la integridad de los datos fuente. Los monitores
son vitales cuando:
- más de una base de datos es actualizada dentro de una transacción;
154
- existen transacciones en línea;
- cuando la arquitectura soporta aplicaciones que tienen más de dos tier8

lógicos; y,
- cuando más de un máquina procesa una transacción.
- Servicios de cola de mensajes que garantizan que los mensajes son

entregados.
- Servicios de base de datos que permitan y soporten el almacenamiento y

recuperación de datos. Estos servicios operan sobre esquemas de bases de
datos de redes, jerárquicos, relaciones u objetuales.
- Servidores web que provean soporte para todos las facilidades de red como
HTTP, ftp, scripts y JAVA.
b.1.3- Capa de servicios de aplicación
Esta capa provee servicios que permiten a los desarrolladores de aplicaciones

desarrollar, probar y desplegar aplicaciones e-Business. Estos servicios
incluyen:
- Soporte para HTML y DHTML (dynamic HTML).
- Script para clientes los cuales soporten, por ejemplo, JAVAScript.
- JAVA applets, JAVA beans y JAVA Servelet Support.
- Script para servidores con soporte CGI, NSAPI e ISAPI.
- Soporte para componentes ActiveX y Active Server Pages.
Entre los factores a tener presente en la selección de componentes se

incluyen:
- La naturaleza del entorno o medioambiente de procesamiento dentro de la

organización. Por ejemplo, homogéneo o heterogéneo.
- La naturaleza de las aplicaciones que necesitan construirse. Por ejemplo, ser

desarrolladas de manera integrada con aplicaciones existentes (legacy
applications).
- Niveles de habilidades en la organización respecto de Tecnologías de la

Información. Podemos preguntarnos:
- ¿Cuáles son las habilidades en Internet y computación distribuida que se

poseen?
155
- ¿Los programadores están familiarizados con el diseño y desarrollo de

aplicaciones orientadas al objeto?
- ¿Qué tipos de habilidades son necesarias para construir aplicaciones para el

procesamiento de transacciones existen? ¿en CICS, DB2, IMS?
- ¿Qué niveles de servicio necesitan ser provistos por las aplicaciones e-

Business?, por ejemplo:
- ¿Los clientes necesitan acceder a información actual?
- ¿Necesita el cliente acceso inmediato a información actualizada?
- Transacciones online.
- Transacciones asíncronas.
- Soporte de e-Mail y trabajo colaborativo.
- Escalabilidad de las aplicaciones.
- Coste total, que incluye costos iniciales de hardware y de software, costes del
hardware de red, costes de soporte y manutención, costes de actualización de
hardware y de software y, costes de rollout.
c.- Factores críticos de éxito de una arquitectura e-Business
• Particionable. Las aplicaciones se encuentran fragmentadas, cuyo

funcionamiento integrado y consistente debe soportar la aplicación, en
razón de la evaluación coste/beneficio de escalabilidad y disponibilidad.
• Escalable. La arquitectura debe proveer niveles aceptables de
escalabilidad en el desempeño de múltiples usuarios y con altos
volúmenes de transacciones. Esto incluye la integración con hardware,
software y aplicaciones diversas. Es decir, un crecimiento en la
capacidad según la demanda, para gestionar el volumen de trabajo
conforme las necesidades de la empresa crecen y garantizar así la
continua disponibilidad del sistema.
• Flexible. La arquitectura es abierta y soporta la incorporación de nuevas
tecnologías y productos conforme lo requieran los diversos procesos de
negocio que se integren. La arquitectura también asegura que los
servicios provistos deben estar disponibles a clientes GUI, Web
browsers, Voice Responde Units y cualquier otro tipo de clientes.
• Confiable. La arquitectura provee soporte confiable y seguro para todos
los usuarios. La confiabilidad debe garantizar un soporte atómico,
consistente, íntegro y durable (ACID9) de todas las transacciones
ejecutadas entre los múltiples gestores de recursos (aplicaciones legacy,
ERP, bases de datos, etc.). En concreto, la infraestructura debe ofrecer
un nivel de seguridad adecuado para satisfacer las necesidades del
comercio electrónico y salvaguardar datos.
156
• Disponible. La arquitectura debe soportar capacidades operacionales

consistentes con los niveles de servicio acordados para la aplicación con
un 99.99% de disponibilidad las 24 horas del día, los 365 días del año.
Si la infraestructura que da el soporta "cae", deberían recuperarse y re-
establecerse las aplicaciones dentro de un lapso de tiempo razonable.
• Accesible. La aplicación debe ser accesible desde cualquier lugar. El
tipo de dispositivo cliente no debe ser un problema.
• Gestionable. Se necesita una gestión única para poder gestionar
fácilmente múltiples plataformas. La arquitectura es soportada por un
conjunto de herramientas comerciales disponibles comercialmente las
cual han de simplificar las funciones de gestión de los sistemas para los
componentes distribuidos de la arquitectura. Esto incluye iniciar y
detener servicios, iniciar automáticamente recuperaciones, monitorear y
reportar errores, distribuir y afinar (tuning) el software, etc.
• Recuperable. La arquitectura provee funciones de detección y
recuperación de errores para todos sus servicios. Esto debería asegurar
que la integridad transaccional y de la base de datos se preserva en los
procesos de re-inicio (re-start) y recuperación (re- backup) del sistema.
1
Fuente: Giga information group. Enlace web: www.gigaweb.com. [Leído:16 de Marzo de 2005,
14.00h GMT-5].
2
14.00h GMT-5].
3
14.00h GMT-5].
4
OSF es una organización cuyo propósito es fomentar y, en algunos casos, desarrollar
tecnologías de software que puedan servir con fines industriales y, más aún, como eventuales
estándares nacionales e internacionales. OSF ha desarrollado una plataforma de uso industrial
para computación distribuida, la Distributed Computing Environment (DCE).
5
DCOM (Distributed Component Object Model) es un conjunto de conceptos e interfaces de
programas de Microsoft con los cuales objetos en aplicaciones cliente pueden solicitar servicios
de objetos en aplicaciones servidor ubicados en otros ordenadores en una red. DCOM se basa
en Component Object Model (COM), el cual provee un conjunto de interfaces que permite a
clientes y servidores comunicarse dentro de un mismo ordenador.
6
14.00h GMT-5].
7
Transacción: secuencia de actualizaciones que necesitan ser ejecutadas como parte de una
misma unidad lógica de trabajo.
8
Tipo especial de arquitectura cliente/servidor que consiste de 3 procesadores diferentes y
distinguibles, cada uno corriendo en plataformas diferentes. Por ejemplo:
9
ACID (Atomicity, Consistency, Integrity, Durability).
4.4 Desarrollo y despliegue

En la Economía en Red el éxito depende de quién primero alcanza con éxito el
mercado. Por ello no es extraño que muchos productos fracasen porque se
llega tarde, fuera de oportunidad o sencillamente porque no se fue eficiente en
alcanzar el mercado.
Para desarrollar y desplegar aplicaciones e-Business exitosas es necesario un

plan táctico que directamente equipare, por un lado, las estrategias
organizacionales y las demandas de mercado y, por otro lado, los objetivos de
157
TI. En otras palabras, conseguir un equilibrio al momento de construir la

solución e-Business entre, por una parte, el negocio y la urgencia de mercado,
con la pureza arquitectónica y la excelencia tecnológica.
4.4.1 Desarrollo
El desarrollo de la solución e-Business involucra un plan táctico y un programa

de desarrollo.
a.1.- Crear plan táctico
Comience dando un pequeño paso y crezca rápidamente. La transición hacia el

e-Business debe realizarse progresivamente. Las empresas y personas
implicadas en la implantación y uso de aplicaciones e-Business aprenden a
medida que avanza el proyecto. Pocas empresas se arriesgan a lanzarse a
gran escala, sin garantías, en el nuevo universo e-Business. La filosofía de
"comenzar dando un pequeño paso y crecer rápidamente" es tan común como
eficaz.
Las empresas que ya tienen una amplia experiencia en e-Business hacen

hincapié en la importancia de contar con una visión o estrategia de futuro. Es la
única manera de garantizar que su inversión en e-Business sea válida y eficaz.
La estrategia e-Business debe desarrollarse desde el primer momento, lo antes
posible en el proceso de implantación, y servirle de guía para regular las fases
sucesivas de su proyecto e-Business.
Por este motivo, el plan táctico requiere considerar varios elementos:
- Los objetivos estratégicos de la organización y las prioridades relativas.
- Los beneficios para el negocio de estas aplicaciones.
- Los atrasos e inconvenientes de aplicaciones actuales.
- Las habilidades de la organización de entregar y soportar tales objetivos

(presupuestos, recursos y habilidades).
El plan táctico debe enfocarse en entregar las aplicaciones e-Business

comenzando de forma creciente desde la más simple. Cada esfuerzo de
desarrollo debería ser medido en tareas concretas y específicas que respondan
coherentemente con los objetivos de negocios.
Por este motivo se recomienda diseñar la arquitectura de manera fundacional,

tal como se hace en la construcción de edificios, de tal manera de tener una
sólida y fuerte base sobre la cual, y a partir de ella, introducir las tecnologías y
servicios necesarios para el adecuado desarrollo de todas y cada una de las
aplicaciones e-Business (figura 4.17). Con este mecanismo de trabajo se
puede mantener a la organización focalizada o pendiente de los objetivos del
negocio minimizando cualquier distracción que conlleve la introducción de las
tecnologías y servicios. Básicamente es no convertir el medio en el objetivo.
158
Figura 4.17: Arquitectura de un sistema e-Business.
El resultado de este paso es un plan de proyecto de alto nivel y una propuesta

de implantación en fases para todo el portafolio de aplicaciones e-Business.
Este portafolio ha de reflejar las prioridades del negocio, el presupuesto
organizacional dedicado al proyecto y las restricciones en recursos. También
ha de incluir una sección con un análisis de recursos y requerimientos de
habilidades y recomendaciones sobre cómo gestionar los recursos.
b.1.- Programa de desarrollo
La figura 4.18 muestra un programa de desarrollo.
Figura 4.18: Desarrollo de la iniciativa e-Business.
Al crear sus primeros sitios web externos que marcan presencia, las empresas
descubren en seguida el potencial de la Red para establecer unas relaciones
más personales, eficientes y competitivas con sus clientes. Esta toma de
conciencia constituye el punto de partida de su proyecto e-Business.
En la fase piloto, las empresas centran su atención en preparar la información

para hacerla accesible a sus clientes como un verdadero "autoservicio". En el
sector de los transportes aéreos, por ejemplo, las compañías aéreas han
159
comenzado simplificando la información sobre salidas/llegadas de sus vuelos,

de modo que sea directamente accesible para los clientes online.
Durante la fase de implantación, las empresas abren estas bases de datos

estratégicas a sus clientes y/o colaboradores y proveedores para efectuar
transacciones u operaciones comerciales electrónicas, Por ejemplo, las
compañías aéreas ofrecen reservas online, y los bancos servicios interactivos.
En esta fase, los clientes pueden comprar y efectuar transacciones online
siempre que lo deseen, y la empresa a su vez adquiere conocimientos
inestimables sobre las necesidades y el comportamiento de sus clientes.
Gracias a lo anterior, la empresa puede clasificar a sus clientes de acuerdo a

su comportamiento y rentabilidad. Sin embargo, si no se hace el esfuerzo inicial
de adecuar la información a los clientes, las ventajas de esta interacción,
aunque reales, serán mínimas. Numerosas empresas han comenzado a ofrecer
transacciones online a fin de disminuir sus costes, pero sin contar con el punto
de vista de sus clientes. Por esta razón, no han logrado de ellos una actitud
comprometida y los resultados no han sido tan buenos como esperaban.
Durante la fase de optimización de los procesos, las empresas ya poseen

información precisa sobre sus clientes y han integrado sus herramientas de
Business intelligence, sus métodos de análisis y sus conocimientos. Estas
condiciones ideales hacen posible la mejora del proceso de gestión de las
relaciones con los clientes, pudiendo personalizar las interacciones online y
ofrecer al cliente una visión unificada de la empresa.
A través de tales interacciones personalizadas, puede aplicarse un análisis de

fidelidad para servir al cliente de un modo más efectivo de acuerdo a sus
necesidades, en lugar de integrar la información una vez que el proceso ya ha
concluido.
La integración horizontal de los procesos, la cuarta fase en la evolución de

e-Business, se centra en la integración de todos los procesos internos de la
empresa, así como de los procesos de los clientes. Para la empresa, esto
significa la integración de todos los puntos de contacto de los clientes con el
conjunto de sistemas operativos, desde el abastecimiento y el cumplimiento de
un pedido hasta la satisfacción del cliente.
En cuanto al cliente, esto implica el establecimiento de enlaces con y entre los

sistemas de todos los proveedores involucrados en el proceso. Así, las
compañías aéreas han comenzado a integrar, internamente, sus sistemas de
reservas con sus programas de fidelidad, conectándose a continuación con los
sistemas de sus partners colaboradores a fin de ofrecer a los clientes la
comodidad de un punto de servicio único. A su vez, los bancos están
integrando todos sus servicios para ofrecer a sus clientes una gama más
amplia de transacciones online accesibles desde un único punto central.
160
4.4.2 Construir la solución e-Business
El negocio electrónico o solución e-Business no es solamente el uso de

tecnología de punta y el análisis de procesos sometidos a una re-ingeniería
para el desarrollo de nuevas y revolucionarias aplicaciones sin fronteras de
tiempo, espacio y geografía. La implantación y soporte de estas soluciones es
un enfoque analítico e intensivo de desarrollo de aplicaciones que pretende
considerar (figura 4.19):
• Planificación de Negocios.
• Planificación de Mercado.
• Planificación Tecnológica.
• Planificación de Operaciones.
Figura 4.19: Planificación de la implementación e-Business.
a.1.- Planificación de negocios
La Planificación de Negocios valoriza el impacto de negocios de la aplicación.

En esto se incluye:
- Identificar los beneficios de la aplicación, mostrando su ajuste y adecuación a

la estrategia corporativa de negocio, y señalando en qué medida ayuda a
conseguir sus objetivos.
- Comprender el alcance de los procesos de negocios que soporta la

aplicación. Esto es útil para establecer el impacto de la aplicación. Lo
importante aquí es que la aplicación resuelva un problema y/o ayude un
objetivo de negocio y no produzca problemas.
- Establecer relaciones de trabajo y acuerdos de servicio con proveedores,

vendedores y partners relacionados y/o afectados por la solución.
b.1.- Planificación de mercado
161
La Planificación de Mercado analiza de qué manera introducir al mercado la

aplicación e-Business según la población de clientes/usuarios. Esto incluye:
- Identificar el mercado objetivo.
- Definir procesos de comunicaciones internos y externos. Se trata de identificar

de qué manera se puede conducir el tráfico en el sitio. Esto incluye una
estrategia de comunicación inicial y una estrategia de comunicación eferente.
Estrategias pertinentes pueden ser: darse de alta en buscadores populares y
especializados, publicitarse en sitios web con altas tasas de visitas, en páginas
web de grupos industriales, mensajería electrónica, TV, radio, prensa, etc. Otro
medio es proveer incentivos a clientes y partners por usar la solución web en
lugar de llamar a un centro de llamados.
- Definir los criterios para medir el éxito de la aplicación.
c.1.- Planificación tecnológica
El proceso de Planificación Tecnológica busca cómo usar la aplicación y

extender la arquitectura. Este proceso incluye:
- Identificar los componentes de la arquitectura.
- Refinar los estándares de desarrollo de la aplicación.
- Determinar los niveles y medios de interacción con el sitio web.
- Planificar el desarrollo de la aplicación.
d.1.- Planificación de operaciones
La Planificación de Operaciones incluye:
- Determinar requerimientos de habilidades para el desarrollo de la aplicación,

soporte continuo y actividades de manutención.
- Definir políticas y procedimientos para manutención de la aplicación, soporte y

gestión de sistemas.
- Buscar opciones para manutención continua como ISP (Internet Service

Providers) y WebHosting y/o Outsourcing estratégico.
- Iniciar procedimientos de Gestión del Cambio con el fin de comprender el

alcance de los cambios que implica la aplicación en los roles de los usuarios y
en el trabajo realizado.
4.4.3 Factores críticos de éxito
• Servicio 24x7. Con un potencial mundial de acceso, toda aplicación y

sus webs, o cualquier interface de acceso público debe ser 24x7,
162
inclusive aquellas que tienen bajo índice de consulta. Esto plantea el

reto de la mantención continua para muchas aplicaciones negocios e
incrementa la demanda por soluciones de alta disponibilidad.
• No hay aplicación segura. Cuando cualquiera en el mundo puede
acceder a nuestras aplicaciones, toda falla tiene efecto mundial, con sus
consecuencias de pérdida de ingresos y retornos, independiente de lo
exitoso que haya sido la captura y manutención de clientes y el buen
desempeño ante un alto tráfico.
• Lo cierto es la incerteza. Otra consecuencia de la ubicuidad de las
aplicaciones es la incerteza de cargas, dejando KO toda previsión y
planificación, tanto para aplicaciones centralizadas como distribuidas. De
hecho, es imposible prever todos los factores que afectan la carga de
una aplicación.
• Riesgo de seguridad siempre posible. Con todo el mundo tratando de
entrar en diversos sitios, hay que tener los mejores procedimientos de
chequeo y técnicas de encriptación de datos y claves posibles.
4.5 Uso y evolución

La cuarta etapa es aprovechar la experiencia, aprender de lo realizado. En
cada empresa hay una enorme cantidad de datos. No solamente en las bases
de datos y en los cajones del escritorio, sino también en las personas:
empleados, proveedores y distribuidores.
El entorno e-Business presenta una oportunidad única para crear una cultura
de la implicación propia. Una cultura que llegue directamente a todos nuestros
clientes. Que haga uso de toda la información de que se dispone para dar a la
empresa una ventaja competitiva.
Con el fin de aprovechar verdaderamente la experiencia, es necesario capturar

todo el conocimiento de la empresa y compartirlo por toda la empresa. Hay que
dar marcha a un proceso de aprender de la experiencia, para lo cual es
necesario capturar y analizar la información, poner esta información a
disposición de quien la necesite, y compartir los resultados con toda la
empresa.
El conocimiento organizativo se plasma de formas muy distintas y tiene muchas

aplicaciones distintas. En su forma más simple, pensamos en la gestión del
conocimiento como una forma de capturar la experiencia humana y, a
continuación, compartirla bastamente por toda la organización. Puede ser
cualquier cosa, desde la memoria de la empresa hasta la experiencia y la
información que conduce al cambio cultural.
Los conocimientos inteligentes de la empresa tienden a presentarse en forma

de datos. Se analizan los datos de la empresa y los datos transaccionales para
encontrar patrones ocultos. Su fin es dar más recursos a los empleados para
captar clientes más eficazmente, puesto que los conocen más: conocen lo que
compran y cuándo lo compran, y una serie de porqués más.
163
Este conocimiento se basa en hechos (datos) y experiencias, que pueden

clasificarse en 2 categorías:
• No estructurados. Datos que son consecuencia de la colaboración

entre las personas: informes, presentaciones, "memoria" de la empresa,
documentos o datos semi- estructurados como mapas de conocimiento.
Son elementos que la gente utiliza para realizar trabajo creativo para el
presente y para el futuro. Organizar estos datos, hacer que estén
disponibles y asegurar el acceso a los mismos es de suma importancia
para la capacidad de una empresa a la hora de aprovechar con
efectividad sus experiencias.
• Estructurados. Datos organizados en bases de datos que se pueden
analizar de cientos de maneras distintas para descubrir los patrones de
compra de los clientes, las dinámicas del mercado, el flujo de la cadena
de suministros y, en definitiva, cualquier aspecto de la empresa.
Conforme aumentan las conexiones entre las personas, la cantidad de
datos que generan y al que tienen acceso las empresas crece
dramáticamente. Más que nunca, es importante poder gestionar estos
datos de forma eficaz.
Cuando una empresa sabe utilizar eficazmente los datos no estructurados y

estructurados, es capaz de transmitir los beneficios de la experiencia a sus
empleados, proveedores, distribuidores y clientes. Esta comunicación de los
beneficios de la experiencia es la mejor manera de asegurar continuas mejoras
en el funcionamiento de las empresas. Aprender se convierte en el resultado
natural del proceso de aprovechamiento.
CASO: CHRYSLER SCORE
Chrysler ha aprendido a aprovechar el capital intelectual de sus proveedores de piezas y

ha experimentado una espectacular mejora de los beneficios como resultado. Mediante
Lotus Notes, algunos enlaces de conexión telefónica y unas cuantas aplicaciones
sencillas, Chrysler está recortando costes de operatividad de más de mil millones de
dólares al año gracias a una comunicación directa y continua con sus principales
proveedores. Utilizando un sistema basado en Notes e Internet, los proveedores pueden
comunicar rápidamente ideas sobre cómo mejorar la fabricación de los componentes de
automóviles.
El sistema que este fabricante de automóviles desarrolló se llama SCORE (Supplier Cost
Reduction Effort), Esfuerzo de reducción de costes del proveedor).
Puesto que más del 70% de las piezas que se pueden encontrar en un automóvil de la
marca Chrysler son de proveedores externos, SCORE se implantó originalmente para
mejorar las relaciones entre Chrysler y los proveedores que le suministran toda clase de
piezas: desde sub- ensamblajes a escobillas.
El programa pronto incorporó incentivos para motivar a los proveedores a sugerir

productos que pudieran ser útiles para reducir costes. Los Proveedores que sugerían
una forma de ahorrar costes, no sólo obtenían el negocio con Chrysler, sino que eran
recompensados con una parte de los ahorros logrados.
El programa SCORE ha tenido tanto éxito que sólo 3 años después de iniciarse, Chrysler
ha tenido que actualizarlo para poder gestionar el volumen de usuarios y las ideas
164
presentadas.
Chrysler ha transformado su relación con los proveedores. Juntos, el fabricante de

automóviles y los proveedores, buscan constantemente cualquier pérdida en la cadena
de valor añadido, identificándola, buscando su solución y compartiendo la mejora.
SCORE establece una relación de ganador a ganador, una forma de trabajar en

colaboración con los proveedores y demostrar que Chrysler se ha comprometido a
verlos crecer.
4.6 Ejemplo
Para comprender un poco mejor la metodología e-Business expuesta en los
apartados anteriores, se desarrollará aquí el ejemplo del paso de la iniciativa e-
Business a las aplicaciones e-Business de una empresa seguros ficticia que se
denominará XYZ.
4.6.1 La estrategia y la iniciativa e-Business
La compañía de seguros XYZ desea pasar de ser un negocio tradicional a un

negocio e-Business. Esto se origina con el siguiente objetivo de negocios:
incrementar las ganancias.
Este objetivo de negocios se traduce en los objetivos estratégicos de:
- Incrementar ganancias y retornos por medio de explorar nuevos canales de

distribución de productos y servicios.
- Bajar el ratio de gastos, manifestado por la relación entre los gastos totales y
los beneficios totales.
- Mejorar tasa de retención de clientes mejorando el servicio.
Para satisfacer esos objetivos, XYZ asume que debe necesita una iniciativa e-
Business la cual necesita implementar sistemas e-Business que provean:
- Soluciones que permitan promocionar productos, analizar clientes

potenciales, y vender los productos a los clientes.
- Aplicaciones orientadas al cliente (customer self service aplicaciones) que

permitan consultar planes o pólizas, consultar reclamaciones y capturar avisos
de daños, todo con el fin de ayudar las llamadas que llegan al Call Center y
proveer un así un servicio one-stop a los clientes.
- Aplicaciones que ayuden a aumentar la velocidad de los procesos tales como

la creación de nuevos planes y el procesamiento de reclamaciones, por medio
de sistemas integrados y backend.
165
4.6.2 El plan táctico
El plan táctico para implementar potenciales soluciones e-Business consistirá

de un proyecto técnico de varias fases sometidas a objetivos que permitan a
XYZ rápidamente comenzar y desplegar funciones adicionales a las
aplicaciones que surjan sobre Internet en una ventana de tiempo de 6 a 8
meses.
El factor de éxito del proyecto e-Business será, en la dimensión gestión: el

tiempo; y, en la dimensión construcción: un desarrollo incremental eficaz que
no entorpezca el paso de un nivel de incremento a otro. Para conseguirlo, se
expone que el principio rector del proyecto estará regido por el enfoque llamado
time-boxed approach, un enfoque de gestión y construcción modular contra el
tiempo.
Este enfoque plantea que cada fase del proyecto a desarrollar tendrá como
objetivo de gestión el tiempo, es decir, cumplir los plazos (como un e-Project).
Este cumplimiento de plazos exige qué, en caso que algún objetivo, una
tecnología, aplicación o sistema e-Business, o algún componente de negocio,
no puede completarse en los términos presupuestados y pactados para la fase,
será transferido a la siguiente fase, aunque ello lleve el apremio del tiempo (en
cierta medida aquí se asemeja al paradigma o ciclo de vida en espiral).
Esto conlleva que la planificación de productos a conseguir (por ejemplo, a

través de un WBS) en cada plazo debe ser incremental de tal manera que lo
conseguido en una fase sea la base para la siguiente (como un ciclo de vida en
cascada).
Con este modus operandi, se pueden tener resultados en corto plazo, uniendo
lo mejor de varios paradigmas de desarrollo para el caso de un proyecto e-
Business y, si el proyecto se queda corto en tiempo, es decir, si algo falta
cuando se alcance la fecha límite del proyecto, los sistemas y las aplicaciones
e-Business que existan estarán funcionando a cabalidad.
Las soluciones e-Business serán arbitrariamente definidas como aquellas

mostradas en la figura 4.20, interface Web, seguridad, gestión de contenido,
servicios de colaboración e interfaces de transacciones y sistemas actuales
(systems legacy).
Las fases serán:
• Establecer presencia.
• Proveer funciones de autoservicio al cliente.
• Ampliación de las funciones de autoservicio al cliente.
• Integración con las aplicaciones del negocio.
a.1.- Fase 1. Establecer presencia
Con esta primera fase se intenta que XYZ tenga presencia en Internet y defina
su arquitectura e-Business.
166
a.1.1.- Presencia en Internet
La fase pretende concluir en 3-4 semanas con un conjunto de aplicaciones

orientadas a dar presencia a XYZ. Esta presencia se caracterizará por:
- Aportar información básica sobre la compañía, sus productos y servicios a los

clientes; y,
- Proveer información de contacto como direcciones postales, números de

teléfono o cualquier otra que sirva para dar un mejor servicio al cliente,
procesar reclamaciones, etc.
a.1.2.- Arquitectura básica
La fase ha de permitir a la compañía establecer los componentes

arquitectónicos básicos que ayudarán a dar soporte a las futuras aplicaciones
e-Business.
Durante esta fase, la arquitectura tendrá los componentes básicos que se

necesiten para crear y gestionar el contenido del web site. La arquitectura debe
planificarse de tal manera que en el futuro nuevas aplicaciones sean añadidas
al web site.
Igualmente en esta fase se implementará una infraestructura de seguridad

básica y un plan de respaldo (backup) y recuperación (recovery) que asegure
que la información y las redes están a salvo de acciones o ataques
intencionadas o no.
La figura 4.20 muestra una arquitectura básica y las primeras aplicaciones e-

Business.
Figura 4.20: Fase 1 del proyecto e-Business (3-4 semanas)1.
167
b.1.- Fase 2. Proveer funciones de autoservicio al cliente
Esta segunda fase del plan amplia funcionalidades y arquitectura conseguidas

en la fase previa (figura 4.21).
b.1.1.- Ampliación de funcionalidades
Con esta fase se intenta construir la comunicación que permita al cliente llegar
al personal y los departamentos dentro de XYZ. Según esto, la fase
implementa las siguientes funcionalidades:
- Capacidad para que representantes y agentes de servicio al cliente envíen y

reciban correo electrónico a sus clientes.
- Integración telefónica que permita a los clientes programar encuentros con

agentes, y enviar mensajes y faxes a individuos dentro de la organización.
Autoservicio básico para que clientes y agentes:
- generen órdenes y/o formularios;
- soliciten brochures y/o adquisiciones;
- completen notas de Daños o Reclamaciones como parte del workflow de un

formulario o plan; y/o
- localicen agentes y oficinas de reclamos usando un GIS (Geographical

Information System).
b.1.2.- Ampliación de arquitectura
168
La arquitectura es extendida con servicios de colaboración que incluyen

gestores de correo, gestor de workflow, servicios de telefonía (fax, por ejemplo)
y otros servicios de workgroup tales como gestores de calendario y
programación de tareas (scheduling).
c.1.- Fase 3. Ampliación de las funciones de autoservicio al cliente
Similar a la fase previa, esta fase amplia las funcionalidades de autoservicio del
cliente y la arquitectura resultante de la fase previa (figura 4.22).
Debe añadirse que fases 2 y 3 pueden haber tantas como incrementos se

permita el proyecto dado el volumen de aplicaciones que se proyecte
inicialmente.
c.1.1.- Ampliación de funcionalidades
A nivel de funcionalidades ahora busca permitir que los clientes realicen

consultas en los planes de su portafolio de cliente. Con esto se puede
chequear el estados de las reclamaciones que puedan tener abiertas y el
estado de sus reclamaciones que hayan iniciado.
Visto así, la fase busca la implementación de las siguientes funcionalidades:
• Búsqueda de clientes y consulta de portafolio.

• Consulta de planes.
• Consulta de reclamaciones.
• Consulta de pagos.
c.1.2.- Ampliación de arquitectura
La arquitectura se amplia con servicios de conectividad backend que incluyan

gestor de cola de mensajes y conectores dentro del sistema backend como
gateways Web-CICS, Web-IMS, SQL server web conecctore, Net.Data y otros
conectores backend.
169
d.1.- Fase 4. Integración con las aplicaciones del negocio
Similar a la fase previa, esta fase amplia las funcionalidades de autoservicio del
cliente y la arquitectura resultante de la fase previa (figura 4.23), pero con la
salvedad que ahora busca consolidar procesos críticos del negocio e integrar
sistemas y aplicaciones e-Business con la realidad actual de sistemas de XYZ.
d.1.1.- Ampliación de funcionalidades
La cuarta fase añade funciones críticas tales como procesamiento de planes y

procesamiento de reclamaciones. Para esto, las funcionalidades que se
persiguen alcanzar ahora son:
- Capturar nuevos negocios a través de Internet.
- Procesar planes (endorsar planes, cambiar direcciones de pagos, añadir

criterios a los planes, etc.).
- Procesar reclamaciones (entrar avisos de daños y ser capaz de hacerles un

seguimiento al reclamo hasta que es satisfecho o atendido).
- Modificar opciones de pago de los planes.
d.1.2.- Ampliación de arquitectura
La arquitectura se amplia de tal manera que se añadan servicios habilitadores

que incluyan elementos como, por ejemplo, el Object Request Broker de
CORBA el cual contiene el Componen Broker y un Monitor de Transacciones
(CICS o ENCINA). Igualmente se añaden conectores dentro de los sistemas
backend tales como Cbconnector, Java-CIS gateway y/o Java-MQ gateway que
permitan acceso transaccional a las aplicaciones backend.
1
Fuente: IBM.
2
Fuente: IBM.
170
3
Fuente: IBM.
4
Fuente: IBM.
4.6.3 Corolario
Independiente de las tecnologías usadas y su complejidad intrínseca, el

proyecto tiene la complejidad de asumir que se está ante una pirámide de la
cual sabemos perfectamente lo que tiene que ir en cada nivel para así tener las
bases del nivel superior. Lo interesante es que esto exige saber cuales
funcionalidades y servicios de la arquitectura deben ir primero, no obstante si
esto se sabe al inicio del proyecto es posible una planificación, en caso
contrario hay que asumir los riesgos de fallar y elaborar una planificación por
contingencia.
4.7 Soluciones e-Business

A continuación se presentan algunas soluciones e-Business implementadas en
algunos negocios:
a.- Autocares Jiménez - Integración de aplicaciones
• Necesidad del Cliente: Venta de Billetes para agencias a través de

Internet.
• Objetivo: Permitir a las agencias de viaje la compra de billetes desde
Internet mediante pago por tarjeta de crédito (los tipos dependen del
proveedor de la pasarela de pago) o con facturación posterior.
- Permitir a los usuarios particulares la compra de billetes desde Internet

mediante pago por tarjeta de crédito.
- El proceso de adquisición de un billete de Autobús será

completo pudiendo escoger el usuario la plaza donde desea viajar
dentro del autobús.
a.1.- Soluciones desarrolladas por iA Soft
Funcional
a.1.1.- PASO 0: Entrar en la aplicación.
- Se permite la entrada a la aplicación a cualquier usuario registrado o no.
- En el caso de usuario no registrado pasará directamente al paso 1 y

automáticamente se le propone utilizar la ayuda para realizar la compra.
- En el caso de ser un usuario registrado deberá introducir su nombre de

usuario y su contraseña, que será verificada, para poder acceder al siguiente
171
paso. De esta forma aparecerán seleccionadas las características de último

trayecto para el que compró billetes excepto las fechas de ida y vuelta.
- Las agencias se validarán mediante un nombre de usuario y una contraseña

que definirá el tipo de operaciones que podrá realizar.
Nota: No es lo mismo un usuario de internet registrado que una agencia

aunque tengan el mismo punto de entrada.
Las operaciones que puede realizar una agencia son:
1. Comprar pagando con tarjeta de crédito.
2. Comprar con pago posterior. Con límite de crédito.
3. Ambas operaciones.
Este punto está paremetrizado así: (desde la aplicación de gestión).
• Definición de agencias.
• Tipos de operaciones permitidas para las agencias.
• Crédito disponible de una agencia.
• Usuarios de las agencias.
• Mantenimiento de los usuarios de internet que se han registrado.
• Consulta de las operaciones realizadas por los usuarios.
a.1.2.- PASO 1: Selección de trayecto.
- El usuario debe seleccionar el origen, el destino, el número de billetes, el tipo

de descuento que desee aplicar, el tipo de vuelta y la fecha de ida y de vuelta
en el caso que corresponda.
- Los origenes y destinos serán todos los disponibles en los que pueda existir
un servicio válido. Además aparecerán todas las posibles combinaciones
posibles de itinerarios para viajar del origen al destino de forma transparente al
usuario.
- La fecha máxima de venta tiene un rango de validez que se aplica a la ida de

forma natural y a la vuelta en función de la fecha de ida.
- Los descuentos se aplican a todos los billetes que se compran. Es decir, no

se pueden combinar descuentos. Un aviso al usuario es mostrado cuando se
produce ésta situación.
a.1.3.- PASO 2: Selección de horarios.
172
- El usuario debe seleccionar una hora de ida y otra hora de vuelta en el caso
que corresponda.
- El objetivo de selección es dar al usuario el mayor abanico posible de horas

de salida para desplazarse un ORIGEN a un DESTINO.
- No se seleccionarán servicios. Sólo se mostraran expediciones.
a.1.4.- PASO 3: Selección de plazas.
- El usuario selecciona las plazas que desea en cada uno de los autobuses en
los que deba viajar.
- Se hace notar al usuario que las plazas que selecciona podrán ser cambiadas
de posición sin previo aviso. Esto es debido tanto a los posibles traspasos de
plazas como a las colisiones producidas por la compra mediante tarjeta.
- Dependiendo del las propiedades del tipo de usuario que está realizando la
compra es posible no notificar que las plazas han colisionado y asignarle
automáticamente otras. Esta opción puede ser interesante para las agencias de
viaje, pero por defecto está desactivada.
- Una vez seleccionadas las plazas se procede a la fase de compra.
a.1.5.- PASO 4: Fase de compra.
La fase compra se compone de:
- Introducción de datos del comprador. Si el usuario es registrado se le da la

opción de modificarlos si lo cree conveniente. Si no es usuario registrado se le
piden obligatoriamente el nombre, primer apellido, cédula de identidad y
dirección de correo electrónico. Además se le propone hacerse usuario
registrado. También se le da acceso a leer la información sobre la Ley de
Protección de Datos.
- Lectura de condiciones de compra, resumen de compra y tipo de pago.

El usuario debe aceptar las condiciones que aparecen en la pantalla para poder
realizar el pago. Los tipos de pago se muestran en función del tipo de usuario;
si el usuario es una agencia o un usuario normal de internet. A los dos tipos de
usuario se les ofrece pagar con tarjeta de crédito. En el caso de usuario de
173
agencia se le permite en pago con cargo en el caso de que tenga crédito mayor
de cero. Si el crédito no es suficiente se le notificará.
En el caso de que el usuario seleccione comprar con tarjeta de crédito se

pasará el control a la pasarela de pago de la entidad bancaria para formalizar el
pago. En el caso de pago con cargo esta operación no es necesaria.
- Visualización del billete comprado e impresión del mismo.
- Se insta al usuario a imprimir su billete.
- Si el usuario ha especificado una dirección de correo válida se le enviará la

información de la compra a dicha dirección.
b.- GIR (Gestión Integral en Red) - Integración de aplicaciones
• Necesidad del Cliente. La Consejería de Educación del Gobierno de

Aragón, con la intención de optimizar las labores de gestión de los
centros de enseñanza y agilizar las relaciones que estos mantienen con
el departamento, se propone llevar a cabo el desarrollo y la implantación
de un sistema informático que permita la Gestión Integral en Red de
todos los procesos asociados.
- El sistema, haciendo uso de tecnologías web, canalizará y

centralizará todos los flujos de información generados,
independientemente de su ubicación física. De este modo, se
convertirá en una potente herramienta de control que, entre otras
prestaciones, ofrecerá un apoyo inestimable a los procesos de
toma de decisiones.
• Los principales objetivos son:
- Centralización de Datos. Todos los datos utilizados y/o

generados por los centros de enseñanza del sistema educativo en
el transcurso de su actividad habitual se centralizarán en un único
Sistema Informático accesible de forma remota.
- Aplicativos Remotos. Para operar sobre este sistema se

desarrollarán una serie de aplicativos remotos que ofrezcan el
servicio adecuado a todos los posibles usuarios del sistema
(centros de enseñanza, personal del departamento, padres,
alumnos, etc....).
- Control de Acceso. Todos los aplicativos remotos

desarrollados implementarán un control de acceso, basado en
perfiles de usuario, de gran versatilidad que delimitará la
capacidad del usuario tanto en consulta como en edición de datos
o ejecución de procesos.
b.1.- Soluciones desarrolladas por iA Soft
174
Funcional
La arquitectura de software propuesta para el Sistema Informático GIR se

corresponde con un modelo de tres capas que responde a la siguientes
características:
- Cada módulo funcional básico provee las funciones de gestión y operación

básicas correspondientes a su repositorio de datos asociado, pudiéndose
considerar cada par módulo - repositorio una aplicación independiente.
- La arquitectura implementará los interfaces necesarios para permitir articular

relaciones entre los distintos repositorios de datos.
- Cada aplicación (por módulo - repositorio), si bien dispondrá de un conjunto

de datos y funciones genéricos de partida, se diseñará de forma que pueda ir
creciendo en función de las necesidades que planteen los aplicativos remotos.
- Los aplicativos remotos se definen como clientes ligeramente pesados ya que

incluyen la lógica de integración necesaria para conjugar y aprovechar todos
los servicios que ofrecen los módulos funcionales básicos.
- En el Diagrama Operativo se hace especial mención, dentro de los

repositorios "Personal Centros" y "Centros", de los apartados "Profesores" y
"Plan Académico"; el motivo es la especial importancia que estos apartados
tienen para el funcionamiento habitual de los centros de enseñanza.
Basada en esta arquitectura se desarrollarán:
- Aplicativos para los centros de enseñanza (Proceso de admisión,

matriculación, gestión administrativa...).
- Aplicativos de información y reporting (acceso de carácter consultivo a toda la

información de los centros de Enseñanza).
- Aplicativos de Padres y Alumnos a través de Internet a los diferentes

procesos (admisión, matriculación, consulta horarios, faltas, calificaciones....).
c.- SIRASA - Sistemas de gestión
• Necesidad del Cliente. La Sociedad de Infraestructuras Rurales

Aragonesas (SIRASA) es una empresa pública que se encarga de
adjudicar y gestionar los proyectos iniciados o subvencionados por los
departamentos de Agricultura y Medio Ambiente de la Diputación
General de Aragón. El cliente nos transmite la necesidad de disponer de
una aplicación para gestionar los proyectos en los que se encuentra
involucrada, desde el momento de su notificación hasta el cierre de los
mismos pasando por la licitación, seguimiento y certificación.
En el momento de plantearnos esta necesidad, el cliente dispone de una
175
aplicación de contabilidad, una aplicación de gestión de nóminas en

COBOL y una aplicación de Access de gestión de expedientes
desarrollada por una persona del departamento jurídico de SIRASA con
la que se gestionan cerca de 180 proyectos. Las dos primeras
aplicaciones cumplen su labor pero la Gestión de Expedientes solo
mantiene registro de datos y fechas relevantes de cada proyecto. La
aplicación de expedientes de Access presenta muchas limitaciones
principalmente por las dificultades que plantea de cara a trabajar en red
y porque se espera de ella un apoyo a la hora de gestionar los
expedientes (alarmas y reglas de validación) y los proyectos (generación
automática de documentos, sobre todo certificaciones) que actualmente
no ofrece.
El cliente requiere una aplicación capaz de funcionar en red local

soportando un mínimo de 12 usuarios simultáneos. La aplicación debe
permitir a las delegaciones en Huesca y Teruel el acceso al servidor
situado en Zaragoza. Se debe garantizar la viabilidad en base a diversas
alternativas (acceso telefónico a redes, VPN, etc.), principalmente para
consultaras.
Para cubrir las necesidades presentadas por el cliente, es necesario que la

aplicación controle lo siguiente:
- Control completo de procesos según los tipos de expedientes con cada una
de sus fases:
- Recepción de documentación de la DGA (apertura del expediente).
- Anteproyecto (pliego, plano, presupuesto y memoria técnica) y estudio de

impacto medioambiental si procede.
- Licitación y, en su caso, aprobación.
- Ejecución, desde el acta de replanteo hasta la de recepción, pasando por las

sucesivas emisiones de certificaciones y registro de facturas en diversas
anualidades.
- En todas las fases del expediente, se debe gestionar el control económico de

estado del expediente y de hitos temporales.
- Se debe incluir la capacidad de control documental permitiendo adjuntar

documentos a cada expediente.
- Para cada tipo de expediente se incluirán una serie de validaciones y alertas

que permitirán controlar incoherencias (sobre todo temporales) y datos
necesarios / opcionales en la gestión del proyecto (por ejemplo: una alerta
avisando de que se ha procedido a la adjudicación del proyecto sin aportar la
fecha concreta o las empresas participantes). Deben ser solo avisos (en forma
de log de alertas) y no impedir el curso normal de trabajo.
176
Según las necesidades aportadas por el cliente, se prevé la inclusión de

nuevas funcionalidades en un futuro:
- Display gráfico del estado del proyecto en forma de workflow que muestre
según códigos de colores el estado de tramitación del expediente: fases
superados, fases incompletas con datos sin concretar y fases pendientes.
- Valoración de índices para controlar la calidad total en la gestión del trabajo

diario de la empresa. Índices tipo: tiempos medios desde la creación del
expediente hasta su publicación, desde publicación hasta su adjudicación, etc.
- Sistema de control de costes interno (horas por proyecto de los

responsables).
c.1.- Soluciones desarrolladas por iA Soft
Funcional
Estudiadas las necesidades del cliente, iA Soft propone un sistema cliente-

servidor que funcione en red y sirva de sistema de Gestión de Expedientes y
Control económico y documental.
Para la Gestión de Expedientes y Control Económico, en SIRANet se refleja la

principal actividad de SIRASA: gestionar encargos de dos departamentos de la
DGA (Departamento de Medio Ambiente y Departamento de Agricultura). A
cada uno de estos encargos, se les dará de alta, asignándoles un número de
expediente para identificarlo. Cada encargo lleva asociado un procedimiento
más o menos extenso según la tipología de los mismos. Todo el trabajo de
SIRASA gira entorno de estos expedientes, por esto han de estar
perfectamente identificados, expresando el mayor número de características de
los mismos, en cuanto a responsables, provincia, comarca, etc.
De manera simplificada, el flujo normal de los expedientes, aunque para cada

tipo varíen algunos factores según se entra en detalle y se incrementa la
complejidad de los mismos, es el siguiente:
• Comunicación de proyecto / subvención desde DGA.

• Apertura y tramitación del expediente.
• Si procede, estudio de impacto medioambiental.
• Anteproyecto (pliego, presupuesto, plano, memoria técnica, etc.)
• Licitación.
• Ejecución (dirección facultativa, coordinación de seguridad y salud).
• Certificaciones mensuales.
Se ha considerado fundamental mantener la información estática que se

gestionaba en la aplicación Access del cliente. A esto se le han añadido una
serie de validaciones en la edición de los expedientes, una mejoría en la
177
gestión de plazos, gestión de proyectos y generación de documentos. Alguna

de la información estática del expediente es la siguiente:
• Estado del expediente (abierto, en ejecución, cerrado, etc.).

• Fechas relevantes de cambios de estados.
• Fechas y costes de publicación en BO y prensa.
• Responsable del proyecto.
• Datos del Anteproyecto (responsable y coste).
• Presupuesto del proyecto.
• Plazos.
• Anualidades.
• Empresas participantes en la licitación.
• Empresa adjudicataria.
• Baja (porcentaje de descuento con el que se ha adjudicado el proyecto
respecto al presupuesto de partida).
• Información de los datos detallados de elementos presupuestados
incluyendo cantidad y precio unitario.
Para el Control Documental, la aplicación genera automáticamente y guarda el

mayor número de documentos posibles. En aquellos casos en los que esto no
sea posible o recomendable por razones operativas, se da la posibilidad de
adjuntar un documento externo de una manera opcional. Algunos documentos
relacionados con la aplicación son:
• Pliego de cláusulas administrativas.

• Información de solicitud.
• Aprobación del expediente.
• Orden del consejero.
• Fiscalización.
• Acta de apertura.
• Informe de licitación.
• Propuesta de Adjudicación.
• Aprobación de la Adjudicación.
• Aval (en el caso de subvenciones parciales).
• Convenio.
• Certificados.
• Comunicaciones de SIRASA.
• Acta de replanteo (comienzo de obras).
• Acta de recepción (final de obras).
• Avisos previos.
• Certificaciones.
• Liquidación.
• Contrato.
Una de las labores mecánicas y laboriosas que se ha resulto con el desarrollo

de la aplicación SIRANet es la elaboración de certificaciones, que deben
realizarse mensualmente. A su vez, se ha desarrollado un sistema de
seguimiento de éstas.
178
Esta documentación de certificación del proyecto (carátula, relación valorada y

factura) se elabora automáticamente a partir de la introducción de elementos
en producción, certificados y facturas a DGA que se lleva a cabo mes a mes y
de la información de meses anteriores.
En el seguimiento de proyectos, se incluye la gestión de formas de pago a

contratistas, directores y coordinadores de seguridad y salud que puede ser
prorrogada a lo largo del plazo del proyecto, en función de las certificaciones,
del progreso del proyecto o gestionada de manera manual. En este último caso
se plantea una validación evidente: la suma de cantidad introducidas
manualmente nunca debe superar la cantidad total estimada para el proyecto.
La aplicación también ofrece informes agrupados por gestor, tipo de proyecto,

empresa proveedora o cliente final (diversos departamentos de DGA,
comunidades de regantes, entes o personas subvencionadas) que muestran
básicamente el importe del proyecto, el importe de la adjudicación teniendo en
cuenta la baja, la cantidad certificada, la cantidad resultante de las obras
ejecutadas, la cantidad facturada, fechas, plazos, totales y medias temporales.
Es posible obtener el estado del proyecto.
Otros aspectos que se han tenido en cuenta en el desarrollo de SIRANet son:
• Se mantiene la información relativa a proveedores y clientes

• Agrupación de datos económicos por anualidades para poder presentar
la información totalizada y anualizada.
• Creación de Gestión de Históricos puesto que la información de
expedientes cerrados de años anteriores no parece relevante para el
trabajo diario.
d.- Col-Ven
Col-Ven S.A es una empresa Argentina, ubicada en Guadalupe, Santa Fe, que
desde hace más de 26 años se caracteriza por brindar Soluciones innovadoras
al mercado automotriz. Sus productos han sido unánimemente adoptados por
las líneas de transporte de cargas y pasajeros, vehículos particulares, etc., en
busca de seguridad y confort para los elementos mecánicos, y las marcas
VIGIA y VIESA están definitivamente incorporadas en el mercado.
Luego de una primera experiencia en Internet con su sitio institucional1, la

empresa decidió re-definir sus objetivos en Internet, y los recursos para
lograrlo.
El desafío
Comenta Lorena Vénica, Responsable de Implementación del Sitio Web de

Col-Ven S.A.:
"Nuestra empresa ha desarrollado mercados en el exterior, y por ello tenemos

una necesidad muy concreta de comunicación con los mismos. Actualmente
179
tenemos agentes en América, Europa y Oceanía y debemos proveerles

información personalizada a cada uno de ellos".
Requerimientos del Portal Corporativo Col-Ven
"Luego de nuestros primeros pasos por Internet, decidimos replantear nuestra

presencia. Entonces definimos los requerimientos que nuestro nuevo sitio
debería cumplir:
• Permitir al personal de Marketing generar y publicar contenidos, sin

necesidad de conversión a HTML por el Area de Aistemas.
• Filtrar contenidos según el cliente que accediese al sitio.
• Entregar contenidos a usuarios específicos.
• Poder "trackear" a nuestros visitantes para conocer mejor sus intereses".
La idea fuerza era que el área comercial tuviese "el control" del sitio, que
pudiese publicar información cuando quisiera, dirigida a quienes quisieran, de
una forma veloz y sencilla, y por otra parte poder analizar el comportamiento de
los clientes.
Luego de recibir varias propuestas, Col-Ven se decidió por utilizar la tecnología

IMS, desarrollada por EXO, para administrar los contenidos a publicar en
Internet y Extranet.
"La propuesta de EXO nos pareció novedosa, absolutamente compatible con

los objetivos que perseguíamos".
El desarrollo del Proyecto
El sitio de Col-Ven fue desarrollado sobre la versión Corporate Hosting de IMS,

la cual corre sobre un Servidor IMS ubicado en las oficinas de EXO. Ello
posibilita realizar recortes de costos de hardware, software y comunicaciones.
La administración de los contenidos es realizada en forma remota por los
usuarios no técnicos, generadores de contenidos.
Próximamente está prevista la puesta en producción del módulo multilenguaje,

el cual permite publicar información en ilimitados lenguajes manteniendo la
relación de los documentos para el caso de modificación o baja.
Ficha Técnica:
• Cliente: Col-Ven S.A.

• Proyecto: Portal Corporativo Col-Ven.
• Solución: IMS Corporate Hosting.
• Implementación: 5-2000.
e.- Ericsson estrena su portal corporativo desarrollado por EXO
EXO desarrolló para Ericsson SACI un sofisticado portal corporativo para

entregar información dirigida a cada uno de sus clientes. Basado en IMS -el
180
sistema de administración de contenidos desarrollado por EXO- incluye

características avanzadas, tales como personalización y filtrado de contenidos,
Business Intelligence, Marketing One to One y generación distribuida de
contenidos.
Eduardo Griffa, Responsable de Marketing & Soluciones de Compañía

ERICSSON SACI, nos brinda un panorama de las características del proyecto:
- ¿Cuáles fueron las causas que impulsaron a Ericsson a desarrollar el

portal corporativo local?
En principio una urgencia de mejorar la comunicación externa y

fundamentalmente con nuestros clientes. El portal local es una herramienta de
relación con nuestros clientes que el portal corporativo de ERICSSON no llega
a brindar.
- ¿Cómo se integra el portal corporativo en la estrategia comunicacional

de Ericsson?
Es una pieza fundamental en este "New Telecoms World" para un marketing

personalizado a cada necesidad.
- ¿Cuáles fueron los requerimientos técnicos que la Solución debería

satisfacer?
Los requerimientos eran: disponibilidad inmediata, fácil administración (no

queremos tener expertos en html!) y customización doble: cada cuenta debería
tener su site particular y cada cliente la posibilidad de personalizar su portal de
Ericsson.
- ¿Qué aspectos tuvieron en cuenta al momento de seleccionar a EXO

para el desarrollo del portal corporativo?
La selección de EXO surgió como proveedor confiable con una solución que
satisfacía nuestros requerimientos.
- ¿Cómo evalúa la interacción del personal de Ericsson y EXO durante el

proceso de desarrollo e implementación de la Solución?
Profesional y correcta.
- ¿Cómo imagina la evolución del portal corporativo de Ericsson

Argentina?
Lo imagino como un sitio preferentemente para clientes y un sitio de referencia
181
en cuanto a Tecnología, y de a poco iremos abriendo nuestra Intranet, que es

una de las más grandes del mundo.
Ficha técnica:
• Cliente: Ericsson SACI.

• Proyecto: Portal Corporativo.
• Solución: IMS.
• Características:
- Generación de contenidos distribuida entre 25 usuarios no

técnicos pertenecientes a las distintas Unidades de Negocios.
- Sitios personalizados en estética y contenidos para cada cliente

corporativo.
- Business Intelligence. Análisis del comportamiento de visitantes.
- Accediendo a una base de datos Oracle 8.05.
- Personalización de contenidos por el visitante.
- Filtrado de contenidos a determinados grupos de usuarios.
f.- Trading Argentina lleva sus negocios a internet
TRADING ARGENTINA es una compañía especializada en Comercio

Internacional y Consultoría de Empresas, con una trayectoria de más de 40
años prestando servicios a algunas de las más prestigiosas empresas del país.
La necesidad de compartir información con clientes, prospectos y proveedores

de una forma personalizada a través de la Web los orientó hacia IMS, el
sistema de administración de contenidos Internet desarrollado por EXO.
Alejandro Jausoro, Gerente General de Trading Argentina, comenta las

características y alcance del proyecto.
1. Cuál es la actividad principal de Trading Argentina?
Trading Argentina es una compañía especializada en Comercio Internacional y

en Consultoría de Empresas.
Llevamos muchos años trabajando con industrias de productos de consumo

masivo, abasteciéndolas de materias primas de primera calidad.
Esto nos ha permitido desarrollar fuertes vínculos con la industria y conocer

personalmente las fábricas, las capacidades y calidad de cada una de ellas.
182
Trading Argentina, es representante de empresas principalmente de: Chile,

Perú, Brasil, Ecuador, Uruguay, Bolivia, USA, Canadá, Tailandia, España y
Francia.
También somos Agente de Compra de algunas empresas del exterior que

confían su abastecimiento en nuestra compañía.
2. Qué causas los impulsaron a desarrollar el site?
Nuestros proveedores están distribuidos en todo el mundo y nuestros clientes

no se limitan al territorio de Argentina, sino que abastecemos clientes en
distintos países.
En definitiva nuestro negocio es global, por lo que el uso de una herramienta

global como lo es internet, es imprescindible para el logro de nuestros
objetivos.
3. Cuáles eran los requerimientos que el desarrollo debía satisfacer?
Desde un principio nos fijamos las siguientes premisas para construir nuestro
site:
- Dinámico y de actualización permanente por el propio personal de Trading,

sin necesidad de recurrir a un desarrollador de páginas html.
- Con contenidos técnicos que interesaran a nuestros clientes y proveedores.
- Amigable para el visitante y fácil de navegar.
- Escalable en contenidos y funcionalidad.
- Versiones en español e inglés.
Trading Argentina está formado por un grupo humano interdisciplinario de

profesionales con distintas extracciones, y todos ellos necesitan aportar
contenidos al sitio. La idea era que lo pudiesen hacer directamente, sin poseer
conocimientos de programación web.
4. Cómo planea integrar sus actividades en la web con proveedores y

clientes?
Respecto a los proveedores, en el sitio tiene un detalle pormenorizado de sus

productos.
En una próxima etapa vamos a dar información extensiva de cada uno de ellos.
Con relación a los clientes, cada uno de ellos tendrá acceso a información
específica, como el seguimiento de los contratos que ellos tienen con nosotros,
tiempos y logística de entrega, modificaciones, etc., como así también a los
futuros negocios a realizarse.
183
5. Qué aspectos tuvieron en cuenta al contratar el desarrollo a EXO?
La premisa básica fue contar con una aplicación poderosa, que permitiera tener
un site ilimitado en cuanto a expansión, de fácil mantenimiento, y amigable.
Buscábamos no depender de un agente externo para el mantenimiento del site
para actualizarlo diariamente desde nuestra empresa.
Eso fue lo que encontramos en EXO, que no nos ofrecieron otros proveedores
de Soluciones Internet.
Además encontramos una empatía muy fuerte con el equipo de EXO, que nos
facilitó la decisión.
Por otra parte, si se analiza la inversión necesaria en función de la información

publicada, la cantidad de páginas generada y el ahorro que surge de la no
utilización de medios de comunicación tradicionales, el costo por página resulta
casi irrelevante.
6. Cómo evalúa la interacción del personal de Trading y de EXO?
Excelente, se trabajó como un solo equipo entre los miembros de EXO y

nuestro personal.
Estamos plenamente satisfechos con los resultados obtenidos.
Ficha técnica:
• Cliente: Trading Argentina.

• Proyecto: Portal corporativo Trading.
• Solución: IMS Corporate Hosting (http://ims.exo.com.ar).
1
http://www.colven.com.ar
Capítulo 5.- Herramientas y técnicas

de gestión de proyectos
OBJETIVOS
- Conocer algunas de las principales herramientas y técnicas empleadas en la gestión de

proyectos.
184
Para completar este capítulo de gestión de proyectos para un proyecto

tecnológico no se deben olvidar una serie de herramientas y técnicas de
gestión. Estas herramientas y técnicas se presentan a continuación vinculadas
los grupos de procesos, lo cual no significa que ellas sólo sean de aplicabilidad
a un solo grupo. Igualmente, muchas de ellas se encuentra soportadas por
diversas herramientas informáticas. (ver Apéndice IV).
5.1 Iniciación
La iniciación es el proceso de reconocimiento formal de que se va a desarrollar,
construir de forma material y tangible, la iniciativa e-Business como una
solución de negocio sustentada en una aplicación e-Business compuesta de
componentes humanos y de hardware y software.
El compromiso aborda el desarrollo de un nuevo proyecto o de que un proyecto

ya existente se va a continuar en su siguiente fase.
Este comienzo formal conecta el proyecto con las operaciones en curso de la

organización ejecutora. En algunas organizaciones, un proyecto no está
formalmente iniciado hasta tener completo un estudio de viabilidad, un plan
preliminar o alguna forma equivalente de análisis que, como tal, también ha
tenido que ser comenzado separadamente. Esto involucra trabajar con el
cliente para identificar las entidades clave en la organización para
entrevistarles.
En particular, algunos tipos de proyectos, especialmente los de servicio interno

y los de desarrollo de nuevos productos (de ingeniería), se inician
informalmente y se realiza una pequeña parte del trabajo para asegurar los
requisitos necesarios para lograr el comienzo formal del proyecto.
5.1.1 Motivaciones del proyecto
En la iniciación es importante determinar con claridad el motivo por el cual

proyecto se inicia, la cual puede deberse a alguna o varias de las siguientes
causas:
- Una demanda del mercado (por ejemplo, una compañía petrolífera comienza
un proyecto para construir una nueva refinería en respuesta a la continua
escasez de gasolina).
- Una necesidad de negocio (por ejemplo, una compañía de formación

comienza un proyecto para crear un nuevo curso para aumentar sus ingresos).
- La demanda de un cliente (por ejemplo, un suministrador eléctrico comienza

un proyecto para construir una nueva subestación para abastecer a un nuevo
parque industrial).
185
- Un avance tecnológico (por ejemplo, una empresa electrónica comienza un

nuevo proyecto para desarrollar un videojuego, después de la generalización
del videocassette).
- Una necesidad legal (por ejemplo, un fabricante de pinturas comienza un

proyecto para fijar las directrices del manejo de materiales tóxicos).
Estas causas también pueden llamarse problemas oportunidades, o

requerimientos del negocio. Lo fundamental de todos estos términos es que la
dirección suele tener que tomar una decisión sobre cómo responder a ellos. En
un proyecto e-Business, esto significa unir negocio con tecnología.
5.1.2 Selección del gestor del proyecto
El gestor del proyecto es habitualmente seleccionado al final de la

conceptualización del proyecto, una vez aprobado. El gestor del proyecto es
una persona responsable de dirigir, gestionar y administrar todo el proyecto.
Su responsabilidad central es coordinar todas las actividades para satisfacer

los objetivos del proyecto en tiempo y presupuesto. Su rol es diferente de un
líder técnico o un desarrollador, cuyas responsabilidades se relacionan con la
integridad técnica del producto. Entre sus diversas responsabilidades se puede
destacar:
• informar a la dirección;
• comunicación con usuarios;
• planificación y programación;
• coordinación de actividades y tareas;
• control de presupuesto, programa, riesgo y calidad;
• gestión de personal; y,
• entregar resultados.
La tarea del gestor es dar visibilidad y gestionar compromisos. Encontrar una

persona para esta tarea no es sencillo, pues pocas personas cumplen con
todas las cualificaciones para proyectos complejos, menos aún que tenga
experiencia y esté disponible. Por este motivo, muchas empresas crean una
Oficina de Proyectos para gestionar mejor los proyectos y crear un pool de
futuros gestores.
Gestores efectivos deberían tener siguientes habilidades de: comunicación,

organización, construcción de equipo, liderazgo; negociación, actuación por
objetivos, capacidad de trabajo bajo presión y competencia técnica.
Se recalca que la competencia técnica es útil y sirve bastante, pero habilidades

de gestión e interpersonales son más importantes para un gestor de proyectos,
de hecho, tener 'roce' en el trato de personas, puede ser determinante al
momento de escoger el gestor de un proyecto, más que sus cualificaciones y
experiencia técnica. Los gestos exitosos son generalistas, no especialistas
técnicos. Aún más, en muchas ocasiones provienen de muchas áreas de la
organización y no necesariamente del mundo de la informática.
186
5.2 Planificación
La planificación requiere un fuerte esfuerzo de estimación para preparar las
acciones conducentes a conseguir el producto y cumplir con los objetivos, y de
selección de personal para cumplir con las tareas y actividades definidas. Todo
esto da lugar a un informe de alcance y al plan del proyecto.
Esta es una etapa de comprensión del proyecto e-Business que implica:
- Entrevistar directivos para conseguir comprender el modelo de negocios, la

situación de mercado actual, objetivos y metas de negocio e intenciones
iniciales sobre cómo Internet puede ayudar al logro de los objetivos y las
metas.
- Revisar procesos de negocios claves y la infraestructura que les soporta.
- Revisar y analizar la situación actual frente al potencial uso de entrar en

Internet (presencia de un sitio web con respecto a la visibilidad actual,
efectividad como medio de comunicación, facilidad de uso/navegación,
desempeño completo, solidez de la arquitectura técnica, etc.).
- Revisar y analizar el actual uso de intranets para promover la comunicación

interna y la compartición de datos.
- Revisar políticas y procedimientos establecidos en los procesos operacionales

asociados o con relación a los potenciales objetivos e-Business.
Además debe hacerse un esfuerzo mayor en un proyecto e-Business por:
- mitigar los factores de riesgos que plagan los esfuerzos de desarrollo;
- recoger información suficiente para estimar de la manera más adecuada

posible;
- asegurar que la visión e-Business sea compartida y esté en concordancia con

los objetivos de negocio de la empresa;
- dar una clara descripción de los requerimientos;
- asegurar la confianza y escalabilidad del proyecto; y,
- tomar precauciones respecto del coste proyectado.
Todos estos elementos han de aparecer detallados en el Plan del Proyecto y

en el Informe del Alcance.
187
5.2.1 Estimación
a.- Estimación del trabajo
La definición del alcance comprende la subdivisión de las principales entregas

del proyecto (identificadas en el informe del alcance) en componentes más
pequeños y manejables con el fin de:
• Mejorar la precisión de las estimaciones de costes, programa y recursos.

• Definir las bases para la medida y control de la realización del proyecto.
• Facilitar una clara asignación de responsabilidades.
La adecuada definición del alcance del proyecto es crítica para el éxito de un

proyecto. Cuando hay una pobre definición del alcance, se puede esperar que
se eleven los costes finales del proyecto debido a los inevitables cambios que
interrumpen el ritmo del proyecto, causan repeticiones de tareas, aumentan los
plazos de entrega, y disminuyen la productividad y la moral, de la plantilla.
Una herramienta útil para estimar el trabajo a realizar lo constituye la Estructura

de Descomposición del Proyecto (WorkBreakdown Structure, WBS).
a.1.- WBS
La base de las actividades de planificación lo constituye el WBS. Un WBS

descompone el proyecto en una estructura jerárquica bien definida de tareas o
actividades gestionables, cuya representación puede ser una tabla (ver
Apéndice II) o un árbol.
El número de niveles depende principalmente del tamaño del proyecto y las

preferencias del gestor del proyecto. Es importante que se expliciten todas las
actividades necesarias para completar el proyecto y que sean asignadas a un
entidad (persona u organización) de manera clara y precisa anulando toda
posibilidad de ambigüedad.
Un WBS es una agrupación de elementos del proyecto orientada a las entregas

del proyecto, que organiza y define el alcance completo del proyecto: trabajos
que no estén en la EDP quedan fuera del alcance del proyecto. Así, el WBS
provee así un marco fundacional para programar, presupuestar y controlar el
proyecto. Una vez definido, el proceso de estimación comienza. Esto no evita
que puedan servir para otros proyectos o se reutilicen.
La descomposición comprende la subdivisión de las principales entregas del

proyecto en otros componentes más pequeños y manejables de forma que las
entregas sean definidas con suficiente detalle para responder a las futuras
actividades de] proyecto. La descomposición comprende los siguientes pasos
principales:
- Identificar los principales elementos del proyecto. En general, los

principales elementos serán las entregas del proyecto y la dirección del
proyecto. Sin embargo, siempre se deben definir los principales elementos
188
dependiendo de como el proyecto sea realmente dirigido. Por ejemplo, las

fases del ciclo de vida pueden constituir un primer nivel de descomposición,
con un segundo nivel determinado por las entregas (figura 5.1) o por algún otro
criterio organizativo (figura 5.2).
Figura 5.1: WBS de una estructura de descomposición por fases1.
Figura 5.2: WBS de una planta de tratamiento de aguas residuales2.
- Decidir si se pueden realizar las adecuadas estimaciones de duración y

costes al nivel de detalle para cada elemento. El significado de adecuadas
puede variar en el curso del proyecto (la descomposición de una entrega que
se ha de producir en un tiempo lejano puede no sea posible). Para cada
elemento, hay que pasar al Punto 4 si se ha logrado el detalle adecuado y al
Punto 3 si no es así (esto quiere decir que los diferentes elementos pueden
tener diferentes niveles de descomposición).
- Identificar los elementos constituyentes de una entrega. Los elementos

constituyentes se deberían describir en términos de resultados verificables y
189
tangibles, para facilitar la medida de la realización. Los elementos

componentes- del proyecto deben definirse, como se hace con los elementos
principales, en la misma forma como se terminará realmente el trabajo del
proyecto. Resultados tangibles y verificables pueden incluir tanto servicios
como productos (por ejemplo, el informe de situación se puede describir como
informe de situación semanal; para un elemento manufacturado, los elementos
constituyentes podrían incluir varios componentes individuales más el montaje
final). Repetir el punto 2 para cada elemento constituyente.
- Verificar si se ha realizado la descomposición correcta:
- ¿Son necesarios y suficientes los elementos en el nivel inferior para completar

el elemento descompuesto? Si no es así, se deben modificar los elementos
constituyentes (añadir, eliminar o redefinir).
- ¿Está cada elemento clara y completamente definido? Si no es así, se deben

revisar o ampliar las descripciones.
- ¿Se puede programar correctamente cada elemento?, ¿presupuestar?,

¿asignar a una unidad específica de la organización (por ejemplo, un
departamento, equipo o persona) que aceptará la responsabilidad de concluir
satisfactoriamente el elemento? Si no es así, se requieren revisiones que
proporcionen un adecuado control.
a.2.- Work packages
Cada nivel descendente representa una descripción cada vez más detallada de
los elementos del proyecto. Cada elemento en la EDP es asignado a un único
identificador; el conjunto de estos identificadores a menudo se denomina
código de cuentas. Los elementos de los niveles más bajos de la EDP se
suelen denominar paquetes de trabajo (work packages). Estos paquetes de
trabajo pueden ser descompuestos aún más.
Las descripciones de los elementos de trabajo se reúnen frecuentemente en un

diccionario de la WBS. Este diccionario incluye generalmente descripciones de
paquetes de trabajo así como otra información de planificación como fechas del
programa, presupuestos de costes y asignaciones de personal.
a.3.- Otros tipos de WBS
No se debe confundir una WBS con otros tipos de estructuras de

descomposición utilizadas para presentar información del proyecto. Otras
estructuras comúnmente utilizadas en algunas áreas de aplicación son:
- Estructura de descomposición contractual, que se utiliza para definir el nivel

de información que el proveedor suministrará al comprador. La WBS
contractual tiene normalmente menos detalle que una WBS utilizada por el
proveedor para dirigir su propio trabajo.
190
- Estructura de descomposición organizativa, que muestra qué elementos de

trabajo han sido asignados a qué unidades de la organización. Un
organigrama.
- Estructura de descomposición de recursos, que es una variación de la

estructura de descomposición organizativa, y se utiliza normalmente cuando se
asignan los elementos de trabajo a personas individuales.
- Lista de materiales, que representa una relación jerárquica de los montajes,

submontajes y componentes necesarios para fabricar un producto
manufacturado.
- Estructura de descomposición de tareas, que es prácticamente lo mismo que

una WBS correctamente realizada. La estructura de descomposición de tareas
se utiliza ampliamente en áreas en las que el término WBS es incorrectamente
utilizado para referirse a una lista de materiales.
b.- Estimación de tamaño del software
Independiente de la estimación del trabajo a realizar por unidad de trabajo,

derivado de un WBS, está el tamaño del software, lo cual ayuda a decidir
respecto del personal necesario para cumplir cara tarea. La calidad de esta
estimación influye directamente en las estimaciones del coste y de la
programación, aparte de ser la más compleja. Cuando se hace de manera
pobre, induce a proyectos que superar costes y programaciones.
Dos mediciones de tamaño de software son habitualmente realizadas: las

líneas de código y los puntos de función.
b.1.- Líneas de código
La técnica de líneas de código requiere estimar el número de líneas de código

fuente por simple analogía. Esto da "una idea" del trabajo a realizar.
b.2.- Puntos de función
El análisis de puntos de función, por otra parte, no requiere conocimiento previo

del código fuente. Se basa en una medición de la funcionalidad del negocio. El
número de puntos de función es determinado de la suma de entradas, salidas,
consultas, ficheros maestros e interfaces del sistema a construir con otros
sistemas.
Este primer conteo es ajustado según la complejidad técnica y factores

medioambientales para arribar a una estimación más precisa de puntos de
función.
De esta manera, los puntos de función conducen a una estimación más

confiable e independiente de los lenguajes de programación.
c.- Estimación de coste y programación
191
Los dos enfoques esenciales para estimar el coste y la programación necesaria

de un proyecto son dos.
c.1.- Enfoque arriba-a-abajo y abajo-a-arriba
• Enfoque arriba-a-abajo. Esta es una estimación por analogías que

significa utilizar el coste real de anteriores proyectos similares como
base para la estimación del coste del proyecto actual. Se usa
frecuentemente para estimar los costes totales del proyecto cuando la
información detallada sobre el proyecto es escasa (por ejemplo, en las
fases iniciales de un proyecto). La estimación por analogías es una
forma de juicio experto.
La estimación por analogías es generalmente más barata que otras

técnicas, pero también suele ser menos precisa. Es más fiable, cuando
los proyectos anteriores son realmente similares y no solo en apariencia,
y las personas o grupos de personas que realizan las estimaciones
tienen la experiencia necesaria.
• Estimación abajo-a-arriba. Esta técnica comprende la estimación de
costes de tareas individuales: sumando las estimaciones individuales se
consigue el coste total del proyecto. El coste y la precisión de la
estimación de abajo-a-arriba depende del tamaño de las tareas
individuales: cuanto más pequeñas son las tareas tanto más se
incrementa el coste como la precisión. El equipo de dirección del
proyecto debe sopesar si la precisión adicional justifica el mayor coste.
Ambos métodos o enfoques se usan en conjunto y se requieren varias

iteraciones hasta alcanzar resultados que puedan considerarse
satisfactorios.
c.2.- GANTT, PERT y CPM
c.2.1.- Características
Conseguir una buena programación es un reto, no obstante es razonable y

alcanzable. Ella debe tener el compromiso del equipo al completo, para lo cual
se recomienda que cada miembro o grupo del equipo determine las tareas a
realizar y el tiempo para cumplirlas.
La programación para grandes proyectos usualmente comprende un programa

máster, mostrando principales actividades e hitos y dejando el detalle en sub-
programas.
La forma más común de presentar un programa es una carta GANTT que

muestra las actividades contra una escala de tiempo horizontal (figura 5.3).
Las cartas GANTT son herramientas populares para comprender y facilitar la
creación y revisión del programa. Esto da lugar a una red de programa que
muestra las inter-relaciones.
192
Figura 5.3: Carta GANTT3.
Estas inter-relaciones se muestran habitualmente como redes PERT (Program

Evaluation Review Technique, figura 5.4) y CPM (critical path method). Ambos
métodos son bastante similares en el uso de flujogramas, grafos o redes de
dependencia para mostrar las inter-relaciones.
193
Figura 5.4: PERT4.
Otra ventaja de las redes de programación (schedule networks) es que pueden

usarse para identificar y seguir el camino crítico del proyecto.
Todas estas técnicas de representación, son instancias de un diagrama de

precedencias.
c.2.2. - Ventajas y desventajas de los gráficos Gantt
"La ventaja principal del gráfico de Gantt radica en que su trazado requiere un
nivel mínimo de planificación, es decir, es necesario que haya un plan que ha
de representarse en forma de gráfico. La técnica descrita de este capítulo
representa y al mismo tiempo ayuda a la elaboración del plan de trabajo. Los
194
gráficos de Gantt se revelan muy eficaces en las etapas iniciales de la

planificación. Sin embargo, después de iniciada la ejecución de la actividad y
cuando comienza a efectuarse modificaciones, el gráfico tiende a volverse
confuso. Por eso se utiliza mucho la representación gráfica del plan, en tanto
que los ajustes (replanificación) requieren por lo general de la formulación de
un nuevo gráfico. Para superar esa deficiencia se crearon dispositivos
mecánicos, tales como cuadros magnéticos, fichas, cuerdas, etc., que permite
una mayor flexibilidad en las actualizaciones. Aún en términos de planificación,
existe todavía una limitación bastante grande en lo que se refiere a la
representación de planes de cierta complejidad. El Gráfico de Gantt no ofrece
condiciones para el análisis de opciones, ni toma en cuenta factores como el
costo. Es fundamentalmente una técnica de pruebas y errores. No permite,
tampoco, la visualización de la relación entre las actividades cuando el número
de éstas es grande5".
c.2.3.- Diferencia entre PERT y CPM
"La diferencia entre PERT y CPM es la manera en que se realizan los

estimados de tiempo. El PERT supone que el tiempo para realizar cada una de
las actividades es una variable aleatoria descrita por una distribución de
probabilidad. El CPM por otra parte, infiere que los tiempos de las actividades
se conocen en forma determinísticas y se puede variar cambiando el nivel de
recursos utilizados6".
c.2.4.- Comparación de los Gráficos Pert y Gantt
"Estos gráficos se presentan frecuentemente como herramientas de gestión de

proyectos mutuamente excluyentes. Normalmente, se recomienda PERT para
grandes proyectos con alta dependencia entre las tareas: Gantt, por su parte,
se recomienda para proyectos más sencillos. Todos los proyectos de desarrollo
de sistemas tienen algunas dependencias entre tareas y ofrecen la ocasión de
solapar tareas. Por consiguiente, los gráficos PERT y Gantt deberían utilizarse
como herramientas complementarias para planear, programar, evaluar y
controlar los proyectos de desarrollo de sistemas. Por lo general los directores
de proyectos de sistemas de información prefieren los gráficos Gantt por su
sencillez y su capacidad para mostrar el calendario de un proyecto. En los
paquetes de software de gestión de proyectos reúnen las mejores
características de PERT (sobre todo, el análisis del camino critico)
incorporadas en gráficos de Gantt. Cuando se introducen las tareas, se
incluyen también su duración y sus dependencias. Las barras de Gantt se
planifican en el tiempo de manera que tengan en cuenta sus dependencias. Por
lo general el camino critico se resalta con mayor intensidad. Además, también
se destaca la cantidad de tiempo muerto apreciada en las tareas de caminos
no críticos. Esta presentación puede probar su utilidad cuando se decida que
tareas se retrasarán con objeto de conseguir recuperar el tiempo en las tareas
que superan los plazos previstos7".
c.3.- Diagrama de precedencias
195
Este es un método de elaborar un diagrama en red del proyecto usando nodos,

que representan las actividades, conectados mediante flechas, que muestran
las dependencias (figura 5.5): el método del diagrama de precedencias. Esta
técnica se denomina también actividades en los nodos y es el método utilizado
en la mayoría de los programas de software para la gestión de proyectos. El
método del diagrama de precedencias se puede realizar manualmente o
mediante ordenador.
Figura 5.5: Diagrama de precedencias.
El método incluye cuatro tipos de dependencias o relaciones de precedencia:
• Terminación-a-comienzo: la actividad inicial debe terminar antes de

que la actividad final pueda comenzar;
• Terminación-a-terminación: la actividad inicial debe terminar antes de
que la actividad final pueda terminar;
• Comienzo-a-comienzo: la actividad inicial debe comenzar antes de que
la actividad final pueda comenzar; y,
• Comienzo-a-terminación: la actividad inicial debe comenzar antes de
que la actividad final pueda terminar.
En el método del diagrama de precedencias, el tipo más habitual de relación

lógica es el terminación-a-comienzo. Las relaciones comienzo-a-terminación se
utilizan rara vez y cuando se utilizan, es únicamente por ingenieros de
programación profesionales. Usar las relaciones comienzo-a-comienzo,
terminación-a-terminación o comienzo-a-terminación con el software para
gestión de proyectos puede producir resultados no esperados, ya que estos
tipos de relaciones no han sido suficientemente probados.
Otros métodos similares son:
• Método del diagrama de flechas. Este es un método de elaboración de

un diagrama en red del proyecto que utiliza flechas para representar las
actividades y las conecta a nodos que muestran las dependencias
(figura 5.6). Esta técnica también se denomina actividades en las
flechas y, aunque menos corriente que el método del diagrama de
precedencias, es la técnica que se elige en algunas áreas de aplicación.
El método del diagrama de flechas utiliza solamente dependencias
terminación-a-comienzo y puede necesitar el uso de actividades ficticias
para definir correctamente todas las relaciones lógicas. El método del
diagrama de flechas se puede realizar manualmente o mediante
ordenador.
196
Figura 5.6: Diagrama de flechas.
Reglas para construir el diagrama de flechas:
1. Cada actividad está representada por una y un solo una flecha en la red.
Ninguna actividad puede representarse dos veces en la red.
2. Dos actividades diferentes no pueden identificarse por los mismos eventos

terminal y de inicio.
3. Al fin de asegurar la relación de precedencia correcta el diagrama de flechas,

las siguientes preguntas deben responderse cuando se agrega cada actividad
a la red:
- ¿Qué actividad debe terminarse inmediatamente antes de que esta actividad

pueda comenzar?
- ¿Qué actividades deben seguir a esta actividad?
- ¿Qué actividades deben efectuarse simultáneamente?8
• Métodos de diagramas condicionales. Las técnicas de diagramas

tales como los modelos GERT (Técnica de Revisión y Evaluación
Gráfica) y sistemas dinámicos, permiten tratar actividades no
secuenciales tales como lazos (por ejemplo una prueba que se debe
repetir más de una vez) o condicionadas (por ejemplo, una actualización
del diseño que sea solamente necesaria si la inspección detecta
errores). Ni el método del diagrama de precedencias ni el método del
diagrama de flechas permiten tratar lazos o actividades condicionadas.
• Redes patrón. Se pueden utilizar redes normalizadas para facilitar la
preparación de los diagramas en red del proyecto. Pueden incluir un
proyecto completo o solamente una parte de él. A las partes de una red
se las suele denominar subredes o fragmentos de redes. Las subredes
son especialmente útiles cuando un proyecto incluye varias partes
idénticas o casi idénticas, como las plantas de un edificio alto de
oficinas, los ensayos clínicos en un proyecto de investigación
farmacéutica, o los módulos del programa en un proyecto de software.
c.4.- Camino crítico
197
El camino crítico del proyecto es el conjunto de actividades que toma mayor

tiempo completarlo. En esencia, el camino crítico determina cuando el proyecto
terminará. Las tareas en el camino crítico requieren atención especial de la
gestión debido a que no dejan espacios libres u holguras en la programación,
de hecho no puede atrasarse bajo ningún concepto.
Debe hacerse notar que un proyecto puede tener muchos caminos críticos y
que las variaciones en la duración de las tareas puede ir de un camino a otro.
El camino critico resulta también de utilidad para identificar programaciones de
riesgo.
El camino crítico es una técnica análisis matemático que comprende el cálculo

teórico para el comienzo y terminación, con mayor antelación y mayor retraso,
de todas las actividades del proyecto sin tener en cuenta las limitaciones del
conjunto de recursos. Las fechas resultantes no son el programa, sino que
indican los periodos de tiempo dentro de los que la actividad debe ser
programada, dadas las limitaciones de los recursos y otras restricciones
conocidas.
En esencia, el Método del Camino Crítico es un método de optimización que

calcula una fecha de comienzo y terminación, la de mayor adelanto y la de
mayor retraso, para cada actividad, basándose en la secuencia de relaciones
lógicas ya especificada y en la simple estimación de duraciones. El objetivo del
método del camino crítico es calcular el margen con el fin de determinar qué
actividades tienen la menor flexibilidad de programación. Los algoritmos del
método del camino crítico se utilizan a menudo en otros tipos de análisis
matemático.
Algunas variaciones ocurren respecto de un GERT y un PERT.
• GERT. Permite el tratamiento probabilístico tanto de las relaciones

lógicas como de las estimaciones de la duración de las actividades (por
ejemplo, algunas actividades pueden no desarrollarse, otras se pueden
desarrollar solamente en parte, y otras pueden desarrollarse más de una
vez).
• PERT. Utiliza las relaciones lógicas secuenciales y una media
ponderada de la estimación de duraciones para calcular la duración del
proyecto. Aunque hay diferencias superficiales, el PERT difiere del
GERT principalmente en que utiliza el concepto de distribución (valor
esperado) en lugar de la estimación más probable originalmente
utilizada en este último (figura 5.7). El PERT en sí mismo apenas se usa
hoy en día, aunque las estimaciones realizadas para el PERT se usan
frecuentemente en los cálculos del CPM.
198
Figura 5.7: Cálculo de la duración de un proyecto mediante PERT.
Un caso especial de análisis matemático es la reducción de plazos, que busca

la manera de reducir el programa del proyecto sin alterar su alcance (por
ejemplo, lograr las fechas impuestas u otros objetivos del programa). La
reducción de plazos incluye técnicas tales como:
- Crashing. Es una técnica en la que se analizan el coste y los cambios del

programa para determinar cómo obtener la mayor reducción posible con el
menor incremento de costes. El crashing no siempre produce una alternativa
viable y da lugar, frecuentemente, a un incremento de los costes.
- Camino acelerado. Consiste en realizar actividades en paralelo que

normalmente se realizarían en serie (por ejemplo, empezar a codificar en un
programa de software antes de completar su diseño, comenzar a construir las
cimentaciones para una refinería de petróleo antes dé realizar el 25 por ciento
de la labor de ingeniería, o empezar a comprar hardware sin tener definida la
infraestructura e-Business). Normalmente esta técnica conduce a repetir tareas
y frecuentemente incrementa el riesgo.
c.5.- Programa del proyecto
El programa del proyecto9 incluye al menos las fechas planeadas de comienzo

y las previstas de terminación para cada actividad.
El programa del proyecto se puede presentar en forma de resumen (el

"programa básico") o en detalle. Aunque puede presentarse en forma de tabla,
es más frecuente presentarlo gráficamente, utilizando uno o más de los
siguientes formatos:
- Diagramas en red del proyecto con información añadida sobre fechas.

Estos diagramas normalmente muestran la lógica del proyecto y las actividades
del camino crítico del proyecto.
- Diagramas de barras, también llamados diagramas de GANTT. Muestran las

fechas -de comienzo y terminación de las actividades así como las duraciones
199
esperadas, pero normalmente no muestran las dependencias. Son

relativamente fáciles de interpretar y se usan frecuentemente en los informes
de dirección.
- Diagramas de hitos. Son similares a los diagramas de barras (figura 5.8),

pero identifican el comienzo o la terminación programados de las principales
entregas y las conexiones externas clave.
Figura 5.8: Diagrama de hitos10.
- Red dimensionada. Es una mezcla de diagramas en red del proyecto y de

diagramas de GANTT en la que se muestra la lógica del proyecto, la duración
de las actividades y la información del programa (figura 5.9).
Figura 5.9: Red dimensionada11.
Ejemplo:
200
Figura 5.10: Actividades para el desarrollo de Software.
Para este ejemplo tenemos algunas actividades realizadas por el ultimo nivel,
entre estas están:
• Test.
• Aplicación de Conceptos.
• STDR.
• Prueba de Nivelación.
• Leer Tool.
• Don de Gente.
• Manejo de Stress y Complejidad.
• Pre-Contrato.
• Convencerlos.
• Plantilla.
• Selec. Clasif.
• CV.
• Hacer Afich.
• Pegar.
• Sel. Medios.
• Claridad.
Por ejemplo si quisiéramos analizar la prueba de nivelación, tendríamos que

hacer lo siguiente:
Para cada proceso de tercer nivel como los que hemos descrito anteriormente,
definiremos, que tareas se realizaran primero, y cual después, y además, cada
tarea deberá tener asignado algún costo y tiempo que se tomara en realizarlo.
201
Figura 5.11: Grafo de Procesos.
Una vez que ya hemos realizado este paso, procedemos a realizar la carta
Gantt.
El gráfico Gantt muestra un formato de un gráfico de tiempo; la columna del

lado izquierdo enfatiza las tareas a realizar, la fila superior indica el tiempo en
que se dará esa tarea. Para tener previsto las semanas en que se tendrá mas
actividades y como se las gestionará.
SEMANA SEMANA SEMANA SEMANA SEMANA

TAREAS
1 2 3 4 5
Identificar necesidades y
1,1,1
beneficios
Reunirse con los clientes
Identificar las necesidades y

las limitaciones
del proyecto
Establecer la declaración del

producto
Hito: declaración de producto

definido
Definir las
1,1,2 salidas/controles/entradas
deseadas (SCE)
Alcance de las funciones del

teclado
Alcance de las funciones de

la entrada de voz
Alcance de los modos de

interacción
Alcance de documento de
diagnostico
Alcance otras funciones WP
Documento SCE
202
RTF: revisar el SCE con el

cliente
Revisar el SCE segun se

requiera
Hito: SCE definido
Definir la
1,1,3
funcionalidad/comportamiento
Definir las funciones del

teclado
Definir las funciones de

entrada de voz
Describir los modos de

interacción
Describir las comprobaciones

de ortografía/gramática
Describir otras funciones WP
RTF: Revisar la definición

SCE con el cliente
Revisar segun sea necesario
Hito: Definición de SCE

completa
1,1,4 Aislar los elementos software
Hito: Elementos software

definidos
Investigar la disponibilidad del

1,1,5
software existente
Investigar los componentes

de edición de texto

de la entrada de voz

de la administración
de archivos

de la comprobación
de ortografía y gramática
Hito: Componentes
reutilizables identificados
1,1,6 Definir la viabilidad técnica
203
Evaluar la entrada de voz
Evaluar la comprobación de
gramática
Hito: Viabilidad técnica

valorada
Hacer una estimación rápida

1,1,7
del tamaño
crear una definición de

1,1,8
ámbito
Revisar el documento de
ámbito con el cliente
Revisar el documento segun

se requiera
Hito: Documento de ámbito

completo
Tabla 5.1. Carta Gantt.
A partir de esta gráfico del tiempo, se producen las tablas de proyecto (tabla
5.2), que son un listado de todas las tareas del proyecto, sus fechas previstas y
reales de inicio y finalización, e información varia sobre el tema. Con esto el
gestor puede ver cuando se realizan las tareas como han progresado y cuando
concluyen.
Inicio Inicio Term. Term. Personas Esfuerzo

Tareas Obs.
Previsto Real Prevista Real Asignadas Asignado
identificar necesidades y
1,1,1
beneficios
Sem Sem Sem Sem Es

Reunirse con los clientes BLS 2pd
1,d1 1,d1 1,d2 1,d2 previsible
Identificar las necesidades y Sem Sem Sem Sem que

JPP 1pd
las limitaciones 1,d2 1,d2 1,d2 1,d2 requiera
mas
del proyecto
esfuerzo/
Establecer la declaración del Sem Sem Sem Sem

BLS/JPP 1pd tiempo
producto 1,d3 1,d3 1,d3 1,d3
Hito: declaración de producto Sem Sem Sem Sem

definido 1,d3 1,d3 1,d3 1,d3
Definir las
1,1,2 salidas/controles/entradas
deseadas (SCE)
Ambito de las funciones del Sem Sem Sem

BLS 1,5 p d
teclado 1,d4 1,d4 2,d2
Ambito de las funciones de la Sem Sem Sem JPP 2pd
204
entrada de voz 1,d3 1,d3 2,d2
Ambito de los modos de Sem Sem Sem

MLL 1pd
interacción 2,d1 2,d1 2,d3
Ambito de documento de Sem Sem Sem

BLS 1,5 p d
diagnostico 2,d1 2,d1 2,d2
Sem Sem Sem

Ambito otras funciones WP JPP 2pd
1,d4 1,d4 2,d3
Sem Sem Sem

Documento SCE MLL 3pd
2,d1 2,d1 2,d3
RTF: revisar el SCE con el Sem Sem Sem

Todos 3pd
cliente 2,d3 2,d3 2,d3
Revisar el SCE segun se Sem Sem Sem

Todos 3pd
requiera 2,d4 2,d4 2,d4
Sem Sem Sem

Hito: SCE definido
2,d5 2,d5 2,d5
Definir la
1,1,3
funcionalidad/comportamiento
Tabla 5.2. Tabla de Proyectos.
d.- Estimación de coste y presupuesto
Otras tareas de estimación son de coste y presupuesto. En un proyecto

informático, el coste del presupuesto se mide en función de las horas de
esfuerzo dedicadas a las tareas. La estimación es un análisis histórico ajustado
a las capacidades y habilidades de cada miembro.
La estimación cubre todas las actividades del WBS, incluyendo la propia

gestión del proyecto y sus funciones de apoyo, como el aseguramiento de la
calidad y el seguimiento de los planes de riesgo, por ejemplo. La estimación
debe incluir costes directos no laborables, y los costes indirectos o de
overhead. Los costes directos se calculan de las horas-hombre multiplicadas
por su valor de mercado o acordado. Los costes directos no laborables incluyen
outsourcing, consultores, viajes, cenas, etc.
El presupuesto total del proyecto es determinado agregando todos los costes

directos e indirectos. Es buena práctica incluir salvaguardas de gestión para
contingencias y problemas no anticipados. Una reserva del 5 al 10% no es
extraña usual y puede ser mayor en proyectos mayores o de alto riesgo.
El presupuesto debe asignarse a individuos u organizaciones siguiendo el

WBS. El presupuesto marca la línea base (baseline) sobre la cual medir el
desempeño del proyecto. Una herramienta adecuada es la curva-s que muestra
los costes acumulados, la cual provee la representación gráfica del
presupuesto en función del tiempo según la programación del proyecto.
205
Figura 5.12: Curva de coste acumulado.
1
Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto
de cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP
para este tipo de proyecto.
2
Esta EDP es únicamente ilustrativa. No trata de representar el alcance completo del proyecto
de cualquier proyecto específico, ni supone que sea este el único modo de organizar la EDP
para este tipo de proyecto.
3
Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. pp. 15-16.
4
Fuente: Barceló. M. La gestió d'un projecte informàtic. UOC. pp. 9-10.
5
Enlace web: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/diaggantaleja.htm.
[Leído: 23 de Junio de 2006, 11.00h GMT-5].
6
Enlace web: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/tecplajfrz.htm.
7
Enlace web: http://www.gestiopolis.com/recursos/documentos/fulldocs/ger/gestioproyecto.htm.
8
Enlace web: http://www.geocities.com/SiliconValley/Pines/7894/modelos/proyectos.html.
9
El programa del proyecto se considera preliminar hasta que la asignación de recursos ha sido
confirmada. Esto normalmente ocurre antes de la terminación del desarrollo del plan del
proyecto.
10
Hay otras muchas maneras válidas para mostrar la información sobre un proyecto en un
diagrama de hitos.
11
Hay otras muchas maneras válidas para mostrar la información sobre un proyecto en una
Red dimensionada.
5.2.2 Selección de los miembros del equipo
La ejecución de un proyecto es como los deportes, la diferencia entre el

miembro más productivo y el menos productivo puede ser amplia. No obstante
se deberían seleccionar los mejores.
Por este motivo es importante tener en consideración que las habilidades a

buscar no son solamente técnicas, sino habilidades para solucionar problemas
e interpersonales. Aún más, debe recordarse siempre que un buen miembro
tiene una alta auto-estima y un fuerte compromiso hacia el éxito de un
proyecto.
Cualquier Test a realizar debe crear equipos con una mezcla equilibrada de
habilidades y personalidades. Muchos programadores o personas del ámbito
técnico son personas introvertidas y pensativas que basan sus decisiones en
hechos en lugar de sentimientos y valores personales. Ellos tienen a encontrar
206
dificultades en construir relaciones y ver el proyecto desde el punto de vista del

usuario. Por ello, formar un equipo equilibrado no es una labor sencilla.
5.2.3 Plan de proyecto
La planificación culmina con el plan del proyecto. Este documento describe el

enfoque completo para desarrollar la aplicación e-Business y sus sistemas
informáticos componentes. Es un documento que informa a la gestión, a los
miembros del equipo y al cliente. Es como un mapa que sirve para guiar al
proyecto y sus involucrados.
El plan del proyecto es un documento formal y aprobado que se utiliza para

dirigir y controlar la ejecución del proyecto. Debería ser distribuido según defina
el plan de Gestión de Comunicaciones (por ejemplo, la dirección de la
organización ejecutora puede necesitar un plan general con pocos detalles,
mientras que un contratista puede necesitar muchos detalles de un solo tema).
En algunas áreas de aplicación, se usa el término plan integrado del proyecto
para referirse a este documento.
Debe establecerse una clara distinción entre el plan del proyecto y las bases
para medir la realización del proyecto. El plan del proyecto es un documento o
conjunto de documentos que debería esperarse que cambien a medida que
haya más información disponible sobre el proyecto. Las bases para la
evaluación de la realización del proyecto representa un control de dirección que
normalmente sólo cambiará intermitentemente y en estos casos, los cambios
serán realizados únicamente como respuesta a un cambio autorizado del
alcance del proyecto.
En este documento se especifican aspectos de desarrollo, los subproductos a

entregar, requerimientos de recursos, programación, responsabilidades
organizacionales y presupuestos, y el proceso de gestión. Además, incluye
factores de riesgo y estrategias de gestión del riesgo, y describe de qué
manera se gestiona y asegura la calidad. Establece el coste y las bases de la
programación para gestionar y controlar el proyecto. Además en sí mismo es
parte efectiva del sistema de control del proyecto.
Hay muchas maneras de organizar y presentar el plan del proyecto, pero

normalmente incluye lo siguiente (estos puntos se describirán con más detalle
más adelante):
• Justificación del proyecto.

• Descripción de los puntos de vista o estrategia de la dirección del
proyecto (un resumen de los planes de dirección para cada una de las
otras áreas).
• Establecimiento del alcance, que incluye las entregas y objetivos del
proyecto.
• WBS al nivel al que se realizará el control.
• Estimación de costes, fechas programadas de inicio de actividades y
asignación de responsabilidades al nivel de la EDP, en el que será
ejercido el control.
207
• Bases para la evaluación de la realización del proyecto en cuanto a

programa y costes.
• Principales hitos y fechas objetivo para cada uno.
• Personal requerido o clave.
• Riesgos clave, incluyendo las restricciones y supuestos y las respuestas
previstas para cada uno.
• Planes auxiliares de dirección, incluyendo el plan de gestión del alcance
del proyecto, el plan de dirección del programa, etc.
• Temas abiertos y decisiones pendientes.
Se deberían incluir otros resultados de la planificación del proyecto en el plan

formal, basándose en las necesidades de cada proyecto en particular. Por
ejemplo, el plan del proyecto para un gran proyecto incluirá, normalmente, un
organigrama del proyecto.
Para probar la adecuación del plan, el gestor del proyecto debe preguntarse:
- ¿El plan permite gestionar el proyecto de forma adecuada?
- ¿El plan provee información suficiente para que los miembros del equipo
planifiquen y ejecuten su trabajo?
- ¿Se cuenta con el compromiso de la dirección y del equipo del proyecto?
Un patrón de plan se entrega en el Apéndice III.
5.2.4 Informe de alcance
El Informe del Alcance constituye una base documentada para la adopción de

las futuras decisiones del proyecto y para confirmar o desarrollar entre las
entidades involucradas en el proyecto aportando un entendimiento común del
alcance del mismo. Según progresa el proyecto, puede ser necesario revisar o
depurar el informe del alcance, para reflejar los cambios en el mismo. El
informe del alcance debe incluir, bien directamente o por referencia a otros
documentos, lo siguiente:
• Justificación del proyecto: la necesidad del negocio que debe ser

resuelta por el proyecto. La justificación del proyecto constituye la base
para la evaluación de futuros compromisos.
• Producto del proyecto: un breve resumen de la descripción del
producto.
• Entregas del proyecto: una lista a modo de resumen de los
subproductos cuya completa y satisfactoria entrega marca la finalización
del proyecto. Por ejemplo, las principales entregas de un proyecto de
desarrollo de software pueden incluir el lenguaje de trabajo del
ordenador, un manual de usuario y un gestor del programa interactivo.
Cuando sean conocidas, las exclusiones deben ser identificadas,
teniendo en cuenta que cualquier cosa no incluida explícitamente es
implícitamente excluida.
208
• Objetivos del proyecto: los criterios cuantificables que deben cumplirse

para que el proyecto se considere un éxito. Los objetivos del proyecto
deben incluir, al menos, medidas de costes, programa y calidad. Los
objetivos del proyecto debe tener un atributo (por ejemplo, coste), un
patrón o unidad fundamental (por ejemplo, dólares USA) y un valor
absoluto o relativo (por ejemplo, menos de 1,5 millones). Los objetivos
no cuantificables (por ejemplo, la satisfacción del cliente) constituyen un
riesgo elevado.
En algunas áreas de aplicación, las entregas del proyecto son llamadas

objetivos del proyecto mientras que los objetivos del proyecto son llamados
factores críticos de éxito.
5.3 Control y seguimiento

El control es una etapa de valoración del trabajo realizado buscando
aprovechar buenas prácticas y analizar las debilidades del proyecto e-Business
tomando de referencia los datos recogidos durante el seguimiento.
5.3.1 Aseguramiento de la calidad
El aseguramiento de la calidad (Quality Assurance, QA) asegura que el

producto cumple con los requerimientos y provee la funcionalidad y calidad
deseada.
La calidad, como los requerimientos de desempeño técnico, debe ser

especificada en términos cuantitativos que claramente comprensibles por el
cliente y los miembros del equipo. Además, mientras el equipo se compromete
a construir la calidad en el producto, una práctica frecuente es contar con
alguien dedicado y separado del equipo cumpliendo funciones de asegurador
de calidad.
El principal propósito del aseguramiento de la calidad es detectar errores y

corregirles rápidamente. La detección y corrección temprana puede resultar en
beneficios de coste y tiempo significativos. De hecho, el coste de corregir
errores en la etapa de diseño es un 10% de corregirle en la etapa de prueba.
La herramientas básicas para el aseguramiento de la calidad son las revisiones

técnicas y las pruebas. Las revisiones técnicas son efectivas cuando
encuentran defectos tempranamente y encuentran diferentes tipos de error
probar. Las prácticas más comunes de aseguramiento de la calidad los
walkthroughs, las inspecciones y las pruebas.
Ambos tipos de revisiones son efectivas para la detección temprana de errores

en requerimientos, interfaces, diseño, codificación o manufactura, y
documentación.
El seguimiento del proceso de calidad, requiere métricas precisas. Por ejemplo,

dos métricas usadas habitualmente en el desarrollo de software son:
209
• Densidad de defectos (número de defectos por 1.000 líneas de código

fuente).
• Eficiencia de remoción de defectos (porcentaje de defectos removidos
en una operación: revisión de código o una prueba).
a.- Walkthroughs
Un walkthrough son reuniones informales en la que los miembros del equipo

revisan el diseño o código para identificar mejoras y problemas.
b.- Inspección
Las inspecciones son revisiones más formales donde revisores usan listas de
chequeo (checklists) para estimular la revisión y recurren a registros de control
y retroalimentación sistemática para mejorar el proceso de desarrollo.
c.- Prueba
La prueba es medio más común de asegurar la calidad. Es el ejercicio

sistemático de buscar y detectar defectos donde lo fueron hallados
anteriormente. Conducidos e nivel de unidad y de sistema, sirven para verificar
la funcionalidad y calidad del sistema.
5.3.2 Tiempo y coste
a.- Proceso de control del proyecto
El propósito del control del proyecto es:
• mantener el proyecto en curso y cercano al plan de trabajo;

• identificar problemas antes de que ocurran; e,
• implementar planes de recuperación antes que los daños sean
irreparables.
El proceso involucra comparar el progreso con el plan y tomar acciones

correctivas conforme existan desviaciones que afecten el desempeño y/o el
plan; y proveer retroalimentación (figura 5.13).
210
Figura 5.13: Control del proyecto.
Para un control a tiempo y efectivo, el gestor del proyecto debe tener completa
visibilidad del avance del proyecto. Para ello, se debe efectuar un monitoreo y
seguimiento sistemático.
El grado de formalidad y frecuencia de monitoreo depende del tipo de proyecto,

aunque siempre debe enfocarse en el coste, programación y desempeño
técnico.
b.- Control del coste y del programa
El seguimiento del coste y de la programación involucra comparar el estado

actual contra lo presupuestado en cuanto coste, tiempo y etapas.
Desviaciones significativas del plan requieren atención prioritaria del gestor del
proyecto para tomar una acción correctiva a tiempo. Conocer la desviación no
es suficiente, hay que identificar la causa del problema. Si la desviación del
plan es grande, se debe decidir si se replanifica.
Para tener visibilidad de estas decisiones, el coste y la programación son

analizados de forma integrada. Estar dentro del presupuesto no es suficiente si
las tareas no se completan a tiempo. Similarmente, completar tareas de
acuerdo al programa no basta si los costes "se han disparado". En este
análisis, disponer de la WBS provee la base fundamental para comparar coste
y programa contra el plan.
c.- Valor ganado
Aunque las cartas GANTT y los informes de acumulación de reportes proveen

indicadores útiles del estado del proyecto, presentan limitaciones. La limitación
primaria es que son complejos y difíciles de analizar, particularmente para
grandes proyectos con muchas tareas. Esta complejidad puede conducir a una
211
percepción distorsionada del estado del proyecto. Una técnica para proveer
una mejor, más holística visión del progreso del proyecto es la técnica del valor
ganado (Earned Value Technique). Originalmente creada para un mejor
seguimiento de proyectos gubernamentales a gran escala, es hoy en día
herramienta habitual en los proyectos informáticos.
La técnica mide el valor del trabajo realizado en términos del presupuesto

asignado al trabajo. Permite separar las variaciones de coste y programación
en términos monetarios.
La variación en coste se debe a la variación en el precio del trabajo realizado

mientras la variación en la programación se debe al trabajo realizado fuera de
los tiempos programados.
El valor ganado y las variaciones son calculados para una actividad simple, un
grupo de actividades o el proyecto completo. De las variaciones de coste y
programación es posible determinar indicadores de desempeño de coste y
programación del proyecto. Estos índices proveen visibilidad instantánea sobre
el desempeño del proyecto. Esto ayuda al gestor del proyecto a estimar el
coste para terminar y el coste actual a la fecha, basado en el desempeño a la
fecha.
La técnica se basa en tres parámetros básicos:
- Presupuesto planeado (planned budget): coste presupuestado de trabajo

planificado (budgeted cost of work scheduled, BCWS).
- Coste actual: coste actual de trabajo realizado (actual cost for work
performed, ACWP).
- Valor ganado (earned value): Coste presupuestado de trabajo realizado

(budgeted cost for work performed, BCWP).
Variación del coste (cost variance, CV) se calcula de la siguiente manera:
- CV = BCWP - ACWP
- Una variante negativa indica un coste excesivo.
Variación de la programación (schedule variance, CV) se calcula de la siguiente

manera:
- SV = BCWP - BCWS
- Una varianza negativa indica que el proyecto esta fuera de programación.
Ambas varianzas son expresadas en términos monetarios, pero también

pueden expresarse en porcentajes de la siguiente manera:
- % CV = CV / BCWP
212
- % SV = SV / BCWP
El índice de desempeño de coste (cost performance index, CPI) está calculado

como:
- CPI = BCWP / ACWP
El CPI puede usarse para calcular el coste del proyecto o el coste estimado al
completarlo (estimate at completion, EAC). Una fórmula simplificada para EAC
es:
- EAC = BAC / CPI
- donde BAC (budgeted cost at completion) es el coste básico o presupuestado

para terminar el proyecto.
Similarmente, es posible calcular el índice de desempeño de la programación

(schedule performance index, SPI) de la siguiente manera:
- SPI = BCWP / BCWS
Por último, una versión simplificada para estimar la duración del proyecto o
tiempo estimado para terminar el proyecto (estimated time to completion, ETC)
se puede calcular de la siguiente manera:
- ETC = OD / SPI
- donde OD es la duración original (original duration, OD).
d.- Revisión
d.1.- Encuentros de revisión
Encuentros de revisión son instrumentos vitales en el control del proyecto. El

propósito es valorizar el progreso e identificar áreas de desviación desde el
plan para proponer acciones correctivas. Los encuentros son el mecanismo
para discutir abiertamente problemas presentes y futuros y proveer un marco
de comunicación habitual, si se desea.
Los encuentros:
- Proveen visibilidad a los planes y su progreso, y crean oportunidades para

obtener y reforzar compromisos con los participantes.
- Son más efectivos cuando ellos son programados a intervalos regulares

(semanalmente es lo habitual) y siguiendo una agenda establecida y acordada
por los involucrados.
213
- Deberían contar con la presencia de personas representativas de las áreas

involucradas para tener respuestas adecuadas, negociar soluciones y hacer
compromisos.
- Son diferentes de una revisión técnica y/o de calidad, donde se dedica

especial atención a detectar y corregir problemas más que revisar el progreso.
- Son diferentes de una reunión de gestión o de dirección, donde el gestor de

proyecto se reúne con un directivo o un comité de dirección, para informar del
proyecto y su integración en la estrategia organizacional.
d.2.- Informes de estado
Los informes de estado son preparados y enviados de forma regular para

informar a las personas externas a la organización. Ellos deben ser cortos y
oportunos.
d.3.- Agenda del proyecto
Una agenda típica incluye:
- detalle del progreso programado (principales hitos, programa y costes);
- avance de actividades específicas;
- estado de determinados ítems y/o recursos;
- planificación futura; y,
- estado de las áreas de alto riesgo.
d.4.- Informe de alcance e informe de realización
Es conveniente mantener actualizado el informe del alcance con el fin de

mostrar los cambios al plan del proyecto. Las nuevas versiones del informe de
alcance deben ser mantenidas en la biblioteca del proyecto y los cambios y
alteraciones ser gestionadas de manera adecuada e informadas a las personas
pertinentes afectadas.
Aparte y vinculados al informe de alcance están los Informes de Realización,

los cuales organizan y resumen la información reunida a lo largo del proyecto y
presentar resultados de cualquier análisis. Estos informes deben proporcionar
los tipos de información y nivel de detalle requerido por las distintas entidades
involucradas, tal y como establece el Plan de Comunicaciones.
5.3.3 Desempeño y evaluación
a.- Control de desempeño técnico
214
El control del desempeño técnico es el proceso de asegurar que todos los

requerimientos son satisfechos a través de revisiones de diseño.
a.1.- Revisiones técnicas
Estas revisiones son usualmente mantenidas en los principales hitos (por

ejemplo, al término de las fases del ciclo de vida) pero pueden hacerse en otros
instantes.
El propósito de estas revisiones es mostrar el logro actual o predecir objetivos

técnicos potenciales. El progreso de los objetivos técnicos debería hacerse con
métricas apropiadas.
Una práctica útil de contar con representantes de los clientes en las revisiones
técnicas para asegurar criterios comunes de las necesidades y evitar sorpresas
futuras.
a.2.- Métricas
Las métricas proveen visibilidad de lo conseguido y sus tendencias ofrecen un

medio predictivo para actuación futura. Ellas deben estar basadas en normas y
estándares, esencialmente cuantitativas, además de acordadas entre las
partes.
b.- Cambio y control de la configuración
El control del cambio es un concepto simple, pero complejo en su detalle. Aún

el requerimiento mejor preparado requiere cambios, especialmente cuando de
software se trata, una vez se diseña y se prueba.
Muchos proyectos fallan por cambios incontrolados que van más allá de los
requerimientos definidos inicialmente o acordados previamente. En varios
casos conducen a situaciones de escalada. Para ayudar a la detección y
seguimiento del cambio es esencial contar con un sistema de control de
cambios que incluya herramientas automatizadas, y un núcleo de gestión del
cambio o grupo de control de cambios.
Un sistema de control de cambios es un conjunto de procedimientos

documentados y formales que definen los pasos a seguir para realizar cambios
en los documentos oficiales del proyecto. Incluye formularios, sistemas de
seguimiento y los niveles de aprobación necesarios para autorizar los cambios.
En muchos casos, la organización ejecutora tendrá un sistema de control de

cambios que podrá utilizarse tal cual para el proyecto. Sin embargo, si no
tienen disponible un sistema adecuado, el equipo de dirección del proyecto
necesitará desarrollar uno como parte del proyecto.
Un proceso de cambio comienza con un requerimiento de cambio, conocido en

ocasiones como una Propuesta de Cambio de Ingeniería (PCI, Engineering
Change Proposal, ECP), que identifica la necesidad de cambio, la naturaleza
215
del cambio y el impacto del cambio. Este cambio se remite al núcleo de gestión
del cambio para que sea revisado y se disponga su aprobación o no (figura
5.14).
Figura 5.14: Proceso de control de cambios.
Los poderes y responsabilidades de dicho grupo deben estar bien definidos y

acordados por las principales entidades involucradas en el proyecto. El núcleo,
usualmente bajo responsabilidad del gestor del proyecto o su designado se
compone de representantes de cada área afectada por el desarrollo. Este
equipo se diseña para que todas las partes comprendan las consecuencias del
cambio antes de hacerlas. En proyectos grandes y complejos puede haber
múltiples grupos de control de cambios con diferentes responsabilidades.
Después de una revisión, el núcleo asegura que sólo los cambios aprobados
sean realizados de manera controlada y notificados a todas las partes
involucradas.
El sistema de control de cambios debe incluir también procedimientos para

realizar cambios que pueden ser aprobados sin una revisión previa, por
ejemplo, como resultado de emergencias. Generalmente, un sistema de control
de cambios permitirá la aceptación "automática" de determinados tipos de
cambios. Estos cambios deben ser documentados y organizados de forma que
no causen posteriormente problemas en el proyecto.
c.- Evaluación del proyecto
La evaluación del proyecto es el proceso de valorizar periódicamente del

estado del proyecto con relación a sus objetivos. Esto difiere del control del
proyecto en dos aspectos:
- El control del proyecto es responsabilidad del gestor del proyecto, la

evaluación es tarea de la dirección.
216
- El control del proyecto es un proceso continuo, mientras la evaluación es

periódica.
Las evaluaciones típicamente son realizadas en hitos importantes para

determinar cuando cambios mayores han surgido. Estos cambios pueden
incluir re-valorización de metas y objetivos, re-estructuración del plan o, aún
mas, cancelación del proyecto.
Por último, la evaluación del proyecto juega un rol importante en la complexión

del proyecto. En este caso, evalúa experiencia pasada y desarrolla las
lecciones aprendidas para beneficio de futuros proyectos.
5.3.4 Recursos humanos
a.- Motivación y construcción del equipo
El desarrollo y construcción del equipo es una labor cubierta por literatura de

ciencias y gestión del comportamiento (comportamiento organizacional,
psicología social) pero a menudo es muy ignorada en ambientes de desarrollo
informático.
Muchos gestores de proyectos tienden a enfocar su atención en los detalles

técnicos, ignorando que son personas las que programan y son personas las
que usarán una aplicación computacional.
Pensar así hoy en día es un gran riesgo, pues muchos proyectos fallan por mal
funcionamiento del equipo y no por problemas técnicos. Las personas saben su
trabajo, lo que saben es compartir con otros, especialmente por prestar poca
atención a las personas y los grupos.
La construcción del equipo es el proceso de transformar un grupo de individuos

de diferentes orígenes y formaciones en un grupo cohesivo de alto desempeño,
con una alta motivación y enfocados al logro de objetivos. Es un proceso que
requiere habilidades de liderazgo y una comprensión de los diversos factores
organizacionales que influyen en el trabajo en equipo y en las relaciones
humanas.
Así es necesario:
• Compartir la visión y el objetivo. Una visión compartida es esencial

para el éxito del proyecto, de hecho se le considera un factor de éxito.
Estar de acuerdo en la visión y en los objetivos ayuda a mantener el
equipo centrado y productivo. En estos casos, la toma de decisiones es
más efectiva y se evitan debates efímeros y que sólo consumen tiempo.
• Compromiso con el proyecto. El compromiso puede definirse como el
sentido de lealtad y dedicación al proyecto. Miembros comprometidos
desean dedicar su tiempo y energía y hacer sacrificios personales por el
proyecto.
La visión compartida es la base del compromiso. Sólo cuando las
217
personas comprenden y comparten una visión del proyecto, desean

comprometerse con el proyecto.
Gestores efectivos, trabajan duro para construir y afianzar el

compromiso. Buscan vías de crear posibilidades excitantes de conseguir
un proyecto exitoso. Crean ambientes de trabajo estimulantes,
generando retos de trabajo interesantes con oportunidades de
crecimiento personal. Involucran a las personas en la toma de
decisiones. Hacen visible el esfuerzo de cada persona informando del
progreso a cada miembro. Convierten a cada miembro en un activo del
proyecto.
• Fuerte sentido de identidad. Miembro de equipos efectivos sienten que
son especiales, diferentes de otros. Este sentimiento de identidad el
gestor de proyectos debe reforzarlo por todos sus medios a mano. Una
práctica común es usar símbolos visibles para mostrar la identidad
(distintivos en la ropa, las tazas de café, etc.) Probablemente la mejor
manera es crear un sitio donde los miembros compartan su trabajo.
Hitos de celebración, o la pizza con cerveza, son momentos de reforzar
el espíritu. Gestores exitosos crear y definen culturas en sus proyectos,
distintas del resto de la organización.
• Confianza mutua. Un equipo efectivo requiere colaboración entre los
miembros. La colaboración existe en climas de confianza. A mayor
confianza, el equipo compartirá mayor información, informará problemas
y tomará decisiones efectivas. Buenos gestores de proyecto crear y
nutren una atmósfera de confianza que a su vez construye y refuerza la
confidencialidad y el compromiso. La confianza solamente existe en
equipos hay valores de honestidad y franqueza, donde las personas son
tratadas con imparcialidad, respecto y dignidad.
• Miembros competentes. Gestores de proyecto efectivos reclutan
personas competentes, según las competencias que requiera el
proyecto. En este sentido no deben olvidarse que las habilidades de
colaboración para el trabajo efectivo con otras personas son tan
importantes que las habilidades y destrezas técnicas. Un gestor efectivo
continuamente evalúa a su equipo y siempre está dispuesto a cambiar o
reasignar personas con un desempeño inadecuado.
Los gestores de proyecto gestionan relaciones con el resto de la organización y

remueven obstáculos. Los miembros se motivan cuando ellos saben que la
dirección está comprometida con el proyecto y busca y provee los recursos
necesarios. Todo esto requiere habilidades de gestión superiores a las
técnicas, que incluso pueden carecer y/o desarrollar con el tiempo.
Entre las habilidades para construir un equipo, se cuenta:
- Evitar comprometer los objetivos del equipo con intereses políticos.
- Exhibir un compromiso personal a los objetivos del equipo.
- No diluir el esfuerzo del equipo con muchas prioridades.
218
- Ser equitativo e imparcial con todos los miembros.
- Estar predispuesto a enfrentar y resolver problemas asociados con el

desempeño inadecuado de miembros del equipo.
- Estar abierto a nuevas ideas e información proveniente de los miembros del

equipo.
b.- Resolución de conflictos
Los conflictos son parte de la vida diaria del proyecto. Ellos surgen desde
cualquier involucrado en el proyecto, tanto puede ser de un miembro del equipo
como de un cliente o promotor. De hecho, la fuente de conflictos es abundante.
La fuente más común es la competencia por los recursos escasos, las

diferencias respecto de los objetivos y los medios para conseguirlos, y
desacuerdos en costes, programación y tecnicismos. Por supuesto deben
añadirse los conflictos que surgen de la relaciones interpersonales.
Independiente de las causas, todo conflicto debe tratarse, identificando sus

motivos y orígenes, comprender sus causas y resolverlos de manera rápida.
Fallar al hacer esto puede seriamente alterar el proyecto y generar atrasos y
gastos excesivos.
5.4 Cierre
El cierre comprende dos procesos y, según el tamaño del proyecto, el volumen
de información manejado y/o el grado de desorden sostenido, el cierre puede
ser tan complejo y extensivo que puede considerarse un proyecto.
Además, en un proyecto e-Business cobra importancia el hecho que el cierre

es una etapa de recomendación y evaluación de lo aprendido.
5.4.1 Cierre administrativo
El proyecto o fase, después de lograr sus objetivos o estar terminado por otras
razones, requiere su cierre. El cierre administrativo consiste en la verificación y
documentación de los resultados del proyecto para formalizar la aceptación del
producto del proyecto por parte de los patrocinadores o clientes.
El cierre incluye la recopilación de todos los registros del proyecto, asegurando

que reflejan las especificaciones finales, así como el análisis del éxito y la
efectividad del proyecto y el archivo de esta información para su uso futuro. De
hecho es importante aprovechar esta información para promover un
aprendizaje.
Esto último no puede hacerse sin hacer una reflexión del trabajo realizado para
ver cuánto se ha aprendido, qué se pudo haber aprendido, el porqué de lo
errores, etc.
219
Además es importante conseguir las aprobaciones finales del trabajo realizado

y del producto entregado.
Es importante hacer notar que las actividades de cierre administrativo no deben

retrasarse hasta la terminación del proyecto. Cada fase del proyecto debe ser
apropiadamente cerrada para asegurar que no se pierde información útil e
importante.
5.4.2 Cierre de contratos
Es similar al cierre administrativo. Comprende la verificación del producto

(¿estaba todo el trabajo realizado de forma completa, correcta y satisfactoria?)
y el cierre administrativo (actualización de registros para reflejar los resultados
finales y el archivo de dicha información para su disponibilidad futura).
Los términos y condiciones del contrato pueden establecer unos

procedimientos específicos para el cierre del contrato.
Una terminación temprana del contrato es un caso especial de cierre del

contrato.
5.5 Cuadro resumen de las etapas de

un proyecto
Fase de planificación. Se trata de establecer cómo el equipo de trabajo deberá satisfacer las
restricciones de prestaciones, planificación temporal y coste. Una planificación detallada da
consistencia al proyecto y evita sorpresas que nunca son bien recibidas.
Fase de ejecución. Representa el conjunto de tareas y actividades que suponen la realización

propiamente dicha del proyecto, la ejecución de la obra de que se trate. Responde, ante todo, a
las características técnicas específicas de cada tipo de proyecto y supone poner en juego y
gestionar los recursos en la forma adecuada para desarrollar la obra en cuestión. Cada tipo de
proyecto responde en este punto a su tecnología propia, que es generalmente bien conocida
por los técnicos en la materia.
Fase de entrega o puesta en marcha. Como ya se ha dicho, todo proyecto está destinado a
finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la
puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y
responde a las especificaciones en su momento aprobadas. Esta fase es también muy
importante no sólo por representar la culminación de la operación sino por las dificultades que
suele presentar en la práctica, alargándose excesivamente y provocando retrasos y costes
imprevistos.
A estas tres grandes etapas es conveniente añadir otras dos que, si bien pueden incluirse en
las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un
conjunto de actividades que resultan básicas para el desarrollo del proyecto
Fase de iniciación. Definición de los objetivos del proyecto y de los recursos necesarios para
su ejecución. Las características del proyecto implican la necesidad de una fase o etapa previa
destinada a la preparación del mismo, fase que tienen una gran trascendencia para la buena
marcha del proyecto y que deberá ser especialmente cuidada. Una gran parte del éxito o el
fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una
220
buena etapa de planificación, algunas personas tienden a menospreciar, deseosas por querer
ver resultados excesivamente pronto.
Fase de control. Monitorización del trabajo realizado analizando cómo el progreso difiere de lo
planificado e iniciando las acciones correctivas que sean necesarias. Incluye también el
liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso
subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.
Los periodos generales de duración los podemos ver a continuación:
Figura 5.15: Curvas de procesos.
Bibliografía
[1] BARBER, JEAN MARIE. (1996). Elaboração de projectos de Acçao e
Planificação. Portugal: Porto Editora. 231 pp.
[2] BLASCO, JAUME. (2000). Los artefactos y sus proyectos. POLITEXT Àrea
d'Enginyeria Mecánica. Barcelona-España: Edicions UPC, 399 pp.
[3] BACCARINI, DAVID. (1999). The Logical Framework Method for Defining
Project Sucess. Project Management Journal, 30(4):25-32. Diciembre.
[4] CLAUSEWITZ, KARL VON. (1992). De la guerra. Barcelona-España:

Editorial Labor, 304 pp.
[5] DAHLBOM, BO; Y, MATHIASSEN, LARS. (1995). Computers in Context.

The Philosophical and Practice of Systems Design. NCC Blackwell. 306 pp.
[6] DAVIS, GORDON, B.; GORGONE, JOHN T.; COUGER, J. DANIEL;

FEINSTEIN, DAVID L.; y LONGENEKER, HERBERT E. (1997). IS 97 Model
Curriculum and Guidelines for Undergraduate Degree in Information Systems.
ACM-AISAITP.
221
[7] DELONG, DAVID; DAVENPORT, TOM; AND BEERS, MIKE. (1997). What
is Knowledge Management Project?. Ernst & Young. Working paper
(17/2/1997). 7 pp.
[8] GIBBS, W. WAYT. (1997). Software's Chronic Crisis. En Thayer, H. (1997).

Software Engineering. Project Management. IEEE Computer Society. 529 pp.
20-28 pp.
[9] GLASS, ROBERT L. (1998). Software Runaways. Lessons Learned from

Massive Software Project Failures. Prentice Hall. 259 pp.
[10] GLASS, ROBERT L. (1999). Computing calamities. Lessons learned from

product, projects, and companies that failed. Prentice Hall. 302 pp.
[11] GÓMEZ-SENENT, ELISEO; CHINER, MERCEDEZ; CAPUZ RIZO,

SALVADOR; ARÁGONES, PABLO; y SANTAMARÍA, JOSÉ LUIS (1996).
¿Teoría de las Dimensiones del Proyecto?. En AEIPRO. (1996). Proceedings III
International Congress of Project Engineering. Septiembre 12-14. pp. 104-113.
Barcelona, España.
[12] GORGONE, JOHN; y GRAY, PAUL (eds.) (2000). Model Curriculum and
Guidelines for Graduate Degree Programs in Information Systems (MSIS).
ACM-AIS.
[13] HORNBY, A. S. (1974). Oxford Advanced Learn's Dictionary of Curren

English. Oxford University Press. 1055 pp.
[14] IEC. (1995). Diccionari de la Llengua Catalana. Intitut d'Estudis Catalans.

Enciclopèdia Catalana, S.A. i Editorial 62, S. A. Publicacions de L'Abadia de
Montserrat, S. A. 1908 pp.
[15] IIVARI, JUHANI: y LYYTINEN, KALLE. (1997). Research on Information

System Development in Scandinavia: Unity in Plurality. En Currie, Wendy L.; y
Galliers, Bob. (1997). Rethinking Management Information Systems. Oxford.
510 pp. 57-102 pp.
[16] ISPMI. (1998). The Changing Role of Project Management in IS/IT. IS SIG
PM Newsletters. September.
[17] JONES, CAPERS. (2000). How the Internet Reduced Y2K Damages. PM
Network. 14(7): 33-35. July.
[18] KEHOE, RAYMOND; y JARVIS, ALKA. (1995). ISO 9000-3. A tool for
Software Product and Process Improvement. Springer. 229 pp.
[19] KEIL, M.; y MIXON, R. (1994). Understanding runaway IT project:

preliminary results from a program of research based on escalation theory.
Proceedings of the Twenty-Seventh Hawaii International Conference on
Systems Science, 3:469- 478.
222
[20] KEIL, M.; Y, MANN, J. (1997). Understanding the nature and extent of IS
projects escalation: results from a survey of IS audit and control professionals.
Proceedings of the Thirtieth Hawaii International Conference on Systems
Science, 3:139- 148.
[21] KERZNER, H. (1989). Project Management. Third Edition, New York: Van
Nostrand Reinhold.
[22] KRASNER, HERB. (2000). Ensuring e-Business Success by Learning from

ERP Failures. IT Pro:22-27. January-February.
[23] KLIEM, RAPHL. (1999). Is History Destined to Repeat Itself. PM Network,

13 (11):25-26. November.
[24] MCCONNELL, STEVE. (1997). Desarrollo y gestión de proyectos

informáticos. España: McGraw-Hill. 691 pp.
[25] MCKAY, JUDY; Y, MARSHALL, PETER. (1999). A Framework for Rigour in

Action Research. Americas Conference on Information Systems. Milwaukee,
WI. August 13-15.
[26] MCKENNA. (1999). Transformar su negocio en e-Business. Como generar

valor añadido con e-Business. Estudio de McKenna Group e IBM. 6 pp.
[27] MINTZBERG, HENRY. (1992). La Estructuración de las Organizaciones.

Barcelona-España: ARIEL. 561 pp.
[28] MYERS, MICHAEL D. (1997). Qualitative Research in Information

Systems. ISWorld Net.
[29] NEUMANN, PETER G. (1993). System development woes.

Communications of the ACM, 36(10):146.
[30] PASTOR, JOAN A. (1990). Memoria presentada para optar a profesor

Titular de Escuela Universitaria. Departament de Llenguatges i Sistemes
Informàtics. Universitat Politécnica de Catalunya. Barcelona, Catalunya,
España. Abril.
[31] PMI. (2000). Project Management Institute PMBOK Guide. A Guide to the
Project Management Body of Knowledge.
[32] PURBA, SANJIV; SAWH, DAVID; y SHAH, BHARAT. (1995). How to

Manage a Successful Software Project. Methodologies, Techniques, Tools.
John Wiley & Sons. 370 pp.
[33] RAE. (1992). Diccionario de la Real Academia de la Lengua Española.

Madrid-España.
[34] RAMÍREZ, CARLOS; RECABARREN, MARGOT, y PALMA, ALFREDO.

(1988). Manual de Capacitación Pedagógica. Instituto Hidrográfico. Chile.
223
[35] REDMILL, FELIX. (1997). Software Projects. Evolutionary vs. Big Bang
Delivery. Wiley. 254 pp.
[36] ROBINSON, ANNE G.; y DILTS, DAVID. (1999). OR & ERP. A Match for
the New Millenium. ORMS Today, 26(3):30-35.
[37] SANTAMARÍA, JOSÉ LUIS; GÓMEZ-SENENT, ELISEO; y CHINER,

MERCEDEZ. (1996). Tendencias y enunciados para una teoría del proyecto.
En AEIPRO. Proceedings III International Congress of Project Engineering.
Barcelona-España. Septiembre 12-14. pp. 114-123.
[38] SOFTWARE PROJECT MANAGEMENT: An Integrated Perspective for

Emerging Paradigm. En Zmud, Robert W. y Price, Michael F. Framing the
Domains of IT Management: Projecting the Future Through the Past.
[39] SOMMERVILE, IAN. (1996). Software Engineering. Addison-Wesley.
[40] STEINER, PHYLLIS A. (1999). Let's Use Project Management for IT

Infrastructure Projects. IS SIG Newsletters. April.
[41] THAYER (ed.) (1985). Software Engineering Project Management. IEEE

Computer Society. 529 pp.
[42] TOMAYKO, JAMES E.; y HALLMAN, HARVEY K. (1989). Software Project

Management. SEI Curriculum Module SEICM-21-1.0. Software Engineering
Institute. Carnegie Mellon University. July. 30. pp.
[43] WARD, LEROY. Transforming IT Project Managers into Business Leaders.

PM Network, 13 (11):29-33. November.
[44] YOUNG, ALLEN. (2000). Reflection on Y2K. PM Network, 14(7): 37-41.

July.
[45] YOURDON, EDWARD. (1996). Rise & Resurrection of the American

Programmer. Yourdon Press. 318 pp.
[46] YOURDON, EDWARD. (1997). Death March. The Complete Software's

Developer's Guide to Surviving "Mission Impossible" Projects. Prentice Hall.
218 pp.
224

Dirección y Gestión de Proyectos e

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dirección y Gestión de Proyectos e

Cargado por

Copyright:

Formatos disponibles

COSIM TI – CAPACITACION PROFESIONAL – BIBLIOTECA VIRTUAL

- Comprender la noción de proyecto.

- Conocer y comprender las dimensiones de un proyecto informático

- Reconocer la importancia de una Teoría de Proyectos.

- Comprender la complejidad de un proyecto e-Business desde una perspectiva teórica.

Figura 1.1: Proyecto e-Business.

Para comprender esta definición, es necesario presentar varios conceptos

1.2 Proyectos: una visión teórica

Para llegar a entender lo que es un proyecto cualquiera, resulta conveniente

Un proyecto siempre da lugar a una solución. Esta solución tiene varias

• Es habitualmente injertada en la misma organización que la requirió, por

Proyecto, desde un punto de vista más concreto, se concibe como una

• Persecución de uno o varios objetivos. Las actividades aisladas no

• Tener objetivos específicos;

Las acepciones previas pueden considerarse extremas dentro de un amplio

Esta pregunta ha llevado a diversas definiciones, o más bien, formas en que se

- Es un esfuerzo conjunto de muchas personas -hombres y mujeres- que

- El proyecto es una operación que se expresa como una experiencia práctica

- se usan conceptos abstractos (por estar en dominios de conocimiento

- Es el conjunto de acciones destinadas a resolver o vulnerar un problema ya

- Es un conjunto autónomo de inversiones, políticas y medidas institucionales y

- Es un proceso para obtener recursos, destinado a convertir una idea surgida

- Es un conjunto específico de actividades en las que se invierten escasos

- Es el conjunto de acciones o actividades que se realiza a partir de una

- Es la unidad operativa más pequeña que puede ser ejecutada en forma

- Es una información estructurada con valor agregado que permite la

- Es una empresa planificada con un conjunto de actividades para alcanzar un

- Es un proceso cuyo objetivo es transformar una idea en un producto

- Es un proceso finito, es decir, que se cuenta con un período de tiempo

- Cuenta con un presupuesto preestablecido para alcanzar el objetivo.

- Es un conjunto no vacío de tareas estructuradas, que se desarrollan en un

- Es un proceso único, consistente en un conjunto de actividades controladas,

- El proyecto es una operación de ingeniería que involucra pasar de un sistema

- ir de una idea inmaterial y difusa proveniente de un problema o necesidad a

• Proyecto como producción de artefactos; y,

Figura 1.2: Atributos principales asociados a la definición de proyecto.

Figura 1.3: Generalización del concepto de Proyecto.

Un proyecto se comprende habitualmente como un medio para obtener un

- Proyecto como programa a seguir. En este caso el 'proyecto' es

- Proyecto (según el Diccionario de la Lengua Española de la Real Academia

"Planta y disposición que se forma para un tratado, o para la ejecución de una

- Projecte, según el Diccionari de la Llengua Catalana del Intitut d'Estudis

- Project (según el Diccionario Oxford):

"Hacer planes para ('Make plans for')".

- Proyecto como consecución de objetivos. En este caso el 'proyecto' es

"Un proyecto es una secuencia única de actividades complejas e

un plazo establecido, dentro de un presupuesto y de acuerdo con unas

- Según el Project Management Institute:

"Un proyecto es un esfuerzo temporario realizado para crear un producto,

"Ensamblaje de recursos para solucionar un problema de un determinado tipo

En un proyecto de acción el fin no es producir un artefacto, sino encontrarlo y

- Proyecto, para Blasco, es:

"La operación de ingeniería que nos lleva a conseguir un objetivo material

- Para Dahlbom y Mathiassen, proyecto es una acción donde se:

- se interviene, debido al cambio en el entorno que se produce por la propia

- se evoluciona, debido a buscar la solución de un problema que no es fijo ni

- se construye, por desarrollar una solución técnica que es la respuesta a un

1.2.2 Tipología de proyectos

Las visiones previas muestran que un proyecto involucra dos proyectos de

La tipología general aquí presentada utiliza criterios de distinción:

• Por objeto, o por el objeto que esta tratando el proyecto;

1.2.2.1 Taxonomía de proyectos

Debe aclararse que estos criterios ni son todos ni son determinantes.