Universidad Tcnica Federico Santa Mara

Departamento de Informtica

Fase 2: Framework BPM

Arquitectura de procesos

Renzo F. Stanley Cotrozo

2373098-7
rstanley@inf.utfsm.cl

1
Desarrollo
Esta etapa es una de las diez que conforman el framework de implementacin de BPM
(adems existen otras tres componentes esenciales). El orden de estas etapas no es estricto,
ya que puede ocurrir que se cambien debido a casos particulares, o incluso se omitan partes.
Se recomienda que no se salten partes, si llega a suceder, debieran registrarse las
justificaciones de las razones para tomar dicha decisin.

A continuacin se explica en detalle la segunda etapa que sigue a la estrategia

organizacional definida en la anterior).

La arquitectura de procesos es el vnculo entre las etapas de Estrategia Organizacional y

Launch Pad (o plataforma de lanzamiento). Al igual que la etapa de Estrategia
Organizacional, la fase de arquitectura de procesos es un prerrequisito para cualquier
organizacin que desee emprender satisfactoriamente actividades relacionadas a la gestin
de procesos, y continuamente cumplir con los objetivos de la organizacin en
circunstancias cambiantes.

La etapa de arquitectura de procesos es la base de los proyectos relacionados con procesos

en una organizacin. Una buena arquitectura de procesos debera ser una parte esencial de
una gran arquitectura empresarial.

Figura 1: Framework de un proyecto BPM

2
Qu es una arquitectura de procesos?
Se dice que: al juntar 10 arquitectos, obtendrs 10 definiciones distintas de
arquitectura. A continuacin se muestran los atributos que comprenden una buena
arquitectura de procesos:

Debe haber un conjunto de reglas, principios y modelos para los procesos.

Debe haber una base para el diseo y realizacin de procesos de la organizacin.
Los procesos deben estar relacionados con la estrategia y los objetivos
organizacionales.
La arquitectura de procesos debe ser dinmica, esto es, fcilmente adaptable a
los procesos evolutivos, de negocios y cambios empresariales.

Principios arquitecturales.

Los siguientes son principios arquitecturales bsicos para una arquitectura de procesos:

La arquitectura no es una meta en s misma, y debera apoyar los objetivos del

negocio.
Una arquitectura es ms que modelos y documentacin, tiene que ver
especialmente con la lgica que constituye la base de los modelos y documentacin.
La arquitectura puede ser desarrollada incrementalmente.
El desobedecimiento a la arquitectura es justificable en ciertas circunstancias.

Resultados

Las salidas esperadas de esta etapa del framework son:

Una arquitectura de procesos documentada y aceptada.

Un proyecto para comenzar una arquitectura.
Una vista de los procesos de la organizacin.
Una lista de procesos end-to-end.

Por qu una arquitectura de procesos?

Una arquitectura de procesos es un paso importante en un proyecto BPM y en una
organizacin BPM. Una arquitectura de procesos asegura:

Los procesos a ser rediseados (o desarrollados desde cero) son acomodados dentro
de la estrategia organizacional junto a los objetivos de la organizacin.
Los procesos estn alineados con la forma en que el negocio es (o debera ser)
realizado, y son capaces de proporcionar los productos/servicios a los clientes.
Los procesos estn alineados con la arquitectura y aplicaciones TI, ya que las TI
tienen que dar soporte a los procesos actuales y futuros.
3
 Los procesos deben estar alineados con otros procesos relacionados. Grandes
organizaciones, muy a menudo, tienen varias iniciativas de gestin de procesos
ejecutndose simultneamente, y es crucial que todos estos proyectos BPM estn en
sintona uno con el otro.
Toda la informacin relevante y decisiones sobre los procesos estn agrupadas. Si la
informacin es dispersa por toda la organizacin, esto puede producir la
duplicacin, confusin e incoherencias.
Las decisiones relevantes y los procesos de alto nivel son presentados en una
manera fcil de comprender. Una arquitectura alineada efectivamente es juzgada
nicamente sobre cun til es, y no por cun complicada o bonita luce.

El autor menciona basado en su experiencia que la arquitectura de procesos es

construida como resultado de un largo anlisis y procesos de planificacin en la
mayora de los casos. Los modelos detallados resultantes tienen dos inconvenientes:

(a) Son demasiado complejos,

(b) Nunca estn a tiempo.

Una arquitectura de procesos debiera ser comprensible (es decir, que da una idea de una
situacin compleja) y dinmicas (que evoluciona con los cambios del negocio). En
resumen, la arquitectura debera ser slo lo necesario, justo a tiempo.

