ARQUITECTURA TECNOLOGICA EMPRESARIAL SEMANA 2

 Introducción a la ingeniería empresarial

o Métodos y frameworks de las estructuras empresariales
o PRISM
o ARIS
o ZACHMAN
o FEAF
o DODAF
o EAP
o Gestión de portafolio de IBM

PRISM: Es un marco para construir aplicaciones XAML sueltas, mantenibles y comprobables en

WPF y Xamarin Forms. Hay versiones separadas disponibles para cada plataforma y se
desarrollarán en línea de tiempo independientes. Propone buenas prácticas para la administración
de proyectos de aplicaciones compuestas para WPF

ARIS: tiene un enfoque orientado hacia el modelado de empresas. Ofrece métodos y

recomendaciones para un análisis de los procesos de una organización con una perspectiva
holística de ellos. Los mira de manera transversal a través de toda la organización considerando los
flujos de trabajo y sus diseños y el procesamiento de todas las solicitudes de consumo de
productos o artefactos

ZACHMAN: proporcionar una estructura lógica para organizar y clasificar las representaciones
descriptivas para su gestión así como para el desarrollo de los sistemas empresariales

FEAF: fue desarrollado por el consejo de directores de la información (CIO) con la finalidad de
promover la interoperabilidad, el desarrollo compartid de procesos federales comunes y el
intercambio de información entre agencias del gobierno federal y otras entidades
gubernamentales

EAP: se trata de un enfoque desarrollado en los 80´s, que se planteó una respuesta al problema de
la integración de la tecnología con la estrategia de negocio

DODAF: permite integrar reglas, elementos de datos y relaciones entre empresas de interés desde
la perspectiva eje rectoral de ambas organizaciones para alinear sus sistemas e información de
manera común

Gestión de portafolio de IBM: se centra en asegurar qué programas y proyectos tienen prioridad
para asignar recursos (personas, presupuestos…) que sean consistentes y estén alineados con la
estrategia organizativa
Introducción a los frameworks
En este momento se va a tratar el tema de los métodos y frameworks de estructuras
empresariales, ampliamente aceptados para su aplicación en los negocios

Un framework de arquitectura empresarial es un marco estructural que define cómo crear y usar
una arquitectura empresarial. Este proporciona principios y prácticas para crear y usar la
descripción de arquitectura de un sistema. Además ayuda a estructurar el pensamiento de los
arquitectos o ingenieros, dividiendo la descripción de la arquitectura en dominios, capas o vistas

Objetivos de los frameworks

Proporcionar soluciones tangibles más allá de solo la TI, integrando todas las capas de la empresa,
incluida la estrategia general, las necesidades comerciales y las aplicaciones

Características más importantes de algunos de los frameworks que

existen
Marco PRISM
Propone buenas prácticas para la administración de proyectos de aplicaciones compuestas para
WPF. Este marco de referencia marca la ruta a trabajar en aplicaciones del tipo WPF y Silverlight
que tienen solamente una base de código, ayudando a desarrollar la aplicación de cliente de una
manera modular, por lo que la complejidad de una aplicación puede ser dividido en módulos más
pequeños

Marco ARIS
Es un marco de referencia de arquitectura de sistemas de información integrados (Architecture of
Integrated Information Systems). Su enfoque está orientado hasta el modelado de empresas, por
lo que ofrece métodos y recomendaciones para hacer un análisis de los procesos de una
organización con una perspectiva holística. Trabaja sobre cuatro perspectivas las cuales son: la
perspectiva organizacional, la perspectiva de datos, la perspectiva de control y la perspectiva
funcional

Marco ZACHMAN
Pertenece a los marcos generales para el modelado empresarial. Este proporciona una estructura
lógica para clasificar y organizar las representaciones descriptivas de una empresa que son
significativas para su gestión, así como para el desarrollo de los sistemas empresariales. Se trata de
un diagrama de dos ejes. El primero son los fundamentos de la comunicación traducidas en
interrogativas abiertas, tales como: ¿qué, cómo, cuándo, quién, dónde y, por qué? El segundo se
trata de las fases de la ingeniería
Marco FEAF
Fue desarrollado con la finalidad de promover la interoperabilidad, es decir, el desarrollo
comparativo de procesos fundamentales comunes y el intercambio de información entre agencias
del gobierno federal y otras entidades fundamentales

Marco DoDAF
Fue desarrollado por el departamento de defensa de USA, con el fin de integrar reglas, elementos
de datos y relaciones entre empresas de interés desde la perspectiva de ambas organizaciones,
para alinear sus sistemas e información de manera común. Su propósito es definir conceptos y
modelos que pueden utilizarse en seis procesos básicos:

1. Capacidad de integración conjunta y de desarrollo

2. Planificación, programación, presupuesto y ejecución
3. Sistemas de adquisición de defensa
4. Ingeniería en sistemas
5. Planificación de operaciones
6. Capacidad de gestión de la cartera

Marco EAP
Se planteó como una respuesta al problema de la integración de la tecnología con la estrategia de
negocio. Consiste en la planificación e implementación de la definición de las arquitecturas dentro
de una organización

La complejidad del sistema que representa a una organización, hace que sea muy difícil realizar
una integración en todas sus partes, sin embargo los frameworks de arquitectura empresarial,
fueron creados para cumplir ese papel, de la manera más sencilla posible

Los marcos pueden variar debido a que algunos enfatizan puntos de vista estratégicos de alto
nivel, otros pueden enfocarse en una fase de planificación de capacidades y muchos proporcionan
formas de estructurar los datos comerciales, la tecnología y los diseños de infraestructura. Por lo
que elegir uno u otro depende del objetivo

THE ZACHMAN INTERPRICE FRAMEWORK

El origen y el propósito del Framework ZACHMAN en la empresa

El framework Zachman fue inventado por Jonh Zachman en 1980 por IBM y ahora es de dominio
público. El framework pide prestado del diseño de negocio sus principios, arquitectura y
manufactura y provee una manera de ver el negocio y su sistema de información desde diferentes
perspectivas, y enseñando como los componentes del negocio son relacionados

Los entornos empresariales complejos de hoy en día, muchas organizaciones grandes tienen gran
dificultad de respuesta al cambio. Parte de esta dificultad es debido a la falta de áreas en la
organización, donde el legado de la información sobre el negocio está bloqueado lejos de la mente
de empleados específicos o unidades de negocio, sin hacer algo explícito

El Framework Zachman proviene de un significado de clasificación de la estructura organizacional.

Es una herramienta de negocios proactiva, la cual puede ser usada como modelo de organización
de funciones existentes, elementos y procesos – y ayuda a los gerentes de cambio de negocio. El
Framework dibuja la experiencia de Zachman en como el cambio es administrado en productos
complejos tal como los aviones y construcciones

Aunque el Framework puede ser usado por sistemas de arquitecturas de información y es

extensamente adoptada por sistemas analíticos y diseños de database, John Zachman destacó que
se extiende a toda la arquitectura empresarial, y no está restringida a una simple arquitectura de
información

El Framework empresarial Zachman es presentado y promovido por la organización ZIFA. No es un

estándar y hay similares framework empresariales que se derivan de ella, tal es el caso de FEAF,
TOGAF, DoDAF

El Framework proporciona una consistente y sistemática manera de describir una empresa y ha

sido empleada por muchas organizaciones, tales como: Vokswagen, GM, Bank of America, etc.

Relevancia de las comunicaciones técnicas

Las comunicaciones técnicas están estrechamente involucradas en el diseño de información y
administración, si el nivel de usuario, diseño, integración y construcción. Tradicionalmente, sus
roles han sido asociados con la información/ el lado de la arquitectura de TI de una organización

La analítica de negocios está actualmente los principales proveedores de servicios de arquitectura

empresarial. Sin embargo, dado que el departamento de conocimiento de negocio y la experiencia
de administración de información que muchas comunicaciones técnicas pueden ofrecer,
documentando una arquitectura empresarial es potencialmente una comunicación técnica con un
gran nivel de entendimiento de negocio puede proveer

En adición, la manera de que el modelo Zachman está estructurado, en términos declara

desintegración de integración por audiencia y cuestiones de estándares, sería familiar ese trabajo
en disciplinas de comunicación, tal como comunicaciones técnicas

Usando el Framework Zachman para el manejo de un proyecto de

administración de conocimiento
Antes de introducir la arquitectura empresarial Zachman en un proyecto de documentación de
arquitectura, procesos y tecnología desplegada en el departamento de TI a lo largo de la
distribución de la organización
La tarea era más amplia que el rol técnica de comunicación técnica de documentación de un
producto o servicio específico. Involucro la gestión de un amplio espectro de conocimiento y
búsqueda de la más eficiente manera de capturar y compartir información sobre todos los
procesos, procedimientos, sistemas, aplicaciones y personas de la organización

El primer requerimiento fue por lo tanto la necesidad de un adecuado framework de organización

de información empresarial. El modelo empresarial Zachman fue sugerido un adecuado
framework para el proyecto

Cómo funciona
La manera más fácil de entender el framework arquitectura empresarial Zachman es verla como
una clasificación del esquema representado visualmente como una tabla o matriz, con columnas y
filas. Cada celda dentro de la matriz proviene de un único modelo o representación de la empresa.
La información en cada fila puede ser relevante a la persona en la empresa viéndolo

El Framework ofrece un conjunto de descriptivas representaciones o modelos relevantes para

describir una empresa

Cada celda en la tabla puede estar alineada con otra celda inmediatamente arriba o debajo. Todas
las celdas en cada fila deben estar alineadas con otra igual. Cada celda es única. Combinando las
celdas en cada fila forma una completa descripción de la empresa desde esa vista
Columnas de la matriz
Las preguntas representas las interrogantes o cuestiones que deben preguntarse a la empresa,
estas son:

 Qué (datos): ¿Cuáles son los datos del negocio, información u objetos?
 Cómo (función): ¿Cómo funciona el negocio, cuáles son los procesos de negocio?
 Dónde (red): ¿Dónde están las operaciones de negocio?
 Quién (personas): ¿Quiénes son las personas que trabajan en el negocio, cuáles son las
