Arquitectura Empresarial U2

Arquitectura Empresarial | Unidad 2.
Introducción
Apreciados estudiantes: reciban una cordial bienvenida a la Unidad 2, en la cual se desarrollarán temas
relacionados con la construcción y la manera como se conforma la Arquitectura Empresarial , enlazando
al estudiante en las temáticas de procesos de negocio, análisis de brechas, priorización de proyectos y
cadena de valor de la empresa.
A lo largo de esta unidad se pretende dar a conocer la problemática que se presenta en la actualidad en la
construcción de soluciones sistematizadas e informáticas en el ámbito organizacional, con requisitos de
eficiencia, eficacia, seguridad y calidad. De acuerdo con lo anterior, en el tema 1 se abordarán los procesos
de negocio en el marco de una arquitectura de negocio (estado AS_IS y estado YO_BE); en el tema 2 el
análisis de brecha, la definición y priorización de proyectos, y en el tema 3 la cadena de valor de una
empresa, la taxonomía de procesos de negocio y el papel que juega cada tipo de proceso dentro de la
organización, así como el impacto de los procesos en la organización con el fin de manejar diseño de
arquitectura de alta calidad. De esta forma se parte de dar claridad sobre la manera como se tiene que
integrar la Arquitectura Empresarial a nivel estratégico, de información, de aplicaciones y de tecnología.
Los invito a que trabajen esta unidad con la mejor actitud, ya que las temáticas que se desarrollarán son
de gran relevancia en la actualidad. ¡Muchos éxitos en el proceso de aprendizaje de esta unidad, y no
olviden que estaré atento a cualquier inquietud que les pueda surgir!
Universidad Cooperativa de Colombia 1

1. Los procesos de negocio en el marco

de una arquitectura de negocio: el
estado AS-IS y el estado TO-BE
1.1 Definición de procesos
Un proceso de negocio es una secuencia de actividades que son realizadas en serie o en paralelo por dos o
más individuos o aplicaciones informáticas, con el fin de lograr un objetivo común. Hoy en día las empresas
se manejan por medio de procesos, pues todas sus actividades están ligadas a estos, por lo cual juegan un
papel muy importante.
No se consideran procesos de negocios aquellas actividades aisladas o realizadas por menos de dos actores,
como por ejemplo: un workflow ad hoc, o la ejecución de una transacción financiera por sí sola. Todos los
procesos de la organización son importantes porque forman parte de la visión “interfuncional” de los
procesos (cross-functional), en la que, en un determinado momento, las conexiones entre ellos permiten
lograr la visión unificada de la actividad empresarial. El fin último es “alcanzar” los objetivos estratégicos
de negocio. Los procesos individuales poseen sus propias metas y objetivos, que deben estar alineados con
sus homólogos y por consiguiente tienen por base la estrategia empresarial previamente definida.
1.2 Definición de Business Process