Adems una arquitectura tiene que generar (o ahorrar) ms que sus costos en desarrollo
y mantenimiento. Existen casos en que se le dedica interminable tiempo y energa sin
que nadie la utilice. La nica forma para desarrollar y mantener una arquitectura
dinmica efectiva y eficiente es asegurar que hay un proceso arquitectural que asegura
que todos los elementos de la primera etapa (estrategia organizacional) estn tomados
en cuenta cuando se desarrolla, mantiene y usa la arquitectura.

4
Cmo crear una arquitectura de procesos?
Lo siguiente debe ser tomado en cuenta durante la ejecucin de esta fase.

Madurez de la organizacin en arquitectura.

La madurez de la organizacin no slo se relaciona con el nivel de pensamiento

arquitectural, sino que tambin con el hacer arquitectura.

Figura 2: Incorporacin de la arquitectura en la organizacin.

Isolation (aislamiento): se refiere a la situacin en la que los arquitectos desarrollan

una arquitectura perfecta en una torre de marfil y dentro de la organizacin muy
pocas personas estn conscientes de aquello, y mucho menos la utilizan. En esta
situacin, los arquitectos deben encontrar ms participacin y compromiso en el
resto de la organizacin.
Barrier (barrera): se refiere a la situacin en donde los arquitectos tienen el
compromiso necesario con el resto de la organizacin pero no son muy avanzados
con su arquitectura. Esto significa que la arquitectura sigue estando
predominantemente a nivel operacional ya que est demasiado fragmentada y en un
bajo nivel para aadir valor a un nivel ms estratgico. La organizacin DEBE
incluir la arquitectura en su estrategia.
Losing (perder): Se refiere a una situacin en que la organizacin ha limitado la
consciencia arquitectural y la integracin en la organizacin. Esto ocurre en las

5
 organizaciones donde todo el mundo est muy ocupado en apagar incendios
operacionales y no hay tiempo para examinar otras opciones tcticas y estratgicas.
Enabling (permitir): se refiere a una situacin en donde la organizacin ha adoptado
la arquitectura como un facilitador clave. El principal desafo es asegurar que la
arquitectura siga siendo un facilitador a travs del tiempo y no se transforme en una
carga.

El mbito y el enfoque de la arquitectura

Antes de embarcarse en la formulacin de la arquitectura es importante decidir el nivel de

ambicin, es decir, el alcance y su enfoque. Una de las decisiones principales es si
empezamos slo con una arquitectura de procesos o si modelaremos la arquitectura
empresarial completa.

Otro aspecto importante ser la eleccin de los procesos que estarn incluidos en el alcance
de la arquitectura. Un alcance demasiado pequeo dar lugar a beneficios limitados,
mientras que un mbito demasiado ambicioso dar lugar a mucho trabajo y a la reduccin
de beneficios. Los pasos que se muestran en la figura siguiente son aplicables a la creacin
de una arquitectura de procesos, y se describen a continuacin:

Figura 3: Pasos para el diseo de una arquitectura de procesos.

6
Paso 1: Obtener la estrategia y la informacin de negocios

La informacin a ser obtenida en este paso incluye:

Objetivos y principios generales tal como se especific en la primera etapa de la

estrategia organizacional.
Modelos y directrices relevantes del negocio.
Modelos y directrices relevantes de la organizacin.

La arquitectura de procesos ha de servir a la empresa, razn por la cual es crucial para

entender el negocio fundamental. La primera etapa del framework ya incluye algunos
principios generales. Sin embargo, la arquitectura de procesos debe capturar hasta los
supuestos ms implcitos, los cuales se dan por entendidos medianamente en la estrategia.

Es importante explicitar estos principios generales en la empresa: estos son temas y

aspectos que forman parte de la estrategia. Existe el peligro de que sean ignorados u
olvidados, o que las personas con influencia (de alto rango) tengan diferentes puntos de
vista entre ellos. Una reunin es la mejor manera de aclarar los supuestos y obtener una
definicin clara de estos principios.

Es necesario capturar la informacin relevante, de ms alto nivel, tales como:

Productos y servicios y los principios y lgica subyacente.

Clientes y sus principios.
Fijacin de precios.
Socios (incluyendo proveedores).

Segn la experiencia del autor la obtencin de esta informacin puede ser un desafo.
Aunque la mayora de la informacin est presente como listado de clientes, proveedores,
socios, productos, precios, el desafo radica normalmente en la obtencin de los principios
y la lgica subyacente. Esto es porque la mayora de los principios y lgica son
consideraciones implcitas que la empresa toma en cuenta, la cual es otra razn para crear
una arquitectura de procesos, en donde las consideraciones implcitas se convierten en
explcitas.