unidades de negocio y su jerarquía?
 Cuándo (tiempo): ¿Dónde están los procesos de negocio realizados, qué son los
pendientes y flujos de trabajo del negocio?

Los Frameworks habilitan temas complejos para ser destilados en categorías sistemáticas, usando
esas seis preguntas básicas. Las respuestas a esas preguntas harán la diferencia, dependiendo de
la perspectiva o audiencia

Las columnas pueden representar cualquier orden

Filas de la matriz
Cada fila representa una vista distinta de la organización, desde la perspectiva de diferentes
audiencias. Estas están ordenadas en un deseo de secuencia de prioridad

Una fila está asignada a cada una de las siguientes audiencias:

 Planificador: entendiendo el alcance del negocio y puede ofrecer una vista contextual de la
empresa
 Dueño: entendiendo el modelo del negocio y puede proporcionar una vista conceptual de
la empresa
 Constructor: desarrolla el modelo de negocio y puede construir la vista lógica de la
empresa
 Diseñador: produce el modelo de la tecnología y puede proporcionar una vista física de la
empresa
 Integrador (sub-contratista): entenderá representaciones detalladas de artículos
específicos de negocio, aunque tendrán una vista fuera de contexto de la empresa
 Usuario: provoca una vista de funcionamiento de la empresa, desde la perspectiva del
usuario
La primera fila de la matriz – la vista del planificador
Esta es la primera fila de la matriz. La vista del planificador de la empresa es contextual. El
planeador mira a requerimientos externos o controladores de negocio y está preocupado con la
representación de las funciones del negocio. La siguiente información es de interés al planeador:

Poniendo el Framework en práctica

Un punto lógico de empezar puede ser relevante en la parte superior izquierda de la matriz y
trabaja muy abajo y a través de la tabla. La información relevante del negocio o modelo usado a
representar un área específica del negocio puede existir en un plan de negocios formalizado,
proyecto, horarios, especificaciones del sistema, guía de procedimiento, organización de las tablas
y otros documentos corporativos

A medida de que avanzas en las filas y columnas de la matriz, habrá lagunas que necesitaran ser
llenas, donde la información implícita conocida por una sola persona o pocos expertos necesitan
hechos explícitos y habilitados a mayor audiencia. Habrá instancias de solapar o redundancia

Como comunicador técnico su rol puede ser asegurar la información que reuniste es compresiva,
fidedigna y categorizada apropiadamente. Al mismo tiempo, el objetivo del negocio es que puede
ganar un mejor entendimiento de la arquitectura de la organización, con la meta de la gestión del
cambio y reduciendo redundancias y traslapos

La información puede ser almacenada en la base de datos u otro sistema de gestión de archivos
que permite recuperarla. Las categorías de la matriz pueden ayudar al negocio a no solo
categorizar la información fácilmente, sino también recuperar fácilmente la información
reveladora

En mi proyecto en particular, creamos un sitio interno de soporte, con links a través de

información detallada, directamente desde la página de representación de filas y columnas de la
matriz
Recomendando el Framework para tu organización
El Framework empresarial Zachman puede ser vista como herramienta de creación de
conocimiento y clasificando el pensamiento, y como ayuda en el análisis y toma de decisiones. Es
una activa información estratégica que puede ayudar en la forma del negocio. Los beneficios
incluyen:

 Documentación disponible para la empresa

 Habilidad de unificar e integrar procesos de negocio y fechas alrededor de la empresa
 Aumenta la habilidad de negocios, bajando la barrera de la complejidad
 Reduciendo la entrega a tiempo y costo de desarrollo maximizando la reutilización de
modelos de empresa
 Habilidad de crear y mantener una visión común del futuro compartido por ambos, el
negocio y comunidades de TI

UN METODO PARA DEFINIR LA ARQUITECTURA DE PROCESOS

Introducción
Cualquier organización puede ser estructurada de acuerdo a tres niveles jerárquicos: estrategia,
procesos y sistemas de información. En la parte estratégica de la organización define sus
mercados, productos/servicios, objetivos y metas; en otros términos, se ocupa de los fines que se
propone conseguir. A nivel procesos la empresa instrumenta las operaciones de negocio
congruentes con los objetivos y metas estratégicas, mediante su estructuración en forma de
procesos de negocio; su propósito es proporcionar los métodos operativos necesarios para
alcanzar los fines delineados en la estrategia. En el mismo sentido, en el nivel de sistemas de
información se tiene por cometido automatizar los procesos de negocio en cuestión; es decir, su
propósito es dar el soporte de TI requerido por los medios establecidos para lograr los fines
estipulados, claro que para ello se apoya en la infraestructura tecnológica compuesta de
plataformas, sistemas operativos, BBDD, redes y telecomunicaciones

La arquitectura de procesos representa el conjunto de procesos esenciales en la empresa,

mostrando sus relaciones entre sí y sus interrelaciones con clientes y proveedores. Los procesos
esenciales son los encargados de crear y comercializar los productos y servicios de la empresa y
servicios de la empresa y constituyen la base para su ventaja competitiva. Ello significa que la
arquitectura de procesos se ubica en la realidad en el nivel estratégico y no en el nivel de procesos
como parecería a priori

Por otro lado, de manera concisa, ¿Cuáles son los procesos esenciales de una organización? La
respuesta a esta pregunta no es trivial, aunque así lo parezca, pues requiere de un entendimiento
detallado en la manera en que la empresa crea valor para los clientes. En el medio empresarial no
solo pocas personas tienen claridad del significado de la pregunta sino que sus respuestas parecen
surgidas de la inspiración divina o de un dogma formado por años de experiencia profesional. Por
el contrario, la literatura académica está plagada del uso de los términos de arquitectura de
procesos o de procesos esenciales pero sin plantear su identificación y definición de manera
explícita

El concepto de la arquitectura empresarial

La arquitectura empresarial es una disciplina que trata en forma integrada los aspectos de negocio
y de las TI, con el propósito de garantizar alineamiento entre las iniciativas/objetivos/metas
estratégicas/procesos de negocio y sus sistemas de soporte. Por ello normalmente se subdivide en
cuatro arquitecturas:

 La arquitectura del negocio se ocupa de la relación con la estrategia, de la organización y

de los procesos de negocio esenciales. En este bloque se ubica la arquitectura de procesos
 La arquitectura de datos describe los aspectos lógicos y físicos de los recursos de datos, así
como su correspondiente gestión
 La arquitectura de aplicaciones proporciona las bases necesarias para identificar las
aplicaciones que requiere el negocio
 La arquitectura tecnológica proporciona el soporte tecnológico requerido por las
aplicaciones, datos y procesos identificados en otras arquitecturas

El marco de referencia Zachman

El marco de referencia Zachman es una herramienta de pensamiento que permite organizar,
clasificar y analizar las diferentes descripciones arquitecturales o artefactos de una empresa

El marco de referencia es una matriz de 5 renglones por 6 columnas, donde cada tipo de artefacto
es caracterizado por una celdilla, lo que a su vez es resultado del cruce de un renglón y de una
columna. Cada renglón representa una perspectiva o vista de cierto rol participante en la empresa,
la cual es matizada por seis dimensiones en forma de interrogante

Las perspectivas
El planeador se ocupa del contexto de la empresa, de su entorno competitivo, de las fuerzas
internas y externas que influyen en su competitividad, del posicionamiento de sus productos y
servicios, que lo obligan a especificar sus alcances a lo largo del plazo; esta perspectiva cubre los
componentes del nivel estratégico. El dueño se interesa en la operación del negocio, para lo cual
requiere del modelado de la empresa mediante modelos de procesos, de los flujos de trabajo, la
logística empresarial, de modelos semánticos y de los planes de negocio que le permitan controlar
la operación de la empresa; esta perspectiva se centra en el proceso de negocio, por lo que
constituye una buena medida del nivel de procesos. El diseñador tiene que ver con la
especificación de los planos conceptuales de los sistemas de información que se requieren para
soportar la operación de los procesos. El constructor se encarga del ensamblado y fabricación de
los diversos componentes de los sistemas de información de acuerdo con las restricciones de la
tecnología utilizada. El programador trabaja en la fabricación de los componentes de acuerdo a las
especificaciones del constructor. Las perspectivas del diseñador, constructor y programador se
ubican claramente en el nivel de sistemas de información

Las dimensiones
El dato responde a la interrogante ¿Qué? Para la perspectiva del planeador se refiere a la lista de
cosas importantes para el negocio como clientes, productos, servicios, contratos, facturas, etc.;
conforme se va descendiendo a las perspectivas inferiores se van teniendo diferentes
descripciones relacionadas con una visión particular de cada perspectiva: el dueño ve las cosas
como entidades representadas en un modelo conceptual que caracteriza el negocio, pero al
diseñador le interesa el modelo lógico que pueda conducir a una base de datos para su
almacenamiento correspondiente, lo que la visión del constructor transforma en un modelo físico
como una tabla de base de datos, para el programador será una entidad de almacenamiento como
un archivo o un registro. La función se ocupa de la pregunta ¿Cómo?, cubriendo desde la lista de
procesos esenciales del negocio (perspectiva del planeador), su modelado correspondiente
(dueño), hasta la especificación de los programas (programador) asociados a la función del
negocio. La ubicación representa el ¿Dónde?, reflejando desde la lista de las localidades donde se
ubica el negocio (perspectiva del planeador), su modelado logístico (dueño), hasta la configuración
de las direcciones de red (programador). La persona tiene que ver con el ¿Quién?, considerando la
lista de unidades organizacionales importantes para el negocio (planeador), su modelo de flujo de
trabajo (dueño), hasta la especificación de las restricciones de seguridad (programadores y
usuarios). El tiempo captura el ¿Cuándo?, incluyendo desde la lista de eventos importantes para el
negocio (planeador), su modelo de planeación operacional (dueño), hasta la especificación de
temporizadores (programador). La motivación explica la interrogante ¿Por qué?, abarcando desde
la lista de los objetivos y metas (planeador), su plan de negocio para operar la empresa (dueño),
hasta la especificación de las reglas de negocio correspondiente (programador)
La neutralidad del marco de referencia
El marco de referencia de Zachman es una herramienta imprescindible para verificar la totalidad
de artefactos requeridos para una solución determinada. Por ejemplo, supónganse que se está
modelando un proceso de negocio (renglón dueño, columna función) y se desea saber qué
aspectos considerar. El marco de referencia sugiere incluir todas las dimensiones para el renglón
del dueño, es decir, un modelo semántico de las entidades que manipulan las actividades del
proceso, un modelo logístico para indicar las localidades donde opera el proceso, la incorporación
de las personas que realizan el trabajo, la identificación de los eventos de negocio que inciden o
son causados por el proceso, y la incorporación de las iniciativas estratégicas que se relacionan con
el proceso