Management
Business Process Management (BPM) —o Gestión de Procesos de Negocio— es una disciplina para la
modelización, automatización, gestión y optimización de un proceso de negocio a través de su ciclo de vida
con el fin de obtener el incremento de su rentabilidad (Khan, 2004). Se trata del logro de unos objetivos
organizativos por medio de la mejora, gestión y control de los procesos de negocios esenciales (Jeston y
Nelis, 2005). Es el arte de mejorar de forma incansable los procesos de negocios de una organización
(Menezes y Gonz[alez Ladrón de Guevara, 2008).

En algunos sectores, los procesos de negocio flexibles y efectivos son una condición crítica para la
permanencia en el mercado. En la actualidad pueden extenderse más allá de los límites de la organización,
pasando a existir en un entorno de e-commerce o e-business por ejemplo, la participación directa de
proveedores, clientes, colaboradores y agentes externos (organismos controladores y sociales) que
interactúan dentro de la cadena de valor, a través del uso de las TIC. De esa manera, la visibilidad de los
procesos va de un extremo a otro en la cadena de valor (end-to-end) y exige mayor agilidad, visión unificada
y entendimiento dentro de una visión interfuncional o interorganizacional.
El rol del modelado de procesos de negocio es permitir tanto la visión de los procesos en los diferentes
niveles (estratégico, táctico y operacional), como la identificación de las necesidades de optimización de
los procesos en estos niveles. La disciplina de Gestión de Procesos de Negocio busca lograr un verdadero
enfoque de procesos en la gestión empresarial, llegando a proponer alternativas para la automatización de
los procesos de la empresa.
1.3 Modelado de los Procesos de Negocio

Los modelos son representaciones o abstracciones de algún asunto u objeto de estudio. Las maquetas de
un complejo hotelero, o los planos de un arquitecto son un ejemplo de modelos. Generalmente en los
modelos se usan símbolos que representan los conceptos que se están analizando y representando. En
resumen, las características de un modelo son:
 Subraya las facetas importantes de lo que pretende representar evitando redundancias, pudiendo
adoptar un enfoque progresivo para añadir un cierto nivel de detalle.
 Es más comprensible, conveniente, y tiene un menor coste representar los objetos manipulados del
mundo real por medio de un modelo. Además, permite la simulación de sistemas (por ejemplo un
workflow) sin necesidad de implementarlo.
 Contempla tanto la representación gráfica como la creación de casos de uso, en los cuales se define
un contexto para la simulación del modelo en cuestión mediante parámetros de un determinado
escenario del caso de uso.
 Permite establecer el control sobre los datos y la información que se manipulan de manera
estructurada o no, con el fin de proveer las bases para la automatización de un determinado
proceso modelado.

El modelado de procesos abarca tres fases orientadas a transmitir la información de este “sistema
nervioso” dentro de la arquitectura de procesos de la organización, con el objetivo de lograr los resultados
previamente definidos en la fase de la estrategia de negocios (analizada en la unidad 1). Estas fases son:
 Identificación de las relaciones entre los procesos y los objetivos estratégicos del negocio.
 Creación de un mapa de procesos con la visión global de todos los macroprocesos que contribuyen
a lograr dichos objetivos.
 Definición del proceso con su mayor nivel de granularidad, dentro de unos límites de objetividad y
comprensión que permitan desglosar las actividades, los flujos en serie o paralelo, las reglas de
negocio, los roles, el comportamiento del flujo, los indicadores de proceso, los tiempos y la
estructura de datos.
En estas tres etapas, el modelado de proceso juega un rol importante a la hora de optimizar procesos de
negocio alineados con la estrategia, ya que la habilidad de los arquitectos del proceso permite establecer
una base óptima para la mejora continua dentro del concepto del ciclo de vida de un proceso. El modelado
de procesos siempre va directamente relacionado con la definición del workflow y la TI. Además, casi
siempre un objetivo primordial del modelado de procesos es establecer las bases para su automatización.
Así que la TI, los procesos, el workflow y el modelado están íntimamente relacionados: aunque no siempre
el resultado del modelado de procesos sea su automatización, esta debería ser un objetivo del modelado
de procesos. Un propósito típico de un modelo de proceso de negocio es describir cómo deben —o
deberían— ser realizadas las cosas en contraste con el
proceso en su entorno real.
El modelado de procesos presenta las etapas de

megaprocesos, procesos interfuncionales y modelo de
procesos ya mencionadas. En esta figura se pone de
manifiesto el planteamiento sistémico al considerar la
retroalimentación de la estrategia y los procesos. Durante
la fase de modelado se descubren necesidades estratégicas
de mejora que pueden suponer incluso una revisión de la
estrategia de negocio. La figura 1 muestra la relación entre
el modelado de procesos, la estrategia de negocio y la Figura 1. Modelo de la estrategia interrelacionada
con el modelado de procesos (en diferentes
niveles) y la automatización de los procesos /
Fuente: elaboración propia

optimización de los procesos que juega un papel importante en la actualidad.
El hecho de que el modelo de los procesos se enlace con la propuesta de automatización se muestra
mediante un ciclo integrado denominado “ciclo de vida de los procesos”, ambos relacionados con los
modelos de proceso de Nivel 3, que son los modelos ya definidos con una granularidad reducida y con el
nivel de detalle óptimo que permita generar, a través de la automatización, toda la gestión de las
actividades que involucren personas y sistemas.
1.4 Definición de workflow

El workflow se puede definir como el flujo de trabajo a seguir para realizar una tarea o un trabajo
predeterminado, de forma que el workflow general de una empresa presenta las actividades a realizar, los
tiempos y la organización de estas. El objetivo del modelado de procesos es descubrir el flujo óptimo de un
proceso de extremo a extremo (end-to-end), identificando los actores que interactúan para lograr un
objetivo común. En la actualidad se dispone de tecnologías que permiten una perspectiva del workflow de
acuerdo con una visión de procesos. La información sobre el workflow evoluciona hacia la dimensión de
los procesos y el trabajo desarrollado en la disciplina de modelado de procesos que camina hacia el mismo
objetivo: definir procesos de negocios con su workflow, y además definir explícitamente:
 Su representación gráfica: mapa de procesos y diagramas de proceso.

 Roles: diferentes actores que interactúan en el proceso, incluyendo los sistemas de información.
 Reglas de negocio: en forma de control de excepciones, o independientes de los procesos.
 Arquitectura de datos: como vemos, dicha visión del modelado de procesos va más allá de la simple
representación gráfica de un determinado modelo, vista la necesidad de conocer previamente
cualquier iniciativa de automatización —una serie de elementos de la modelización— para que esta
tenga un objetivo concreto.
1.5 Arquitectura de proceso

1.5.1 Definición de procesos estratégicos
Dentro de la arquitectura de procesos de una organización se requiere una visión de estos en diferentes
dimensiones: la estratégica, la táctica y la operacional. El proceso de análisis del negocio se realiza
mediante la comprensión de las diferentes facetas de este dentro de la cadena de valor. Todas las

actividades relativas a la definición de la estrategia de negocio afectan el diseño del macromodelo del
negocio, y muestran las limitaciones y oportunidades de mejora en las interacciones internas y externas
dentro de dicha cadena. El diseño del megaproceso permite la visión global (en una única hoja) del negocio,
para que la alta dirección de la empresa tome las decisiones idóneas que permitan definir y considerar
tanto el modelo de negocio como las oportunidades de mejora estratégica de los procesos.
Las actividades involucradas en esta etapa contemplan la realización de lo que se define como auditoría de
procesos, en la cual la organización estudia el negocio en el contexto de la cadena de valor bajo la
perspectiva de procesos identificando los “vacíos” que existen en las interacciones entre procesos que se
convierten en objeto de la mejora. El resultado de esa auditoría es un mapa de sistemas que permite
establecer las relaciones y los puntos críticos del megaproceso.
1.5.2 Auditoría de procesos

La función primordial de la auditoría de procesos es proporcionar elementos de análisis en un contexto
global que permitan identificar el funcionamiento de la organización como resultado de su interacción con
los clientes, proveedores, otros agentes externos, y también en el ámbito interno.
Esta no es una actividad sencilla de realizar por varias razones: la primera de ellas es que una organización
típica posee muchos procesos y cuando se realiza la auditoría es imposible analizar todos ellos para
determinar sus debilidades, amenazas, fortalezas y oportunidades (DAFO); la segunda razón es que muchas
organizaciones son dirigidas con una perspectiva funcional, lo que origina una visión aislada de los
diferentes departamentos. Dicha perspectiva cambia según el nivel de adopción de tecnologías que
emplean la visión interfuncional, pero lo que se pretende enfatizar con este concepto es que —en muchas
ocasiones— las personas están adoptando un punto de vista funcional que dificulta los esfuerzos de
comprensión del impacto de los diferentes procesos departamentales entre sí.
Otra cuestión clave que dificulta la realización de la auditoría de procesos está en que muchas veces las
personas tienden a ver solamente el lado negativo de los procesos, insistiendo en la burocracia excesiva, o
que son efectivamente mal gestionados. Esa visión es importante, pero además se requiere que las
personas sepan identificar los puntos fuertes de los procesos por pequeños que estos sean. Conviene

además que ningún proceso dentro de la organización sea considerado trivial: puede darse alguna situación
en que el resto de los procesos dependan de la respuesta proporcionada por este.
1.5.3 Mapa de sistemas

Un mapa de sistema posee unas características que le permiten modelar procesos y sus interacciones en
el entorno de la cadena de valor de la empresa (Nivel 1). Dispone de los siguientes elementos
identificadores:
 P = Procesos.
 D = Departamento.
 C = Compañía.
 I = Industria.
Estos actores interactúan entre sí dentro de los límites internos de la empresa y en el entorno de la cadena
de valor. Cualquier proceso posee clientes internos que intervienen y matizan las relaciones entre
departamentos. Las técnicas del mapa de sistema recomiendan analizar las relaciones clave entre
departamentos y considerarlas críticas para establecer un mecanismo de retroalimentación interno a lo
largo de toda la cadena. No todas las organizaciones tendrán las mismas interrelaciones clave, por ejemplo
una compañía de seguros puede considerar el Departamento de Altas de Pólizas/ventas y el Departamento
de Quejas y Reclamos como los más importantes, mientras que una empresa que personaliza sus productos
y servicios al cliente puede considerar las relaciones entre los Departamentos de Ventas y Producción como
las más relevantes. Las áreas de soporte de la empresa (Calidad, R.R.H.H., TI y Finanzas) y los procesos de
negocios clave deberían ser objeto de estudio por medio de los mapas de procesos para determinar si
realmente estos departamentos cumplen sus funciones de soporte y colaboran con la estrategia
empresarial.
En los últimos años muchas empresas se han dado cuenta de la importancia que los “clientes y proveedores
internos” tienen a la hora de cumplir misiones empresariales; por ello, en muchos casos se crean unidades
de negocios que explotan sus capacidades tanto para satisfacer las necesidades internas como para facilitar
los servicios externos. Un ejemplo de ello es la empresa de informática constituida por el Corte Inglés, que
ofrece soluciones de TI al mercado, además de atender y dar soporte a toda la demanda de TI interna del
grupo.
Como se puede observar en la figura 2, el objetivo fundamental de un mapa de sistemas es identificar los
vacíos (“brechas”) y las deficiencias que son limitaciones que se traducen en oportunidades para ajustar u
optimizar procesos estratégicos de la empresa. Típicamente esas brechas aparecen como outputs y se
reflejan en factores que afectan el coste, servicio, velocidad, puntualidad, amabilidad, honestidad, entre
otras formas. La empresa identifica esas brechas por medio de los clientes que manifiestan (de forma
retroactiva) directa o indirectamente sus sensaciones sobre el cumplimiento de especificaciones y
expectativas, tal y como la empresa hace en las relaciones con sus proveedores. El mecanismo de
retroalimentación puede ser formal o informal. El mecanismo formal normalmente se inicia por iniciativa
de la empresa por medio de encuestas, entrevistas o visitas al cliente. La mecánica informal es fruto de la
interacción cotidiana con el cliente por medio de llamadas telefónicas, correos electrónicos o contactos
personales. Ambos mecanismos (formal e informal) deben ser tenidos en cuenta y la empresa debe ser
proactiva a la hora de conseguir información que le permita evaluar los megaprocesos, pues muchas veces
la pérdida de un cliente se puede originar por no comprender y valorar sus inquietudes aunque estas sean
expresadas de manera informal.
La figura 2 muestra un ejemplo de un mapa de sistemas. Para entender cómo usarlo y cuál es su aplicación,
se puede considerar la siguiente situación: una organización empieza un proyecto de mejora estratégica
de sus procesos de negocio y necesita un enfoque
de procesos desde las etapas del desarrollo de la
estrategia. En este caso, la empresa debe buscar
la visión global de sus procesos clave en la cadena
de valor, para luego identificar las distintas
interacciones y los gaps, que pueden ser
traducidos como las deficiencias y oportunidades
de mejora en el contexto de procesos. En las
diferentes dimensiones de las interacciones en la
cadena de valor, la organización debe identificar
vía mecanismos de feedback, el efecto de dicho
Figura 2. Ejemplo de mapa de sistemas /Fuente: elaboración propia
contexto sobre el resultado de los diferentes
procesos contrastados con los P/D/O/S, que son: Procesos, Departamentos, Organización y Sector. Al

mismo tiempo, se deben entender las interacciones internas de la organización, con el objetivo de
identificar de qué manera los diferentes departamentos sirven apropiadamente a los demás,
contemplándolos bajo el enfoque de clientes y proveedores internos.
Una vez mencionado que el enfoque de procesos interfuncionales es el primer paso y la base para el
análisis, la organización debe identificar aquellos procesos de importancia estratégica con miras a detectar
deficiencias que deban ser subsanadas, ya que es muy arriesgado intentar desarrollar iniciativas en todos
los procesos de manera simultánea. Todos los procesos organizativos y de negocio son importantes y deben
ser tratados, pero la necesidad de escalar la iniciativa de mejora y automatización también es fundamental.
Como se mencionó antes, el mapa de sistemas es la big picture en la que se apoyan los analistas de
estrategia para realizar el análisis DAFO, porque da la visión preliminar de los diferentes procesos y sus
interacciones (objetos de análisis). El mapa de sistemas se desarrolla de forma simultánea con el análisis
DAFO y es utilizado en las etapas siguientes al modelado de procesos como mecanismo recurrente
(feedback) para confirmar la dirección de los esfuerzos de mapeado y modelización de los procesos.
1.6 Procesos interfuncionales

La visión interfuncional de los procesos (cross-functional) es la base para el entendimiento de las
interrelaciones entre departamentos, agentes externos, clientes y proveedores. La organización identifica
aquellos procesos clave que suponen un impacto estratégico en los objetivos de negocio como forma de
guiar los pasos de la mejora de procesos.
Normalmente, cuando se identifican los procesos dentro de una perspectiva “extremo a extremo”, las
personas —como actores de los procesos departamentales— tienden a dar una visión negativa de estos
como señal de que estos no funcionan o requieren un cambio radical, o incluso considerar otro
departamento como el causante de la lentitud y los retrasos en las interacciones internas y externas. La
visión negativa puede ser un aliado para identificar los procesos candidatos a ser tratados de manera
prioritaria teniendo en cuenta su significado estratégico; no obstante, es importante identificar las
fortalezas de los procesos para no correr el riesgo de quedarse con los puntos negativos y perder de vista
una oportunidad de mantener una ventaja estratégica a partir de los procesos clave.

1.6.1 Mapa de procesos

Desde hace mucho tiempo, el enfoque tradicional de la mejora de los procesos ha sido la suma de la
contribución de cada Departamento para reducir los tiempos de los diferentes ciclos. La idea principal era
que si cada Departamento redujera su parte de tiempo, los tiempos totales se reducirían dramáticamente.
En la actualidad, se ha extendido la idea de que el enfoque debe ser integrado, y las perspectivas de gestión
—como la teoría de las restricciones o el Business Process Management— exigen dicho enfoque. Otras
filosofías y herramientas están orientadas a la mejora incremental y sectorizada de los procesos, como por
ejemplo el TQM y el más reciente Six Sigma.
Los mapas de procesos son distintos a los diagramas de flujo tradicionales precisamente por su carácter
interfuncional. Se trata de una herramienta eficaz para identificar los diferentes procesos
interrelacionándolos, con el fin de obtener una visión real de estas relaciones. Una característica
importante del perfil del directivo responsable de un Departamento en una organización es su capacidad
de gestionar las interacciones en vez de las acciones, porque es ahí donde casi siempre se encuentran los
puntos críticos para la mejora constante de los procesos de extremo a extremo.
El mapa de procesos siempre considera su extensión hacia la cadena de valor, en la cual los clientes
manifiestan necesidades, los proveedores suministran materiales o servicios y la organización pone en el
mercado productos y servicios. El concepto de extensión de procesos también puede ser entendido desde
la lógica mediante la cual un proveedor pasa a realizar actividades clave en el proceso productivo —como
por ejemplo el montaje de componentes que antes se realizaría internamente— lo que se debe tener en
cuenta al estudiar los gaps que puedan existir, con posibilidad de extender los procesos tanto externa como
internamente, como sería el caso si se detectan mayores ventajas potenciales en volver a montar
componentes internamente. Dado que el entorno actual de los negocios es dinámico y cambiante, el
enfoque de procesos debe ayudar a comprender y actuar en función de la realidad de cada momento en
la mejora de procesos.
1.6.2 Modelado de procesos

Según lo visto hasta el momento, los procesos pueden ser descritos o diseñados en diferentes niveles. Un
mapa de sistemas es una visión global de la organización que orienta el 2do. y 3er. nivel. El 2do. nivel, el
mapa de procesos, es la big picture de los procesos desde la perspectiva interfuncional, y lo que se define
como modelo de procesos son esos procesos visto desde “arriba” a través del mapa de procesos elevados
a determinado nivel de detalle. Los criterios a seguir para elevar el nivel de detalle implican algunas
consideraciones básicas que incluyen: una identificación sencilla de los procesos, la definición del alcance,
y, por consiguiente, el mapeado del workflow aumentando su nivel de detalle.
Para definir los modelos de procesos es necesario, por un lado, conocer dichos procesos en lo que se
definirá como procesos AS-IS (el proceso tal como es), para luego, sobre este modelo, obtener lo que se
define como procesos TO-BE (procesos mejorados futuros). Esta etapa es bastante compleja y difícil ya que
los procesos no son “evidentes” y siempre están “ocultos” en la estructura organizacional, organigrama,
departamento y sistemas. No sería sorprendente encontrar que la empresa no logre modelizar sus
procesos y que —en algunos casos— los propios clientes tengan más facilidad en definir los procesos que
la propia organización, ya que el cliente sabe qué resultado espera de un servicio o del proceso de entrega
de un servicio o producto. Así que la definición de un proceso siempre empieza por la búsqueda del
“cliente”, el objetivo principal que motiva la realización de diferentes actividades que confirman un
proceso, con miras a descubrirlo y definirlo. A continuación se profundiza un poco más en estas técnicas
buscando una visión general de ellas.
1.6.3 Modelado de Procesos ( AS-IS Processes)

Para describir los procesos, lo primero que se debe hacer es identificarlos correctamente. Como se
mencionó antes, la característica oculta o intrínseca de los procesos dentro de los complejos sistemas en
la organización dificulta su identificación, pudiendo derivar en una mala definición y sus consecuencias
asociadas. Para identificar los procesos correctamente tal y como son (AS-IS,) se emplea una visión
partiendo de la base y subiendo hasta que se identifican niveles de detalles satisfactorios que permitan su
completa definición. Los participantes definen actividades, aplican técnicas colaborativas para su
definición, hasta que conforman el proceso objeto. El alcance queda más claro cuando se identifican los
procesos relacionados que no están dentro del alcance representado sobre el mapa de procesos.

Cuando se estudia el estado actual de los procesos, estos deben estar claramente definidos durante el
análisis AS-IS. La identificación preliminar de esos procesos debe incluir los siguientes datos:
 Nombre del proceso utilizando un formato verbo-nombre.

 Evento que “dispara” (origina) el proceso de negocio.
 Resultado(s) logrado(s) por el proceso.
 Cliente que recibe el resultado.
 Definición de cinco a siete actividades importantes (o pasos) dentro del proceso.
 Actores con un rol en el proceso.
 Mecanismos que soportan el proceso (sistemas, formularios y equipos, entre otros).
 Tiempos y frecuencias del proceso.
 Procesos relacionados que están representados en el mapa de procesos (Sharp y McDermott,
2001).
Con esa identificación inicial se comienza definitivamente a “aclarar” los procesos, partiendo de una
descripción y un planteamiento base para entrar más a fondo en los detalles. Durante la fase inicial —
relativa al descubrimiento, la identificación y documentación de los procesos actuales (AS-IS)—, el
consultor responsable de realizar el modelado de procesos deberá obtener la información necesaria de la
manera más adecuada y precisa posible. Es frecuente encontrar numerosa documentación sobre los
procesos que en muchos casos es parcialmente aprovechable y útil, ya que los criterios necesarios para
definirlos y documentarlos no están suficientemente atendidos en estos documentos. Por ello, los
consultores deben disponer de una fina capacidad analítica para identificar los datos relevantes del proceso
que se está analizando. Esta habilidad es crítica a la hora de definir los procesos, y las técnicas utilizadas
son sólo un soporte, ya que la técnica aplicada sin criterio y razonamiento no conduce a ningún lugar. Así,
durante la definición de los procesos, se utilizan el análisis de la documentación, entrevistas directas con
los actores de los distintos procesos (focus groups), o mesas redondas. Es decir: no hay nada revolucionario
para realizar esta etapa del modelado de procesos, sino que la habilidad del consultor de procesos, y de
los arquitectos de proceso de la empresa para identificar los aspectos relevantes de la situación actual, se
convierte en la competencia básica necesaria para una comprensión suficiente de los procesos analizados.
En esta fase no se llegan a modelar propiamente los procesos con un amplio nivel de detalle —por lo menos
no es lo recomendable—, sino que se definen los pasos básicos en función de lo propuesto anteriormente
para su identificación. Por otro lado, se puede utilizar algún modelo sencillo (sin pretensiones de
profundizar), solamente para permitirles a los analistas obtener las informaciones requeridas para conocer

los procesos actuales. Un diagrama con bandas que identifique cada rol sirve de modelo para diseñar
aquellos procesos con detalle que incluyen: integrantes, actividades, decisiones, interacción con sistemas,
datos de tiempos y costes de esos procesos, entre otros datos importantes. Por ejemplo, se puede utilizar
la notación BPMN (Business Process Modeling Notation) —que se explicará en un apartado siguiente—
para generar y mostrar gráficamente la información que formará parte del análisis AS-IS. Este tipo de
notación permite separar los roles en bandas, utilizando objetos representativos de cada acción
relacionada con el proceso. No es común el uso de herramientas que permitan “automatizar” las tareas
durante la fase de descubrimiento o definición de los procesos. El proceso interactivo de captura de la
información debe ser una pretensión importante durante esa fase: las impresiones de cada participante
son captadas para enlazar con la lógica extraída a partir de la comprensión del proceso.
Un aspecto importante de esta fase es saber identificar las deficiencias y potencialidades del proceso en
este nivel de modelado o granularidad, en relación con la estrategia empresarial. Los procesos tienen la
misión de implementar la estrategia, por lo cual todas las perspectivas de la estrategia de negocio (misión,
visión, objetivos) y las herramientas de modelado de 1ro. y 2do. nivel que dan soporte a este nivel de
modelado son contrastadas para confirmar que se está logrando seguir y articular la estrategia definida.
Todo el trabajo realizado anteriormente relacionado con la estrategia de negocio adquiere una fuerza muy
importante cuando la organización decide gestionar los negocios desde la perspectiva de los procesos. Los
procesos son la coordinación, el camino-patrón que sigue la empresa para entregar valor a sus clientes, si
no existieran procesos coordinados, todo en la empresa sería controlado en una dimensión ad hoc y
probablemente caótica. Ocurre que aquellos procesos que no están enlazados con los objetivos
estratégicos son similares a los procesos ad hoc.
Para la realización de la etapa AS-IS, un equipo multidisciplinar formado por consultores externos, líderes
de proyecto de la empresa y responsables de área de negocio deben estar involucrados. Durante las
reuniones, la búsqueda del consenso será tan complicada como aplicar demasiados detalles que no aportan
valor al entendimiento del proceso. El punto de equilibrio está en conseguir la información que
efectivamente permita conocer las facetas importantes del proceso para su posterior mejora. El tiempo
dedicado al análisis AS-IS no puede ser largo, las actividades deben estar completas para procesos

complejos en cuestión de días, de lo contrario puede ser un indicativo de que su definición no va por buen
camino.
El análisis AS-IS termina con un informe de una única página —que se puede denominar como sumario AS-
IS— que explica con tablas, diagramas y texto todos los detalles relevantes para entender el macroproceso
que contiene a su vez un conjunto de subprocesos o procesos independientes. Dicho informe contiene las
actividades más importantes de estos procesos de 3er. nivel, indicando todos los parámetros necesarios
para promover el conocimiento suficiente como para poder mejorarlo en la fase siguiente, denominada
TO-BE processes, que se explica a continuación. La tabla 1 demuestra el output de la fase de entendimiento
de los procesos actuales, en la que el proceso en su visión interfuncional muestra todos los subprocesos de
los cuales dependen el proceso principal y que incluso podrían ser procesos independientes que actúan
como subproceso para el ejemplo propuesto antes en el mapa de procesos de ciclo de desarrollo de
producto.
En la tabla 1 se visualiza mediante un ejemplo lo perseguido en líneas generales por medio del análisis AS-
IS.
Proceso de diseño de producto

Procesos y subprocesos Resultado
Dis Ap Des Pr Se entrega prototipo para evaluación, pruebas
eñ ro arro ep y aprobación final.
ar bar llar ara
co co mat r
nc nc erial pr
ep ept es. ot
to. o. oti
po.
Casos para la acción Visión
 El tiempo de desarrollo del producto es  Nuestro diseño de producto ofrecerá una capacidad de
demasiado largo en comparación con los desarrollo superior con reducción drástica del tiempo de

competidores. diseño.
 El workflow del circuito de aprobación de  Enfocaremos la captura de información de mercado y de
conceptos es demasiado complejo. clientes de forma estructurada.
 La información capturada no es la más  Reduciremos inicialmente el tiempo de desarrollo de
capturada en todos los casos, prototipos de 6 a 4 meses para equipararnos con la
requiriendo volver atrás para competencia, y luego reduciremos de 1 año a 3 meses.
recuperarla.
 La captura de información para
determinar la demanda del mercado y las
necesidades de clientes no está
estructurada.
Actores Mecanism Indicadores
os
 Clientes.  Plataforma  Tiempo de desarrollo superior a 6 meses.
 Analistas de BPMS.  60 desarrollos simultáneos al año.
marketing.  Sistemas  Índice de prototipos rechazados de 45%.
 Ingeniería de CAD/CAM.  70% de rechazos en la fase desarrollo.
producto.  Sistema
 Proveedores. calidad.
 Sistema ERP.
Tabla 1. Ejemplo del Proceso AS-IS / Fuente: elaboración propia con base en Sharp y McDermott, 2001, p. 113
Finalmente se puede concluir que el objetivo de esta fase es poner las bases en las que los procesos futuros
deben estar apoyados para la optimización y el rediseño de los procesos.
1.6.4 Modelado de Procesos (TO-BE Processes)

El modelado TO-BE es la redefinición de los procesos con base en los resultados de su condición actual (AS-
IS). Se potencia lo que mejor hace el proceso y se corrigen los gaps se hayan detectado. Los objetivos del
modelado de los procesos futuros son: obtener una descripción de las rasgos más destacados de manera
que faciliten su mejora; diseñar flujos coordinados; detectar necesidades de TI para su automatización;

aumentar el nivel de detalle de los modelos de procesos, incluyendo su arquitectura de datos y llegando a
definirlos a un nivel de datos estructurados y no estructurados que compondrán el proceso optimizado.
Para realizar las actividades de los procesos futuros, se realizan las siguientes tareas:
 Generar ideas orientadas por los objetivos estratégicos que deben cumplir los procesos.
 Seleccionar aquellas que se presentan factibles y acordes con dichos objetivos.
 Desarrollar el nuevo workflow (flujo de trabajo) con el nivel de detalle necesario para su ejecución.
En la fase TO-BE juegan un papel preponderante las herramientas de modelado de procesos. Actualmente
existen varios estándares para el diseño de procesos, como por ejemplo el UML (Unified Modeling
Lanaguage), que se trata de una tradicional notación actualmente bajo el control del OMG (Object
Management Group) que emplea un lenguaje de modelado para la visión gráfica con especificación y
construcción de artefactos de sistemas orientados al desarrollo de software. Es una notación para
modelado de procesos orientados al desarrollo de aplicaciones que tiene cierta desventaja al exigir un nivel
de detalle que va más allá de los límites del negocio.
Otro estándar para el diseño gráfico de modelos de proceso es el denominado EPC (Event driven Process
Chain), un método desarrollado en la plataforma ARIS en los inicios de la década de los años 90. Se trata
de una herramienta que obtuvo gran notoriedad a raíz de ser utilizado por SAP integrado con soluciones
de IDS Scheer AG propietaria de ARIS.
La herramienta de modelado de procesos que más va ganando notoriedad es la llamada notación BPMN
(Business Process Management Notation). Esta notación presenta una mecánica para modelado de
procesos bastante sencilla de interpretar y accesible a cualquier persona del área de negocio no
directamente relacionada con TI. Para conocer y utilizar la notación BPMN se recomienda la lectura de la
documentación facilitada por OMG Group, que se encarga de mantener y actualizar toda la información
relacionada con el BPMN (esta información se ha incorporado en los recursos de este tema).
En estos apuntes se ha optado por la notación BPMN (versión 1.1) por ser un estándar de facto (con
posibilidades de serlo en el futuro) en el que se destacan las siguientes características:

 Posee una serie limitada de objetos de la notación que hace posible definir procesos lo
suficientemente potentes como para generar resultados que permitan el rediseño.
 Está basada en el concepto de diagramas de flujo (flowcharting).
 Posee un modelo de redes de actividades: nudos y transacciones.
 Maneja flujos secuenciales, paralelos y rutas condicionadas.
 Con él se pueden crear diagramas complejos.
 Permite comunicar de forma estandarizada los procedimientos de negocio interpretables por
cualquier función de la organización.
Resumen 1:
BPM es el entendimiento, la gestión y la innovación de procesos de acuerdo con
estándares internacionales, alineados con la estrategia de negocio para asegurar la efectividad del
proceso y crear valor a la cadena productiva de la empresa y su sector. Constituye un nuevo paradigma
para abordar procesos de mejoramiento que aumentan la eficiencia y facilitan la integración entre
diferentes compañías.
Resumen 2:
La gestión de procesos de negocio se lleva a la práctica integrando la estrategia, los
procesos y la tecnología, la cual emplea estándares de modelamiento para permitir una comunicación
fluida y con menor esfuerzo entre los procesos de negocio y las compañías del sector. BPM constituye
una alternativa para la búsqueda de ventajas competitivas, para afrontar escenarios de competencia
en mercados nacionales e internacionales. Se perfila como una nueva línea de pensamiento que
atiende necesidades tangibles de las empresas y abre nuevos nichos de mercado para nuevas
empresas que se enfoquen en temas de gestión empresarial.

Objetos de Información
Nombre del OI Descripción del OI
El modelo de procesos Este documento sirve para fortalecer el
http://www.ccee.edu.uy/ensenian/catcambio modelado de procesos y da a conocer ejemplos
rg/material/clase15_201006.PDF que facilitan el aprendizaje de la tematica. Leer
documento completo.
Workflow Management: Models, methods Este documento y amplía la información sobre
and systems. modelo, análisis, métodos y roadmap para
http://wwwis.win.tue.nl/~wvdaalst/publicatio workflow. Leer los 5 primeros capítulos.
ns/p120.pdf

2. Análisis de brecha, definición y

priorización de proyectos
2.1 Análisis de brechas
El análisis de brechas, también conocido como GAP Analysis, es aquel que muestra la comparación entre
el estado de situación actual de la empresa y el estado de situación deseado; las diferencias que se generan
en esta comparación son las brechas que se buscan evaluar, examinar y eliminar.
Después de establecer las metas y los objetivos planteados por la organización, una vez realizada la
planeación estratégica, se debe llevar a cabo la comparación del objetivo planteado con el resultado actual
de la empresa.
Las brechas necesitan el desarrollo de estrategias para que puedan ser cerradas con el objetivo de alcanzar
las metas propuestas. El estratégico que se proponga debe tener alta probabilidades de éxito.
Como se muestra en la figura 3, dentro del análisis de brechas se deben tener en cuenta e identificar la
comparación del plan estratégico con el actual,
comparar las líneas de negocio que se formularon en la
planeación estratégica y las actuales, realizar un análisis
de los indicadores estratégicos y examinar las
estrategias actuales. En relación con el cierre de
brechas, algunas de las medidas para realizarlo son la
expansión interna o el inicio de nuevos negocios.
2.2 Definición y
priorización de Figura 3. Análisis de brechas / Fuente: elaboración propia
proyectos
2.2.1 Concepto de proyecto y su gestión

El proyecto se puede definir como “un producto de características únicas, de fabricación no repetitiva, con
unos recursos y organización propia establecidos a tal fin, y con unos objetivos claramente establecidos de
alcance, calidad, coste y plazo”. (Fernández, 2009, p. 2)
La definición anterior comporta una serie de características especiales que diferencian un proyecto de
cualquier otro tipo de producto o actividad y, por tanto, el sistema utilizado para su gestión será distinto
del Sistema Integrado de Gestión de Proyectos que estamos tratando. Por tanto, la definición que hemos
dado ya supone una visión más amplia e integrada que la concepción clásica o tradicional que se tenía de
un proyecto.
Tradicionalmente, por proyecto se entendía “el conjunto de planos y documentos precisos en cada caso
para que un Técnico, aún cuando no sea el autor del mismo, pueda dirigir y ejecutar totalmente los trabajos
necesarios para la realización de la obra”. (Fernández, 2009, p. 2)
En la definición clásica la idea de proyecto se corresponde con el documento conocido por todos que
comprende: Memoria, Planos, Pliegos de Prescripciones, Técnicas Particulares, Presupuesto y Programa de
los Trabajos. Distingue entre Proyecto y Obra/Construcción, cuando, como veremos más adelante, se trata
de diferentes fases o subsistemas de un concepto más global, al que se denomina Proyecto según las
técnicas modernas del “Project Management”.
De las múltiples acepciones que se aplican para definir un proyecto hay una especialmente concreta:
“conjunto de acciones tendentes a una finalidad: crear un cambio” (PMBoK Guide, 2000). Esta definición
nos parece muy ajustada pero al mismo tiempo indica una concepción muy general del término proyecto.
En efecto, proyecto puede ser lanzar un nuevo producto al mercado o poner en marcha una aplicación
informática. Todo lo contrario de una actividad continua como una planta de envasado, o el montaje bajo
pedido de un producto para el cual se tienen almacenados previamente los componentes (plazo de entrega
más corto que el plazo completo de ejecución).
Como se muestra en la figura 4, gestionar un proyecto consiste en aplicarle a las actividades de un proyecto
un conjunto de conocimientos, habilidades, herramientas y técnicas necesarias para cumplir las

necesidades y expectativas de las partes interesadas en el proyecto. La gestión de un proyecto debe

balancear:
 Especificaciones, tiempo, coste y calidad.

 Partes interesadas con diferentes necesidades y expectativas.
 Requisitos identificados (necesidades) y no identificados (expectativas).
En la figura 4 se relacionan los elementos más importantes a tener en cuenta en la gestión de un proyecto,
partiendo desde los costos y la financiación, hasta los
plazos, el recurso humanos y los requisitos técnicos,
legales y comerciales necesarios.
2.3 Características de los

proyectos
 Entidad, tamaño, alcance. Figura 4. Aspectos esenciales de la gestión de
 Necesidad de medios importantes, transitoriamente. un proyecto / Fuente: elaboración propia
 Discontinuidad: falta de familiaridad o habitualidad. Supone algo innovador, algo que no es

totalmente rutinario. Cada proyecto tiene una identidad propia y necesita una gestión distinta.
 Complejidad: necesidad de distintos especialistas. Actividad multidisciplinar.
 Riesgo, contingencia, azar, coste.
 Actividades no repetitivas.
 Las decisiones asociadas al proyecto son irreversibles.
 Sujetos a numerosas influencias del entorno: agentes meteorológicos, inflación, cambios paridad
moneda, etcétera.
Es difícil medir el efecto de las influencias citadas y una mala decisión, un acontecimiento externo puede
provocar consecuencias catastróficas.
2.4 Objetivos del proyecto

Un principio básico en la gestión de proyectos —y en general en toda actividad de gestión seria y
profesional— es que los objetivos estén definidos a priori y con un grado suficiente de claridad y precisión.

Es la mayor garantía de que después no se producirán situaciones conflictivas y la única forma de poder
controlar el proyecto y tomar decisiones eficaces y coherentes.
En ciertos proyectos la definición de objetivos es más difícil y laboriosa que en otros. Los proyectos más
excepcionales e inusuales, y aquellos de naturaleza más inmaterial, presentan dificultades especiales a la
hora de formular los objetivos o para hacerlo con la concreción deseable.
El objetivo del proyecto es siempre triple como se observa en la figura 5. Muchos de los defectos habituales
en la gestión de proyectos provienen de olvidar
este simple hecho, pensando por alto que para
el éxito del proyecto basta conseguir uno o dos
de los objetivos, o que la importancia relativa
entre estos es muy diferente. El triple objetivo
del proyecto se puede representar en un
triángulo para resaltar que los tres vértices son
necesarios e igualmente importantes.
Figura 5. Objetivos de un proyecto / Fuente: elaboración propia
El primer objetivo es, por supuesto, el resultado final del proyecto, consistente en la obra que se desea
realizar y que supone el origen y la justificación del proyecto, por lo que puede considerarse el objetivo
más importante y significativo. El proyecto se ha concebido para algo, y si ese algo no se consigue, el
proyecto habrá fracasado, al margen de otras consideraciones de coste o de tiempo.
El objetivo de coste es esencial en todo proyecto y siempre debe estimarse explícitamente, tanto en
proyectos internos como externos, lo que no impide que, como toda estimación, pueda después no
cumplirse.
El objetivo del plazo es el objetivo que más fácilmente se deteriora y se convierte, en muchos casos, en el
que hay que seguir más de cerca y el que mejor mide el grado de calidad de la gestión del proyecto. El plazo
de realización del proyecto se considera por ciertas personas como un problema secundario o algo que,
por su dificultad, no debe valorarse excesivamente. Sin embargo, el plazo es un elemento muy importante
en casi todos los proyectos y, en algunos, tal vez, el objetivo más importante o el que más condiciona el
éxito del proyecto.

2.5 Ciclo de vida del proyecto

Un proyecto parte de una idea, a veces sumamente abstracta, que es la etapa de concepción. El siguiente
paso es la etapa de formulación, que es un estudio general con sus objetivos y desarrollo a nivel
aproximativo, como por ejemplo un concurso de ideas para proyectos piloto o experimentales. Esta
formulación del proyecto en términos ya mucho más precisos permitirá en ocasiones tomar una decisión
definitiva sobre el interés de acometerlo o no. A continuación se aborda el análisis de viabilidad (estudios
de coste/eficacia, rentabilidad, viabilidad técnica y económica), con carácter previo a la adopción de la
decisión definitiva. Una vez que se tome la decisión de proseguir con la idea inicial, se inicia la etapa de
ejecución. Las etapas posteriores: informes y control, y transición al estado de operación, son para llegar
al estado de explotación del proyecto. Por último hay una etapa de evaluación o balance que compara los
objetivos del proyecto con la realidad.
Habitualmente la etapa que más tiempo y recursos consume es la correspondiente a la implementación

(construcción o ejecución del proyecto/obra), fase en la cual explicitaremos el sistema de control. Esto no
implica que las otras fases tengan menor importancia. Tanto la fase de concepción como la de diseño son
de gran trascendencia y los errores cometidos en ellas se pagan con fuertes pérdidas en la fase de
construcción, que puede llegar al fracaso total con el abandono de la obra. Un proyecto (diseño) mal
calculado puede resultar inviable a la hora de su implantación, por razones técnicas o económicas. De ahí
que todas las fases citadas se cumplan en el tiempo con el rigor adecuado a la importancia del proyecto.
En un proyecto de construcción las fases se solapan y se realimentan con base en los diferentes
mecanismos de control que se introducen para comparar con los objetivos y la toma de acciones
correctoras. Lo normal en la práctica es que existan solapes entre la fase de definición y la fase de ejecución,
y entre la fase de ejecución y la de operación o puesta en marcha del sistema. Esto también dependerá de
la forma en que se gestione al proyecto, tanto por la propiedad/cliente como por el
contratista/constructor.
2.5.1 Concepción del proyecto

El punto de partida de todo proyecto es la concreción de los objetivos. Prioritariamente es un papel que
corresponde al cliente. Esto, a veces, es un poco teórico porque puede que el cliente no esté preparado
para fijar los objetivos. Por tanto, el cliente puede marcar la estrategia general de la empresa, en un cierto
campo, y auxiliarse en un consultor en esta fase, que es muy importante.
El factor tecnológico es de especial relevancia sobre todo en proyectos de nuevas tecnologías y que tengan
un plazo de ejecución largo. Piénsese, por ejemplo, en un proyecto que incorpore sistemas informáticos y
que tenga una duración prolongada. El dilema siempre se plantea a la hora de especificar técnicamente los
equipos durante el desarrollo del software, y en escoger el momento adecuado para comprar las máquinas.
En un sector como el de las TI, este es un punto a tener muy en cuenta y no sólo por lo que afecta a los
equipos; por ejemplo en la construcción de un radioenlace o de un sistema de radiocomunicaciones, en
general, la concesión de frecuencias suele ocasionar, cuando menos, retrasos en la ejecución, cuanto más
si en el estudio de viabilidad no se han realizado las consultas pertinentes a la Subdirección General de
Gestión del Espectro Radioeléctrico (MTT y C).
Resumiendo, la formulación de los objetivos y el análisis de viabilidad son los puntos más importantes a
tener en cuenta en la fase de concepción del proyecto. Esta fase es clave para todo el desarrollo posterior.
De ella se derivan los objetivos de la empresa constructora encargada de la ingeniería y ejecución del
proyecto, que si bien formulará unos objetivos propios, estos se derivarán de los que inicialmente fije el
cliente. Esta fase marca, asimismo, el comienzo de la planificación del proyecto y del sistema de
información y control asociado.
2.5.2 Formulación
Las características del proyecto implican la necesidad de una fase o una serie de etapas previas destinadas
a su planificación o preparación, fases que tienen una gran trascendencia para la buena marcha del
proyecto y que deberán ser especialmente cuidadas. No es una exageración decir que el éxito o el fracaso
del proyecto se fraguan principalmente en estas fases preparatorias que algunas personas tienden a
menospreciar, inquietas por querer ver los resultados excesivamente pronto.
Los errores cometidos en tiempos o costes suelen no ser posibles de compensarlos durante la ejecución y
se pagan con fuertes pérdidas económicas en el proyecto.

2.5.3 Análisis de viabilidad

El análisis de viabilidad es aquel que permite determinar el éxito o fracaso de un proyecto, teniendo en
cuenta una serie de datos empíricos como lo son el medio ambiente del proyecto, la rentabilidad,
necesidad y demanda del mercado, factibilidad técnica, factibilidad operativa, flujo de caja entre otros,
enfocándose en viabilidad financiera y del mercado.
2.5.4 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.
2.5.5 Entrega y 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 aprobadas en su momento. Esta fase también
es muy importante no sólo para 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.
2.5.6 Explotación
La finalización de la obra no supone en sí misma la terminación total del proyecto. Es preciso tener siempre
presente que la mayor parte de los proyectos están destinados —cuando se logra el resultado previsto—
a pasar a una etapa completamente diferente que consiste en el uso o la explotación de dicho resultado
por el propio cliente o por terceros. Si, por ejemplo, se construye una fábrica es porque una vez construida
entrará en producción y será explotada en el día a día, lo que entrañará, además, la necesidad de adoptar
otras medidas de gestión, dirección, mantenimiento y control.

La transición del proyecto a la fase de uso o explotación es inherente a la naturaleza de los proyectos y
resulta ser especialmente delicada.
2.5.7 Evaluación o balance

Una vez finalizado el proyecto, es muy recomendable efectuar un balance de los resultados obtenidos en
relación con los objetivos inicialmente propuestos. Es una fase cuyo interés resulta evidente y que, sin
embargo, raras veces se cumple, tal vez para no poner de relieve los numerosos errores cometidos.
2.6 Actores relacionados con el proyecto

Distintos actores —sean individuos, grupos o entidades— participan activamente en la “organización
temporal” del proyecto, influyen en sus objetivos y tienen intereses que puede afectar su ejecución, sus
resultados o conclusiones. El orden habitual de aparición de los actores en el escenario del proyecto es el
siguiente:
 El patrocinador o impulsor del proyecto suele ser un consultor externo o un directivo interno de la
entidad destinataria, que convence de su necesidad.
 El cliente es su parte contratante y proporciona los recursos para producirlo. No se debe confundir
con los usuarios, que hasta pueden no ser de la misma entidad.
 El proveedor, suministrador o ejecutante del proyecto es la parte contratada para desarrollarlo.
 El Comité de Dirección incluye directivos del cliente (al que suele pertenecer una autoridad para
tomar decisiones al máximo nivel) y del proveedor, posiblemente junto a otros actores influyentes
en el desarrollo del proyecto, como algún directivo importante de los usuarios o de manejo de
recursos del cliente, o algún experto, consultor o especialista del proveedor o de terceros.
 El director del proyecto es el responsable nombrado por el proveedor o el Comité de Dirección para
dirigir su ejecución hacia su objetivo, con la mejor gestión posible de los recursos asignados.
 Los Usuarios son quienes utilizarán el resultado del proyecto y además pueden explicar las
deficiencias de lo que están usando y sus necesidades futuras, o sea los requerimientos
imprescindibles para diseñar dicho resultado.
 Los miembros del equipo del proyecto lo desarrollan bajo la autoridad ejecutiva del director del
proyecto y la supervisión del Comité de Dirección.
2.7 Modelo de desarrollo de un proyecto TIC

Un proyecto TIC completo (anteproyecto y desarrollo) suele combinar un conjunto documental para la
comunicación entre los agentes implicados, con un paquete de comunicación con el sistema informático.
La proporción de ambos tipos de comunicación es variable, desde sólo un paquete de software en
aplicaciones sencillas, hasta el conjunto documental, como por ejemplo en consultoría.
El anteproyecto TIC es un conjunto de documentos que determinan concreta y concisamente, con

suficiente amplitud, todos los aspectos que interesan a los clientes y usuarios en su futura relación con el
proyecto-resultado con el que interactuarán. Este va acompañado de directrices para que el realizador del
proyecto-proceso necesite el menor número posible de aclaraciones e interpretaciones de parte del autor
del anteproyecto o de sus clientes-usuarios, antes de las pruebas para la aceptación del proyecto-resultado.
La petición de ofertas por el cliente y el desarrollo del anteproyecto por el proveedor permiten tomar la
decisión de ambas partes de hacer el proyecto. Este seguirá o no en función de su propio contenido y sobre
todo de la información sobre su entorno, incluidas las capacidades de los actores y la competencia
contenida frente a otros proyectos.
A menudo el desarrollo TIC se apoya en el Método en V —más útil que el Modelo en cascada— para
relacionar las etapas y los resultados con los roles del cliente-usuario y las distintas profesiones que
intervienen en el desarrollo. Se aclara así la responsabilidad de quién ejecuta, verifica y valida las etapas
de obtención de información, análisis y diseño, decisivas para el éxito. El proveedor obtiene del cliente-
usuario sus requerimientos lo más concretos posibles (qué hacer) y los traduce en su oferta como requisitos
amplios del resultado deseado y del proceso para producirlo (diseñando la arquitectura o forma global de
cómo y dónde se va a hacer, lo que permite prever el plazo cuándo y el coste cuánto). Cuando se haga el
diseño detallado, se producirán además especificaciones para los desarrolladores. Se tienen así:
 Los requerimientos del cliente, solicitados explícitamente en su “Petición de ofertas” a los posibles
proveedores, o que más frecuentemente estos han de averiguar o extraer (elicitate). Siempre deben
describirse con la terminología usada por el cliente, para que este los valide al principio del proyecto
frente a posibles conflictos de producto incompatible (cuando tenga que aceptarlo).
 Los requisitos del proyecto, redactados por el proveedor como una primera transformación de los
requerimientos a un lenguaje más técnico y estructurado funcionalmente, que debe ser validado
por las correspondientes pruebas funcionales (de su funcionamiento) cuando se integren los
módulos o subsistemas en el sistema final a entregar.
 Las especificaciones del sistema y para cada subsistema proceden del diseño detallado y deben
verificar las pruebas de los módulos/subsistemas y sus interfaces, antes de integrarlos.

La figura 6 muestra cada una de las etapas o fases que es necesario tener en cuenta cuando se va a
desarrollar un proyecto TIC.
Figura 6. Modelo de desarrollo proyecto TIC. / Fuente: elaboración propia
2.8 Planes de contingencia

Un plan de contingencia es un plan alternativo que será utilizado si un riesgo previsto finalmente se
produce. El plan de contingencia representa acciones preventivas que reducirán o mitigarán el impacto
negativo del evento que implica riesgo. Como todos los planes, el plan de contingencia responde a las
preguntas qué, dónde, cómo y cuándo deberá tener lugar la acción. La ausencia de dicho plan puede causar
que el gestor retrase o posponga la decisión de intentar afrontar el problema con repercusión negativa en
el proyecto global. Los planes de contingencia evalúan alternativas posibles a los eventos antes de que
ocurran y selecciona el mejor plan entre estas alternativas. Por todo ello, la existencia de un plan puede
incrementar significativamente el éxito del proyecto.
Las condiciones para la implementación de un plan de contingencia deben ser decididas y claramente
documentadas. El plan debería incluir una estimación de costes y la identificación de las fuentes de fondos.
Todas las partes afectadas deberán estar de acuerdo y tener autoridad para hacer modificaciones. Debido
a que la implementación de un plan de estas características implica la interrupción en la secuencia del

trabajo, todos los planes deberían ser comunicados a los miembros del equipo para minimizar sorpresas y
resistencias.
Las matrices de respuesta a riesgos son útiles para resumir cómo el equipo de proyecto planea gestionar
los riesgos identificados. El primer paso es identificar si se va a reducir, compartir, transferir o aceptar el
riesgo. En el ejemplo propuesto el equipo decide reducir la posibilidad de que el sistema “se cuelgue”
experimentando con un prototipo del sistema. La experimentación no solamente les permitirá identificar
los posibles problemas, sino también recoger información útil para los usuarios finales. El equipo de
proyecto es entonces capaz de determinar y documentar cambios del viejo y nuevo sistema que serán
incorporados en la formación de los usuarios. El riesgo de mal funcionamiento es transferido eligiendo un
proveedor fiable y de garantía.
El siguiente paso es identificar los planes de contingencia en caso de que el riesgo siga existiendo. Por
ejemplo, si el sistema se cuelga después de la instalación, el equipo intentará primero reinstalar el
software. Si la insatisfacción del usuario es alta, el Departamento de Sistemas proporcionará más personal
de apoyo, etcétera.
Algunas veces los imprevistos se dan en la mitad del proyecto, y si no existe plan de contingencia, es
necesario desarrollar uno rápidamente. Normalmente estos planes que responden a eventos externos
implican nuevos participantes en el equipo. Estos participantes, aunque son necesarios, pueden no estar
familiarizados con la organización del proyecto y tienen objetivos en conflicto con los objetivos del
proyecto, presentando problemas adicionales.
Los planes de contingencia se diseñan para asegurar que los objetivos del proyecto se alcancen cubriendo
riesgos de programación, coste y técnicos. Algunas consideraciones acerca de estos aspectos se revisan a
continuación.
2.9 Riesgos de programación

El riesgo más frecuente en la programación es el “Uso de holguras”. Cuando algunos gestores ven holguras
en la red dejan de preocuparse por completar sus operaciones a tiempo, ¿por qué preocuparse si hay 10
días de holgura? Infortunadamente, esta holgura puede ser necesitada por otra actividad del conjunto que

debe comenzar ahora retrasada y encontrar poco o ninguna holgura disponible porque ya ha sido
consumida. La gestión de holguras puede ser un excelente método parar reducir los riesgos de
programación. Es preciso recordar que el uso de las holguras mueve la mayoría de las actividades cerca de
su límite máximo de comienzo, con lo que el riesgo de retraso del proyecto se incrementa. La gestión de
riesgos de programación requiere decisiones de transacción. Es paradójico que actualmente los gestores
incrementen el riesgo por alguna de sus decisiones. Dos de estas situaciones son:
 Imposición de duraciones: la experiencia demuestra que aproximadamente el 80% de los proyectos

tienen fechas impuestas. Normalmente esto significa que alguien ha determinado que el proyecto
o hito puede o debe ser completado en una fecha concreta. Ejemplos significativos pueden ser la
finalización de una carretera para el 1 de enero, o el desarrollo de un videojuego para el mercado
navideño. La duración de estos proyectos es frecuentemente una decisión de alto nivel que no
incluye una planificación bottom-up (abajo-arriba) y frecuentemente está por debajo del tiempo
normal requerido para completar el proyecto. Si este el caso, es necesario que algunas tareas se
realicen en menos tiempo del inicialmente previsto. Esta aceleración incrementa los costes y la
oportunidad de que las actividades se retrasen y reduzca la flexibilidad en el sistema de
programación global. Algunas veces para completar el proyecto es necesaria la imposición de
duraciones, pero en casi todos los casos de imposición de duración, aumentan los riesgos tanto de
desfase en la entrega final del proyecto, como de incremento en los costes.
 Reducción de la duración del proyecto: en ocasiones, antes —o a lo largo de la realización del
proyecto— surge la necesidad de acortar la duración global del proyecto. Acortar la duración del
proyecto se alcanza comprimiendo o acortando una o más actividades del camino crítico. Acortando
una actividad se incrementa el coste directo. Además, comprimir o acortar el camino crítico
disminuye la holgura en otros caminos, y más caminos se convierten en críticos o casi críticos.
Cuantas más actividades críticas o casi críticas haya, mayor será el aumento del riesgo de que la
duración global del proyecto aumente.
2.10 Riesgos de costes
2.10.1 Dependencia tiempo/coste

Existe una dependencia entre la duración y el coste derivado de problemas de índole técnico. Por ejemplo,
si la actividad “desarrollo de un prototipo” requiere un 50% más de tiempo que la estimación original,
puede esperarse que también los costes se incrementen. Así, el tiempo y el coste no son independientes.

2.10.2 Decisiones de flujo de caja

Algunas decisiones de flujo de caja pueden provocar riesgos en la programación. Por ejemplo, los analistas
financieros harán comparación de una programación lo antes posible frente a una programación lo más
tarde posible. Teóricamente, concluyen que retrasando actividades, el valor futuro del dinero es mayor
que su valor hoy (el dinero puede ganar intereses). Alternativamente, el dinero puede ser utilizado. El
incremento en riesgo de reducir holguras es algunas veces ignorado o significantemente desestimado. El
uso de la programación para resolver problemas de flujo de caja deberían ser evitados en la medida de lo
posible, y se debería hacer con el claro conocimiento de que un incremento en los riesgos de programación
representa un incremento en costes.
2.10.3 Previsión de coste final

Un escenario habitual se produce cuando el proyecto está en el 20% de su cumplimiento. Los gestores
suelen preguntarse: ¿nos ajustaremos al presupuesto cuando el proyecto termine? El método más utilizado
—aunque el más peligroso— es comparar el presupuesto frente al coste actual en un determinado instante
de tiempo, por ejemplo al 30% de su realización. Si el coste actual está un 4% sobre el presupuesto a la
fecha de hoy, la conclusión es que el proyecto completo costará 4% más de lo presupuestado. La
experiencia muestra que en raras ocasiones es verdad. Por supuesto que pueden tomarse acciones
correctivas, pero la mejora es difícil y requerirá seria atención en la gestión para cambiar la situación.
2.10.4 Riesgos de protección de precio

Los proyectos de larga duración necesitan algunas contingencias para cambios en precios, que
normalmente tienden al alza. El importante punto a recordar cuando revisamos precios es evitar el error
de utilizar dicho incremento para cubrir el riesgo de precios. Por ejemplo, si la inflación ha crecido un 3%,
algunos gestores añaden 3% a todos los recursos utilizados en el proyecto. Este método no identifica
directamente donde es necesaria esta protección al riesgo de incremento. El resto de precios debería ser
evaluado, recurso a recurso.

2.11 Riesgos técnicos

Los riesgos de ámbito técnico son problemáticos, ya que pueden ser frecuentemente causa de que el
proyecto fracase. Si el sistema o proceso no funciona, deben existir planes de contingencia ante las
posibilidades que hayan sido previstas. Además de las estrategias de backup, los gestores de proyectos
necesitan desarrollar métodos para identificar rápidamente si las incertidumbres de índole técnica pueden
ser resueltas. El uso de sofisticados programas CAD han ayudado mucho a resolver problemas de diseño.

Resumen 1:
Un consultor para la integración de las TIC en las organizaciones debe conocer la
Dirección de Proyectos con la profundidad que requiera una doble perspectiva: porque tiene como
interlocutor principal a los directores de los proyectos relacionados con su trabajo, y porque él
mismo ejerce esa dirección. El éxito de estas relaciones dobles hacia los dirigentes organizacionales
y hacia los dirigentes de las TIC reside en un mutuo entendimiento, que puede facilitar ampliamente
el uso de un lenguaje lo más unificado posible que permita entrar con suficiente claridad en los
respectivos problemas, como primer paso de su solución.
Resumen 2:
La visión integral incluye los procesos de selección de proyectos que mejor soportan
la estrategia organizacional, y todas las técnicas y los procesos de gestión que permiten cerrar el
ciclo de vida de estos proyectos. Los objetivos de esta visión prospectiva son la comprensión del
papel de un proyecto en la organización, y la revisión de las técnicas y herramientas de gestión de
proyectos, así como las habilidades interpersonales necesarias para poder coordinar el proyecto
hasta su finalización.

Nombre Descripción
Una metodología efectiva para la Este documento describe la experiencia en la
priorización de proyectos en TIC construcción e implementación de una
http://www.iiisci.org/Journal/CV$/risci/pdf metodología diseñada para priorizar los
s/GC492KA.pdf proyectos de las Tecnologías de la Información y
las Comunicaciones. Leer documento completo.

3 .La cadena de valor de una empresa, la

taxonomía de procesos de negocio, y el
papel que juega cada tipo de proceso
dentro de la organización
3.1 Cadena de valor de una empresa
La cadena de valor es la forma de analizar las actividades empresariales por medio de la cual se desglosa
una organización en sus partes constitutivas, con el fin de lograr identificar las ventajas competitivas en las
actividades que generar valor. Dicha ventaja se alcanza cuando la compañía lleva a cabo el desarrollo de
las actividades de su cadena de valor de manera diferenciadora con respecto a la competencia. Lo anterior
quiere decir que la cadena de valor de una organización está compuesta por cada una de las actividades
que generan valor agregado.
La cadena de valor se divide en actividades primarias y actividades secundarias. Las actividades primarias
están relacionadas con la creación de producto, la venta y la posventa. Dentro de las actividades primarias
sobresalen las siguientes: logística interna, operaciones, logística externa, marketing-ventas y servicio. En
cuanto a las actividades secundarias, estas se caracterizan porque brindan apoyo a las actividades
primarias. Dentro las actividades secundarias se destacan
la infraestructura de la organización, la dirección de
recursos humanos, el desarrollo tecnológico y el área de
compras.
En la figura 7 se identifican cada una de las actividades tanto

primarias como de soporte que forman parte de las cadena
de valor de Porter.
En un entorno cada vez más globalizado y con mayor nivel de

competencia, las empresas deben hacer una profunda Figura 7. Actividades Cadena de Valor / Fuente: Michael Porter

reflexión acerca de sus metas, sus objetivos, el entorno en el que se moverán y competirán, y la forma en
la que tratarán de seguir su estrategia.
A partir de un profundo y estricto análisis estructural del sector en el que la empresa competirá, cada
empresa deberá especificar cuáles serán sus objetivos y metas, y marcar de esta forma hacia dónde
pretende dirigir sus pasos y cómo hacerlo.
Una vez la empresa tiene definida su estrategia, tendrá que buscar la forma en la que intentará alcanzarla,
cómo realizará sus operaciones y sobre qué políticas concretas buscará adquirir las ventajas competitivas
que la sitúan como líder en su mercado.
Todas las decisiones y políticas que tome la empresa deberán estar alineadas con la estrategia seleccionada
y todas las áreas de la organización tratarán de empujar en la misma dirección. Se tendrán que definir las
secuencias de actividades del negocio apropiadas y detectar cuáles serán los factores de éxito sobre los
que se sustentarán los procesos.
Para un óptimo control y gestión de estos procedimientos y actividades críticas se deberán crear los
indicadores y parámetros apropiados, de forma que la empresa y sus directores puedan apreciar el grado
de avance de todos los objetivos estratégicos.
3.2 La organización empresarial vista como

sistema
Las organizaciones empresariales tienen las características de los sistemas abiertos:
La empresa es un sistema creado por el hombre y que mantiene una interacción dinámica con su medio
ambiente, ya sea con los clientes, los proveedores, los competidores... Influye sobre el medio ambiente y
recibe influencias de este. Además de esto, es un sistema integrado por diversas partes relacionadas entre
sí que trabajan en armonía unas con otras, con la finalidad de alcanzar una serie de objetivos, tanto de la
organización como de sus participantes. (Johansen, Oscar, 2004, p. 87)

La empresa se concibe como un sistema específico porque cumple o contiene las siguientes propiedades:
 Está en interacción y en equilibrio dinámico con el medio (un sistema abierto).

 Es una creación humana ajena a los sistemas físicos y biológicos (sistema artificial).
 Presta atención a la relación entre los aspectos psicosocial y técnico (sistema sociotécnico).
 Tiene límites flexibles y variables que la separan del medio (frontera del sistema).
 Forma parte de una jerarquía por encima y por debajo (sistemas, subsistemas y elementos).
 Tiene objetivos a conseguir, de la empresa y sus miembros (sistema teleológico).
 En ella el todo supera las partes (globalidad).
 Para su comprensión y gestión no basta las del conjunto de sistemas (sinergia).
 Tiene mecanismos de adaptación para acomodarse al cambio y de mantenimiento para asegurar el
equilibrio interno y externo (sistema homeostático).
 Tiende a elaborar niveles crecientes de complejidad organizativa (sistema evolutivo).
La organización empresarial elimina el incremento de la desorganización (entropía propia de los sistemas

cerrados), mediante la utilización de la información (entropía negativa y de los sistemas abiertos),
permitiendo que la organización mantenga el equilibrio dinámico interno a lo largo del tiempo, pese a los
cambios del entorno (homeostasis, como mecanismo de retroalimentación por recepción continua de
información desde el entorno con la que el sistema se ajusta para mantener el equilibrio).
3.3 Análisis estructural

Aunque existen muchas razones por las que se crean las empresas —desde cumplir con fines sociales hasta
crear empleos—, podríamos decir que la razón fundamental —o al menos la que se utilizará para definir su
estrategia— siempre será la de ganar dinero de manera sostenida en el tiempo por parte de sus socios
capitalistas.
Para conseguir alcanzar esta meta de la mejor forma posible, las empresas tendrán que definir una
estrategia que guíe sus pasos. Algunas empresas lo intentarán fabricando y vendiendo mobiliario de baño,
otras ofreciendo reservas en vuelos transoceánicos y otras construyendo puentes y carreteras, pero al final
toda empresa buscará esa forma óptima de ganar dinero. A partir de ahora seremos más rígidos con esta
definición, y entenderemos la expresión “ganar dinero” como “ganar más dinero, de forma sostenida en el
tiempo, que la media del sector en el que opera la empresa”.

En cualquier caso, las empresas nunca son entidades aisladas, sino que interactúan con agentes del entorno
como entidades bancarias, clientes, proveedores y otras empresas competidoras dentro de su mismo
sector. En este sentido, cabe destacar que no todos los sectores tienen por qué ser buenos para ganar
dinero.
Existen multitud de teorías y herramientas que permiten hacer un estudio detallado de un sector, y
probablemente la más conocida sea el Modelo de las Cinco Fuerzas de Michael Porter, creado en 1979. A
partir de estos modelos han surgido una variedad de teorías que pueden simplificar notablemente el
estudio de un mercado. Una de estas teorías es la desarrollada por el profesor Juan Vindel, quien propone
hacer un rápido diagnóstico estructural de un sector
basado en los tres conceptos básicos que se
expondremos en los siguientes apartados. A partir
de esta reflexión, cada empresa tendrá que diseñar
de qué forma operará en un determinado sector y
dónde le posicionará su estrategia. La figura 8 da las
pautas de los aspectos importantes que hay que
tener presente en el análisis estructural. Figura 8. Esquema del análisis estructural / Fuente: elaboración propia
3.4 Barreras de entrada

En un sector con pocas barreras de entrada serán muchos los que intenten competir y se trata de un sector
muy atomizado. Por el contrario, la existencia de barreras de entrada fuertes hará que los competidores
se lo piensen dos veces antes de entrar a participar en el sector, e incluso los competidores existentes
traten de unir sus fuerzas.
Siguiendo con las definiciones del modelo, se definirá barrera de entrada como aquel “elemento que hace
que un nuevo competidor tenga más difícil ganar dinero que uno existente”. De acuerdo con esta
definición, el capital o la inversión financiera necesaria no podría ser considerada como una barrera de
entrada, ya que si alguien puede conseguir financiación suficiente, estaría dentro del sector con las mismas
condiciones que los competidores previos.

De hecho, sólo existen tres tipos de barrera de entrada, que son las economías de escala, la diferenciación
y las normativas legales:
 La economía de escala se da cuando gracias al alto volumen de producción o distribución alcanzado

por una empresa sus costes unitarios de producción se reducen y, en consecuencia, se producen
grandes ahorros económicos en los procesos de negocio. En este sentido, un claro ejemplo de
economía de escala puede ser la empresa Microsoft y su sistema operativo Windows. El hecho de
que este sistema esté tan extendido como lo está, hace prácticamente imposible la aparición de
nuevos competidores y el sector está muy concentrado (de hecho finalmente aparecen acusaciones
de monopolio y oligopolio).
 La diferenciación de la empresa o sus productos respecto a la competencia se presenta cuando se
ha creado un vínculo efectivo entre producto y cliente, de manera que este estará dispuesto a pagar
un precio mayor. Un claro ejemplo de esto es cuando un cliente está dispuesto a pagar un 40% de
más por una camiseta respecto a otra idéntica, sólo porque la primera luce un símbolo con un
caballo o un cocodrilo. Otro ejemplo de barrera de entrada por diferenciación es la empresa Coca-
Cola: actualmente, no sería una misión fácil lanzar una bebida refrescante que pudiera hacer frente
a esta compañía americana.
 Las normativas legales son un tipo de barrera de entrada especial, ya que la empresa está
condicionada a la existencia de normativas y directrices “artificiales” que hacen más difícil la
existencia de competidores. Este podría ser el caso de los estancos o las farmacias en España,
limitadas (entre otros factores) por el censo de habitantes en una zona.
3.5 Barreras de salida

Las barreras de salida son otro condicionante que puede hacer más o menos atractivo un sector. Las
barreras de salida son aquellos elementos que les impiden a los competidores abandonar fácilmente un
sector. Las barreras de salida pueden hacer que los competidores dentro de un sector no tengan otra
opción que enzarzarse en una guerra de precios y, por consiguiente, hacer menos atractivo el propio sector.
Los principales casos en los que las barreras de salida constituyen este tipo de problemática se produce
cuando se da una combinación de elevados costes fijos y capacidad ociosa. Por ejemplo, en el sector de los
buques que transportan aceites, los propios barcos no se convirtieron en barrera de salida cuando se
empezaron utilizar para almacenar trigo en puerto.
En un sector sin importantes barreras de salida, los competidores pueden abandonar fácilmente la guerra
y el propio sector se regula.

Como se ha expuesto, el concepto de competencia está fuertemente ligado al de barreras de salida. En un

momento determinado en que las ventas caigan, en un sector donde las barreras de salida sean
relativamente fáciles de superar, los competidores preferirán abandonar el sector y la competencia entre
ellos no será excesivamente feroz. En cambio, en estas mismas circunstancias, unas barreras de salida muy
elevadas hacen que no sea fácil abandonar el sector (por ejemplo se tiene una maquinaria pesada que no
puede ser utilizada en otras tareas), los competidores no tendrán más remedido que aferrarse al mercado,
la competencia sea muy dura, y muy probablemente se desencadene una guerra de precios, y se haga más
complicado que alguien pueda ganar dinero.
3.6 Clientes
El último agente que puede definir la bondad de un sector es la naturaleza de los propios clientes y de las
propiedades que valoren los productos o servicios ofertados. Las empresas deben estudiar qué atributos
de sus productos son realmente apreciados por sus clientes y cuáles no. Estos atributos “valorados” pueden
variar en el tiempo, y cuando los clientes valoraban cierta cualidad relacionada por la salud (por ejemplo
un producto bajo en calorías) pueden pasar a valorar únicamente el precio del producto (por ejemplo si en
el mercado existieran cinco productos con las misma cualidades principales).
Si los clientes no valoran ninguna diferencia entre los productos (como es el caso de las commodities), los
participantes del sector se verán abocados a una guerra de precios, puesto que este será el único atributo
que atraiga a los clientes hacia sus productos. Así pues, este sería uno de los peores escenarios, y las
empresas hacen muchos esfuerzos e inversiones para tratar de evitarlos por medio de campañas de
marketing o intentado que el cliente valore otros atributos de sus productos. La idea siempre es intentar
vincular emocionalmente al cliente con los productos de la compañía.
3.7 Necesidad de las TIC en las diferentes

estructuras organizativas
Las organizaciones son sistemas cuyos elementos integrantes son:
 La estructura: desde un punto de vista de coordinación, la forman las relaciones de autoridad y

distribución geográfica.
 Los recursos humanos.

 La tecnología: infraestructuras tecnológicas.
 El conjunto de los procesos y las actividades que constituyen los mecanismos operativos en los que
se basa la realización de los fines de la organización.
Cada uno de estos componentes puede determinar el uso de la información. El recurso información tiene
además características singulares (Glazer, 1993) que lo hacen diferente a los demás recursos y que
contribuyen a incrementar la dificultad de su manejo adecuado. Estas características son:
 Expansibilidad. A diferencia del carbón, los automóviles, los alimentos o la ropa, la información
crece y mejora con el uso. Cuantas más personas se interesan y usen una Base de Datos (BD), tanto
más interés habrá en tenerla actualizada y disponible.
 Difusividad. Tiende a difundirse o filtrarse, siendo difícil mantenerla secreta.
 Compartible. Si doy comida o vendo un coche, dejo de tener esos recursos, si doy información no
dejo de poseerla, sino que tanto el dador como el receptor la comparten.
 Interpretativa. El recurso información es algo más que el recurso físico o dato; requiere de una
interpretación de los datos dentro de un contexto determinado.
 Sorpresiva. La información debe tener un “efecto sorpresa”, debe aportar luz sobre algo
desconocido. La información que no sorprende es probablemente irrelevante o redundante.
 Sin valor intrínseco. Si pierdo un diamante y el papel con la dirección del único joyero capaz de
tallarlo, el que se encuentre el diamante mantendrá el valor de este, pero el que se encuentre el
papel con la dirección no podrá darle ningún significado y consiguiente valor.
 Recurso de apoyo y estratégico. El coste de la información crece con la precisión, cantidad, calidad,
rapidez de respuesta y distribución. Proporcionar la información adecuada, en el momento
adecuado, a la persona adecuada, con el mínimo coste, es el objetivo tradicional del SI (punto de
vista de apoyo a los demás subsistemas de la empresa). Sin embargo, con ser importante lograr
dicho objetivo, está orientado a mejorar la productividad o la eficiencia.
Como se puede evidenciar en la figura 9, la introducción de las TIC tiene un notable impacto estructural en
la organización y permite transformar
prácticas y dinámicas consolidadas de la
organización. Esto se produce
especialmente en la organización mediante
integración vertical de la cadena de mando,
y horizontal de la cadena de valor, sobre
todo en virtud de una alineación de la
Figura 9. Procesos de negocio con TIC / Fuente: elaboración propia

arquitectura de los sistemas de información con las estructuras de la organización afectadas, y también
gracias a las oportunidades vinculadas al hecho de compartir la información y a las posibilidades de acceder
a ella.
Gracias a la posibilidad de compartirla y utilizarla de forma integrada en contextos distintos del que la ha
producido, la información se traduce en conocimiento y se hace evidente la importancia de los
instrumentos destinados a favorecer la producción y multiplicación de dichos procesos.
La compartición de información también es uno de los principios propuestos por Hammer (1994) para el
“rediseño de los procesos” desde una perspectiva interdepartamental (reingeniería), con el objeto de
transformar actividades fragmentadas con estructuras mecanicistas en tareas integradas y orgánicas, por
medio de la combinación, eliminación y reprogramación del trabajo. Esto permite romper muchas tareas
secuenciales tradicionales que pasan a poder ejecutarse en paralelo. La capacidad de las TIC para romper
las restricciones de tiempo y espacio de muchas tareas es uno de los principales parámetros a considerar
en el alineamiento estructural de las TIC.
Por todo lo anterior, el potencial que pueden alcanzar los progresos en bases de datos, y el desarrollo de
metodologías y técnicas de integración de las fuentes, permiten beneficiarse de un patrimonio organizado
de información y conocimientos inimaginables hasta hoy, y aprovecharlos para fines productivos.
También conviene destacar que las TIC son neutrales a la hora de su uso en la organización, todo depende
de qué orientación se les quiera dar. Pueden usarse para centralizar, para descentralizar, e incluso para
tratar de lograr las ventajas de ambas estructuras evitando sus inconvenientes. Así se puede tener la
eficiencia y el control de la organización centralizada sin los problemas típicos de burocracia o lentitud, al
mismo tiempo que la flexibilidad y capacidad de respuesta de la descentralizada, sin los problemas de
duplicación de recursos y costes. Esto ya es realidad en algunas empresas con estructuras híbridas de tipo
matricial y red apoyadas en TIC.
La vinculación de las TIC en los procesos de las organizaciones destacan un valor importante para la
empresa y para el cliente, ya que esto sirve para poder llevar a cabo el desarrollo de estrategias y modelos
de negocio, así como también una arquitectura tecnológica para aplicaciones de negocio.

3.8 Procesos y mapas de actividades

Una vez establecida claramente la estrategia por medio de la cual la empresa buscará sus metas, será el
momento de diseñar con detalle cada uno de sus procesos operativos. Con el fin de buscar una ventaja
competitiva a partir de su estrategia, cada una de las diferentes tareas que conformen estos procesos
tendrán que ir alineados con la forma de competir que la empresa haya seleccionado: liderazgo en costes
o diferenciación.
De una forma más detallada, estas dos estrategias básicas se pueden descomponer en otras seis estrategias
específicas cuya combinación y éxito de ejecución darán como resultado alcanzar las ventajas competitivas
buscadas y descritas en la estrategia principal. Estas estrategias específicas son las siguientes:
 Flexibilidad en diseño y volumen. Por ejemplo, la capacidad de algunas empresas con amplios
departamentos de investigación y desarrollo que introducen novedades constantemente en sus
productos o servicios.
 Precios reducidos. El ejemplo quizá más claro de esta estrategia son las líneas aéreas de bajo coste.
 Calidad de entrega de producto o servicio. Todas las campañas de garantías y devoluciones en casos
de incidencias van en este sentido. También las entregas garantizadas en cierto plazo de tiempo.
 Calidad en las prestaciones del producto o servicio. Las empresas que siguen esta estrategia buscan
reducir el número de productos defectuosos e implantan técnicas y sistemas de calidad total en sus
procesos.
 Servicio posventa excelente. Las empresas que “cuidan” a sus clientes y les dan un trato cuidadoso
una vez finalizada la venta buscan fidelizar a sus clientes por medio de esta estrategia.
 Amplia gama de productos. Sería el caso, por ejemplo, de las entidades bancarias o de inversión.
En cualquier caso, para lograr llevar a la práctica cualquiera de estas estrategias, las empresas deberán
definir correctamente sus procesos e implementar correctamente sus actividades. Desde el punto de vista
de la dirección de operaciones, para definir estas actividades se tienen que tomar importantes decisiones
que pueden ser agrupadas en las siguientes diez áreas:
 Diseño de bienes y servicios. En la mayoría de las ocasiones, el diseño de los productos marcará, en
gran medida, los costes de producción y distribución de estos. En este sentido, tanto el diseño de
los productos y materiales asociados como los embalajes serán claves para el posterior proceso
productivo.
 Calidad. La calidad del producto o servicio (en incidencias, prestaciones, personalización, etcétera)
percibida por el cliente será vital para determinar el éxito o fracaso de una determinada actividad.

 Diseño del proceso y de la capacidad. Los procesos productivos utilizados y las tecnologías aplicadas
determinarán de forma crítica la productividad y eficiencia de las empresas.
 Elección de la localización. La determinación de la ubicación física de las plantas de producción o de
la empresa puede ser un factor clave y permitir ahorrar importantes inversiones económicas. Por
ejemplo, situando las fábricas cerca de caudales de agua naturales.
 Diseño del layout. Dentro de las plantas productivas se pueden producir grandes ahorros de costes
y tiempo si los diseños de las propias plantas son adecuados, produciéndose sinergias entre
procesos y evitando la acumulación de stocks de productos semielaborados innecesarios.
 Recursos humanos. La capacitación de las personas que tienen que realizar el trabajo puede ser
clave si el proceso requiere un alto nivel de especialización. En cambio, si los procesos son simples
y automáticos, el perfil requerido puede ser diferente. La formación continua puede llegar a ser una
ventaja competitiva en sí misma.
 Gestión de la cadena de suministros. Los procedimientos de calidad y proceso de las empresas
también deben tener en cuenta la interacción con socios estratégicos y proveedores para
integrarlos dentro de la estructura diseñada de la mejor manera.
 Inventario. Las decisiones sobre plazos de entrega, variedad de gama de productos, niveles de
calidad de entrega, etcétera marcarán los niveles de stock que la empresa tendrá que soportar.
 Programación. Las hojas de ruta o programación de la fabricación deberían permitir el ahorro de
tiempos muertos o desperdicios en los procesos fabriles.
 Mantenimiento. Las decisiones sobre mantenimiento o posventa determinarán la relación final
entre las empresas y sus clientes.
Las decisiones tomadas sobre estas diez áreas serán determinantes para la consecución o no de ventajas
competitivas que les permitan a las empresas competir en mejores condiciones dentro de sus mercados,
siguiendo en todo momento la estrategia principal que se haya seleccionado.
La figura 10 muestra la relación entre las decisiones de las operaciones, las estrategias específicas utilizadas
y las estrategias principales
seleccionadas. En la figura se aprecia
la secuencia de mayor operatividad a
mayor nivel estratégico.
A partir de las decisiones tomadas en

cada una de estas diez áreas, se
deberá determinar el mapa de
actividades dentro de la Figura 10. Decisiones operativas y estrategias específicas
Fuente: Heizer y Render, 2007
organización. En un mapa de
actividades se plasman los principales procedimientos de las empresas, desglosando estos procesos en las
diferentes tareas o actividades que los componen y definiendo los flujos de información y trabajo que se
generarán.
Dentro del mapa de actividades existen algunas tareas críticas o factores críticos de éxito que tendrán que
cumplirse obligatoriamente para alcanzar los objetivos especificados por la estrategia y las ventajas
competitivas asociadas.
Aunque dos empresas del mismo sector tuvieran un mapa de actividades muy parecido, serán los factores
críticos de éxito, seleccionados por cada una de ellas, los que hagan que una pueda tener éxito y quizá la
otra no.
Como ya se ha comentado, todos los procesos de la empresa estarán alineados con la estrategia de bajo
coste, y en este sentido irán orientados todos los factores de éxito de la compañía.
3.8.1 Identificación de los procesos dentro de la

organizaciones
Al iniciar la definición de procesos, es de vital importancia tener en cuenta el tamaño de la organización, al
igual que el número de actividades que esta realiza. De acuerdo con lo anterior, uno de los primeros pasos
que es necesario tener en cuenta para poder gestionar correctamente es la identificación de estos.
Toda empresa lleva a cabo actividades que, al agruparlas, se convierten en procesos, los cuales interactúan
entre sí permitiéndoles a las organizaciones tener un funcionamiento adecuado. La identificación de las
actividades dentro de las empresas suena fácil de hacer pero no es así. Lo anterior se comprueba cuando
las empresas se dan cuenta de todas las cosas que deben realizar y por mala definición no se realizan o se
hacen de manera equivocada, esto debido a que no está bien definida la identificación.
Una manera fácil de saber lo que se realiza dentro de una organización es desarrollar un organigrama por
medio del cual se pueda extraer lo que hace cada dependencia o personal de la compañía. Al realizar este

ejercicio lo más seguro es que se encuentre un número n de actividades dependiendo del tipo de
organización.
Al definir los procesos se debe tener en cuenta que no se deben incluir un gran número de actividades por
proceso puesto que puede resultar excesivo y se presentarán dificultades para procesar. Así mismo, no se
deben incluir un número bajo de actividades, ya que esto generaría una gran cantidad de procesos. Es
importante no implicar un gran número de departamentos o dependencias por proceso, al igual que la
responsabilidad de la gestión de procesos es de todos los que forman parte de las actividades que se
realizan dentro de cada proceso.
3.8.2 Procesos dentro de las organizaciones

 Procesos estratégicos. Dentro de este grupo se encuentran cada uno de los procesos relacionados
con la planificación de mediano y largo plazo. Procesos relacionados con la revisión de los sistemas
de gestión, procesos de establecimiento de políticas y objetivos, entre muchos otros.
 Procesos de soporte. Aquí se relacionan cada una de las actividades que aunque no son parte de la
actividad principal de la empresa, sí juega un papel importante dentro de la organización y son
necesarias para llevar a cabo una buena gestión y desarrollo dentro de esta. Algunos ejemplos son
servicios generales, limpiezas, mantenimiento, etcétera.
 Procesos de medición. Los procesos de medición dentro de las organizaciones son los que brindan
la información de cómo se están llevando a cabo las actividades dentro de la organización y en qué
estado se encuentran. Son los procesos relacionados con auditoría, análisis de datos e inspección,
control y calidad.
 Procesos asistenciales. Son los procesos que forman parte de la actividad de la organización, los
cuales están relacionados con lo que se hace.
En la figura 11 se puede evidenciar que después de

que se identifiquen las actividades, el proceso a
seguir es definir la gestión de estas por medio de
procesos.
A partir de las decisiones tomadas en cada una de

estas diez áreas, se deberá determinar el mapa de
actividades dentro de la organización. En un mapa de
actividades se plasman los principales
procedimientos de las empresas, desglosando estos Figura 11. Mapa de procesos / Fuente: Javier Cabo

procesos en las diferentes tareas o actividades que los componen y definiendo los flujos de información y
trabajo que se generarán.
Dentro del mapa de actividades existen algunas tareas críticas o factores críticos de éxito que tendrán que
cumplirse obligatoriamente para alcanzar los objetivos especificados por la estrategia y las ventajas
competitivas asociadas.
Aunque dos empresas del mismo sector tuvieran un mapa de actividades muy parecido, serán los factores
críticos de éxito, seleccionados por cada una de ellas, los que hagan que una pueda tener éxito y quizá la
otra no.
Como ya se ha comentado, todos los procesos de la empresa estarán alineados con la estrategia de bajo
coste, y en este sentido irán orientados todos los factores de éxito de la compañía.
3.8.3 Análisis y modelado de los procesos en las

empresas
Las organizaciones actuales —y sobre todo las empresas— necesitan cada vez más apoyarse en un modelo
organizativo que facilite su relación e interacción con los demás agentes económicos. El simple intercambio
de información ya no es suficiente en sectores de comercio electrónico o negocio electrónico, donde
incluso es imprescindible emplear estándares para el intercambio de datos.
El modelado de organizaciones (Business Modeling) ya se viene empleando en el diseño de las

organizaciones y hasta cierto punto en proyectos de desarrollo de software. Esta metodología permite
clarificar la responsabilidad y las funciones que los sujetos tienen dentro de la organización, y especifica al
mismo tiempo los distintos procesos organizativos y el flujo de información entre ellos. El business
modeling se ha desarrollado más a partir de la definición de lenguajes de modelación estándares (por
ejemplo UML, Architecture of Integrated Information Systems ARIS,...) que se utilizan para representar los
procesos organizativos.

El empleo de “objetos” (objects) ha facilitado la producción de modelos intuitivos de las empresas y

organizaciones, sus procesos y sistemas. Un objeto permite describir cualquier proceso o fenómeno como
un conjunto de otros objetos interactuantes; un objeto de negocio (business object) incluye objetos más
simples —y sobre todo más reconocibles por los usuarios— que constituyen los procesos organizativos del
negocio (actores, departamentos, documentos, sistemas, etcétera). El uso de estos objetos permite
además modificar rápidamente la organización de los procesos del negocio, para adaptarlos a los cambios
en el entorno donde se mueve la empresa.
Para tratar de manera reducida la complejidad que todo proceso de negocio conlleva, se empieza por
delimitar el dominio de estudio o área de interés y a identificar en estos los objetos y los roles que tienen
con un modelo de roles que define, en particular, la interacción entre objetos. El uso conjunto de los
modelos de objetos y roles permite describir la empresa en todos sus niveles, sistemas, funciones,
actividades, etcétera.
El análisis de un sistema empresarial también requiere la identificación del entorno en el que opera la
empresa, su comportamiento frente a las amenazas y oportunidades de negocio que ofrece el entorno, así
como la determinación interna de las interacciones y conexiones entre sus divisiones organizativo-
funcionales y sus procesos de negocio.
Este análisis organizacional cubre nuevos procesos de negocios o reorganiza los existentes y suele dirigirse
por equipos de expertos en ámbitos empresariales diversos: tecnologías de información, desarrolladores
de software, expertos en marketing.

Resumen 1:
La Gestión de Procesos de Negocio es una disciplina de modelado, automatización,
gestión y optimización de procesos de negocio a través de su ciclo de vida con el objetivo de
aumentar la rentabilidad de la compañía que los ejecuta. Estos procesos cruzan departamentos,
unidades de negocio y organizaciones involucrando distintas aplicaciones, recursos humanos y
culturas.
Resumen 2:
El éxito de los proyectos TI radica en la necesidad de fusionar la definición de los
procesos (componente normativo y de organización) con la mecanización de estos (sistemas de
información). En otras palabras, es necesario que el “proceso” y la “normativa” se integren y se
soporten en el sistema de información.

Nombre Descripción
Estrategia competitiva: Ventaja Documento que amplía la información de la cadena
competitiva y la cadena de valor. valor y su importancia como estrategia y ventaja
https://competitivestrategy404a.files.w competitiva. Leer documento completo.
ordpress.com/2011/06/ventaja_competi
tiva_y_cadena_de_valor-informe.pdf
La cadena de valor como herramienta de Este artículo fortalece y da a conocer cómo se
gestión para una empresa de servicios puede manejar la cadena de valor como una
http://sisbib.unmsm.edu.pe/bibvirtual/p herramienta de gestión en las empresas.
ublicaciones/indata/v16_n1/pdf/a03v16 Leer documento completo.
n1.pdf

Glosario
Auditoría
Proceso que se lleva a cabo mediante la agrupación y evaluación de evidencias para determinar si se
cumplen los procesos de forma eficaz dentro de la organización.
BPM
Business Process Management, metodología utilizada en las organizaciones para gestionar todos los
procesos de negocio que buscan mejorar y optimizar con eficiencia y eficacia los procesos que se manejan
dentro de la organización.
Mapa de procesos
Aquel mapa que presenta una visión general del sistema organizacional de una empresa en el cual se
plasman sus procesos más relevantes.
Proyecto
Planeación de un conjunto de actividades que se encuentran interrelacionadas y coordinadas con el fin de
alcanzar los objetivos propuestos dentro de los límites de calidad, presupuesto y tiempo.

Bibliografía y Webgrafía
Aneja, A. (2007). 3 Steps for Aligning Project to Business Priorities. BPMEnterprise.com. Recuperado de
http://www.bpmenterprise.com/content/c070326a.asp?action=print
Cabo, Javier. (2005). La Gestión por procesos.
Glazer, R. (1991). Marketing in an information-Intensive Environment: Strategic Implications of knowledge
as an Asset, JOURNAL OF MARKETING, Vol. 55, oct, pp. 1-19.
González Ladrón de Guevara, F. (2008, abril). Sistemas de gestión empresarial (ERP), una ayuda para
orientarse hacia el cliente. Aitex Review, 26-27.
Hammer, (1994). Reengineering work.
Heizer y Render. (2007). Dirección de la producción y de Operaaciones. Decisiones Tacticas. Pearson
Education, Octava edicición.
Jeston, J. y Nelis J. (2006). Business Process Management. Practical Guideliness to Successful
Implementations. Elsevier. London.
Khan, R. (2004). Business Process Management: A Practical Guide. Meghan-Kiffer Press.Tampa, FL.
Menezes, A. y González Ladrón de Guevara, F. (2009). Estrategia BPM. Seminario Internacional Business
Process Management. Joinville, Brasil.
Porter, Michael. (1980). Estrategia Competitiva: Técnicas para analizar Industrias y Competidores
Sharp, A. y McDermott, P. (2001). Workflow Modeling: Tools for Process Improvemen and Application
Development. Norwood, MA, USA: Artech House Inc.
Smith, R. F. (2006). Business Process Management and the Balanced Scorecard: Using Processes as Strategic
Drivers. John Wiley & Sons. New York.
Vindel, Juan. (2012). Director de Desarrollo Corporativo de UNION FENOSA. Madrid, España.

Créditos
El curso Arquitectura Empresarial, con metodología virtual, es propiedad de la Universidad Cooperativa
de Colombia y hace parte de la Maestría en Gestión de Tecnologías de la Información. Algunas imágenes
se relacionan con su respectiva fuente y otras fueron creadas por el autor de los contenidos, con el diseño
posterior del equipo de producción. El contenido del curso está protegido por las leyes de derechos de
autor que rigen al país.
Este material tiene fines educativos.
Autor
Fernando Prieto
Bustamante
Ingeniero de Telecomunicaciones de la Universidad Santo
Tomás. Especialista y Magíster en Consultoría en Integración
de las TIC en las Organizaciones, de la Universidad Politécnica
de Valencia, España (UPV). Magíster en Redes Corporativas e
Integración de Sistemas de la UPV. Magíster en Diseño y
Gestión de Proyectos Tecnológicos de la Universidad
Internacional de la Rioja.
Coordinador de Internacionalización de la Facultad de Ingeniería de Telecomunicaciones, docente de las

asignaturas Introducción a la Ingeniería, Investigación, y Gestión de Servicios en Telecomunicaciones,
Coordinador del Área de Administración en la Universidad Santo Tomás.
Director de proyectos de investigación en la Universidad Manuela Beltrán.

Responsable Académico
Marlene Lucia Guerrero Julio
Decana – Facultad de Ingenierías – Sede Bucaramanga
Ing. Lina María Torres Barreto
Coordinadora Maestrías Ingenierías – Facultad de ingenierías
Dirección General
Dirección Nacional de Innovación y
Tecnologías Educativas
Producción y Montaje
Subdirección E-learning
Angélica Ricaurte Avendaño
Subdirectora Nacional E-learning
Enry Doria Doria
Especialista en Diseño Instruccional
Camilo Toscano Rojas
Especialista en Producción
Jaime Eduardo Gómez Arango
Programador
Daniel Morales Rojas

Administrador de Plataforma
Mario Fernando Castaño
Diseñador Gráfico
María Alejandra López Vanegas
Practicante E-learning
Corrección de estilo
Fondo Editorial "Ediciones Universidad Cooperativa de Colombia”
Tercera Versión. Junio de 2015
Derechos Reservados
Esta obra es publicada bajo la licencia CreativeCommons. Reconocimiento-No Comercial-Compartir Igual

2.5 Colombia.

Arquitectura Empresarial U2

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitectura Empresarial U2

Cargado por

Copyright:

Formatos disponibles

Arquitectura Empresarial | Unidad 2.

Universidad Cooperativa de Colombia 1

1. Los procesos de negocio en el marco

1.2 Definición de Business Process

Universidad Cooperativa de Colombia 2

1.3 Modelado de los Procesos de Negocio

Universidad Cooperativa de Colombia 3

El modelado de procesos presenta las etapas de

Universidad Cooperativa de Colombia 4

optimización de los procesos que juega un papel importante en la actualidad.

1.4 Definición de workflow

 Su representación gráfica: mapa de procesos y diagramas de proceso.

1.5 Arquitectura de proceso

Universidad Cooperativa de Colombia 5

1.5.2 Auditoría de procesos

Universidad Cooperativa de Colombia 6

1.5.3 Mapa de sistemas

Universidad Cooperativa de Colombia 8

1.6 Procesos interfuncionales

Universidad Cooperativa de Colombia 9

1.6.1 Mapa de procesos

1.6.2 Modelado de procesos

Universidad Cooperativa de Colombia 10

1.6.3 Modelado de Procesos ( AS-IS Processes)

Universidad Cooperativa de Colombia 11

 Nombre del proceso utilizando un formato verbo-nombre.

Universidad Cooperativa de Colombia 12

Universidad Cooperativa de Colombia 13

Proceso de diseño de producto

Universidad Cooperativa de Colombia 14

1.6.4 Modelado de Procesos (TO-BE Processes)

Universidad Cooperativa de Colombia 15

Universidad Cooperativa de Colombia 16

Universidad Cooperativa de Colombia 17

Universidad Cooperativa de Colombia 18

2. Análisis de brecha, definición y

2.2.1 Concepto de proyecto y su gestión

Universidad Cooperativa de Colombia 20

necesidades y expectativas de las partes interesadas en el proyecto. La gestión de un proyecto debe

 Especificaciones, tiempo, coste y calidad.

2.3 Características de los

 Discontinuidad: falta de familiaridad o habitualidad. Supone algo innovador, algo que no es

2.4 Objetivos del proyecto

Universidad Cooperativa de Colombia 21

Universidad Cooperativa de Colombia 22

2.5 Ciclo de vida del proyecto

Habitualmente la etapa que más tiempo y recursos consume es la correspondiente a la implementación

2.5.1 Concepción del proyecto

Universidad Cooperativa de Colombia 23

Universidad Cooperativa de Colombia 24

2.5.3 Análisis de viabilidad

2.5.5 Entrega y puesta en marcha

Universidad Cooperativa de Colombia 25

2.5.7 Evaluación o balance

2.6 Actores relacionados con el proyecto

2.7 Modelo de desarrollo de un proyecto TIC

Universidad Cooperativa de Colombia 26

El anteproyecto TIC es un conjunto de documentos que determinan concreta y concisamente, con

Universidad Cooperativa de Colombia 27

Figura 6. Modelo de desarrollo proyecto TIC. / Fuente: elaboración propia

2.8 Planes de contingencia

Universidad Cooperativa de Colombia 28