Formas sugeridas para adquirir esta informacin:

Obtener listas de productos, precios, clientes y socios.

Obtener el plan financiero anual, planes de marketing, presupuesto.
Discutir con los directivos la razn por la que han hecho su seleccin de estos
productos, precios, clientes y socios

7
No se debe intentar incluir todo en el modelo, recordar que un modelo es algo que
simplifica la realidad y no tiene que explicar todo.

Organizaciones que no tienen clara su arquitectura de negocios a menudo ofrecen

soluciones que son difciles de poner en una amplia arquitectura. La mayora de los
gerentes de empresas y jefes de ventas aportan con soluciones en formas diferentes, lo cual
es otra razn para comenzar con una arquitectura de negocios.

Paso 2: Obtener modelos y directrices de los procesos.

En este paso se debe especificar lo siguiente:

Directrices de procesos
Modelos de procesos
Lista de procesos end-to-end

a) Directrices de procesos
Las directrices que deben ser formuladas para los procesos, incluyen lo siguiente:
1) La propiedad del proceso.
2) Alcance de los procesos.
3) Seleccin de un mtodo de modelado.
4) Seleccin de un proceso de modelado y una herramienta de gestin.
5) Mtodo de gestin de los procesos.
6) Proceso de outsourcing:
Es donde la organizacin debe decidir si externaliza o no los procesos. En caso que
desee externalizarlos es necesario lo siguiente:
a. Tipo de procesos para ser externalizados
b. Tipo de procesos para no ser externalizados
c. Criterios mnimos que deben cumplirse (i.e. seguridad, SLA1, etc).
d. Consideraciones a ser tomadas en cuenta (i.e. personas involucradas).

7) Modelos de referencia de procesos: Una arquitectura de procesos tiene que incluir

modelos de referencia. Estos modelos proporcionan una base poderosa para los
procesos basados en la experiencia (mejores prcticas).

1
Service Level Agreement: en espaol, Acuerdo de Nivel de Servicio; es un contrato de mutuo acuerdo entre
proveedor y su cliente para definir el nivel de calidad del servicio y otros detalles que proporcionen un
marco de entendimiento.

8
b) Modelos de procesos

La arquitectura de procesos debe contener una grfica o representacin de alto nivel de

estos procesos. Una buena manera de realizarlo es incluir una vista de procesos de la
organizacin.

Figura 4: Vista de procesos de la organizacin

Vista de procesos de la organizacin

Este diagrama representa un representa una vista de alto nivel de una organizacin, desde
una perspectiva de procesos. La agrupacin de los procesos se presenta en tres niveles:

1) Procesos estratgicos: deben asegurar la direccin de los dems procesos (bajo

ellos) hacia objetivos especficos.
2) Procesos bsicos: son los procesos del core-business de la empresa.
3) Procesos de apoyo: representan los procesos no bsicos que apoyan a los
procesos bsicos.

Observaciones importantes sobre este diagrama de alto nivel:

Permite describir los procesos de la organizacin a todas las partes interesadas.

Podra ser puesto en algn lugar visible para toda la organizacin (por ejemplo, en
el sitio web de intranet).
Permitir entender a toda la organizacin las principales actividades y prioridades a
partir de una perspectiva de procesos.

9
El beneficio de tener una vista de procesos de la organizacin de alto nivel es que puede ser
usado para vincularlo a procesos de bajo nivel y ms detallados. De esta manera, se provee
un lenguaje comn para los interesados.

Paso 3: Obtener informacin relevante y principios tecnolgicos.

En esta etapa se debe obtener la informacin relevante (que son los datos de los procesos
que se utilizarn), adems se deben obtener aspectos tecnolgicos (middleware,
plataformas, redes, etc). Todo esto incluye:

Modelos de datos
Aplicaciones principales e interfaces
Middleware principal
Plataformas
Redes

Se debe considerar que la idea central es apoyar la empresa, su estrategia y objetivos, por
ello, es recomendable crear primero las arquitecturas de negocios y procesos antes de la
arquitectura de TI.

Paso 4: Consolidar y validar

En este paso se debe validar la coherencia de lo realizado. Por ello, es uno de los pasos ms
difciles ya que se todos los conflictos que se encuentren deben ser solucionados.

Una manera para consolidar la informacin recolectada es combinar varios modelos de

arquitectura. Por ejemplo, se pueden combinar el organigrama y los procesos de la
organizacin dando como resultado el siguiente diagrama denominado mapa de relaciones
organizacionales que se muestra a continuacin.