Por otro lado, el marco de referencia no prescribe métodos y técnicas para el desarrollo de los
artefactos, ni mucho menos recomienda o sugiere herramientas, estándares o tecnologías
particulares. Esto es, el marco de referencia Zachman es neutral ante cualquier iniciativa e
desarrollo de artefactos. Este hecho ha propiciado que un buen número de proveedores de
herramientas, académicos y organismos independientes como la comunidad de reglas de negocio,
propongan modelos y métodos basados en el marco de referencia. Este mismo razonamiento
hicieron los autores de este trabajo al desarrollar un método para obtener el artefacto de la
celdilla formada por el cruce del primer renglón y la columna función: la arquitectura de procesos

Descripción del método

En la literatura existen diferentes trabajos que han tomado el marco de referencia Zachman como
sustento de diversas iniciativas. Por ejemplo se propone un método de formalización del marco de
referencia: algunos consultores plantean métodos de desarrollo de software basados en procesos
de negocio aunque no los publican en la literatura; y se delinea un método que sugiere ciertos
artefactos en las tres primeras perspectivas (planeador, dueño y diseñador) y se define una
secuencia de llenado de las celdillas correspondientes. El método propuesto en este artículo tiene
un propósito diferente: apoyar al planeador en la especificación semántica de la arquitectura de
procesos de cualquier empresa. Entendiéndose por empresa a toda la organización o a cierta parte
específica de ella, como una división, departamento o sucursal. Además, el método ha sido
utilizado para enseñanza y en el rediseño de procesos y desarrollo de sistemas de información
integrados

Los pasos del método

El método corresponde a cuatro pasos:

1. Captura del organigrama

2. Modelado de la vista horizontal
3. Modelado de la configuración de valor
4. Modelado de la arquitectura de procesos
Paso 1. Captura del organigrama
Este paso sigue de introducción a la empresa, se entrevista a su director general, se entienden su
forma de organizarse y su cultura corporativa, se identifican las personas clave de la operación. El
organigrama de la empresa muestra la forma en que ésta se organiza para realizar el trabajo
requerido en los niveles operacional, táctico y estratégico. En la mayoría de las empresas se
prefieren los agrupamientos funcionales - a lo que suele dárseles el nombre de divisiones,
departamentos o áreas - en los que se encuentran personas que tienen por cometido realizar una
función de negocio determinada. Para garantizar consistencia en los flujos de mando y de
información, tanto los agrupamientos funcionales como las personas que los componen,
mantienen vínculos verticales de reporte, dando lugar a estructuras jerárquicas. En realidad el
organigrama, proporciona una vista vertical de la empresa. Su artefacto se ubica en la dimensión
persona (¿Quién?)

Paso 2. Modelado de la vista horizontal

En este paso se logra un entendimiento detallado de la operación de la empresa. El diagrama de la
vista horizontal proporciona información que no es posible extraer del organigrama.
Fundamentalmente la respuesta a las tres preguntas cruciales: ¿Qué hace la empresa? ¿Cómo lo
hace? ¿Para quién lo hace? Las interrogantes qué y para quién tienen que ver con la misión y con
la estrategia, pues se relacionan directamente con los propósitos de la empresa: qué
productos/servicios es conveniente ofrecer al mercado y quiénes son los clientes a los que hay que
dirigirlos. Una vez establecidos el qué y para quién, el cómo se refiere a la manera precisa en cómo
se llevarán a cabo las actividades en la empresa para elaborar los productos/servicios y entregarlos
a los clientes previstos, identificando y definiendo los flujos de trabajo entre las diversas unidades
organizacionales. En la siguiente figura, el diagrama resultante se denomina de la vista horizontal
pues centra su atención en los clientes, a diferencia del organigrama que privilegia la relación con
el jefe. El artefacto se ubica en las dimensiones datos (producto, servicios, clientes, proveedores) y
funciones (flujos de trabajo)
Para hacer el modelado se procede de la siguiente manera:

 Se coloca el bloque de los clientes al lado derecho, el de los proveedores del lado
izquierdo y el de la empresa en el centro
 Se identifican claramente los productos/servicios que provee la empresa, los clientes
específicos a los que se les surten y los proveedores de los que reciben insumos
 Se traslada el organigrama de la empresa en cuestión al bloque central, se acomodan las
diversas unidades organizacionales respetando la estructura jerárquica
 Se identifica, dibuja, nombra y numera la secuencia de flujos de trabajo que intervienen en
la operación de la empresa

Paso 3. Modelado de la configuración valor

En este paso se entiende la manera en que la empresa crea valor para los clientes. La
configuración de valor describe la lógica que sigue el conjunto de actividades primarias que crean
valor para los clientes. La cadena como la lógica de creación de valor válida para cualquier tipo de
empresa. Aunque en otros trabajos, se demuestra que la cadena de valor se ajusta perfectamente
para empresas manufactureras y comerciales pero es incapaz de modelas la creación de valor de
empresas de servicios. Es por ello que se proponen dos nuevas configuraciones de valor: el taller
de valor y la red de valor
Esto significa que cualquier empresa, sin importar el giro, podrá ser modelada por una cadena,
taller o red de valor. Si esta aseveración es cierta, en consecuencia nuestro método podrá ser
aplicado a cualquier empresa. Por otro lado, las configuraciones de valor se componen de dos
tipos de actividades o funciones de negocio: las actividades primarias y las actividades secundarias.
Las actividades primarias son las actividades relevantes de la empresa, pues es donde se crea el
valor para los clientes y constituyen la razón de ser de la empresa y de la ventaja competitiva;
ocupan la etapa inferior del diagrama de configuración de valor. Por el contrario, las actividades
secundarias son actividades de soporte para las primarias, son importantes y útiles pero son
relevantes para la empresa; ocupan la parte superior del mismo diagrama. Las actividades
primarias específicas dependen de la configuración de valor de que se trate y tienen que ver con la
lógica de creación de valor, mientras que las actividades secundarias son las mismas sin importar
la configuración de valor. Tanto las actividades primarias como las secundarias se componen a la
vez de un conjunto de actividades de negocio, que son las que realmente detallan la manera
particular en que se realiza el trabajo en la función de negocio

En la cadena de valor, el valor se crea al transformar las entradas en productos. Es por ello que las
actividades primarias son: logística de entrada, operaciones, logística de salida, marketing y
ventas, servicio. En contraste, en el taller de valor, el valor se crea al resolver problemas
particulares de clientes; es útil para modelar empresas de servicios profesionales y sus actividades
primarias reflejan el ciclo de solución de problemas: definición del problema, especificación de la
solución, alternativas de implementación, ejecución de la solución, monitoreo de la solución. Por
otro lado, en la red de valor, el valor se crea al facilitar los intercambios entre los clientes; permite
modelar empresas mediadoras y sus actividades primaria se dedican a poblar y operar la red:
promoción de la red y administración de contratos, suministro de los servicios e infraestructura de
operación

Para hacer el modelado se procede de la siguiente manera:

 Se elige la configuración de valor aprobada

 Para cada una de las actividades primarias se anota la secuencia lógica de actividades de
negocio que las soportan; es importante validad minuciosamente este procedimiento con
algún directivo clave

Paso 4. Modelado de la arquitectura de procesos

En este paso se identifican, modelan y definen los procesos esenciales de la empresa, los cuales se
encuentran dentro de las actividades primarias de la configuración de valor elegida. Para
identificar los procesos esenciales se procede de la siguiente manera:

 Las actividades primarias se recorren de izquierda a derecha

 Centrando la atención en las actividades de negocio, se identifican la primera actividad de
negocio como punto inicial en un proceso
 Al continuar el recorrido hacia las derecha las actividades de negocio se van cotejando
para discernir si pertenecen a una misma agrupación lógica y, al mismo tiempo, también
 se determina si alguna corresponde al punto final de un proceso (en buen medida por
sentido común de la secuencia lógica que inicia en un punto y termina en otro)
 Se le asocia un nombre al proceso identificado
 Se continúa con el recorrido hasta terminar con todas las actividades de negocio
consideradas. Es importante validar meticulosamente este procedimiento con algún
directivo clave de la empresa

ARIS ARCHITECTURE AND REFERENCE MODELS FOR BUSINESS PROCESS MANAGEMENT

Nuevos enfoques de desarrollo de sistemas de información

Hay dos fundamentales maneras de re-ingeniería de sistemas de información. El enfoque
“controlador formal” está basada en la meta de desarrollo e implementación de técnicas correctas
de sistemas en ejecución. El enfoque “controlador de contenido” está basado en la meta de
desarrollo e implementación de una organización correcta de sistemas en ejecución. Usando
modelos de referencia, contenido y tecnología puede ser combinada en una nueva manera

El enfoque de controlador de contenido empieza con el diseño de las oportunidades de estrategia

de negocio y los requerimientos de la organización. Los modelos resultantes son la base de una
interactiva mejora de negocios e implementación tecnológica. El enfoque de controlador de
contenido puede estar estructurado como una capa de modelo y describir un framework de
arquitectura para administración de procesos de negocio. Modelos de referencia como
“impresiones azules” para ingeniería de negocio puede ser usado para modelo y optimizar
procesos de negocio

El término “procesos de negocio” es universal. Un proceso de negocio es descrito como un

procedimiento relevante de valor agregado en la organización. Es visto en su totalidad, desde el
principio al fin. La siguiente imagen, ilustra el proceso de negocio de entrada de procesamiento de
pedidos. El requerimiento inicial del cliente principal de orden de aceptación por el departamento
de ventas. Las ventas entonces transmiten información de compras, para que suministren piezas
compradas. Finalmente, los planes de producción y ejecución de trabajo-orden

Además también ilustra este procedimiento por una serie de funciones de eventos activación. El
evento inicial del proceso es el requerimiento del cliente. El evento final es la terminación del
producto en manufactura. Los eventos no solo funciones detonantes, ellos mismos son los
resultados de las funciones. Los procesos pueden partir de sub-procesos. En cambio, los sub-
procesos pueden unirse juntos. Introduciendo operadores lógicos, la estructura de control con su
cadena de proceso del evento controlador puede expandirse a procedimientos complejos
acomodados
Además de la descripción de la estructura procesal de eventos y funciones, también debe haber un
centro de atención en la descripción de las unidades organizacionales asignadas a las funciones.
Muchos proyectos de re-ingeniería son actualmente dirigidos a funciones de re-asignación de
unidades organizacionales

Alineando la estrategia a lo largo de sus procesos ofrecen la posibilidad de alcanzar varios

objetivos comerciales. Pero un proceso orientado a administración de negocios no solo requiere
un concepto del diseño sistemático y organización de procesos de negocio de ellos mismos

Procesos orientados a administración de negocio también se llama herramientas y conceptos de

sistemas de soporte de información de estos procesos. El objetivo es diseñar y controlar las
estructuras organizacionales en una flexible manera para que puedan adaptarse rápidamente a
condiciones cambiantes

ARIS- casa de la arquitectura de ingeniería de negocio

A pesar de varios conceptos de reingeniería en años recientes, los procesos negocio pueden
emerger de un punto focal de reingeniería de negocios

La arquitectura de sistemas de información (ARIS) puede ser usada como una llave para el proceso
de reingeniería de negocios y procesos de administración de negocios. ARIS-inicio de la
arquitectura de negocios mejora el proceso de arquitectura de ARIS por direccionamiento
comprensivo de procesos de administración de negocios, no solo desde la organización, pero
también desde la perspectiva de IT
Porque los dueños los procesos de negocio necesitan centrar su atención en “la ingeniería y
descripción de aspectos de sus procesos de negocio” ARIS HOBE proporciona un Framework de
gestión de procesos de negocio – desde la ingeniería organizacional al mundo real de
implementación IT, incluyendo mejoras adaptativas continuas. También permite a los propietarios
de procesos de negocio planificar y controlar continuamente los procedimientos comerciales
actuales y dedicar su atención a la mejora continua de los procesos

Nivel 1 (ingeniería de procesos) los procesos de negocio se modelan de acuerdo con un programa
de trabajo de fabricación. El concepto ARIS proporciona un marco que cubre todos los aspectos
del proceso de negocio. Varios métodos para optimizar, evaluar y garantizar que la calidad de los
procesos también esté disponible

Nivel 2 (proceso de planeación y control) es donde se planifican y controlan los procesos de

negocio actuales de los propietarios de procesos de negocio, como métodos para la programación
y capacidad y análisis de costos (basado en actividades) también disponible. La supervisión de
procesos permite que los gerentes de procesos vigilen los estados de los diversos procesos

Nivel 3 (control del flujo de trabajo) objetos que se procesarán, como pedidos de clientes con los
documentos apropiados o reclamos de seguro, se entregan desde un lugar de trabajo a la
siguiente. Los documentos almacenados electrónicamente son entregados por sistemas del flujo
de trabajo

Nivel 4 (sistemas de aplicación) los documentos entregados en los lugares de trabajo se procesan
específicamente, es decir, las funciones del proceso de negocio se ejecutan utilizando sistemas de
aplicación asistido por computadora, que van desde simples sistemas de procesamiento de textos
hasta módulo de soluciones de software estándar complejos – objetos de negocio y aplicativos
java

Los cuatro niveles están inter-dependientemente conectados. Información en el nivel 2 sobre la

rentabilidad de los procesos actuales, es el punto de partida para el ajuste continuo y la mejora de
los procesos de negocio en el nivel 1. El flujo de trabajo, el control es vinculado al nivel 1, porque
el control del flujo de trabajo en el nivel 3 requiere la descripción de procesos de negocio. Al
mismo tiempo, el flujo de trabajo de control informa de los datos reales sobre los procesos a
ejecutar (importes, tiempos, asignación organizativa) de vuelta al nivel 2. Las aplicaciones del nivel
4 se ejecutan desde el sistema de flujo de trabajo en el nivel 3 y configurado de acuerdo con los
modelos de procesos de negocio en el nivel 1

Ingeniería de procesos de negocio

En general, los procesos de negocio empresariales, como un proceso de compra típico, son
diseñados a nivel de tipo. Subtipos para determinados subformularios (pedidos de piezas de
recambio, también se puede crear piezas normales o piezas justo a tiempo, por ejemplo) también
se pueden crear. Sin embargo, los procesos de pedido generalmente no se modelan solo porque
se deben pedir piezas específicas

Por otro lado, los horarios de trabajo para piezas específicas en los procesos de fabricación están
documentados. Esto se debe al hecho de que las descripciones de los procesos no son solo
utilizados para apoyar las reglas organizativas fundamentales, pero también para la ejecución
directa de procesos

Cuanta más documentación de procesos se utilice para ejecutar procesos de negocio, por ejemplo,
cuántas más descripciones se conviertan en instancias de proceso necesario

Cuando se diseñan procesos de negocio óptimos, se pueden incluir modelos de referencia, junto
con el conocimiento disponible sobre las mejores prácticas. También es posible comparar
procedimientos alternativos (benchmarking) o realizar estudios de simulación o calidad de
evaluaciones

Modelos de referencia, que pueden desarrollarse en situaciones del mundo real (mejores
prácticas) o teóricamente, documentar el know-how del proceso que se puede utilizar para el
modelado. Podemos distinguir entre modelos de procedimiento o la implementación de software
estándar, y modelos de negocio como para procesamiento de pedidos o la introducción de
productos. Los modelos pueden especializarse para mercados verticales. El modelo de referencia
conceptual ARIS, desarrollada por consultorías con experiencia adquirida en proyectos de clientes,
están disponibles para prácticamente todos los mercados verticales. Por lo tanto, la experiencia
documentada en procesos da como resultado el desarrollo de productos comerciales

Puede ser bastante complejo, que consta de cientos o miles de objetos modelo. Esta es la razón
por la que se utilizan varios niveles de agregación. Los modelos de referencia proporcionan a las
empresas una solución inicial de ingeniería de procesos, lo que les permite determinar el grado de
detalle del modelo y el contenido del negocio. Adaptados en los requisitos específicos de la
empresa, los modelos de referencia evolucionan hacia modelos específicos de la empresa.
Estudios de casos reales han demostrado que el uso de modelos de referencia pueden reducir los
factores de tiempo y los costos en más del 30%
Los modelos de referencia proporcionados por los proveedores de software como documentación
de software benefician al cliente mediante la utilización de procesos de negocio know-how,
proporcionando la oportunidad de comparar soluciones de software empresarial o identificar
problemas de implementación positivos o negativos

El proceso know-how se considera cada vez más como un componente importante de la gestión
primordial del conocimiento corporativo. El conocimiento corporativo incluye el know-how con
respecto a los productos, tecnologías, procedimientos y reglas organizativas, así como el know-
how individual de cada empleado individual. Documentar, almacenar, utilizar y mejorar este
conocimiento básico es una tarea clave de la gestión del conocimiento

Si bien es esencial evaluar los resultados de costos y evaluación comparativa basadas en

actividades para un solo proceso de negocio, múltiples alternativas se generan, estudian y analizan
en estudios de simulación con el fin de diseñar el mejor proceso de negocio posible. No se necesita
ninguna mejora metódica del modelo de proceso de negocio para definir y analizar las diversas
alternativas de ingeniería en situaciones de “qué pasaría sí”. Después del análisis, el modelo del
negocio existente sirve como base para la simulación. En simulaciones dinámicas, por otro lado, se
estudia el comportamiento dinámico de las alternativas del proceso. Los procesos individuales se
generan de acuerdo con el modelo del proceso, se realiza un seguimiento del procesamiento. Así,
los procesos se definen a nivel de instancia y se analizan sus interrelaciones. Esto identifica
cualquier retraso potencial antes de cualquier procesamiento inicial. En cuanto a las alternativas
de procesos a analizar, es posible definir diversas estructuras de procesos, procesos con diferentes
tiempos de función y comportamiento operativo, respectivamente, de las respectivas unidades
organizativas. Las alternativas son generadas individualmente, de acuerdo con estudios empíricos
o aleatoria y automáticamente

La estructura de un modelo de simulación puede derivarse directamente del proceso de estructura

general
Las definiciones de ISO 9000 incluyen criterios para definir la calidad de los procesos de negocio.
Las empresas pueden certificar su adhesión a estas normas. La idea principal de estas
certificaciones es que la calidad de los procesos es una indicación de la calidad de los propios
procesos