10
 Figura 5: Mapa de relaciones en la organizacin.

Este mapa permite visualizar en alto nivel las relaciones y los flujos de procesos entre los
distintos departamentos de la organizacin. Una ventaja de este mapa es que permite
visualizar como se dispersa un proceso end-to-end dentro de la organizacin y detectar las
razones de retrasos o errores.

Interesante se hace mencionar que se muestra en el mapa una desconexin de procesos, esto
es, el call-center en esta organizacin crea las polticas de crdito para sus clientes, sin
embargo, el departamento de colecciones recibe las cuentas atrasadas. Quizs el call-center
debiera tener un feedback acerca de cun efectiva es la poltica para otorgar crditos a sus
clientes, sin embargo, no existe esa retroalimentacin.

Para evitar problemas similares se puede proponer acordar reuniones con los stakeholders
ms importantes para tratar algunos de los siguientes puntos:

utilizar la organizacin objetivos y la estrategia como un punto de partida de la

reunin.
aadir todas las diversas necesidades y opiniones de los interesados.
poner de relieve las relaciones y los conflictos entre estos requerimientos.
priorizar los requerimientos.

11
Paso 5: Comunicaciones

Una buena arquitectura, es la que se entiende y es utilizada como base para la toma de
decisiones dentro de la organizacin. Esto puede lograrse a travs de la comunicacin de la
arquitectura y sus beneficios.

Algunas formas para comunicar son:

Colocar posters con modelos de la arquitectura en toda la empresa.

Asegurarse que los proyectos usan esta arquitectura como punto de partida.

Paso 6: Aplicar la arquitectura

Para aplicar la arquitectura es necesario que la organizacin tenga la disciplina para

hacerlo. Puede suceder que un proyecto quiera alejarse de los principios arquitectnicos
documentados, sin embargo, el nivel de jerrquico ms alto en la organizacin deber
tomar las medidas adecuadas. Esta decisin es vital para concretar la aplicacin de la
arquitectura.

En la mayora de los casos, afectarn sobre esta decisin los beneficios inmediatos de la
decisin del proyecto de desviarse de la arquitectura, contra los beneficios a largo plazo que
nos provee el modelo arquitectnico.

Una solucin es la gestin de excepciones a la regla, en vez de reprimirlas completamente,

tal como se presenta en la siguiente figura:

12
Arquitectura de inicio de proyecto

Con el fin de utilizar la arquitectura de procesos, la organizacin debe desarrollar una PSA
(del ingls: Project Start Architecture) sobre la base del DYA (Dynamic Architecture). La
PSA es simplemente un subconjunto de la arquitectura de procesos.

Paso 7: Hacerlo mejor

Es fundamental utilizar un mecanismo para la gestin del cambio, ya que las variaciones de
la arquitectura a travs del tiempo pueden afectar considerablemente los procesos.

Maneras de expandir la arquitectura:

En amplitud: Agregar ms aspectos tcnicos.

En profundidad: Incluir ms detalles (por ejemplo, un proceso de negocios ms
detallado).
En volumen: Ms procesos pueden incluirse (una unidad de negocio que antes no se
haba contemplado).

Como ltimo paso, es extremadamente importante que la arquitectura se utilice, para ello
debe evaluarse de forma peridica garantizando su utilidad.

Conclusiones

En el diseo de una arquitectura de procesos influyen muchos factores (internos y externos)

por lo que se asume altamente probable la posibilidad que vare constantemente su
estructura, lo que sugiere incorporar mecanismos de gestin del cambio.

Una gran ventaja de una arquitectura de procesos es la capacidad que tiene para crear un
lenguaje comn para todos los involucrados en los procesos. De esta forma, todos pueden
comunicarse de mejor manera al momento de expandir esta arquitectura.

Las habilidades de negociacin deben estar presente en el arquitecto, debido a que es de

suma importancia el que los stakeholders puedan llegar a un mutuo acuerdo y ponerse de
acuerdo en lo que quieren.

Finalmente, y debido al anlisis ms profundo que el realizado en la fase 1 del framework,

la arquitectura puede servir de retroalimentacin para los objetivos y estrategia de la
organizacin, al descubrir aspectos que se puedan haber olvidado.

13
Referencias

Jeston, J., & Johan, N. Business Project Management, Practical Guidelines to Succesful
Implementations.

Geofress, B. (2006). BPM Institute. Recuperado el 13 de Octubre de 2008, de Business

Architecture: Creation and Application:
http://www.bpminstitute.org/articles/article/article/business-architecture-creation-and-
application.html

14