En todo el mundo, estándares como ISO 9000 y 9xxx, así como el más rígido QS-9000 en la
industria automotriz, ahora están bien establecidas. Además de certificar el cumplimiento de
normas como ISO 9001, enfatizan los aspectos de gestión y allanan el camino para la gestión de la
calidad total (TQM). Sin embargo, los esfuerzos para mejorar la calidad no se detienen una vez que
el cumplimiento de las normas ISO 9000 ha haber sido certificado. Con el fin de optimizar los
procesos empresariales de acuerdo con ciertos objetivos. TQM requiere que las personas piensen
y actúen de manera orientada a los procesos y revisar y mejorar constantemente los
procedimientos existentes

El resultado de capturar, almacenar y mantener sistemáticamente el proceso del conocimiento del

know-how en un repositorio se denomina almacén de procesos. Los almacenes de procesos se
alimentan de una amplia gama de fuentes de proyectos en las que se analizan los procesos de
negocio. Estos proyectos pueden incluir tareas de reingeniería, certificación ISO 9000,
implementación de software estándar, cálculo de costes basado en actividades, etc. cuando se
utilizan varios métodos y herramientas en estos proyectos, el contenido de los modelos en el
almacén de procesos debe ser consolidado y luego fusionado con otros modelos. En guías
organizativas coherentes y transparentes, este know-how de proceso puede ponerse a disposición
de proyectos adicionales. Finalmente, la tecnología de internet e intranet permite la distribución
de la empresa global

Planificación y control de procesos de negocio

La ingeniería de un proceso de negocio concluye con una especie de plantilla para procesos de
negocio individual (instancias de proceso). Para poder planificar y controlar los procesos de
negocio actuales, la información adecuada debe ponerse a disposición de las personas
responsables del proceso

El monitoreo de procesos proporciona a los empleados involucrados y responsables de los

procesos de negocio con información de estado actualizadas sobre los procesos de negocio
actuales. Además del estado de procesamiento, los tiempos de proceso actuales y los costos de
proceso se pueden mostrar ad-hoc. Este proporciona a las personas responsables del proceso de
negocio información transparente para responder a las preguntas de los clientes y manipular el
resto del proceso si es necesario

Los sistemas de programación de proyectos y producción también proporcionan información

sobre las desviaciones “por estar” y “tal cual” del cronograma y los costos de los procesos
comerciales que se van a ejecutar. Esto, así como otra información, se utiliza para mejorar
continuamente los procesos de negocio
Se puede emplear un método muy utilizado para describir el nivel 1, como el análisis de procesos,
la comparación de modelos, la certificación ISO 9000 o la simulación. El BPR y el IPC deben
considerarse en la misma línea. Cuando surge una determinada situación, haciendo que una
empresa reflexiones sobre sus estructuras, esto a su vez puede conducir a un proyecto BPR. Sin
embargo, incluso después de resolver el problema, los procesos siguen cambiando. Pueden surgir
nuevos conceptos organizativos. Los nuevos casos de mejores prácticas están disponibles como
modelos de referencia. Se inventan las nuevas tecnologías. El nuevo conocimiento se obtiene de
los procesos que acaban de ser implementados, lo que lleva a un ajuste del proceso. Por lo tanto,
el diseño de procesos es un proceso continuo. Con frecuencia, los conflictos de interés conducen a
aparentes disparidades entre BPR y CPI: a veces se culpa a los proveedores por el largo
procedimiento ocasionalmente necesario para implementar su software. Les preocupa que su
producto pudiera ser considerado responsable de cualquier retraso adicional si están conectados
con un proyecto BPR. Por lo tanto, se oponen a las estrategias de BPR y recomiendan la instalación
rápida de su software y el IPC posterior. Debido a su interés en vender servicios de consultoría, las
empresas de consultoría, por otro lado recomiendan el enfoque opuesto: primero, desarrollar un
nuevo concepto de ingeniería (organizacional) y luego apoyarlo con el nuevo software. Esto evita
procedimientos innecesarios e incómodos siendo trasladado al nuevo concepto de software. Las
contradicciones de estos dos enfoques se resuelven en el ARIS-HOUSE, porque BPR y el IPC están
tan estrechamente entrelazados

La integración se compone del cálculo de costos de procesos dentro de ARIS es importante para
implementar un proceso de mejora permanente

Los intensos debates en los círculos de administración de empresas en los últimos años sobre el
coste de los procesos generalmente se disipan si uno se adhiere a esta visión básica de los
procesos de negocio. Sin embargo, el cálculo de costos de procesos siempre ha existido en áreas
en las que descripciones de los procesos están disponibles, como en el cálculo de los procesos de
fabricación. Es por eso que utilizamos términos como cálculo concurrente, donde tal cual los
costos de un orden de fabricación, y por lo tanto de un proceso de fabricación se determinan en
paralelo con un proceso continúo

Los datos de un proceso también se pueden resumir en un sistema de información ejecutiva (IES)
o data warehouse, soporte para la gestión de procesos con un proceso continúo

Control del flujo de trabajo

Los niveles de ingeniería de procesos de negocio y planificación de procesos de negocio,
respectivamente, son orientando a gerentes orientados a negocios. El control del flujo de trabajo
convierte los procesos de negocio en herramientas de TI

Generalmente, no es posible administrar un proceso de negocio completo con un sistema de

software de aplicación. Muy a menudo, una variedad de sistemas para ventas, compras,
fabricación, o contabilidad son necesarios. Incluso los paquetes de aplicaciones estándar
integrados tienen lagunas que deben llenarse con sistemas personalizados o aplicaciones estándar
de otros proveedores. Ninguno de estos sistemas es individualmente capaz de determinar el
estado de todo el proceso (por ejemplo, cada estado de procesamiento de un orden en particular).
Por lo tanto, tiene sentido asignar la responsabilidad del proceso integral. Control a un nivel de
sistema explícito en lugar de distribuirlo a través de varios sistemas. Este nivel se denomina “flujo
de trabajo”

Los sistemas de flujo de trabajo pasan los objetos (documentos) que se procesaron de una obra a
la siguiente. Idealmente lo hacen electrónicamente, desde el sistema informático de uno al lugar
de trabajo al sistema del siguiente paso de operación. Esto requiere una descripción detallada del
procedimiento, personalizado para el tipo de proceso individual, y del empleado respectivo

La siguiente imagen ilustra cómo se deriva un proceso específico en el nivel de ejecución del
procedimiento definido en el nivel 1. En lugar de los atributos generales de la unidad organizativo,
ahora encontramos usuarios empresariales generales. En lugar del término general, encontramos
un pedido vinculado a un cliente real

Después de la conclusión de un paso de trabajo, el sistema del flujo de trabajo recupera el

documento de la bandeja de salida electrónica del usuario empresarial y lo transporta a la bandeja
de entrada electrónica del siguiente usuario empresarial. Si varios usuarios empresariales
participan en el procesamiento, el procedimiento se puede colocar en varios contenedores. Tan
pronto como un usuario empresarial ha comenzado con el proceso, el procedimiento se elimina en
los otros contenedores. El sistema del flujo de trabajo es informado del estado del proceso, el
tiempo de ejecución y el usuario empresarial apropiado de cada proceso de negocio. Por lo tanto,
el procedimiento del flujo también es la base para la gestión de procesos en el nivel 2. Informa los
datos para las evaluaciones de costos y programación y proporciona información de procesos para
el monitoreo de procesos. Un acuerdo de administración de coalición workflow, un grupo de
proveedores de workflow, tiene interfaces estandarizadas. Ahora, varios sistemas de trabajo se
pueden vincular entre sí
La representación de procesos de los sistemas de flujo de trabajo también se puede utilizar para
guiar el negocio usuarios. Esto aumenta su conocimiento de la interrelación de los procesos de
negocio organizacionales

El procedimiento específico de la siguiente figura (cuadro derecho) se deriva del procedimiento

general del proceso de negocio. Para crear un procedimiento específico, se obtiene información
sobre usuarios empresariales concretos y se selecciona una ruta determinada descrita en la
descripción general del proceso empresarial. Por lo tanto, los usuarios de negocio pueden ver
cómo su actividad está integrada en el proceso, quién los precederá y quién los sucederá dentro
del proceso. Por ejemplo, también pueden ver como la rama izquierda de un proceso de negocio
es relevante para ellos; es posible que se elimine el flujo de control de la rama derecha. Dado que
no se ha creado un proceso particular para el usuario empresarial de la siguiente actividad, solo el
nombre del departamento “werehouse” aparece en la lista. Dependiendo de la situación de
capacidad en ese momento, el usuario comercial del siguiente paso de trabajo no se determina
hasta la conclusión de la tarea. Durante el flujo de trabajo de procesos, los procesos con
estructuras de procedimientos definidas con precisión se pueden diferenciar de los procesos con
solo los pasos de procedimiento definidos aproximadamente

En muchos procedimientos operativos o repetitivos (como el procesamiento de pedidos o

préstamos), las funciones, sus ramas de procesamiento y unidades organizativas se determinan a
partir del de empezar. Por lo tanto, el proceso está bien estructurado y se puede describir con el
método EPC. Por otro lado, otros procesos solo se pueden solo se pueden describir parcialmente
ya que las funciones se hacen evidentes durante el proceso. Este es también el caso cuando la
secuencia de los pasos del proceso se determina ad-hoc o las unidades organizativas que se
procesarán se hacen evidentes sobre una base ad-hoc. En estos casos definimos el proceso como
mal estructurado. Solo se puede modelar de una manera imperfecta. Por ejemplo, las funciones
puede solo ser representada en una lista de “tareas pendientes”; la secuencia será determinada
por el proyecto equipo durante el proceso. Es en este momento que la persona a quien se le ha
encomendado la tarea, asignando, también se determina

Los sistemas de flujo de trabajo parecen más adecuados para controlar procesos más adecuados
para controlar procesos bien estructurados. Asimismo, los procesos menos estructurados son
soportados por sistemas de groupware, que solo ofrecen herramientas como correo electrónico,
videoconferencia, conferencia compartida, etc., pero que no quieren conocimiento lógico de los
procesos. En situaciones de la vida real, siempre encontramos una mezcla de estas dos formas de
estructura. Por lo tanto, los sistemas de flujo de trabajo son capaces de “manejo de excepciones”,
es decir, el control de procedimientos se puede cambiar ad-hoc durante el procesamiento. Esta
funcionalidad se puede vincular con herramientas de groupware, complementando el flujo de
trabajo y el groupware. En el futuro, estos dos sistemas incluso crecen juntos

Sistemas de aplicación
Los proveedores actuales de sistemas de software integrados están dividiendo sus sistemas en
módulos más pequeños. Muchos de ellos están vagamente acoplados. Esto hace posible lanzar
actualizaciones para cada módulo individual y no de forma general para todo el sistema entero. En
general, existe una fuerte tendencia hoy en día hacia la división del software de aplicaciones de
componentes individuales. Estos módulos se vuelven a ensamblar en soluciones completas de
acuerdo con los modelos de proceso. Los datos operativos en estas aplicaciones son administrados
por sistemas de base de datos

El enfoque orientado a objetos, los datos y las funciones se encapsulan y se comunican a través de
un sistema de mensajería, que realizar el manejo de materiales para el sistema de flujo de trabajo.
Los objetos corresponden a la “carpeta” y proporcionan referencias a datos y funciones. Es
importante tener en cuenta que el nivel 3 es responsable de todo el proceso de la operación.
Llama a objetos para ser procesados, como formularios electrónicos para presentar reclamos de
seguros, formularios de solicitud de préstamos para operaciones de procesamiento de préstamos
o pedidos de clientes para el procesamiento de pedidos de clientes. Luego los pasa a la estación de
procesamiento apropiada y llama a los módulos del programa

Su separación del flujo de control de los programas y ejecución de función está provocando
enormes cambios en el mercado del software. Los proveedores de software de aplicación
convencional tendrán que decidir si quieren ser corredores en el nivel 4 y simplemente
corresponde “componentware” con alguna funcionalidad de edición, o si desea ascender al
mercado de sistemas de flujo de trabajo en rápido crecimiento. Por el contrario, el software de los
fabricantes sin mucha experiencia en aplicaciones están llegando a un nuevo punto de partida,
ahora que se están desarrollando sistemas de flujo de trabajo. Particularmente en las aplicaciones
de servicio, las reglas de procesamiento en el nivel 4 pueden ser tan simples que solo involucran
entrada de datos o edición de documentos. Por lo tanto, muchas funciones podrían ejecutarse en
este nivel, como para llamar a una hoja de cálculo o de un programa de procesamiento de texto.
Esto hace que los sistemas de flujo de trabajo que controlan la coherencia de un procedimiento
sean aún más importantes
Lo que significa para los usuarios es que una nueva arquitectura para el software de aplicación
está en camino. Los proveedores de servicios, como los bancos y las compañías de seguros, no
tienen una gran selección de aplicaciones estándar a su disposición para respaldar sus
procedimientos operacionales. Ahora pueden documentar (modular) sus procedimientos
comerciales en el nivel 1 y pueden comprobar sus procedimientos mediante la implementación de
un sistema de flujo de trabajo en el nivel 3. En el nivel 4, todavía pueden usar su software
existente para admitir las reglas de procesamiento. Sin embargo, hoy en día es necesario dividir el
software en el nivel 4 y hacerlo accesible para el control del flujo de trabajo. Separando el control
de procedimientos de la ejecución de funciones de las declaraciones, los sistemas de información
se dividen en gestión de datos, control de procedimientos y ejecución de funciones

La siguiente figura muestra un prototipo de este sistema de información integrado orientado a

procesos. La ventana izquierda representa la interfaz de usuario de la herramienta de modelado y
las características que se pueden utilizar para analizar y diseñar modelos de información en los
niveles 1 y 2. Los modelos almacenados en el repositorio se pueden utilizar para configurar y
activar procesos de flujo de trabajo. La ventana de en medio muestra un proceso de flujo de
trabajo activado en el nivel 3. El software de aplicación en el nivel 4 es empujado por el sistema de
gestión de flujo de trabajo y representado en la ventana derecha

Personalización y configuración con modelos de referencia

Cuando se apoyan los procesos de negocio en su totalidad, no es suficiente simplemente dividir
todo el proceso en las cuatro partes intelectualmente o como un sistema físico, como se describió
anteriormente. También debemos separar sus vínculos entre sí. Ya habíamos observado que los
eventos empresariales individuales en el nivel del flujo de trabajo de procesos se generan
copiando el diseño de procesos de negocio en el nivel 1. La generación para este tipo de negocio
es, por lo tanto, un vínculo entre esta herramienta de modelado de procesos de negocios y de
sistema de flujo de trabajo. En la administración de coalición de flujo de trabajo, los expertos están
trabajando en la creación de estándares aceptados para este alcance. Lo mismo ocurre con la
entrega de resultados de flujo de trabajo al nivel 2, por ejemplo, mediante la entrega de detalles
sobre los cronogramas tal como están o los montos de ASSIS al nivel 2 para fines de evaluación

Estos dos alcances permiten actualizar inmediatamente un procedimiento de proceso de negocio,

incluso en los niveles de ejecución y evaluación. Esto ocurre sin tener que manipular ningún
programa informático. Por lo tanto, el nivel de diseño organizacional 1 juega un papel tremendo
dentro de toda la arquitectura

Desde un punto de vista administrativo, el vínculo entre el nivel 1 y el 4 es igualmente importante.

Por lo tanto, el nivel de modelado no solo genera control de procedimientos, sino también reglas
de procesamiento y transformación de datos. Después de comenzar con un grupo de reglas de
procesamiento que solo están definidas de manera muy aproximada, por ejemplo, es posible
filtrar y adaptar solo aquellas que son realmente importantes para los procedimientos comerciales

Los sistemas de aplicación del futuro tienen que ser consistentes en llevar a cabo este concepto de
personalización basada en modelos

Al cambiar los atributos del modelo de datos en el nivel 1, se alteran las tablas de los datos del
nivel 4 (siguiente imagen). La modificación de modelos de proceso, a su vez, varía la secuencia de
procedimientos de funciones. El cambio de modelos de funciones desactiva o activa las funciones.
Finalmente el empleo del modelo organizativo asigna funciones a ciertas unidades organizativas y
determina la secuencia de pantalla. Los sistemas de aplicación se derivan directamente de los
modelos de referencia de mercado específico de la industria descritos de acuerdo al método ARIS.
Utilizando las herramientas de modelado, se pueden desarrollar en modelos “to be” específicos de
la empresa

Con el fin de transferir el modelo a un software de aplicación, un sistema de tiempo de

compilación, clase de biblioteca y el modelo de configuración son relevantes. El sistema de tiempo
de construcción convierte al modelo ARIS específico de la empresa, basado en la programación
orientada a objetos, en un sistema de aplicación operativa (sistema de tiempo de ejecución). El
sistema de tiempo de compilación utiliza una biblioteca de clases que consta de clases
predefinidas de administración de empresas y procesamiento de datos. Las reglas de
procesamiento para esta conversión se incluyen en el modelo de configuración. Aquí hay un
ejemplo: las reglas de procesamiento garantizan la conversión DP de los modelos ARIS en objetos
de bases de datos. Además, rigen la descripción de los objetos de la base de datos y vínculos entre
identificadores externos e internos (por ejemplo, para tablas y columnas). Además de modificar las
reglas de procedimiento, la personalización basada en modelos permite el ajuste o la expansión de
modelos de datos, mascaras de diálogo y organización por procesos. Por lo tanto, la aplicación se
deriva directamente del modelo de proceso de la empresa y luego se configura desde objetos de
negocio

UPDATING THE ENTERPRISE ARCHITECTURE PLANING MODEL

La necesidad de actualizar el EAP

Permítanme contarles una historia corta que capture las razones esenciales para la actualización
EAP. Hace varios años estaba hablando con mi colega sobre la necesidad de actualizar EAP y dijo:
“es un pequeño proceso hermoso que es bien organizado y fácil de entender. ¿Realmente crees
que necesita ser cambiado? Respondí enfáticamente: si, y he aquí el porqué”… hemos aprendido
mucho sobre cómo y por qué funciona desde que se publico EAP por primera vez, y el hecho es
que las cosas están cambiando tan rápido y tantas especialidades han crecido en y alrededor de la
práctica y profesión de EA que para no cambiar EAP socavaría la viabilidad continua del enfoque. A
medida que las cosas se pusieron en marcha, mi colega contribuyó con sus propios cambios

Lo siguiente fue una serie de discusiones de seguimiento y sesiones de trabajo entre los autores
que dieron lugar a una serie de cambios sutiles pero importantes en el PAE enfoque y el modelo
general de apoyo (a veces llamado “pastel de bodas” EA modelo). La simplicidad del enfoque se
conservó en reconocimiento de que EAP permite de forma única a los arquitectos empresariales
implementar un programa de EA y ponerlo en marcha mediante la captura de información del
artefacto primitivo que se quiere para rellenar de forma rápida y eficaz las dos filas superiores del
Framework EA Zachman

Una revisión de una serie de proyectos de EA que habían utilizado la metodología EAP reveló que
se necesitaba otra fase de implementación, donde las soluciones y los componentes del sistema se
detallan, planifican, diseñan e implementan. Esta fase implica mucho más que un plan de
transición, más bien es un plan programático institucionalización de EA y un proceso de desarrollo
dirigido que se utiliza continuamente y se basa en el EA para la dirección y corrección

Este es un buen punto en el artículo para mencionar que una de las razones por las que
cambiamos el modelo de pastel de bodas EAP fue asegurar como parte de la institucionalización
del programa EA que la gobernanza se establece de manera efectiva. Reconocemos que sin ella los
planes de migración o transición creados son solo proyectos no validados. Solo a través de una
gobernanza eficaz se invierten en una verdadera cartera de proyectos aprobados del plan de
transición. Este aspecto es quizá el más importante de todas las razones para cambiar el modelo
del pastel de bodas EAP y sus descripciones

Cambios al modelo EAP

Para aquellos que están familiarizados con el modelo original de pastel de bodas EAP, debería
poder detectar fácilmente los cambios. Para aquellos para quienes el modelo es nuevo, los
cambios se encuentran en el “conocimiento del negocio, gestión de repositorios y transición del
programa y diseño de seguimiento”, cada una de las cuales reemplaza una plaza del modelo
anterior

El modelo EAP original, cada área del modelo corresponde a un conjunto de pasos bien definidos
de la EA muy organizado y ordenado proceso, como se muestra en la siguiente imagen, las
actualizaciones del modelo EAP se muestran en las otras dos imágenes
En términos generales, el modelo funciona de tal manera que el proceso fluye de arriba a abajo y
de izquierda a derecha. El inicio de planificación es la preparación para el proceso de arquitectura
y no forma parte de los pasos de implementación EAP. La planificación de EA debe verse como una
actividad de proyecto, por lo general, se estima que toma de seis a ocho meses y esto
generalmente resulta en una última vez o presentación sin ir a un tomador de decisiones que
apoyaría la implementación de la EA

En nuestra observación de muchos proyectos de arquitectura anteriores de EAP, que rara vez los
altos ejecutivos no aprobados los planes de transición. Esto se debe a que el equipo que realiza la
implementación de EAP generalmente hizo su tarea, aseguró la participación a nivel ejecutivo y
presentó un plan de EA que estaba bien documentado y alineado con el negocio. La dirección
ejecutiva tenía trabajó junto con el equipo de proceso, y de hecho se presentaron opciones para
tomar muchas decisiones en el transcurso del proyecto. Por lo tanto, sería poco probable que
rechazaran una recomendación de transición a una arquitectura futura que hayan ayudado a
definir y documentar. Las lecciones aprendidas de muchos proyectos de EAP apoyan la definición
temprana de los criterios de éxito que garantizarían, si se cumplieran, que el plan sería aprobado y
la EA tendría éxito. Este criterio se suele establecer para la etapa de iniciación a la planificación

Sin embargo, tratar la EAP en un enfoque centrado en el proyecto podría hacer que el proceso de
EA sea visto como un evento de una sola vez, en su lugar un programa continuo que es parte
importante de cómo una empresa desarrolla, gestiona y cambia un entorno operativo empresarial
y tecnológico. Otras preocupaciones incluían la falta de cobertura para la base de conocimientos o
gestión de repositorios para la información de EA. Este es un tema importante que se enfatiza en
los cursos de EAP, pero no era muy evidente en el modelo original o en el libro de EAP. Este es un
cambio importante en la forma en que se realiza la EA y las herramientas y repositorios cada vez
más sofisticados están ayudando a los arquitectos empresariales a administrar y obtener valor de
los programas de EA
A medida que aprendemos más sobre el área del negocio del modelo EAP, ahora sabemos que la
información empresarial definida por la EA debe ser algo más que una simplificación descripción
de las funciones de orden superior. Lo que se requiere hoy en día es un conjunto completo de
artefactos comerciales, que describan el negocio base de conocimiento que integra las iniciativas
estratégicas y la visión, a través de los principios y reglas de negocio, hasta los procesos, tareas y
actividades. De hecho, con las arquitecturas orientadas a servicios, estas tareas y actividades
también deben traducirse en patrones y, en última instancia, convertirse en servicios
empresariales. Así que el término “modelo de negocio” es demasiado limitante

Cuando quise llamar a esta parte del modelo de arquitectura de negocios, mi colega sintió que el
término “arquitectura” sigue siendo demasiado estático y limitante en el contexto antes
mencionado y parte de proceso de EAP, por lo que dijo: “llamémosle conocimiento del negocio”,
pensé sobre ello y decidió que tenía sentido dadas todas las diversas facetas que componen la fase
del conocimiento empresarial. Vi que la “Arquitectura” podría malinterpretarse solo con un
conjunto limitado de definiciones funcionales de alto nivel que deja desatraer los detalles críticos
como: reglas de negocio y procesos, tareas y actividades explícitamente definidos y
documentados. A medida que EA progresa y evoluciona, se une a otros enfoques populares de EA
(por ejemplo: servicio de arquitectura orientada, arquitectura impulsada por modelos) la
necesidad de robustez en el conocimiento de negocios crecerá. Como resultado de nuestra
redefinición de varios de los elementos del modelo del pastel de bodas EAP, decidimos que era
importante hacer llegar esos cambios a los profesionales de EA, y en consecuencia, comenzamos a
escribir un folleto titulado “uso de la planificación de la arquitectura empresarial en el gobierno”.
En el folleto se describía las revisiones al modelo de pastel de bodas en el contexto de cómo se
podría aplicar el EAP en el gobierno, con especial énfasis en cómo se relacionaba y apoyaba al
modelo de referencia de arquitectura de empresas federal, que actualmente se utiliza en los
programas de EA en el gobierno federal. La siguiente discusión es una visión general de la
información sobre las actualizaciones del EAP que se presentaron en el folleto

El nuevo modelo EAP

Inicio de planificación: esta es la fase de planificación previa que es fundamental para establecer
todas las cosas en su lugar para poder utilizar un enfoque EAP para crear un EA. Los principales
resultados de las siguientes actividades son un plan de trabajo detallado del proyecto y el
compromiso de recursos:

 Definir la empresa y , en última instancia, el alcance del EAP (y del EA)

 Establecer una visión del futuro del EA
 Instalar y personalizar (según sea necesario) un conjunto de herramientas básicas. Esto
solía significar herramientas muy básicas

A medida de que EA ha evolucionado y el proceso se ha vuelto más estricto en los requisitos para
cada vez es más necesario decidirse por una herramienta que tenga más capacidades funcionales
para capturar detalles y representarlos gráficamente en una miríada de vistas articuladas:
  Identificar, seleccionar y obtener la aprobación de los requisitos de tiempo para la
participación de los miembros del equipo. Los miembros del equipo se refieren a los
representantes de las unidades de negocio (o al personal de las áreas del programa) que
estarán en el equipo de EA
 Identificar los factores de éxito, los obstáculos, los criterios de aceptación y utilizarlos para
llevar a cabo una evaluación para determinar la preparación de la organización para hacer
el EAP

Cada uno de estos pasos se puede dividir en subcapa, y hay, por supuesto, un conjunto definido de
artefactos, documentos o entregables que se crean

Valores y principios: estos son la base para iniciar un EA. Crean la base para todas las decisiones
futuras que involucran la EA y lo que se define dentro de él. Los principios rectificados y bien
formados dan forma a la base de las decisiones arquitectónicas. La aceptación de estas decisiones
y la continuación de la gestión continúa del plan de implementación, así como la
institucionalización del programa de EA son una manera importante al resultado de completar
este paso

 Definir valores de apoyo en los que basar la gobernanza efectiva de la información y la

tecnología que determinen las acciones y decisiones adecuadas
 Definir y aprobar los principios de EA

Conocimiento de negocios: este a menudo se conoce como un modelo de negocio y, a veces,

como la arquitectura empresarial. Completar este paso proporciona el núcleo que se
interrelacionan estrategias de negocio para las arquitecturas actuales y futuras de la TI y planes de
aplicación

 Identificar y relacionar todos los objetivos estratégicos (negocios y TI) con el EA

 Compilar una base de conocimiento sobre funciones empresariales, subredes, procesos,
actividades, la información utilizada, las medidas y métricas de rendimiento, las reglas de
negocio y las oportunidades de mejora de procesos

Sistemas y tecnologías actuales: el resultado de este paso es un inventario de sistemas de

aplicación, componentes y servicios, esquemas de datos, interfaces y plataformas tecnológicas
que proporcionan una línea de base para la transición, la modernización y/o planes de migración
para su utilización en la gestión operativa de TI:

 Definir y documentar los sistemas de aplicación actual (tal cual) (componentes y servicios)
y la tecnología de plataformas de soporte al nivel de detalle requerido y definido en el
paso de inicio de planificación
 Utilizar la línea base para establecer métricas de EA en términos de un retorno de la
inversión final, basado en ahorros de costos y la evitación de las economías y eliminación
de redundancia, duplicaciones innecesarias y otros resultados similares
Arquitectura de datos: el resultado de este paso es un lenguaje empresarial común que permite
una comunicación mejorada y coherente en toda la empresa:

 Definir los principales tipos de datos para formar vocabulario básico para el lenguaje
empresarial
 Asignar atributos críticos

Arquitectura de aplicaciones: como resultado de este paso, identificar los sistemas necesarios
para apoyar el negocio, el equipo estará equipado para abordar las capacidades operativas y
características en aplicaciones y componentes (y servicios) que se requieran para gestionar y
utilizar datos e información:

 Definir conjuntos de capacidades para administrar datos

 Desarrollar la relación (crear, leer, actualizar o eliminar - CRUD) con los datos
 Facilitar la identificación de oportunidades para mejorar el negocio, objetivos estratégicos
y problemas actuales del sistema

Arquitectura tecnológica: esta fase se está ajustando a veces a cientos de potenciales y

tecnologías actuales (componentes) para habilitar diferentes capacidades que la empresa
requerirá, para implementar la arquitectura:

 Identificar y categorizar las capacidades requeridas

 Establecer un perfil de estándares y un modelo de referencia técnica
 Seleccionar diversas tecnologías y/o estrategias tecnológicas a implementar
 Validar la suficiencia de las tecnologías seleccionadas

Plan de implementación y migración (también llamado plan de transición): este plan es el

resultado de partir del análisis de la brecha entre las arquitecturas de referencia y de destino.
Como resultado de este paso, la organización estará lista para comenzar la transición a la
arquitectura futura a través de un plan organizado y priorizado:

 Emitir juicios sobre la inclusión o exclusión de los sistemas actuales

 Determinar la secuencia para la implementación de aplicaciones, componentes y servicios
 Programar recursos y tiempos para la implementación de proyectos
 Analizar el costo-beneficio neto y el ROI para alimentar casos de negocio
 Desarrollar un plan de proyecto maestro para un período de transición del programa
después de EAP

Transición programática y diseño de seguimiento: después de completar el EAP, la administración

recibe informes finales, entregables, bases de datos electrónicas, archivos y presentación de
resultados, para luego, comenzar la transición a un programa EA. El programa EA es una función
continúa o un conjunto de actividades que no solo garantiza la actualización y el mantenimiento
del EA y del plan de transición, pero también se integra con los procesos de gobernanza y decisión
presupuestaria. En última instancia también integra las operaciones de TI y los sistemas, servicios y
componentes de diseño, desarrollo y pasos de implementación también. Otras actividades que
podrían entrar dentro de esta fase son:

 Institucionalizar el uso de arquitecturas y procedimientos para mantener las arquitecturas

actualizadas
 Supervisar los mecanismos de presentación de informes y financiación requeridos por EA
 Asegurar que los diseños, actualizaciones e implementación de TI se sincronicen
continuamente con las arquitecturas
 Actualizar las políticas, estándares, orientaciones y procedimientos de EA
 Recomendar la adquisición de nuevas tecnologías
 Establecer puestos y formación de programas para nuevos conjuntos de habilidades para
apoyar el trabajo y la gobernanza de EA
 Prepararse para la implementación de planos arquitectónicos que establezcan vínculos
con el ciclo de vida de desarrollo del sistema (SDLC) u otros enfoques y/o estrategias de
implementación, incluido el modelo de arquitectura de componentes y/o arquitectura
orientada a servicios

Además en el nuevo modelo hay dos áreas “externas” de los componentes del modelo que son
clave para la implementación de EA. Estos son los elementos: gestión de proyectos y gestión de
repositorios. Estos elementos del modelo se muestran en ambos lados, porque tienden a ser
aspectos importantes de los procesos generales de definición y realización de la EA, en todo
momento. Cuando le sugerí a mi colega que deberíamos usar la segunda área para enfatizar la
función de gestión de repositorios, que al igual de la gestión de proyectos, también fue requerida
e importante durante todo el proceso, pensé que era una gran idea. Enfatizó, como enseñó en sus
clases de EAP, que la creación de la base de conocimientos de EA (gestionada en forma de
repositorio) es importante. Las facetas clave de cada uno de estos aspectos del proceso, a medida
que lo revisamos, son gestión de proyectos y gestión de repositorios

Gestión de proyectos: cualquier actividad de cualquier alcance en estos días en la empresa será
gestionado como un proyecto que tiene un cronograma, una estructura de desglose de trabajo
(WBS), entregables específicos y, en algunos casos, un enfoque de métrica de rendimiento como la
gestión de valor ganado o al menos el criterio de finalización. Las cosas específicas cubiertas son:

 Desarrollar un plan de gestión de proyectos detallado (que eventualmente se

transformará en un plan de gestión de programa EA anualizado continuo)
 Desarrollar una estructura de desglose de trabajo que identifique entregables específicos
alineados con objetivos de finalización específicos
 Proporcionar informes periódicos o sesiones informativas sobre el estado y la finalización
de la EA

Gestión de repositorios: a medida que los métodos y programas EA han evolucionado, se está
convirtiendo cada vez es más importante que las herramientas de modelados correctas y un
repositorio muy eficiente, tanto con una gestión de configuración adecuada como con la gestión
adecuada de administración de seguridad está en su lugar para apoyar el EA y sus diversos usos.
Esto se ha convertido en un área nicho dentro de EA que está especializada de algunas maneras
(trabajando y utilizando herramientas de modelado de EA) y común a otros sistemas y
conocimientos de apoyo, capacidades de gestión de proyectos y programas (operación y gestión
de un portal o un sistema de repositorio). Algunas de las áreas de requerimiento son:

 La identificación de una herramienta y/o repositorio para apoyar el EA

 La adquisición del conjunto de herramientas y/o repositorios y su implementación con
gestión de configuración adecuada y gestión de operaciones y sistemas
 La capacitación del equipo de EA y otros para acceder y utilizar las herramientas y el
repositorio
 La actualización continua (y control de versiones) de los artefactos y la documentación de
EA en el repositorio

PPM: ALINEANDO NEGOCIOS Y TI

En los últimos años, el alineamiento entre la IT y las estrategias de negocio ha estado y se

mantiene en el nivel más alto de prioridad de las organizaciones. Este interés radica en la manera
en que las inversiones de TI, recursos, oportunidades de negocio y el portafolio de aplicaciones
pueden estar en armonía con los objetivos estratégicos de la organización, de tal manera que
permitan apoyar el proceso de toma de decisiones y mejorar el uso de recursos existentes para
incrementar la productividad, haciendo así más efectiva y eficiente a la organización

De acuerdo con información reportada en diversos estudios, las organizaciones enfrentan una
diversa problemática al respecto. Pocas empresas seleccionan de manera exitosa un portafolio de
proyectos que sea consistente con su estrategia de negocio. Un proyecto puede ser exitoso desde
la perspectiva de tiempo, presupuesto y alcance, pero si falla en cumplir o satisfacer los objetivos
de negocio, fracasa de manera completa

Al igual que la selección de proyectos, la ejecución de estos también acostumbra a estar

descentralizada y fragmentada. Las mejores prácticas de la industria y lecciones de vida derivadas
de la ejecución de los proyectos no se identifican y gestionan para ser aplicadas sistemáticamente
en la organización, desaprovechando la sinergia potencial entre proyectos. En otros casos, no se
cuenta con procesos definidos para revisar propuestas de proyectos, ni un rastreo adecuado que
permita identificar los proyectos que fracasan en el cumplimiento del valor de negocio prometido.
Incluso, llega a suceder que los niveles directivos ni siquiera cuentan con una lista completa de los
proyectos de TI en curso dentro de la organización. En resumen, no se cuenta con una visibilidad
adecuada de lo que en realidad se está haciendo en la organización

El resultado de estas deficiencias se ve reflejado en la ejecución de demasiados proyectos, una

gran cantidad de complejidad y redundancia: así como fallas, retrasos y excesos en el presupuesto
de los proyectos. Es evidente por lo tanto, que las organizaciones que no tienen control sobre sus
portafolios de proyectos de TI están condenadas al fracaso
Para solucionar esta problemática, una de las estrategias de negocio que más fuerza está tomando
es la gestión de portafolio de proyectos (PPM). PPM permite a las organizaciones alinear sus
proyectos de TI y recursos con los objetivos de negocio corporativo. PPM brinda a las
organizaciones una visión integral de su estrategia de TI, permite ganar control sobre todos sus
proyectos y ayuda a generar valor al negocio

Características y beneficios de PPM

PPM involucra desde la identificación y priorización de oportunidades de negocio (se examinan las
propuestas de proyecto con respecto a los objetivos corporativos), hasta la ejecución y cierre de
proyectos, organizándolos en portafolio

Con PPM se desarrollan y monitorean mediciones que tratan los activos de TI de igual manera
como se tratarían activos o portafolios de diversas inversiones financieras: por ejemplo,
inversiones estratégicas más riesgosas se balancean con inversiones más conservadoras y la
mezcla se monitorea constantemente para evaluar cuáles proyectos siguen en curso, cuáles
necesitan ayuda y cuáles deben ser terminados. Al mantener un portafolio balanceado, se reduce
el riesgo en cada proyecto, se obtiene un mayor entendimiento de los aspectos económicos de
cada uno y se genera una tasa más alta de retorno de inversión general de portafolio. Asimismo,
se tiene mayor visibilidad y un uso eficiente de los recursos entre los diferentes proyectos

PMB brinda claros y múltiples beneficios en las organizaciones. En esencia, los ejecutivos y
gerentes pueden manipular sus portafolios de proyectos facilitando la administración integrada
del alcance, tiempo, costo, recursos, habilidades, adquisiciones, comunicación, reporte
predicciones y riesgos, y alineando estos proyectos a los objetivos de negocio para incrementar la
productividad, apoyar la toma de decisiones oportuna e informada, y generar mayor valor al
negocio

Como iniciar PPM

No hay una manera única de implantar PPM. Diferentes empresas manejan diferentes modelos y
metodologías. Sin embargo, se establecen ciertos pasos clave en la creación y administración de
portafolios de proyectos de TI:

 Reunir: crear un inventario de proyectos es una tarea ardua pero también vale la pena. En
muchos casos, puede ser la primera vez que se tenga una vista completa de los proyectos
de TI, y permite encontrar redundancias. Un buen inventario es la base para desarrollar
proyectos alineados con los objetivos estratégicos del negocio
 Evaluar: después de inventariar los proyectos, se establece un portafolio de éstos. Los
líderes de las unidades de negocio, en conjunto de los líderes de TI, deben soportar los
proyectos con casos de negocio que muestren estimación de costos. ROI, análisis de
riesgos y beneficios esperados
  Priorizar: aun después de evaluar los proyectos, la mayoría de las empresas tendrán más
proyectos de los que pueden realizar. El proceso de priorización permite asignar recursos
a los proyectos que estén más alineados con los objetivos estratégicos de la organización
 Revisar: una vez que se tiene una lista de los proyectos aprobados, es vital administrarlos
activamente. Esto involucra monitorear los proyectos a intervalos frecuentes. Contar con
la revisión de portafolio también facilita la decisión de cancelar proyectos cuando sea
necesario “no requieres completar todos los proyectos simplemente porque no
empezaste”

Herramientas de apoyo a PPM

Existen diversas herramientas de software para asistir en la implantación y automatización de esta
práctica. Uno de los productos más conocidos es primavera. Como toda iniciativa nueva, la
implementación de PPM requiere tiempo y esfuerzo. Sin embargo, los retos que conlleva son
mínimos en comparación con el valor y los beneficios que brinda a la organización