Texto Universitario NOTACION de PROCESOS

NOTACIN DE
PROCESOS DE NEGOCIOS
Asignatura: NOTACION DE PROCESOS DE NEGOCIO
Universidad Continental
Material publicado con fines de estudio
Primera edicin
Huancayo, 2015
Pg. 2
PRESENTACIN
Notacin de Procesos de Negocio es una asignatura que proporciona conocimiento sobre
los fundamentos de Business Process Management, a travs de un trasfondo histrico para
comprender mejor la evolucin de la ingeniera de procesos. Asimismo se considera los conceptos
de implementacin, para conocer y entender las definiciones que facilitan comprender el alcance de
BPM, la segunda parte integra a los modelos de procedimiento el apoyo tecnolgico en cada una de
las capas del BPM y finalmente se muestra la notacin BPMN con el objetivo de aplicarlo a casos de
negocios.El resultado de aprendizaje: Al finalizar la asignatura el estudiante ser capaz de
elaborar modelos de diversos procesos de negocio, utilizando los principios de Business
Process Management (BPM) y elementos de notacin de Business Process Model and
Notation (BPMN), basado en una plataforma de diseo, simulacin y automatizacin de
procesos como representacin estndar para las necesidades de una organizacin.
El presente material consta de cuatro unidades: Unidad I: ENFOQUE: BUSINESS

PROCESS MANAGEMENT (BPM)n presenta conceptos, y principios bsicos, la organizacin y
estructura de BPM. Unidad II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO
BUSINESS PROCESS MANAGEMENT BPM presenta conceptos y las relaciones entre estndares
existentes para la gestin empresarial basada en procesos. Unidad III:
BUSINESS PROCESS
MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN

presenta los elementos de notacin de Business Process Model and Notation (BPMN). Unidad IV:
AUTOMATIZACIN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN),
presenta herramientas de simulacin y automatizacin, desarrollados a partir del texto BPM:
Business Process Management Fundamentos y Conceptos de Implementacin (HITPASS, Bernard,
2014).
Es recomendable que el estudiante desarrolle una permanente lectura de estudio junto a la

elaboracin de los modelos de procesos, as como la investigacin en otros textos y va internet. El
contenido del material se complementar con las lecciones presenciales y a distancia que se
desarrollan en la asignatura.
Agradecemos a quienes con sus aportes y sugerencias han contribuido a mejorar la presente
edicin, que slo tiene el valor de una introduccin al conocimiento de las estructuras de datos para
la programacin en un computador.
Las autoras.
Pg. 3
NDICE
Pg.
PRESENTACIN
NDICE
UNIDAD I: INTRODUCCION Y DEFINICION DEL BPM
Tema N 1: Introduccin al BPM
1.1 Antecedentes de BPM
1.2 Historia y Evolucin
Tema N 2: Conceptos Bsicos de BPM
2.1 Definicin de Proceso
2.2 Proceso de Negocio
2.3 Gestin de o por procesos de negocio?
2.4 Gestin tradicional sin BPM
2.5 Bussiness Process Management (BPM)
Tema N 3: Organizacin y Estructura del BPM
3.1 Conceptos de Gestin en BPM
3.2 La automatizacin de procesos (BPA)
3.3 Los participantes en BPM
3.4 Herramientas para BPM
3.5 La arquitectura del BPM y SOA
3.6 Reglas de Negocio
3.7 Gestin de Reglas de Negocio
3.8 Reglas de negocio y Reglas de ruteo
3.9 Tcnicas de Mejora Continua
UNIDAD II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS MANAGEMENT
Tema N 4: Arquitectura Empresarial
4.1 Definicin de Arquitectura
4.2 Definicin de Arquitectura Empresarial AE
4.3 Drivers y Objetivos de una AE
Tema N 5: reas de una Arquitectura Empresarial
5.1 Business Process Outsourcing (BPO)
5.2 Gestin de calidad - riesgo - conocimiento - regulaciones - otras
5.3 Auditoria
5.4 Portafolio de proyectos
5.5 ITIL (Information Technology Infrastructure Library)
Tema N 6: Modularizacin de Programas
6.1 Relacin Arquitectura Empresarial Business process Management - Service Oriented Architecture (AE & BPM & SOA)
Tema N 7: Frameworks de Arquitectura Empresarial
7.1 Framework de AE
7.2 Framework de Zachman
7.3 TOGAF (The Open Group Architecture Framework)
7.4 FEA (Federal Enterprise Architecture)
7.5 ARIS (Architecture of Integrated Information Systems)
7.6 Enterprise Architecture as Strategy (Ross et al)
Tema N 8: Modelos de Madurez de BPM
8.1 Qu es un modelo de madurez?
8.2 Modelo de Madurez BPM de la OMG (BPMM: Business Process Maturity Model)
8.3 Modelo de madurez BPM de Schmelzer
UNIDAD III: BUSINESS PROCESS MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN)
Tema N 8: Evolucin de Business Process Model and Notation (BPMN)
8.1 Historia de tcnicas para modelado de sistemas y procesos
8.2 Clasificacin de las tcnicas de modelamiento
8.3 Otras Tcnicas de Modelado
8.4 Business Process Model and Notation (BPMN)
Tema N 9: Los elementos bsicos de BPMN
9.1 Modelos, instancias, token y correlaciones
9.2 Categoras de los elementos de BPMN
9.3 Actividades
9.4 Flujos de Secuencia
9.5 Actividades globales
9.6 Un proceso simple en BPMN
9.7 Flujo de Procesos con Gatewatay
9.8 Eventos
9.9 Lane
9.10 Artefactos
9.11 Participantes y flujos de mensajes
9.12 Subprocesos
Tema N 10: Diferentes vistas de un proceso
Tema N 11: Categora de Procesos
11.1 Orquestacin
11.2 Coreografa
11.3 Colaboracin.
UNIDAD IV: AUTOMATIZACIN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN)
Tema N 12: Automatizacin de Procesos
12.1 Niveles de Procesos
12.2 BPMN comparado con otras notaciones
BIBLIOGRAFA
Pg. 4
3
4
5
5
5
5
9
9
10
13
15
16
18
18
25
26
29
31
34
35
36
38
46
46
46
46
48
52
52
53
53
54
54
55
55
58
58
58
59
60
61
62
63
63
63
64
65
65
65
67
67
68
70
70
70
71
74
75
75
75
80
87
88
88
89
90
91
91
91
92
93
93
94
99
100
UNIDAD I
INTRODUCCION Y DEFINICION DEL BPM
Tema N 1: Introduccin al BPM
1.1 Antecedentes de BPM

(HITPASS, 2013)
La globalizacin est demandando mayores exigencias, tanto a las empresas privadas como a las
organizaciones pblicas, en su capacidad de reaccin frente a los cambios exigidos por el
mercado. stos pueden ser cambios en el tipo de demanda o cambios de regulaciones.
Existen muchas definiciones de BPM. Aunque todas ellas tienen algo en comn tambin existen
diferencias, sobre todo en el alcance. Algunos autores y expertos, en especial en Europa,
restringen el BPM a una disciplina de gestin sin incluir explcitamente el apoyo de TI. Otros
autores, definen BPM como el proceso hacia la automatizacin y operacin de los procesos
implcitamente con TI.
El concepto de BPM es incluso ms amplio, pero va a depender cuelas son los objetivos que
perseguimos con BPM, que por lo general todas las escuelas los comparten. Por lo general las
diferencias de las escuelas se encuentran en el concepto de cmo enfrentar el proceso hacia el
logro de los objetivos y cada concepto parte por una definicin, razn por la cual algunas
definiciones se diferencian de otras. La descripcin de los objetivos es clara y bien definida.
1.2 Historia y Evolucin
Evolucin de la Ingeniera de Procesos hacia el BPM

Fuente: (HITPASS, 2013)
Pg. 5
1.2.1 La ingeniera de procesos nace con Frederick Taylor

(HITPASS, 2013)
La idea que las actividades (el trabajo) se pueden describir como un proceso no es nueva. A
principios del siglo pasado Frederick Winslow Taylor (1911) desarroll el concepto de la
Administracin Cientfica (Taylor public poco antes de morir (1915) en 1911 su obra que lo hizo
tan famoso The Principles of Scientific Management .) [TaylorFre08]. A Taylor se le atribuye
haber desarrollado los principios de la especializacin y estandarizacin de los procesos en la
produccin industrial elevndolos a una ciencia que podramos llamar ingeniera industrial y
mejora de procesos, razn por la cual muchos autores lo denominan como el padre de la
ingeniera industrial. Taylor aporta en mtodos de observacin de buenas prcticas, de medicin
del trabajo y a partir de estos conocimientos de disear procesos industriales desagregados hasta
el nivel de actividad manual (Taylor hablaba de administracin de tareas) altamente
especializados para lograr mejoras sustanciales en la productividad.
Los principios de la administracin cientfica que describe Taylor en su obra pueden resumirse
segn (Bravo, 2011) en los siguientes cuatro pasos:
1. Desarrollar el estudio cientfico del trabajo, una ciencia segn Taylor
2. Seleccionar cientficamente al obrero ms adecuado a la tarea, segn sus capacidades, y luego
instruirlo en cmo hacer correctamente la tarea, segn el punto anterior.
3. Cooperar con los obreros para que todo el trabajo sea hecho de acuerdo con los principios
cientficos que se aplican. Se refiere a una cooperacin de los investigadores y de los
administradores. Armona es la palabra principal que emplea Taylor.
4. Distribuir equitativamente el trabajo y la responsabilidad entre la administracin y los obreros.
Juan Bravo (Bravo, 2011) en su libro indica lo siguiente sobre Taylor:
Podemos resumir que el objetivo que persegua Taylor al reunir hechos y mediciones era
proporcionar un fundamento cientfico para disear y mejorar los procesos. Con estos
fundamentos pretenda terminar con la improvisacin que predominaban en aquella poca. En vez
de hacer que cada trabajador hiciera la tarea a su manera, Taylor quera encontrar la forma ptima
de hacerla y estandarizar las buenas prcticas hacindolas ms eficientes y lograr economas de
escala. Este enfoque fue empleado con xito durante toda la poca de la industrializacin
(mercado de la oferta) durante el siglo XIX y principios del siglo XX, pero esta tcnica estaba
restringida a los procesos manuales y a la produccin industrial y no inclua el seguimiento de
los procesos de gestin.
Pg. 6
1.2.2
El cambio del mercado de la oferta al mercado de la demanda
(HITPASS, 2013)
Ms adelante, a principios de los 80, aparecieron enfoques estadsticos con el objetivo de mejorar
los procesos de control. As naci el enfoque TQM (Total Quality Management) basado en una
gestin de control estadstico, pero aplicarlo requiere de una rigurosa disciplina en la organizacin
que es Management) basado en una gestin de control estadstico, pero aplicarlo requiere de una
rigurosa disciplina en la organizacin que es difcil de alcanzar.
Empresas japonesas, en particular Toyota, reconocieron a principios de los 90 el cambio hacia el
mercado de la demanda y enfocaron la gestin orientada hacia las necesidades del negocio
(clientes).
Nota: En el mercado de la demanda, la oferta es mayor que la demanda por lo que en economa
se deduce que la fuerza compradora es ms influyente que el poder que pueden ejercer los
proveedores en los mercados en que operan.
Toyota desarroll el concepto Toyota Production System (TPS)[ Liker06]. Este se caracterizaba
por contar con una estructura organizacional muy plana, instalando equipos multidisciplinarios en
centros de produccin y con el encargo de resolver en forma autnoma propuestas de mejora
continua en los procesos de produccin. A este sistema de trabajo se le llam tambin Lean
Production, indicando en quitarle grasa a las estructuras organizacionales burocrticas y lentas en
sus procesos de decisiones.
Cuando en los aos 90 muchas empresas occidentales fueron azotadas por la recesin, debido a
que los mercados haban llegado a una situacin de la sobre oferta (saturacin, cambio hacia el
mercado de la demanda) y el comienzo de la globalizacin, aparece el Business Process
Reengineering (BPR, Hammer and Champy, 1993) (Hammer, M. y Champy, J., 1993) como
medida de salvacin para deburocratizar las empresas y ser ms eficientes en sus procesos de
negocios.
Pg. 7

1.2.3 La reingeniera de procesos como precursor de BPM
(HITPASS, 2013)
El Business Process Reengineering BPR tiene como finalidad redisear y hacer ms eficientes
los procesos, atacando las estructuras jerrquicas funcionales y alinendolos con los objetivos
del negocio, buscando alcanzar resultados de desempeo espectaculares a corto plazo. La
reingeniera de procesos se basa y apoya fuertemente en la incorporacin de tecnologas de la
informacin, como elemento clave para la transformacin esperada. El BPR es el primer enfoque
end to end en introducir como gestin los procesos de negocios transversales a las
organizaciones funcionales, centrados en las necesidades del cliente y no en los procesos de
produccin, pero esto no fue fcil, muchos proyectos de BPR terminaron siendo proyectos de
racionalizacin de recursos con una fuerte reduccin de personal. Perdiendo, muchas veces, la
perspectiva de agregacin de valor para el cliente. BPR no fue el nico enfoque en aparecer en
dichas dcadas, a principio de los aos 80 apareci Six Sigma como una opcin para mejorar la
eficacia y eficiencia de los procesos de negocio. Este enfoque surgi en Motorola Inc. y el caso
prctico de aplicacin ms conocido fue General Electric en los 90. Como TQM, Six Sigma se
basa en principios estadsticos para mejorar los procesos de control y mejora. La sigla Six Sigma
significa one output defect in six Standard deviations of a probability distribution for a particular
process output. Las tcnicas de Six Sigma se emplean sobre la base de episodios o eventos, los
cuales debiesen estar dentro del nivel de exigencia definida para el proceso (cantidad de Sigmas),
pero no incorporan un pensamiento de mejora continua. Muchas empresas combinan el enfoque
de Six Sigma con TPS o Lean Production. An no se puede predecir cmo va a seguir
evolucionando Six Sigma, pero a pesar que se detectan signos de cansancio an est muy
difundido en empresas norteamericanas (Davenport, forward BPM Jeston and Nelis, 2008) (John
Jeston & Johan Nelis, 2008). A mediados de los 90 aparece la ola de los ERPs (Enterprise
Resource Planning). Los ERPs se vendieron como la solucin para todos los problemas en la
organizacin, pero los ERPs no generaron la eficiencia y eficacia esperada en los procesos de
negocios, estaban diseados para mejorar la eficiencia administrativa. A fines de los aos 90 y a
principios del 2000 aparecieron los sistemas Customer Relation Management (CRM) como medida
para mejorar los servicios a los clientes, pero an no contbamos con una integracin entre los
procesos del front office (CRM) con los del back office (ERP).
Pg. 8
Tema N 2: Conceptos Bsicos de BPM

2.1 Definicin de Proceso
(HITPASS, 2013)
En principio, un proceso corresponde a la representacin de un conjunto de acciones (actividades)
que se hacen, bajo ciertas condiciones (reglas) y que puede gatillar o ejecutar cosas (eventos). En
forma genrica se puede definir un proceso como:
Una concatenacin lgica de actividades que cumplen un determinado fin, a travs del tiempo y
lugar, impulsadas por eventos. Esta definicin contiene los principales elementos que describen
un proceso: Los eventos son ocurrencias externas que inician un proceso, es decir un proceso no
se inicia por s slo, algo tiene que ocurrir y el proceso reacciona ante el suceso. El proceso debe
cumplir un determinado fin, en las ciencias econmicas destinadas a producir bienes y servicios.
A diferencia de los eventos, las actividades en un proceso consumen tiempo y recursos. Una
actividad se puede definir como una accin sobre un objeto, es decir el proceso de
transformacin ocurre a travs de las actividades en un proceso.
Las actividades en un proceso estn encadenadas a travs de una secuencia lgica que
determinan en su conjunto las condiciones del negocio.
Estos elementos bsicos describen en su conjunto los procesos y estn contenidos en la mayora
de las notaciones para modelarlos, as tambin en el estndar BPMN. La definicin es pura, no
dice nada respecto para qu objetivos se levantan y modelan procesos en una organizacin.
Ejemplo de proceso: Proceso de Matrcula Universidad
(Fuente: http://www.universidad.continental.edu.pe/sobre-matriculas/)
Pg. 9
Ejemplo de proceso: Proceso de Elaboracin de calzado artesanal

(Fuente: http://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.html)
Paso 1: Seleccin y adquisicin del material.
Paso 2: Seleccin del modelo y corte a realizar.
Paso 3: Armado de la Pala.
Paso 4: Montado.
Paso 5: Desmontado.
Paso 6: Terminado.
Paso 7: Empaquetado y distribucin.
2.2 Proceso de Negocio

(Hammer, M. y Champy, J., 1993) Introducen en su obra de Reingeniera de Procesos en el ao
93, el concepto de proceso de negocio:
Un proceso de negocio es un conjunto de actividades que toman uno o ms tipos de inputs y
crean un output que es de valor para un cliente.
Los procesos de negocio son los que crean valor para un cliente, es decir la definicin est ligada
al concepto de creacin de valor para el cliente. Siguiendo la definicin propuesta en este trabajo
de un proceso en forma general, se definir un proceso de negocio como:
Un proceso de negocio es un conjunto de actividades que impulsadas por eventos y
ejecutndolas en una cierta secuencia crean valor para un cliente (interno o externo).
Un proceso de negocio se reconoce por el tipo de evento que lo gatilla. Una de las principales
caractersticas de un proceso de negocio es que es gatillado por el cliente y los resultados de la
ejecucin del proceso tienen que volver al cliente, entendindose en el sentido ms amplio que el
cliente tambin puede ser interno, por ejemplo un rea de negocio o externo un proveedor. En
Ingeniera Industrial se le conoce como Pull Process, el cliente tira el proceso de negocio. A
diferencia de Push Process, donde se empuja los objetos a travs del proceso para llegar al
cliente. El concepto de Pull y Push Process est relacionado con la forma en que se planifican,
distribuyen y reponen los productos en bodega (logstica). Existen dos formas que cubren este
ciclo:
1. En el concepto push, se calcula la demanda sin conocer los pedidos de los clientes (por ejemplo
las representaciones de autos en Chile funcionan as). Importan autos y luego los venden.
2. En el concepto de pull, solo se planifica y produce bienes bajo demanda real y est muy
relacionado con el concepto de just in time, es tratar de bajar al mnimo los procesos de bodegaje
intermedio. Dell por ejemplo se hizo famoso en los aos 90 aplicando este concepto al extremo.
Slo se produce a pedido real (orden de compra) del cliente. Es normal encontrar en muchas
compaas combinaciones de ambos tipos de flujos, en particular para responder con mayor
oportunidad a los requerimientos de los clientes. El proceso de negocio es transversal a las reas
y atraviesa la cadena de valor de principio a fin (tambin se usa mucho el trmino anglosajn end
Pg. 10

to end). Este principio es indistinto si se trata de un cliente externo (cliente final) de la empresa o
cliente interno.
Muchas veces se confunden los macroprocesos con los procesos de negocio.
Por lo general corresponden los macroprocesos con las grandes reas de negocio de una
empresa como por ejemplo abastecimiento, produccin, bodega, venta, etc. Ningn cliente externo
va a gatillar un proceso en el rea de abastecimiento y los procesos en esta rea tampoco
atraviesan la cadena de valor de la empresa.
A pesar que estas reas pueden ser muy grandes y muy complejas no tienen relacin directa con
el concepto de proceso de negocio: gatillado por el cliente, de principio a fin y el resultado tiene
que ser de valor para el cliente.
Los procesos de negocio se encuentran debajo de los macroprocesos y los atraviesan. Al mapear
los procesos de una organizacin en muchas ocasiones se cometen grandes errores al respecto.
Si se descomponen top down los macroprocesos se van a mapear los procesos internos de las
reas en diferentes grados de abstraccin, y justamente stos no son los procesos de negocio.
Cmo se pueden identificar entonces los procesos de negocio?

Para estos efectos se recomienda realizar un anlisis del contexto y hacer un listado de todos los
eventos iniciados por el cliente. A continuacin se nombran ejemplos de procesos de negocio:
Solicitudes de crditos, prstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra
de pasajes Procesos de reclamaciones Seguimiento de resolucin de problemas en Servicio a
Clientes Gestin de Hipotecas, Multas,... Recepcin y pago de factura Recepcin y confirmacin
de orden de compra Elaboracin de ofertas
Los siguientes ejemplos no se pueden clasificar como procesos de negocio.

Partida doble en contabilidad: Se trata de una funcin contable, que le sigue a un movimiento
contable.
Reserva de pasajes: Se trata de un subproceso del proceso de negocio compra de pasajes.
En este caso no se cumple el principio de finalidad, que sera la compra del pasaje.
Ingreso de un nuevo empleado al sistema de RRHH: Actividad manual del proceso de negocio
contratacin de personal. El cliente interno es el rea de negocio, quin gatilla la solicitud de
contratacin.
Ingreso de una orden de compra: Actividad manual del proceso de negocio compra de un
producto o servicio.
Envo de email: Actividad tcnica sin significado de negocio
Emitir una pliza: Emitir puede significar imprimir, generar o extender una pliza de seguros, pero
de todas formas el proceso de negocio sera la solicitud de un contrato de seguros
Pg. 11

Debe tener cuidado en no confundir el concepto de cadena de valor propuesto por Porter con el
concepto de proceso de negocio que est ligado al concepto de valor para el cliente. La figura
muestra la tpica estructuracin de una cadena de valor descompuesta en procesos de direccin,
procesos primarios y procesos de soporte, siendo los procesos primarios los procesos de la
cadena de valor porque estn directamente relacionados con la creacin de bienes y servicios
para el cliente externo, pero la cadena de valor no es lo mismo que los servicios que solicitan los
clientes.
Figura Estructura de Cadena de Valor segn Porter

FUENTE: (HITPASS, 2013)
La siguiente figura muestra la transversalidad de los procesos de negocio que son impulsados por
clientes y cuyos resultados tienen que volver a ellos.
Figura Estructura de procesos de negocio

La cadena de valor muestra las dependencias en los pasos de produccin, mientras que los
procesos de negocio muestran las dependencias de las polticas de negocio para atender las
peticiones de los clientes y llevarlos a un resultado satisfactorio que tiene una expresin de
mercado, es decir el cliente est dispuesto a pagar (creacin de valor).
Pg. 12

2.3 Gestin de o por procesos de negocio?
Actualmente es muy utilizado ambos trminos tanto Gestin por procesos como Gestin de
procesos, y es importante saber si existe diferencia entre ambos trminos:
(HITPASS, 2013)
En una organizacin existen muchos procesos de negocio. Si nos referimos a gestionar un
proceso en particular hablamos de gestin de proceso.
Generalmente el primer objetivo en las organizaciones es lograr un mayor control y desempeo
sobre los procesos.
Mayor control significa tener conocimiento en tiempo real en qu estado se encuentra cada uno de
los procesos instanciados.
Por ejemplo saber sobre la carga de trabajo de cada uno de los usuarios y saber cules procesos
se encuentran estancados por alguna razn.
Esta informacin le permite al supervisor (gestor del proceso) detectar problemas antes que
impacten sobre los resultados. Al tener mayor control sobre lo que est sucediendo podemos
mejorar el desempeo de los procesos, por ejemplo acortar los tiempos de ciclo y en general
mejorar el grado de satisfaccin de cliente.
Al introducir gestin de procesos en una organizacin tenemos la posibilidad de mejorar el
grado de cumplimiento de objetivos funcionales, pero no es un instrumento suficiente para alinear
la gestin de procesos con la estrategia de la organizacin y sus debidos objetivos de negocio.
La gestin de procesos se focaliza en medir y analizar el desempeo de los procesos en
operaciones, pero no incluye los conceptos de alineamiento con otras capas de la organizacin,
por ejemplo la integracin a los procesos de alineamiento con la estrategia y la capa de
tecnologa.
Gestin por procesos significa incluir los procesos de planificacin y alineamiento a la gestin de
procesos.
Pg. 13

Entre acadmicos y profesionales de BPM es ampliamente conocido el principio que los procesos
deben seguir la estrategia y que la tecnologa debe seguir a los procesos .
Gestin de procesos no incluye estos ciclos de planificacin y de alineamiento a los procesos
como lo pide la disciplina de gestin BPM, pero si ampliamos el concepto de gestin e integramos
las otras disciplinas empresariales a la gestin de procesos, entonces hablamos de gestin por
procesos y en su definicin ms amplia en ingls de Business Process Management (BPM).
En la gestin de procesos nos centramos en el resultado de cada proceso y las acciones a realizar
(mejora continua, reingeniera o innovacin).
1. Identificacin de los procesos y planificacin de los Objetivos a conseguir con cada proceso. (Fase
de Modelizacin y Planificacin de Procesos)
2. Medicin de los resultados de los indicadores en la ejecucin o funcionamiento de los procesos
(Fases de Automatizacin y Ejecucin de Procesos)
3. Control de la consecucin de los indicadores al compararlos con los objetivos y definicin de
acciones correctoras (Fase de Monitorizacin)
En la Gestin Por Procesos nos centramos en la alineacin de la gestin de procesos con la estrategia
empresarial y con el resto de gestiones empresariales:
1. La gestin DE procesos para que cada proceso produzca el resultado esperado
2. La alineacin de cada proceso con la Estrategia Empresarial, de esta forma sabremos qu aporta
cada proceso a cada objetivo estratgico, y definido un objetivo estratgico a qu procesos afecta y
si es necesario optimizarlos
3. La cultura de la empresa ser coherente con un sistema de gestin de procesos
4. La gestin y direccin del personal se realizar con enfoque a procesos
5. Las diferentes gestiones de la empresa se alinearn con la gestin por procesos
Fuente: http://pedrorobledobpm.blogspot.com/2014/07/gestion-de-procesos-versus-gestion-por.html
Pg. 14
2.4 Gestin tradicional sin BPM
Para conceptualizar y entender la diferencia entre la gestin de y por procesos es importante

realizar una retrospectiva, y saber cmo funcionaba una organizacin sin BPM.
(HITPASS, 2013)
Para responder a esta pregunta fundamental vamos a analizar primero cmo funciona la gestin
tradicional centrada en consolidar planes de negocio por rea y no por procesos de negocio que
son transversales a la organizacin.
Por lo general, la formulacin de la estrategia de una empresa es amplia y define los grandes hitos
que se deben lograr y sobre todo en que hay que centrarse para cumplir con la misin de la
empresa y los objetivos de negocio que se formulan a travs del ciclo presupuestario en un ao
comercial, pero la estrategia es transversal a las reas de negocio, igual que los procesos de
negocio. Aqu nos encontramos en la gestin empresarial tradicional con la primera brecha.
De alguna forma se traspasan los objetivos de negocio desde la alta direccin a la capa de
operaciones y a su vez operaciones formula, por medio de una especificacin, los requerimientos
de cambio a la capa de tecnologa, pero este proceso no est estandarizado y menos integrado
bajo una metodologa comn. Al no estar estandarizado ni integrado ocurren fricciones y por lo
tanto prdida de valor. Como la estrategia es transversal y no existe un cargo que se
responsabilice por el rendimiento del proceso completo, vale decir de principio a fin, los procesos
de alineamiento son lentos y de alto costo. As se produce prdida de valor en tres grandes
mbitos de la gestin empresarial tradicional, a saber:
1. Cmo plasmar la estrategia en la organizacin
2. Cmo lograr que los procesos se implementen con tecnologa
3. Prdida de valor en la estructuracin misma de los procesos
Estas son las tres grandes razones (oportunidades) para implementar gestin por BPM. El aporte
del concepto de BPM como disciplina integrada es cerrar estas brechas.
Pg. 15
2.5 Bussiness Process Management (BPM)
Es una metodologa corporativa y disciplina de gestin, cuyo objetivo es mejorar el desempeo

(eficiencia y eficacia) y la optimizacin de los procesos de negocio de una organizacin, a travs
de la gestin de los procesos que se deben disear, modelar, organizar, documentar y optimizar
de forma continua. Por lo tanto, puede ser descrito como un proceso de optimizacin de procesos.
El modelo de administracin por procesos, se refiere al cambio operacional de la empresa, al
migrar de una operacin funcional a una operacin administrada por procesos.
El BPM es el entendimiento, visibilidad y control de los procesos de negocio de una organizacin.
Un proceso de negocio representa una serie discreta de actividades o pasos de tareas que
pueden incluir personas, aplicativos, eventos de negocio y organizaciones.
BPM se puede relacionar con otras disciplinas de mejora de procesos como Six Sigma. Los
procesos de negocio deberan estar documentados (actualizados), para ayudar a entender a la
organizacin que estn haciendo a travs de su negocio.
Detallamos otros conceptos de BPM:
(John Jeston & Johan Nelis, 2008): BPM es el logro de los objetivos empresariales a travs de la
mejora, la gestin y el control de los procesos de negocio.
En esta definicin, se abstrae explcitamente, que la tecnologa va a solucionar los problemas a las
organizaciones.
Paul Harmon (Harmon, 2007) tambin define BPM como: Una disciplina de gestin focalizada en
la mejora del rendimiento corporativo por medio de la gestin por procesos de negocio.
Finalmente Jeston y Nelis (John Jeston & Johan Nelis, 2008) concluyen, BPM es:
Ms que slo software, ms que solo la mejora o la reingeniera de los procesos, no es solamente
una moda, es parte integral del management, ms que slo levantamiento y modelado de
procesos, tambin es la implementacin y ejecucin de los procesos, los cuales requieren ser
analizados y mejorados.
Pg. 16

Factores crticos del BPM segn Jeston y Nelis:
El logro de la estrategia organizacional
La organizacin est alineada con los procesos end to end
Los objetivos estn alineados con la estrategia organizacional
Los procesos deben mejorar en su eficiencia y ser eficaces Gestin orientada a procesos
(Management)
Controlar el ciclo completo de BPM
Seleccionar los procesos crticos, no todos los procesos contribuyen al logro de los objetivos
estratgicos
Implementar BPM tiene que tener impacto en los beneficios del negocio Nuestra definicin tiene
un alcance amplio y abarca tanto la disciplina de gestin como la incorporacin de TI para la
automatizacin de los procesos.
Definimos en forma abreviada BPM como: Disciplina de Gestin por Procesos de Negocio y
de Mejora Continua apoyada fuertemente por las Tecnologas de la Informacin
Una definicin ms amplia la encontramos en la gua de referencia de la Asociacin Internacional

de Profesionales de BPM (BPM Common Body of Knowledge, ABPMP (Association of BPM
Professionals) (Tony Benedict, Nancy Bilodeau, Phil Vitkus, Emmett Powell, Dan Morris, Marc
Scarsig, Denis Lee, Gabrielle Field, Todd Lohr, Raju Saxena, Michael Fuller, Jose Furlan, 2013):
Business Process Management (BPM) es un enfoque sistemtico para identificar, levantar,

documentar, disear, ejecutar, medir y controlar tanto los procesos manuales como
automatizados, con la finalidad de lograr a travs de sus resultados en forma consistente los
objetivos de negocio que se encuentran alineados con la estrategia de la organizacin. BPM
abarca el apoyo creciente de TI con el objetivo de mejorar, innovar y gestionar los procesos de
principio a fin, que determinan los resultados de negocio, crean valor para el cliente y posibilitan el
logro de los objetivos de negocio con mayor agilidad.
Como lo indica (HITPASS, 2013) la definicin de la ABPMP, BPM es una disciplina integradora
que engloba tcnicas y otras disciplinas organizacionales, que abarca las capas de negocio y
tecnologa, que se comprende como un todo integrado en gestin a travs de los procesos. Nos
inclinamos por esta definicin porque diferencia entre procesos manuales y automatizados, pero
integra ambos casos a la disciplina de BPM. Con esta definicin pretendemos lograr un
entendimiento comn que es necesario para tener xito en introducir BPM en una organizacin.
Para lograr los objetivos que se persiguen en BPM es necesario sincronizar e integrar los
procesos manuales con los implementados con apoyo de TI o los que se van a automatizar.
Pg. 17
Tema N 3: Organizacin y Estructura del BPM

3.1 Conceptos de Gestin en BPM
BPM ataca la automatizacin de procesos por toda la empresa, pero con total adherencia a las
modificaciones de negocios que un mercado de fuerte competicin exige. No existe una
combinacin nica y exacta de los procesos, metodologas e indicadores, y en muchos casos
estos existen aisladamente.
Una herramienta de BPM debe soportar las actividades bsicas de la gestin, que pueden ser
resumidas en:
Definir una estrategia para conducir el performance;
Traducir la estrategia en objetivos, indicadores y metas;
Acompaar el progreso en relacin a las metas;
Analizar los motivos en caso de metas no alcanzada y
Seleccionar e implementar acciones correctivas.
Sistemas de BPM sirven para ayudar la empresa a controlar mejor sus propios procesos, a
reformarlos cuando es necesario y a realizar tareas importantes con ms eficiencia. Estos
sistemas dan al usuario ms control sobre la automatizacin de procesos, lo que alivia el trabajo
de la informtica. El BPM impone a la empresa un desafo muy grande, pues obliga el usuario a
dos acciones que, casi siempre, a l no le gusta hacer: repensar en las tareas del da-a-da y, al
menos en la fase de implementacin, trabajar lado a lado con el personal de informtica.
(HITPASS, 2013)
BPM como disciplina de gestin orientada a procesos abarca dos grandes reas de la gestin
empresarial: BPM Governance y BPM Operacional.
3.1.1 BPM Governance

(HITPASS, 2013)
BPM Governance, tambin llamado gobierno corporativo, como un modelo de gestin
corporativo orientado a procesos, pero integrado con todas las capas de una organizacin
(capa de direccin, operacional y de tecnologa), las fases del ciclo de gestin, la gestin del
cambio de nuevos requerimientos (en ingls: Change Management), la estructura organizacional y
todos los instrumentos de alineamiento de y entre las estructuras corporativas.
BPM Governance abarca el alineamiento con todo el ciclo de gestin organizacional desde la
planificacin y gestin estratgica, la definicin de planes de negocio, el ciclo presupuestario, la
definicin de perfiles y cargos, la gestin en operaciones, apoyo tecnolgico hasta el alineamiento
con el portafolio de proyectos corporativo.
Pg. 18

(Harmon, 2007) En la literatura se encuentran varias definiciones de BPM Governance, (John
Jeston & Johan Nelis, 2008), la mayora de ellas muy amplias pero todas coinciden que se trata de
un concepto definido para una organizacin de cmo debe aplicarse Gestin por Procesos y
que integra instrumentos y disciplinas existentes en torno a los procesos de negocio.
Harmon (Harmon, 2007)] discrimina primero entre governance y management, explicando

que governance es la organizacin del management. Resumiendo a su entender cuando
hablamos de governance nos referimos a un modelo especfico de gestin, mientras que
gestin es una actividad humana.
Para Jeston y (John Jeston & Johan Nelis, 2008)(pags. 323-324) en un modelo de BPM
Governance son clave la definicin de roles y responsabilidades, los procesos de alineamiento con
la estrategia de la empresa, el control de gestin orientado a procesos y finalmente la
estandarizacin de los procesos de gestin.
Fuente:
https://www.paradigma.com/html/espanol/notas_de_interes/opiniones_profesionales/opiniones/Go
bierno%20por%20procesos.html?keepThis=true&TB_iframe=true&height=450&width=650
Pg. 19
3.1.2 BPM Operacional

(HITPASS, 2013)El BPM Operacional abarca la gestin del ciclo BPM por proceso y no los
mecanismos de alineamiento con las otras capas de la organizacin que, es dominio de un modelo
que incorpora BPM Governance.
El ciclo presentado est pensado para ser aplicado para cada proceso por separado o en forma
independiente. Cada proceso puede encontrarse en un estado diferente del ciclo. El ciclo
comienza a partir de dos posibles constelaciones: Un proceso actual que debe levantarse y
documentarse y/ o redisearse. Se debe introducir un nuevo proceso, no existente en la
organizacin.
En la fase de Levantamiento del Proceso primero se debe recoger la informacin sobre cmo
est organizado el flujo de trabajo. Esto se realiza con la ayuda de tcnicas de moderacin,
talleres, entrevistas, recoleccin de documentacin, etc. Para esto en el proceso a levantar se
debe:
Delimitar claramente desde procesos anteriores o posteriores
Describir los servicios que produce para los clientes y qu prioridad tiene desde el punto de
vista de los objetivos de negocio
Representar tanto el flujo de trabajo como los roles que intervienen en cada uno de los
pasos, los recursos que se utilizan y los sistemas de informacin que lo apoyan
Pg. 20

En la etapa de Documentacin del Proceso el conocimiento adquirido en la etapa de
levantamiento se documenta en un modelo de procesos que refleja la situacin actual. La
documentacin resultante comprende los diagramas de los flujos, fichas de descripcin, polticas
de negocio y procedimientos que se utilizan para ejecutar el trabajo.
Las debilidades identificadas en la fase de Anlisis de mejora o las desviaciones que muestra el
Monitoreo del Proceso son por lo general el punto de partida para un rediseo de procesos.
Eventualmente, se pueden evaluar diferentes variantes o escenarios con ayuda de simuladores.
Esto aplica tambin si se est diseando un proceso nuevo. En ambos casos el resultado o
entregable es un modelo de procesos deseado (To be).
La etapa de Implementacin del Proceso abarca tanto la implementacin tcnica como tambin
las adaptaciones organizacionales que se requieren. La gestin del cambio (en ingls: Change
Management) y la estrategia de comunicacin constituyen elementos fundamentales a considerar
para el xito del proyecto. El modelo tcnico puede implementarse por medio de una Suite de
BPM (en ingls: Business Process Management Suite, BPMS) o a travs de un clsico desarrollo
de software. El resultado final de la implementacin tcnica del proceso es la situacin actual (As
is) automatizada y documentada, corresponde con el modelo de proceso deseado (To be).
Las fases desde el Levantamiento del Proceso hasta la Implementacin del Proceso se
administran por lo general por medio de la organizacin de un proyecto, mientras que el
Monitoreo del Proceso (ingls: Process Controlling) se concibe como un proceso continuo y
forma parte de todas las operaciones. Las actividades ms importantes de Monitoreo del
Proceso son el control constante de las operaciones (tcnicamente hablamos del control de
instancias de los procesos reales) y su respectiva evaluacin de los indicadores. De acuerdo a la
escuela de BPM, si se detectan problemas puntuales debieran corregirse de inmediato o en lnea.
Si hay recursos disponibles es posible solucionar problemas estructurales sin necesidad de
formular un proyecto, pero si sus causas no estn claras o son complejas, se hace necesario
planificar e implementar un proyecto de mejora y rediseo. La decisin sobre si es necesario
formular un proyecto nuevo o instalar un equipo de trabajo en operaciones, debiera tomarla el
responsable del proceso de comn acuerdo con los participantes.
El ciclo BPM muestra en sus principales fases cmo funciona el crculo virtuoso de mejora
continua de los procesos. Para aplicarlo es necesario:
Asignar responsabilidades a los procesos y a cada uno de sus pasos Emplear mtodos de anlisis
y gestin en l Contar con el apoyo de soluciones adecuadas de TI
Lograr una coordinacin fluida entre estas tres componentes es tarea de gestin por procesos
(BPM-Governance). Gestin por procesos se encuentra por sobre cualquier proyecto de
modelamiento y tiene por consiguiente la misin de apoyar la Gestin de Procesos, para el
cumplimiento de los objetivos estratgicos.
Pg. 21
3.1.3 Gestin de Casos - Case Management

La gestin de casos es una forma de avanzar y mejorar la atencin integrada, coordinada y
continuada, centrado en la responsabilidad compartida de coordinar los cuidados, recursos,
servicios y profesionales. Nos dice:
(HITPASS, 2013)
Un caso, como un proceso de negocio, consiste en un conjunto de actividades o tareas. Sin
embargo, a diferencia de un flujo predeterminado, el proceso de un caso desde su inicio hasta la
finalizacin no est limitado a una secuencia del proceso como lo entendemos normalmente, de
principio a fin, aunque con una lgica compleja de anidacin y encadenamiento.
Qu actividades se deben realizar para completar el caso? Depende de los detalles de cada
caso. Por lo general, el encargado del caso, o tal vez todos los participantes de una tarea, tomarn
esta decisin. Las "reglas", por as decirlo, son conocimiento experto de los usuarios. En la
literatura tambin se habla de adaptive case management (ACM) o dynamic case management,
en donde se argumenta que el foco se centra ms en el tratamiento del caso que en el proceso
mismo [Lamont12].
Por ejemplo en un hospital toda la atencin se centra en el paciente y el caso es lo que est
sucediendo con l. Los procesos clnicos apoyan la atencin del caso, pero el mdico o el equipo
mdico decide qu procesos de diagnstico o de apoyo teraputico se van a emplear y cundo
recurrir a ellos. El caso especfico determina la secuencia. Sin embargo, en la industria de la salud
a medida que ha aumentado el conocimiento se han desarrollado guas de prctica clnica que
orientan la toma de decisiones por parte del equipo de salud, facilitando la estandarizacin de los
procesos clnicos. En algunos tratamientos, hoy en da lo normal es encontrarse con un proceso
conocido de principio a fin. En todo caso, el mismo proceso debe considerar en sus reglas la
opcin de no continuar con el flujo estandarizado.
La gestin de casos no suele trabajar por la carpeta de enrutamiento del caso a la siguiente tarea
de forma secuencial en la lnea. En su lugar, los avances son a travs de eventos, tanto externos
como internos:
Los eventos externos afectan el caso. El contenido de ese mensaje se agrega a la carpeta del
caso y nuevas tareas o procesos pueden ser creados. Los eventos internos incluyen las
asignaciones y reglas del negocio. Los trabajadores de casos asignan tareas e inician los
procesos que consideren necesarios en su trabajo sobre el caso. Las reglas del negocio pueden
crear y asignar tareas o llevar a cabo plenamente las acciones automatizadas sobre la base de
cualquiera de los eventos externos, la realizacin de las tareas de los dems casos, o el
vencimiento de los plazos de trabajo.
Pg. 22

As, de un flujo determinado, el modelo conceptual de un caso es una coleccin visible de tareas
en conjunto con los documentos y carpetas de cada caso. El estado del caso en su conjunto est
determinado por el estado combinado de todas sus tareas y documentos.
Las tpicas reas en donde nos encontramos procesos del tipo de gestin de casos son:
rea salud
Trabajo social
Soporte
Educacin
Proyectos que inducen al cambio
Exploraciones mineras
En general todos los negocios que requieren de conocimiento experto que an no han alcanzo un
nivel de estandarizacin Cules son las funcionalidades especficas que se requieren para
apoyar tecnolgicamente la gestin de casos en el contexto de BPM? Tomando en consideracin
las principales caractersticas que tiene la gestin de casos se requiere:
Derivacin del caso a otros especialistas
Decisiones grupales Gestin de contenidos
Administracin de documentos
Funcionalidades de bsqueda y filtros
Configuracin de atributos
Adjudicacin de recursos
Ejemplo Gestion de caso Clinica

FUENTE:http://www.elsevier.es/es-revista-enfermeria-clinica-35-articulo-gestion-casos
Pg. 23
3.1.4 Case Management versus BPM?

(HITPASS, 2013)
Luego de revisar las caractersticas distintivas de ambos enfoques, podemos indicar que, BPM
normalmente se focaliza en procesos repetitivos con flujos muy estrictos. La abstraccin necesaria
debe gestionar tareas ms complejas. Por su parte, la gestin de casos ofrece una flexibilidad
mucho mayor, pero falla cuando se dirige al usuario de negocio y dificulta el cumplimiento de las
normas reguladoras. Se pueden complementar y puede ser til su trabajo en conjunto. Sin
embargo, las decisiones recurrentes en la gestin de casos, permiten ir identificando patrones
respecto a las acciones, pero dada la naturaleza de la gestin de casos, no debiese estructurarse,
pero es posible generar manuales o guas de ejecucin.
La gestin de casos aporta flexibilidad y directrices. Se centra en informacin de casos, no en los

procesos determinados. Un caso recoge toda la informacin necesaria para gestionarlo: los
actores (usuarios/ roles que participan en el caso), datos/ contenido, reglas y, por supuesto,
procesos y tareas. La gestin de casos habilita a los trabajadores calificados dndoles la
posibilidad de tomar decisiones dentro de las restricciones de las estrategias de negocio. La
gestin de casos define negocios y objetivos realizables, y los comunica de forma transparente
mientras que los propios usuarios aaden tareas para lograr esos objetivos. Esto lleva a un modo
design-by-doing que permite a los usuarios crear, modificar y analizar los procesos sobre la
marcha. Los procesos adaptables, a pesar de no tener una progresin predecible y repetitiva, se
mueven de un estado menos ordenado a otro ms ordenado por medio de la accin del usuario.
Las decisiones tomadas por los usuarios son compartidas al ser almacenadas en plantillas y estn
disponibles para otros actores de la compaa como acciones propuestas. Este es el caso de lo
que se llama ficha clnica nica en la historia de un paciente en un hospital que siempre se puede
volver a retomar y crear una nueva instancia de proceso. Finalmente podemos resumir que Case
Management es un caso especial en la disciplina de BPM, pero igualmente se trata de gestionar
un proceso, en este caso llamado gestin de un proceso de casos.
Fuente: http://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukasz
Pg. 24
3.2 La automatizacin de procesos (BPA)
Implica la utilizacin de sistemas tecnolgicos para automatizar las actividades y/o servicios de
una funcin o unidad de negocio determinada. De esta manera, procesos de negocio tales como
los que desempean las reas de ventas, administracin, operaciones, abastecimiento y
distribucin, cobranzas, recursos humanos o TI pueden ser automatizados mediante la utilizacin
de paquetes informticos especializados para desarrollar tal funcin. En consecuencia, el BPA
permite liberar al personal de labores rutinarias para que en contraste stos se concentren en
actividades que maximicen el valor agregado de toda la operacin.
(HITPASS, 2013)
Para entender que puede abarcar la automatizacin, se va a describir primero un proceso simple
de solicitud de crdito organizado en forma manual y luego se va a describir como hoy en da se
automatizan (implementan tcnicamente) este tipo de procesos.
El proceso se inicia cuando se hace ingreso de una solicitud de crdito por correo y es derivada a
un ejecutivo de negocio en el banco. El ejecutivo revisa primero la solicitud en forma visual para
luego ingresar algunos datos del solicitante en un sistema de anlisis de riesgo. Si el ndice de
riesgo es positivo o aceptable, ingresa los datos de la solicitud en un sistema de crdito financiero
y luego enva la solicitud evaluada a su superior para que la apruebe. La automatizacin de este
proceso podra resultar de la siguiente forma: El arribo de la solicitud de crdito por correo, se
digitaliza y va un programa de OCR (Optical Character Recognition reconocimiento de texto
automtico) se extraen ciertas variables del formulario y se ingresan a un sistema de evaluacin
de crdito. Luego se crea un documento electrnico que gatilla la creacin de una orden de trabajo
en el Process Engine (motor de procesos) y es depositada en la bandeja de entrada de
actividades nuevas del ejecutivo correspondiente. El ejecutivo selecciona de la lista la solicitud
correspondiente y visualiza la solicitud de crdito en el Process Engine, la revisa formalmente y
luego el Process Engine por medio de un servicio web invoca el sistema de anlisis de riesgo
envindole (tcnicamente se traspasan las variables) la informacin correspondiente. Si el
resultado del anlisis es positivo, el Process Engine deriva automticamente la solicitud de
aprobacin a su superior, ingresando los datos en el sistema de crdito financiero por medio de un
servicio web y depositndolo en la bandeja de entrada de l para su debida aprobacin.
Podramos discutir si este proceso podra ser mejorado, pero este caso describe la diferencia entre
un proceso manual y uno automatizado:
El Process Engine controla el proceso, a travs del cual dirige a los usuarios que participan en las
diferentes actividades y sus respectivos resultados (Human Workflow Management) y controla las
interfaces internas y externas con los sistemas que participan en el proceso (Orquestacin de
servicios).
Pg. 25

Las decisiones sobre qu tipo de actividades o servicios deben invocarse, las toma el Process
Engine a travs de la lgica tcnica implementada (modelo de procesos tcnico) y los puntos de
intervencin de los usuarios. Dicho de otra forma, no siempre la lgica del proceso implementada
es mandatoria, en ciertas circunstancias puede ser influenciada por los participantes del proceso,
con la salvedad que debe quedar todo registrado.
Automatizacin de un proceso con un Proceso Engine

3.3 Los participantes en BPM
(HITPASS, 2013)
Si admitimos que BPM como disciplina de gestin integrada abarca todas las capas de una
organizacin desde la alta direccin hasta la tecnologa que se encarga de implementar y dar
soporte a los procesos de negocio, queda claro que tanto para los procesos de BPM Governance
como para gestionar los ciclos de BPM deben participar muchos actores en un gobierno
corporativo por procesos.
Los roles de participantes que se describen a continuacin debieran estar presente de alguna
forma en proyectos, gestin u operaciones de BPM. La figura 2.3 muestra los principales roles que
asumen los participantes en las capas de negocio y de TI.
Se ha podido constatar que empresas que cuentan con mayores niveles de madurez en BPM
tambin cuentan con roles bien definidos y estructuras orientadas a procesos. En el captulo 9 se
va describir como se insertan estos roles en estructuras organizacionales orientadas a procesos.
Pg. 26
Dueo de Proceso (Process Owner): El dueo de proceso es un miembro de la alta direccin de la

empresa y responsable de una lnea de negocio. l es el responsable de plasmar la estrategia en
sus procesos de negocio. l aprueba y disponibiliza parte o gran parte del presupuesto para un
proyecto de BPM. l debiera tener el mayor inters de todos los participantes en promover BPM
como un instrumento de gestin.
Gestor de Proceso (Process Manager): El gestor del proceso es el responsable en operaciones,

reporta directamente al dueo de proceso y es l quien normalmente impulsa las propuestas de
mejora. l es responsable de mantener la comunicacin con los clientes y/ o proveedores.
Normalmente al gestor de proceso lo encontramos inserto en un nivel de jerarqua intermedia,
como subdirector, subgerente, jefe de sucursal o jefe de grupo.
Usuario de Negocio o Ejecutivo de Negocio (Process Participant): Es el que trabaja en

operaciones con el proceso, es decir parte integrante de la cadena que crea valor para los
clientes. Se puede relacionar de muy diferentes maneras con el gestor de proceso. En la mayora
de las organizaciones son usuarios de un rea funcional, como ventas, finanzas o logstica. En
estos casos no existe un gestor de proceso o acta en su parte del proceso como tal y el usuario
reporta directamente al encargado del rea. Si la empresa est organizada en forma matricial, lo
que en empresas globales es bastante comn, pueden surgir conflictos entre el gestor de proceso
y los responsables de reas. En estructuras matriciales se requiere de un modelo de decisiones
colaborativo para evitar el conflicto de intereses que surge en el punto de interseccin.
Analista de Proceso (Process Analyst): Las competencias que se esperan del analista de procesos
son conocimientos de BPM en general, conocimientos del negocio y de la tcnica de
Pg. 27

modelamiento de procesos que se va a utilizar. El analista de procesos apoya al gestor de proceso
como asesor interno o externo en todas las fases del ciclo de BPM. l puede representar como
experto al gestor de proceso ante consultores externos o formar parte del equipo de proyectos de
BPM. El analista de procesos puede ser miembro de un rea de negocio, de un rea de procesos
o pertenecer como analista al departamento de informtica de la empresa. En muy pocas
ocasiones ser el responsable de la implementacin de los procesos, a pesar que posee buenos
conocimientos o una gran afinidad con las tecnologas de la informacin. El analista de procesos
debiera de tener una gran habilidad en materias de desarrollo organizacional y tcnicas de
comunicacin. Pero sobre todo es, como lo indica su rol, un analista. Se espera un gran dominio
de la tcnica de modelamiento y como coordinador entre personas de negocio y de TI es un rol
clave en cualquier proyecto de BPM. De acuerdo a observaciones y experiencias del autor,
muchas personas que ocupan este rol no cuentan con las competencias suficientes para cumplir
con este objetivo. En la mayora de los casos porque les faltan las habilidades para este perfil. La
calificacin ms importante de un analista de procesos no es el comunicar sino el captar o
escuchar a los participantes. Buenos analistas de negocio sienten la necesidad de querer atender
todo en detalle. Al mismo tiempo poseen la empata, como para poder ponerse en el lugar del
cliente y representar sus inquietudes. A ellos no se les escapa ningn detalle, pero al mismo
tiempo poseen un buen sentido de abstraccin y pueden reducir los modelos a su esencia. El perfil
de un jefe de proyecto es diferente, l est centrado en cumplir las metas del proyecto y por lo
general prioriza las metas tcnicas del proyecto, como fechas de entrega y mantencin del
presupuesto de costos del proyecto, ante aspectos de calidad y eficiencia. Por esta razn no se
aconseja mezclar ambos roles en el sentido que un jefe de proyectos acte como analista o vice
versa.
Ingeniero de Proceso (Process Engineer): El ingeniero de procesos implementa un modelo tcnico

a partir de la especificacin y el diseo operacional validado por l y los analistas de procesos. El
diseo tcnico debe realizarse en el mismo entorno (process engine o BPMS) en donde se
implementarn los procesos. El ingeniero de procesos est bien capacitado en el entorno de
implementacin, configura y construye la solucin de BPM en la suite escogida. El ingeniero de
procesos tambin puede actuar como asesor en la fase de modelamiento de la lgica operacional.
Ingeniero de Desarrollo y Servicios (EAI Developer): Un programador puede asumir el rol de

ingeniero de desarrollo, si la solucin requiere de ampliaciones o adaptaciones de desarrollo por
medio de programacin (Servicios web, Java, C# u otros lenguajes).
Arquitecto SOA (SOA Architect): El arquitecto SOA es responsable de disear una arquitectura de
software que cumpla con los requerimientos tcnicofuncionales de los procesos y servicios que se
van a automatizar y orquestar con los sistemas de informacin. La mayora de los procesos de
negocio deben integrarse con los sistemas de informacin del back-office, desarrollar interfaces
B2B e integrar el BPMS a un portal corporativo.
Pg. 28
En empresas y organizaciones de menor tamao, muchos de estos participantes tendrn que

asumir varios roles a la vez. Los siguientes roles en conjunto podran por ejemplo asumir los
participantes en empresas Pyme:
Dueo de Proceso y Gestor de Proceso Analista de Negocio y Ejecutivo de Negocio Analista de
Negocio e Ingeniero de Procesos Arquitecto SOA e Ingeniero de Desarrollo
3.4 Herramientas para BPM

Si se est pensando en disear o modelar procesos, se trata de un proceso de anlisis.
Si se est pensando en BPM Governance, se trata de una metodologa de gestin.
Si se est pensando realizar un prototipo, se trata de probar un entorno de implementacin o de
automatizacin de procesos.
Y si se est pensando en acortar el ciclo de duracin de un proceso, se trata de tcnicas de
optimizacin y control a travs de indicadores.
Todos estos objetivos se refieren a diferentes reas de aplicacin en BPM. Cada rea de
aplicacin es una especialidad en BPM y se apoyan en diferentes conceptos. Entonces
difcilmente se va a encontrar una herramienta universal que cubra todos estos mbitos; por el
contrario sera una aberracin intentar de construir una suite universal para BPM.
(HITPASS, 2013)
Como comparacin analicemos un ejemplo prctico: Un Ferrari o un Porsche no nos va a servir
para jeepear y es impensable que un Jeep o un Land Roover gane una carrera de Frmula 1.
As es tambin en BPM, una suite de BPMS no nos va a servir para representar un mapa
estratgico y alinearlos con los procesos de una empresa. Tampoco nos va a servir para describir
las polticas y reglas de negocio en forma independiente de los procesos que las utilizan.
En el primer caso estamos hablando de una suite BPA (Business Process Analysis) y en el
segundo caso de Motores de Reglas llamados BRMS (Business Rules Management Systems).
En general se puede segmentar el mercado de herramientas para BPM en:

Herramientas que apoyan los procesos de anlisis y Gobierno Corporativo (BPM
Governance) llamadas plataformas BPA (Business Process Analysis) o tambin EA
(Enterprise Architecture Tools)
Herramientas que apoyan la implementacin tcnica o automatizacin de los procesos
llamadas BPMS
Pg. 29

Herramientas que apoyan la administracin y ejecucin de reglas de negocio en forma
independiente de los sistemas que las utilizan, llamados Motores de Reglas o BRMS
(Business Rules Management Systems)
Herramientas que permiten implementar junto a los procesos los indicadores de control de
gestin en tiempo real, llamadas BAM (Business Activity Monitoring)
Herramientas que permiten la orquestacin de servicios entre los BPMS con cualquier tipo de
sistemas, principalmente los del back office, llamadas SOA Suite Herramientas que permiten
analizar los datos histricos de los procesos ejecutados para detectar desviaciones del
comportamiento deseado o descubrir nuevos patrones. A estos entornos analticos se les
llaman herramientas de Minera de Procesos o Process Mining Tools en ingls.
Los expertos de BPM saben que dependiendo de la exigencias o la complejidad de una
organizacin puede hacerse necesario una descomposicin ms fina aun, por ejemplo de
separar la capa de presentacin de un BPMS o de descomponer una SOA-Suite en varios
entornos especializados (ESB, SOA-Repository, etc.).
Todas estas herramientas las podemos posicionar en tres niveles o capas de un marco de
Arquitectura Empresarial moderno como lo muestra la figura.
Plataformas y herramientas para BPM

La capa de negocio abarca todo el ciclo de planificacin, anlisis, gestin y control de la estrategia
y del modelo de negocio. Herramientas que apoyan todas las funcionalidades para planificar,
analizar, modelar y llevar el control de cambios de requerimientos bajo modelos integrados en una
base de datos comn, se les denomina en ingls EA (Enterprise Architecture) o BPA (Business
Process Analysis) Tools.
Pg. 30

(HITPASS, 2013)
Nos comenta que: El lector no debe confundir BPA Tools con herramientas que fueron concebidas
para modelar e implementar procesos como la tan difundida herramienta libre de licencia Bizagi
(es un modelador de procesos BPMN de libre licencia).
Tampoco se debe confundir herramientas de diagramacin como MS Visio con herramientas BPA.
Con MS Visio se puede diagramar lo que se le ocurra al analista y los diagramas tienen una buena
calidad de impresin, pero no tiene ninguna otra funcionalidad que se necesitan para BPM
Governance como administracin de versiones, de atributos, de usuarios, anlisis de impacto,
animacin y simulacin, etc.
Cules herramientas se pueden clasificar como verdaderos BPA Tools? En el mercado podemos
encontrar herramientas como: ARIS, Idungu, IBM Coporate Modeler, y Troux entre otras.
La segunda y tercera capa llamada en ingls BPE (Business Process Execution) abarca tanto la
ejecucin tcnica de los procesos como la orquestacin e integracin de servicios en la capa de
SOA (Service Oriented Architecture) con aplicativos del back office.
Aqu nos encontramos con los tan conocidos BPMS como la BPM Suite de Oracle, Tibco,
AuraPortal, Intalio, Lombardy (IBM) entre muchos otros. Algunas de estas plataformas incluyen
una SOA Suite o motores de reglas, pero algunos proveedores slo ofrecen entornos para
Human Workflow es decir orquestar procesos con usuarios, pero no orquestar servicios con el
back office (SOA). Si bien es cierto la mayora de los BPMS incluyen modeladores de procesos,
pero al lector le tiene que quedar claro que estas componentes no reemplazan un entorno de BPA.
Los modeladores de procesos de los BPMS fueron diseados para la especificacin de un proceso
que se va a ejecutar tcnicamente, razn por la cual son muy tcnicos y no sirven como ambientes
analticos o para gente de negocio. Muchos vendedores de BPMS declaran que su oferta
tecnolgica es universal, que cubre todas las capas y funcionalidades, pero no lo son. Los BPMS
son entornos especializados para especialistas de TI, no para usuarios de negocio.
En resumen se puede concluir que en BPM existen muchas reas de aplicacin y cada rea de
aplicacin requiere de una herramienta especializada que apoye las funcionalidades requeridas.
Herramientas para BPM existen muchas y la pregunta esencial es Con que finalidad fueron
diseadas y que rea o especialidad del BPM apoya?
3.5 La arquitectura del BPM y SOA
(HITPASS, 2013)
BPM como disciplina de gestin de procesos y como conjunto de herramientas tecnolgicas que
apoya su anlisis y operaciones.
SOA como arquitectura tecnolgica que puede implementar o automatizar procesos aportando
flexibilidad y reutilizacin de infraestructura de TI existente y en el desarrollo de nuevas
componentes.
Pg. 31

En general la orientacin al servicio proporciona la capacidad de interoperar con aplicaciones y
con agentes externos (Instituciones, clientes, proveedores, etc...) de forma flexible e invocarlos
mediante llamadas de servicios. SOA estandariza las funciones genricas utilizadas por muchas
aplicaciones expresndolas en forma de servicios reutilizables. Uno de los objetivos principales del
concepto de SOA es que cualquier futuro cambio se realice de forma transparente, afectando slo
a las funciones y unidades afectadas. Si se logra esta capacidad aumenta la agilidad de negocio
de una organizacin. Por el momento se va a trabajar con esta definicin para entender el modelo
estructural de BPM y SOA como una arquitectura integrada de la capa de negocio y de TI.
SOA como arquitectura tecnolgica que puede implementar o automatizar procesos aportando
flexibilidad y reutilizacin de infraestructura de TI existente y en el desarrollo de nuevas
componentes
Arquitectura del BPM y SOA

En el contexto de BPM tenemos una capa que la vamos a llamar BPG (Business Process
Governance) que define la estrategia, una subcapa de diseo y control y una parte de la capa de
implementacin, que la vamos a llamar BPE (Business Process Execution). La primera capa
define la estrategia y la redefine. Los estrategas estn mirando el entorno y van adaptando los
productos y servicios de la empresa a la demanda del entorno. Si la adaptacin es exitosa
hablamos de eficacia. En este sentido la eficacia no es otra cosa que adaptacin exitosa al
entorno. La segunda capa define cmo lo hago (el qu) que es la etapa de diseo. El diseo tiene
como input dos aspectos que considerar, la estrategia y el anlisis del comportamiento del
negocio. En el diseo, por s o como parte del comportamiento del negocio se puede considerar la
simulacin de procesos, es decir, qu pasa si ..? (Ocurren cambios en las variables del entorno,
como demanda, competencias, nuevos productos, etc.), de otra forma, simular cmo las variables
Pg. 32

que llevaron a redefinir la estrategia afectan la gestin de los procesos. Puede ocurrir que se
requiera de una adaptacin de los sistemas reales o que se requiera de una adaptacin de la
estrategia. La segunda capa BPE abarca la implementacin tecnolgica de los procesos
diseados de acuerdo a la estrategia. Esta capa tiene una responsabilidad compartida. La capa de
negocio tiene la responsabilidad de entregar una especificacin (modelo de procesos
independiente de la tecnologa) automatizable (lgica de negocio) y la capa de tecnologa tiene la
responsabilidad de llevarlo a un modelo tcnicamente ejecutable (BPE). La figura 2.5 muestra la
relacin entre las componentes de las capas en el marco estructural de la arquitectura descrita.
En la capa BPE nos encontramos con los famosos BPMS (Business Process Management Suite)
los cuales segn el producto como lo indica la palabra Suite contienen varias componentes, el
ms importante el motor de procesos (ingls: process engine) el cual ejecuta los modelos tcnicos
de los procesos.
Las plataformas o suites ms completas e integradas incluyen todas las componentes necesarias
para:
modelar el flujo de procesos que se va a ejecutar (Modelador tcnico o Process Modeler),
crear formularios dependiente o independiente del modelador tcnico (Interfaz de usuario),
ejecutar las instancias del modelo representado con un motor de procesos, configurar el cuadro
de mando (BAM: Business Activity Monitoring), editar y ejecutar reglas de negocio (BRMS:
Business Rules Management System),
invocar y orquestar servicios con aplicaciones a travs de un bus de servicios (ESB: Enterprise
Service Bus)
(HITPASS, 2013)
Finalmente podemos incorporar a una arquitectura de BPM y SOA un ambiente analtico de
minera de procesos que le vamos a llamar Process Mining and Controlling (PMC). Process
Mining se puede concebir como subrea del Data Mining. El objetivo del Data Mining es extraer de
grandes fuentes de datos (data) conocimiento (mining). El objetivo especfico del Process Mining
es descubrir el comportamiento de los procesos en la realidad y compararlo con los modelos. A
partir de este conocimiento se pueden crear nuevos modelos ms asertivos y eficientes.
Generalmente se descargan los registros (ingls: log files) que dejan los motores de procesos y se
cargan en un sistema analtico en donde se aplican diferentes algoritmos de minera de procesos
para descubrir el comportamiento real de las instancias que se han procesado. Con el tiempo la
base histrica de los registros va creciendo lo que permite analizar tendencias, patrones que se
repiten, comparar diferentes prcticas geogrficas, sucursales, usuarios y muchos otros factores
ms. El trmino controlling en este contexto nos indica que los resultados analticos son un input
para el anlisis de control de gestin y que junto a los indicadores del BAM (Business Activity
Monitoring) sirven para descubrir porqu suceden desviaciones frente al comportamiento deseado
y de esta forma obtener informacin de cadenas de causa y efecto que permiten un nuevo anlisis
de un rediseo tendiente a mejorar la calidad y el desempeo de los procesos.
Pg. 33
3.6 Reglas de Negocio

Las Reglas del Negocio o Conjunto de Reglas de Negocio (Business Rules, por su descripcin en
ingls) describe las polticas, normas, operaciones, definiciones y restricciones presentes en una
organizacin y que son de vital importancia para alcanzar los objetivos misionales.
Ejemplos de reglas de negocio: "Un cliente al que facturamos ms de 10.000 al ao es un cliente
de tipo A", "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a
3.000".
(HITPASS, 2013)
Una Regla de Negocio es una declaracin que define o restringe algn aspecto del negocio;
intenta definir, controlar o influenciar el comportamiento y la estructura del negocio.
Ejemplos de aplicacin de reglas de negocio las encontramos en:

Reglas para la determinacin del precio de un producto o servicio
Reglas para la aplicacin de descuentos
Reglas para acceder a becas, subsidios, etc.
Factores de riesgo para la tarificacin de planes de seguros
Si una poltica de negocio se puede expresar formalmente como una accin asociada a un
conjunto de condiciones, entonces se puede transformar en una regla de negocio automatizable.
En general toda regla de negocio sigue el esquema condicin,regla y accin.
existen principalmente tres tcnicas para expresar reglas de negocio de manera formal:
1. Lenguaje estructurado (pseudocdigo parecido a un lenguaje de programacin, pero ms

sencillo y restringido a la aplicacin de reglas)
Ejemplo:
Si el conductor es > a 40 aos y < a 65 aos
......... aplica descuento de 15 %
sino aplica tarifa BN5
2. rboles de decisin (Cada rama del rbol describe condiciones y al final de cada rama se
encuentra especificada la accin)
Ejemplo:
Pg. 34
3. Tablas de decisin (matrices que combinan condiciones, reglas y acciones, las condiciones de
entrada estn en las primeras filas. Las columnas expresan las reglas de decisin, es decir las
entradas de acciones)
Ejemplo:
3.7 Gestin de Reglas de Negocio

(HITPASS, 2013)
Gestin de Reglas de Negocio (Business Rules Management) es una disciplina independiente y
como el nombre lo indica reglamenta las condiciones del negocio. En BPM la administracin
centralizada e independiente de las reglas de negocio toma la importancia de un factor crtico de
xito para el negocio.
Debido a que las reglas son uno de los componentes ms verstiles de cualquier organizacin, es
indispensable para los expertos de negocio contar con las herramientas adecuadas para la
formulacin, verificacin, validacin y gestin de las reglas. Producto de esto, desde hace varios
aos se puede observar una fuerte tendencia en la gestin de forma centralizada y sistemtica de
estas reglas a travs de Sistemas de Gestin de Reglas de Negocio (Business Rules Management
System o BRMS).
Un BRMS es un sistema que permite a los usuarios determinar y escribir la lgica del negocio
mediante la formulacin de reglas. En estos entornos los usuarios pueden definir, representar,
ejecutar, monitorear y actualizar las reglas de negocio, para que sean utilizadas por las
aplicaciones que realizan toma de decisiones automatizadas. De esta manera, se otorga mayor
control a los analistas sobre la lgica del negocio y mayor independencia del personal de TI, al
externalizar las reglas del cdigo de las aplicaciones.
Algunas Suite de BPM (BPMS) traen motores de reglas incorporados, en otros casos existen
BRMS independientes que pueden ser invocados por sistemas de software. Cualesquiera que
sean las opciones por las que una organizacin se decida, lo importante es que no ser necesario,
o mejor dicho no se recomienda, modelar las reglas en un flujo de proceso, sino slo identificar
donde se utilizan e invocar stas en las actividades que las requieran.
Pg. 35

3.8 Reglas de negocio y Reglas de ruteo
Muchos analistas de negocio cometen el error de especificar con ayuda de los elementos de la
notacin de una tcnica de modelamiento las reglas de negocio.
La notacin no impide hacerlo, pero si las reglas son complejas llenan gran parte del diagrama y
los hacen ilegibles. Por otro lado, si las reglas representan el estado actual de ciertas polticas de
negocio, queda claro que se espera un cambio frecuente de stas. Si las reglas estn codificadas
en el flujo, cada cambio requiere pasar por un proceso de liberacin de versiones en operaciones.
En cambio si las reglas se administran en un motor de reglas en forma independiente, se pueden
efectuar cambios de reglas en tiempo real sin afectar la lgica de control de los procesos
implementados. Las reglas de ruteo (en ingls routing: guiar, enrutar) definen como lo indica su
nombre la lgica de control de un flujo de procesos.
Para mostrar la diferencia entre reglas de negocio y reglas de ruteo se analizar a continuacin un
ejemplo simple de un proceso del tipo Aprobacin de Orden de Compra (OC) aplicando la regla
revisin de credibilidad en la notacin BPMN (este caso fue descrito en [FreRueHit11]).
Bajo qu condiciones habr que revisar la credibilidad del cliente, antes de confirmar la OC?
Vamos a suponer que la respuesta a esta pregunta va a depender del tipo de cliente y el volumen
del pedido, expresado en dlares. Entonces podemos definir como lo muestra la figura el primer
pas en el proceso como una actividad de Revisin de datos de la OC y en esta actividad se va
a decidir, si es necesario hacer una evaluacin de credibilidad o no.
Proceso orden de compra con revisin de credibilidad

En el siguiente paso tenemos que conocer las condiciones concretas para representar las reglas
de negocio:
Habr que revisar la credibilidad del cliente, si el valor del pedido es mayor a $ 300.000.
Si se trata de un cliente nuevo, habr que revisar la credibilidad del cliente a partir de los $ 50.000.
Si se trata de un cliente VIP, no es necesario revisar la credibilidad del cliente. Con esta
informacin podemos modelar la regla de negocio como lo muestra la figura.
Pg. 36
Proceso de orden de compra con regla de negocio modelada en BPMN

Supongamos ahora que cambian las polticas de negocio y habr que incluir otras condiciones
adicionales.
Cada nueva condicin implica un nuevo Gateway y flujos de secuencia.
El problema aumenta, si las condiciones estn entrelazadas, como lo es nuestro caso de tipo de
cliente y valor del pedido.
El diagrama del proceso se vuelve rpidamente ilegible.
Si cambian las reglas frecuentemente habr que estar adaptando el modelo a la nueva situacin.
Si adems tenemos que revisar la credibilidad del cliente en otros procesos, por ejemplo para
entregar una cotizacin, habr que modelar y administrar estas condiciones en forma redundante.
Se puede concluir entonces, que modelar condiciones que representan reglas de negocio no es
una buena prctica en el modelamiento de procesos. Para evitar que esto suceda, el analista
debe aprender a diferenciar entre reglas de negocio y reglas de ruteo. En el modelamiento de
procesos tenemos que distinguir claramente entre reglas de negocio y reglas de ruteo, siendo slo
estas ltimas las que se deben modelar. Para editar y mostrar reglas de negocio por lo general se
usan tablas de decisin. De qu forma se tratan entonces reglas de negocio en un modelo de
procesos? Para estos efectos volvemos a nuestro ejemplo de la Orden de Compra.
Traspasamos las condiciones y las reglas de nuestro ejemplo a una actividad del tipo Regla de
Negocio como el lector puede apreciar en la figura.
Proceso orden de compra con actividad del tipo regla de negocio

Pg. 37

A continuacin se describen las diferencias de ambos tipos de reglas:
Reglas de ruteo son evaluadas por compuertas exclusivas (XOR-Gateways), compuertas
condicionales (OR-Gateways) o flujos de secuencia.
Las reglas de ruteo son generalmente estables, simples y no entrelazadas.
Reglas de negocio pueden ser muy complejas y se administran en forma independiente del
modelo de proceso.
La regla de negocio puede entregar la variable que controla el flujo de la regla de ruteo.
Con la finalidad de diferenciar estos casos el nuevo estndar BPMN 2.0 ha definido una actividad
especializada del tipo regla de negocio.
En nuestro ejemplo sera nuestra actividad Aplicar regla de negocio justamente una actividad de
este tipo que podramos asignar a partir de la nueva versin. La OMG (Object Management
Group) introdujo justamente este tipo de actividad para promover la separacin de modelos de
procesos y modelos de reglas.
3.9 Tcnicas de Mejora Continua
3.9.1 Six Sigma

Es una metodologa de mejora continua que fue desarrollada por Motorola en los aos 80 con el
objetivo de mejorar la calidad de los productos y servicios basado en un concepto estadstico de
gestin de calidad tendiente a reducir errores en el proceso de produccin de una empresa
manufacturera.
El objetivo principal de Six Sigma es disear y gestionar los procesos de tal forma que los
resultados de los procesos tengan una mnima variacin y mejore su rendimiento promedio sin
errores. El objetivo del mtodo de Six Sigma (6 sigma) es lograr estadsticamente 3,4 errores o
defectos por milln de eventos u oportunidades (DPMO).
(HITPASS, 2013)DPMO es el acrnimo de Defectos Por Milln de Oportunidades. Medida de la

eficiencia de un proceso cuyo significado literal es Defectos Por Milln de Oportunidades y se
calcula con la siguiente formula: DPMO = (1.000.000 x Nmero de defectos) / (Nmero de
unidades x Nmero de oportunidades) Donde: Nmero de defectos, es la cantidad de unidades o
no conformidades fuera de especificacin encontradas en una cierta cantidad de unidades
tomadas como muestra. Nmero de unidades, es la cantidad de piezas o elementos de muestra
producidos. Nmero de oportunidades, es la cantidad de defectos posible dentro de una misma
pieza o unidad. Fuente: Wikipedia
El sistema de medicin se basa en la unidad error por milln de oportunidades y la variacin. Se

entiende por error cuando el resultado (medido a travs del indicador respectivo) del proceso est
fuera del rango de aceptacin o desempeo meta. Obtener 3,4 defectos en un milln de
Pg. 38

oportunidades es un objetivo bastante ambicioso. Se puede clasificar la eficiencia de un proceso
en base a su nivel de sigma: (Cuatrecasas, 2010)
1sigma = 690.000 DPMO = 69 % tasa de error (31 % de eficiencia)

2sigma = 308.538 DPMO = 30,8 % tasa de error (69,2 % de eficiencia)
5sigma = 233 DPMO = 0,02 % tasa de error (99,98 % de eficiencia)
6sigma = 3,4 DPMO = 0,00003 % tasa de error (99,9997 % de eficiencia)
Si se lograra la meta de Six Sigma se alcanzara una calidad de resultados de produccin sin
errores de 99,9997 %, es decir matemticamente una curva de produccin que asintticamente
tiende a la perfeccin o dicho de otra forma productos y servicios casi sin defectos o errores.
Obtener 3,4 defectos en un milln de oportunidades es una meta bastante ambiciosa pero
lograble. Motorola alcanz en 1991 6 Sigma [Schmelzer08]. En la prctica esto significa que las
posibilidades de mejorar significativamente los resultados son ilimitadas.
(SIGMA, 2015)Hoy en da Six Sigma es un mtodo de mejora continua muy difundido en todos los
rubros a nivel mundial. El mtodo naci en la industria con el objetivo de mejorar la calidad de los
productos en el rubro de manufactura, sin embargo actualmente en EEUU hay ms
organizaciones de servicios que compaas manufactureras utilizando Six Sigma, pero se debe
mencionar que existen muy pocas empresas que han alcanzado el nivel de Six Sigma.
Metodologia DMAIC - SixSigma

FUENTE: Extraido de http://aacarsa.com/calidad.php
3.9.2 Kaizen
Es una filosofa de gestin japonesa de calidad total cuyo objetivo principal es el dominio de los
procesos de produccin por medio del mejoramiento continuo focalizndose principalmente en las
capacidades de las personas
Pg. 39
(HITPASS, 2013)Kaizen se podra traducir del japons Kai = cambio y zen = lo bueno. En el
sentido figurado se puede interpretar como cambio para mejorar; el uso comn de su traduccin
al espaol sera mejora continua. La filosofa de Kaizen concibe errores y problemas como
pequeos tesoros que esconden oportunidades de mejora y potenciales de innovacin. Dicho
de otra forma, si no se transparentan los problemas no podrn inducirse mejoras. En este sentido
se trata de una metodologa de trabajo tanto individual como colectiva.
Hoy mejor que ayer, maana mejor que hoy! [Imai97]( How can we do the job better tomorrow
then were doing it today?) es la base de la filosofa Kaizen, ningn da debe pasar sin una cierta
mejora. Dicho de otra forma el principio alude a que siempre es posible hacer mejor las cosas. En
un seminario realizado en octubre de 2013 en Santiago de Chile, Masaaki Imai present los
principios fundamentales de la filosofa de KAIZEN:
Mejoras todos los das

Mejoras de todos los colaboradores
Mejoras en todos los lugares de la empresa y la vida
Desde pequeas mejoras incrementales a mejoras estratgicas drsticas
Kaizen busca principalmente centrar sus esfuerzos en generar lo que llaman un flujo lean en el
puesto de trabajo (operaciones). La optimizacin se lleva a cabo en el Gemba (puesto de
trabajo). En el concepto de Kaizen, un flujo lean elimina las actividades que no agregan valor.
Generalmente los enfoques tradicionales centran sus esfuerzos en mejorar la eficiencia, mientras
que Kaizen busca principalmente eliminar aquellas actividades que no agregan valor (muda =
desperdicio) y minimizar aquellas actividades que son necesarias pero no agregan valor aadido.
Desde el punto de vista de BPM, calza muy bien el principio fundamental de Kaizen que hay que
centrar los esfuerzos en mejorar los procesos, antes que simplemente la orientacin al resultado.
Kaizen se focaliza en captar la demanda y los requerimientos de los clientes que les son de valor.
La mejora se dirige tanto a los clientes internos como a los externos (el cliente manda!), slo lo
que al cliente le sirve tiene valor. Kaizen contempla el prximo paso de un proceso como
actividad dirigida al cliente y el paso que le antecede como proveedor. Cada usuario participante
en el proceso se identifica como proveedor interno y cliente al mismo tiempo. Se compromete con
sus clientes de entregar sus productos y servicios de acuerdo a los requerimientos de calidad y
tiempos de entrega. Los actores de la mejora continua son las personas en todos los niveles de la
organizacin por igual. El xito de Kaizen depende fuertemente que las personas involucradas
apliquen sus conocimientos expertos y capacidades. Las personas deben trabajar en grupos
(teams), aplicar y compartir conocimiento, analizar en forma abierta, proponer como grupo de
trabajo mejoras, y tomar responsabilidad sobre sus decisiones. Los grupos de trabajo actan como
pequeas empresas autnomas dentro de la organizacin. Ellos planifican, analizan, toman
Pg. 40

decisiones, implementan mejoras y se comunican en forma independiente con sus proveedores y
clientes. Como consecuencia se simplifican y acortan los procesos de decisiones al interior de la
organizacin. Los dirigentes de niveles superiores pueden concentrarse a realizar su verdadera
funcin, la gestin estratgica.
Principios generales de Kaizen
Orientacin hacia el proceso, antes que simplemente orientacin al resultado

Involucrar a todos los participantes de una cadena de produccin o servicio
Compromiso de los altos niveles gerenciales
Una comunicacin vertical y horizontal eficaz y sin trabas
Mejoramiento continuo de todos los productos y procesos, internos y externos
El cliente manda
La inversin en personal
La gestin de calidad se inicia y concluye con la capacitacin
Dos cabezas piensan mejor que una Todos participan en la determinacin y comunicacin de las
metas
Ciclo de mejora Kaizen

FUENTE: Extrado de http://filosofia5s.blogspot.com/p/filosofia-5s-kaizen-kamban.html
3.9.3
Lean Management
(HITPASS, 2013)
La metodologa Lean Management surge de la necesidad de eliminar pasos innecesarios en el
cadena de produccin, controlar las actividades primarias y dar control al que hace el trabajo como
apoyo a la cadena de valor. Es as como su nombre nos indica claramente la direccin a la cual se
dirige: Manufactura esbelta o gil.
Su mayor aporte est en que, al ser correctamente aplicada, se disminuyen costos, adems de
mejorar los procesos y eliminar los desperdicios, lo que se traduce directamente en el aumento de
la satisfaccin de los clientes y la mantencin del margen de utilidad. Como toda metodologa,
Pg. 41

cuenta con principios que son clave para llevar cabo de manera exitosa, las cuales apuntan a lo
siguiente:[ Cautre10]
1. Calidad perfecta a la primera: Es decir, bsqueda de cero defectos, deteccin y solucin de los
problemas en su origen, evitando as las dificultades que podran afectar al proceso de produccin.
Por esto es tan importante la identificacin de la totalidad del flujo de valor para cada producto,
concretamente el anlisis del flujo de valor mostrar casi siempre la existencia de tres tipos de
acciones a lo largo del mismo. Antes de seguir en los pasos de produccin, se descubrirn
muchos pasos cuya creacin de valores es inequvoca, tambin se descubrirn muchos otros
pasos que no crean valor alguno, pero que son inevitables de acuerdo a la tecnologa actual y los
activos de produccin disponibles; y luego se logra descubrir los pasos adicionales que no crean
valor alguno y pueden evitarse de modo inmediato.
2. Minimizacin del despilfarro: Esto se refiere a la eliminacin de todas las actividades que no son
de valor aadido y redes de seguridad, tambin la optimizacin del uso de los recursos escasos,
como son el capital, recursos humanos y espacio. Permitir un flujo continuo y una operacin ms
eficiente ayuda y facilita a que las cosas funcionan mejor cuando se concentra en el producto y
sus necesidades, en lugar de hacerlo en la organizacin o la maquinaria, de forma que todas las
actividades necesarias para disear, solicitar y proporcionar un producto se realicen en un flujo
continuo.
3. Mejora continua: Apunta a la reduccin de costos, mejora de la calidad, aumento de la
productividad y compartir la informacin entre los miembros del grupo de produccin. Se busca la
perfeccin en el producto, y para lograrlo es fundamental la transparencia, el hecho que todos los
que estn involucrados en el proceso, como son subcontratistas, proveedores de primer nivel,
integradores de sistemas, distribuidores, consumidores, empleados, pueden ver todo de forma que
resulta ms fcil descubrir mejores metodologas para la creacin de valor.
4. Procesos "pull": Esto quiere decir que los productos son tirados, es decir solicitados por el
cliente final, no empujados por el final de la produccin, para asegurar la satisfaccin total de
quien solicit el producto. Para lograr esto es necesario disear, programar y hacer exactamente
lo que el consumidor desea y en el momento que lo desea, dejando que el cliente sea quien
atraiga el producto de acuerdo a sus necesidades, en lugar de empujar productos, a menudo no
deseados, hacia el consumidor.
5. Flexibilidad: Esto apunta a la capacidad de producir rpidamente diferentes mezclas de gran
variedad de productos, sin sacrificar la eficiencia debido a volmenes menores de produccin.
6. Construccin y mantenimiento de una relacin a largo plazo con los proveedores tomando
acuerdos para compartir el riesgo, los costes y la informacin, lo que podra definirse como la
clave del pensamiento lean, es decir, el valor del producto, el cual slo puede ser definido por el
cliente final, y slo es significativo cuando se expresa en trminos de un producto especfico que
satisface las necesidades del consumidor a un precio concreto, en un momento determinado.
Pg. 42
Ilustracin 1 Caractersticas - Lean Managment.

FUENTE:
Extrado
de
http://www.eoi.es/blogs/nayellymercedeslazala/2011/12/18/lean-
manufacturing-y-sus-herramientas/
3.9.4
Benchmarking
El benchmarking es un proceso para medir la calidad de los productos y servicios o el desempeo

de los procesos comparndose con competidores ms fuertes o de alguna otra industria que
muestra un excelente desempeo de sus procesos relacionados con los que se quieren medir.
Desde el punto de vista de BPM el benchmarking puede servir como un argumento para
fundamentar la necesidad de introducir gestin orientada a procesos en la organizacin.
Benchmarking es un instrumento muy valioso para determinar objetivos centrados en mejorar la
competitividad a travs de la medicin del desempeo de los procesos propios y compararlos
continuamente con los competidores.
El benchmarking no tiene un origen preciso, se conocen algunos antecedentes en Japn a travs
del denominado shukko o prstamo de empleados entre empresas para mejorar las prcticas; otra
teora indica que comenz en centros de investigacin en Estados Unidos a travs de la
comparacin de diagramas y tambin existen otras hiptesis. En el mundo de los negocios se
comenz a ver en Estados Unidos a inicios de los 80, cuando Xerox inici un proceso denominado
benchmarking competitivo a raz de una crisis que impuls la bsqueda de mejoras en sus
procesos productivos, buscando el porqu la competencia venda al mismo precio cuando los
productos que manufacturaba Xerox eran de calidad.
(HITPASS, 2013)En la literatura nos encontramos con diferentes conceptos de benchmarking. Las
definiciones ms antiguas lo describen como un instrumento de comparacin, mientras que
actualmente se utiliza ms para observar las buenas prcticas de otras organizaciones y
adaptarlas a los procesos propios. A continuacin se citan algunas definiciones de reconocidos
autores:
Pg. 43

Robert Camp [Camp89] define Benchmarking como un proceso continuo para medir productos,
servicios y prcticas contra los competidores ms duros o aquellas compaas reconocidas como
lderes en la industria.
Michael Spendolini [Spendolini05] define Benchmarking: como un proceso sistemtico y continuo
para evaluar los productos, servicios y procesos de trabajo de las organizaciones que son
reconocidas como representantes de las mejores prcticas, con el propsito de realizar mejoras
organizacionales.
Robin Mann [Mann08] define Benchmarking como aprender de la experiencia positiva de otros.
Segn Robin Mann [Mann08-1]: Las organizaciones estn constantemente buscando nuevas
formas y metodologas para mejorar su desempeo y obtener una ventaja competitiva. Mientras
buscan la mejora de sus propios procesos de negocio, muchas organizaciones reconocen la
importancia del aprendizaje de las mejores prcticas que han logrado otras organizaciones. Al
eliminar la necesidad de reinventar la rueda y que proporciona la posibilidad de adoptar prcticas
de eficacia probada, el benchmarking comparativo se ha convertido en una importante
metodologa para proporcionar una va rpida de alcanzar la excelencia organizacional.
Existen dos tipos de benchmarking, el informal y el formal, por lo general se utiliza el
benchmarking informal, pero se debe trabajar en disear y ejecutar benchmarking formal en todas
las organizaciones.
Tipos de benchamarking
FUENTE. Extrado de http://es.slideshare.net/yohadriana/presentacin-benchmarking
3.9.5
El modelo EFQM
Es un marco de trabajo (referencia) estandarizado y un modelo de gestin que busca la

satisfaccin de todos los Grupos de Inters (stakeholders): Clientes, Personas, Inversionistas,
Alianzas y Proveedores en concordancia con el medio ambiente a travs de sus Personas,
Procesos, Recursos, Conocimiento y Tecnologa.
Pg. 44

El Modelo EFQM se fundamenta en que el rendimiento general de una organizacin depende del
Liderazgo que dirige e impulsa la estrategia, la cual se materializa a travs de las Personas, las
Alianzas y sobre todo el control de sus Procesos de Negocio.
Estructura del modelo EFQM
Pg. 45
UNIDAD II
ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO BUSINESS PROCESS
MANAGEMENT
Tema N 4: Arquitectura Empresarial

4.1 Definicin de Arquitectura
(HITPASS, 2013)
La palabra arquitectura por lo general pensamos en la estructura y en los planos de un edificio,
pero en realidad el concepto de arquitectura est relacionada con cualquier tipo de obra, puentes,
barcos, carreteras, monumentos y no slo construcciones fsicas sino tambin abstractas como
organizaciones, aplicaciones y sistemas de software.
La norma 1471-2000 del IEEE[ Hilliard00] define el trmino de arquitectura como: the
fundamental organization of a system embodied in its components, their relationships to each other
and to the environment and the principles guiding its design and evolution, where: fundamental
organization means essential, unifying concepts and principles system includes application,
system, platform, system-of-systems, enterprise, product line, ... environment is developmental,
operational, programmatic, . . . context of the system
Podemos resumir que el trmino arquitectura se refiere a un todo estructural. Se trata ms que el
detalle de mostrar la relacin entre las partes en un entorno complejo. Se responde por
consiguiente a la pregunta de por qu? se necesita una arquitectura: Los sistemas
organizacionales son complejos y por lo general dinmicos, es decir estn sometidos al cambio de
requerimientos, la mejora y la actualizacin.
4.2 Definicin de Arquitectura Empresarial AE
Ejemplo de la construccin de un edificio:

Antes de empezar a construir un edificio, la empresa constructora requiere de todos los planos
comenzando por los planos estructurales que define la estructura fundamental de la obra sobre los
cuales los fundamentos se sustentan, pilares fundamentales, esttica y estabilidad del edificio.
Luego por cada planta y por cada departamento existen planos que muestran la distribucin de los
espacios.
Adems, por cada instalacin como electricidad, gas, calefaccin, caeras de agua fra y caliente,
desage, red hmeda, red seca, red de cableado de televisin y telfono, existen planos
individuales.
Pg. 46

Todos estos planos tienen puntos de conexin: el edificio con sus proveedores externos, provisin
de reas comunes, distribucin entre plantas y departamentos y finalmente por cada departamento
debe existir un plano por cada instalacin.
Ahora formulamos la pregunta, si usted como dueo de un departamento quiere agregar un
interruptor de luz a la salida de la cocina al comedor, porque slo se puede prender y apagar a la
entrada de la cocina que es por hall principal.
Bueno, tendr que llamar a un electricista y lo primero que har es pedirle los planos para
estudiarlos y hacerle una propuesta de un proyecto elctrico.
Qu sucedera si los planos se perdieron o ya no existen? En trminos vulgares diramos hay
que entrar a picar para ver por donde van los ductos!.
Si esta situacin la comparamos con una organizacin o empresa y sta requiere realizar un
cambio, en similitud al caso del edificio, podramos preguntar, dnde estn los planos para
estudiar que podemos aprovechar y dnde impactan los cambios?
Es aqu entonces, donde por general nos encontramos con una triste realidad: los planos no
existen!, hay que entrar a picar!.
En una organizacin entrar a picar significa realizar un ante-proyecto y levantar toda la
informacin necesaria para el estudio de factibilidad tcnica y econmica.
Si tuviramos los planos empresariales podramos ahorrarnos gran parte del ante-proyecto, en
este sentido el ante-proyecto reconstruye los planos y se puede pasar directamente a la etapa del
estudio de factibilidad.
Literatura sobre el arquitectura empresarial es abundante y se encuentran muchas definiciones al
respecto, pero la mayora de ellas coinciden que una AE es un conjunto de modelos y sus
relaciones, que describen la empresa como una estructura coherente.
Su principal funcionalidad es de proveer de un fundamento para lograr mayor agilidad y control en
la gestin del cambio en las empresas.
Si buscamos un denominador comn de todas estas definiciones podramos resumir:
Una Arquitectura Empresarial es un conjunto de modelos que describe la empresa como una
estructura coherente, documenta el estado actual de la organizacin, el estado deseado y la
brecha entre ambos.
Con el objetivo de abstraer y sintetizar la complejidad de un sistema organizacional es necesario
distinguir y gestionar los niveles y vistas de la Arquitectura Empresarial por separado. Para lograr
la separacin de las capas de Negocio, Integracin y Aplicaciones, es necesario disear y
construir una Arquitectura Empresarial que cumpla con los siguientes requisitos:
Cada capa tiene sus objetos y lgica propios. Cada capa debe gestionarse en forma separada,
pero en coherencia con las dems.
Desde el punto de vista estructural, una arquitectura empresarial es: un mapa del negocio y
de la organizacin, la descripcin de los objetivos del negocio, la descripcin de los procesos de
la organizacin, la descripcin a nivel funcional de los servicios de la organizacin, la descripcin
de las interfaces a nivel macro de los sistemas de la organizacin, la descripcin de los sistemas
reales implementados y la descripcin de sus productos, servicios y sus mercados.
Pg. 47
Componentes de la arquitectura empresarial

FUENTE: http://www.colombiadigital.net/actualidad/articulos-informativos/item/8123-que-esarquitectura-empresarial.html
4.3 Drivers y Objetivos de una AE
(HITPASS, 2013)
Zachman describi acertadamente las razones de por qu se justifica o hace necesario trabajar
con un concepto de una arquitectura empresarial en una organizacin:
1. Levantar y construir los modelos: Si la empresa existe tambin existen los modelos Es
necesario invertir en construir los modelos
2. La empresa es el sistema: La suma de los procesos manuales y automatizados son la empresa
AE no es un problema tcnico, es un problema empresarial
3. La realidad organizacional es la necesidad de estructuracin: Todas las necesidades que
requieren un buen funcionamiento de los procesos y sistemas son necesidades empresariales
Existe una serie de drivers (utilizamos el trmino en ingls porque engloba una serie de
significados en conjunto que son difciles de traducir como, hilo conductor, motivador, gatillador,
justificador, necesidad, etc.) tanto internos (son impulsados desde el interior de la organizacin)
como externos (requerimientos que impactan desde afuera a la organizacin) que requieren de
mando y control.
Pg. 48
Drivers de una AE
Necesidad de Abstraccin
Como la realidad universal es para nosotros infinitamente compleja, para comprenderla se da la
necesidad de abstraer y sintetizar el objeto de observacin. Las principales caractersticas de un
modelo son:
La representacin simplificada de un objeto real o abstracto
Slo descrito hasta un cierto nivel de detalle
Descrito para representar slo el aspecto de inters
Descrito para cumplir un objetivo declarado
Estandarizacin
Contar con un estndar en BPM y en TI facilita la comunicacin, la interoperabilidad, la
independencia de plataformas tecnolgicas, la transparencia, la formacin de profesionales, la
certificacin de habilidades, las reglas de modelado, la documentacin de modelos referenciales y
por ende los costos de operacin y la agilidad de negocio.
La arquitectura empresarial, si cuenta con un metamodelo que pueda representar estos
estndares, aporta a la integridad de los datos en los modelos que siguen los estndares.
BPM Governance
Definimos BPM-Governance como un modelo de gestin corporativa orientada a procesos, pero
integrada con todas las capas de una organizacin, las fases del ciclo de gestin, la gestin del
cambio de nuevos requerimientos, la estructura organizacional y todos los instrumentos de
alineamiento de y entre las estructuras corporativas. BPM Governance abarca el alineamiento con
todo el ciclo de gestin corporativa desde la planificacin y gestin estratgica, la definicin de
planes de negocio, el ciclo presupuestario, la definicin de perfiles y cargos, la gestin en
operaciones, apoyo tecnolgico hasta el alineamiento con el portafolio de proyectos corporativo.
La pregunta clave que se da en este contexto es cmo podemos cumplir con los requerimientos de
integracin de modelos sin una plataforma que permita relacionarlos y mantener miles de
relaciones de negocio, que se conocen y aplican en un repositorio integrado como ARIS. Otra
pregunta clave es cmo mantener el control en la dinmica del cambio empresarial sin el apoyo de
una plataforma que mantenga relacionados los objetos de un modelo con otro. Se agrava la
Pg. 49

situacin an ms si incorporamos la dimensin del tiempo. La situacin actual de un modelo es
una dimensin, pero cmo controlamos las n dimensiones que estn destinadas al cambio
(futuro)? Si adems se considera que cada capa tiene su propio ciclo de vida y que tienen que ser
coordinadas con las otras en n dimensiones de tiempo, cmo mantenemos el control?
Conocimiento experto puede ser una respuesta, pero aunque dudo que un experto pueda controlar
todas las variables en su mente, queda por responder si la evolucin no tiende a estandarizar las
buenas prcticas.
Time to market
Es el tiempo que se requiere para introducir un nuevo producto o servicio (innovacin) al mercado
desde que es concebido hasta que est disponible para la venta.
Empresas que mantienen un rea de investigacin y desarrollo (I + D) cuentan con un proceso en
la cadena de valor llamado Product Lifecycle Management (PLM), entonces el time to market es
el tiempo de ciclo del proceso PLM que se intenta constantemente reducir al mximo. Por lo
general el PLM comienza con el estudio de mercado, demanda estudiada que se combina con
ideas de innovacin. La I + D en el PLM est fuertemente anclado con el concepto de creacin de
valor para el cliente.
Product Lifecycle Management (PLM)
La arquitectura empresarial puede contribuir en dos aspectos importantes a reducir los tiempos de
ciclo del PLM:
1. Identificar los elementos que se pueden reaprovechar de las estructuras existentes
2. Evitar iteraciones en las etapas de planificacin y especificacin, aprovechando la buena
documentacin que entrega una base de modelos integrada de una arquitectura empresarial Si la
empresa tiene documentado en un repositorio integrado sus procesos, productos y servicios,
mapa estratgico y objetivos de negocio, aplicaciones e infraestructura de TI, entonces puede
revisar en qu componentes impacta el nuevo producto. Se ahorra el tiempo de levantar y validar
toda esta informacin. Por otro lado, muestra relaciones de negocio documentadas que fcilmente
se olvidaran al levantar por primera vez la informacin requerida.
Gestin de calidad
Los modelos que se desarrollan en el marco de una arquitectura empresarial facilitan la
comunicacin y el entendimiento comn sobre los requerimientos entre las capas de estrategia,
negocio y tecnologa con los diferentes stakeholders. El empleo de los modelos de una AE
Pg. 50

conlleva a una mejora sustancial de los procesos de planificacin y permite detectar y evitar
redundancias y aprovechar sinergias de otros proyectos en curso. Otros aspectos como
cumplimiento de regulaciones, seguridad y mejor control se complementan positivamente con los
atributos de calidad de productos y servicios.
La Globalizacin
La empresa que pueda adaptarse ms rpido a los constantes cambios en el mercado, que son
adems cada vez ms frecuentes, tendrn mayores ventajas competitivas que aquellas que no
logran adaptarse al ritmo que la globalizacin exige.
BPM en s no ofrece ningn instrumento para administrar la complejidad del cambio frecuente.
BPM se puede apoyar del concepto de administracin del cambio que ofrece una AE. El apoyo a
la estandarizacin y la integracin de componentes es el fuerte de las arquitecturas empresariales.
Cumplimiento de regulaciones
Regulaciones son el conjunto de procedimientos y reglas que adoptan las instituciones en el
marco de polticas de negocio, sean stas de carcter legal, financiero contable, seguridad,
arancelario, sanitarias, medio ambiente, u otros aspectos de inters no nombrados.
El seguimiento de cumplimento de regulaciones se puede complementar perfectamente con el
seguimiento de procesos de negocio, porque estn directamente relacionados. Para identificar en
qu etapas de un proceso de negocio influyen las regulaciones, se pueden desarrollar vistas
especializadas en una AE en la cual se relacionan las actividades de un proceso o un subproceso
con las materias de regulacin.
Relacin con externos
Es importante para las organizaciones coordinar y disear las relaciones de negocio con su mundo
externo en forma objetiva y formal.
El estndar de BPMN 2.0 cuenta un con diagrama especial llamado diagrama de coreografa
para disear el flujo de mensajera con los participantes externos de un proceso de negocio. La AE
se presta especialmente para documentar vistas individuales y relacionarlas con otras. Se evita
redundancia, se facilita la comunicacin y prevalece la integridad.
Fusiones y adquisiciones
Si dos empresas se fusionan o una adquiere otra de un mismo rubro queda claro que tambin se
deben fusionar y estandarizar los procesos de ambas compaas.
Migrar sistemas de informacin y armonizar procesos de negocio constituyen proyectos complejos
y de alto riesgo.
As debiera ser posible documentar los procesos y los sistemas de cada empresa por separado,
desarrollar modelos referenciales y luego referenciar las componentes de cada empresa con los
modelos referenciales. Estas vistas permiten planificar proyectos integrados que consideran
dependencias lgicas y temporales.
Pg. 51
Tema N 5: reas de una Arquitectura Empresarial

Se ha definido la arquitectura empresarial en el contexto de BPM, pero el concepto de AE se
puede concebir y aprovechar para integrar la planificacin de otras reas o disciplinas
empresariales.
reas de una arquitectura empresarial

5.1 Business Process Outsourcing (BPO)
Es la externalizacin de uno o ms procesos de negocio incluyendo el de TI que los soporta. El

BPO es el servicio ms completo que se pueda recibir como externalizacin porque incluye Data
Center, Servicios de Comunicaciones, Application Management , Configuracin de los procesos a
medida (workflow), Seguridad y mesa de ayuda. EL BPO constituye una relacin muy estrecha
entre el cliente y el proveedor.
El cliente de BPO se concentra en la gestin estratgica y en el diseo y rediseo de los procesos
y comunica los requerimientos de adaptacin y cambio al proveedor de BPO. La pregunta clave es
entonces qu instrumentos va a utilizar el cliente para especificar y documentar la lgica de
negocio, definir los niveles de servicio (SLA: Service Level Agreement), llevar a cabo los procesos
de alineamiento y control de cambio? Una plataforma de AE se convierte en el instrumento
predestinado para estos fines. Se pueden administrar en forma integrada todas las funcionalidades
mencionadas anteriormente y sobre la misma plataforma se pueden gestionar los mecanismos de
coordinacin con el proveedor.
Pg. 52
5.2 Gestin de calidad - riesgo - conocimiento - regulaciones - otras

La gestin de calidad debiera orientarse a los procesos de negocio, porque la calidad de los
procesos est directamente relacionada con la calidad de los productos y servicios. La calidad es
una propiedad o un atributo del bien y el conjunto de propiedades definidas de forma que se
puedan medir, representan al grado de calidad de un producto o servicio.
La gestin de riesgo tiene como objetivo manejar la incertidumbre relativa a la ocurrencia de un
suceso negativo (amenaza) que puede, si sucede, afectar, parar o destruir la marcha de uno,
varios o todos los procesos organizacionales. Por consiguiente, la gestin de riesgo se centra
primero en identificar y evaluar los posibles riesgos. Al igual que en calidad, el riesgo es una
propiedad de una actividad o de un proceso completo relacionado con los productos y servicios
destinados al cliente.
La gestin de conocimiento es controlar la curva de aprendizaje de las personas en una
organizacin. La gestin del conocimiento est muy relacionada con la gestin del cambio
(cultural) en una organizacin. Las personas, para cumplir con sus roles de gestores, requieren de
diferentes materias de conocimiento. Por lo tanto, para detectar la brecha del grado de
conocimiento requerido, con el grado de conocimiento existente, se da la necesidad de levantar la
estructura del conocimiento requerido y representarlo en modelos, igual que en las otras
disciplinas de gestin.
En gestin de regulaciones habr que identificar cules actividades o procesos estn sujetos al
cumplimiento de regulaciones y cules son las variables que deben monitorearse para lograr una
trazabilidad que lleve el registro de cumplimiento de ellas.
Cada rea de gestin debe recurrir como fuente y fundamento al mismo modelo de procesos y
relacionar los objetos y atributos de sus modelos (calidad, riesgo, conocimiento, etc.) con el
modelo central de procesos. Esto prcticamente no es posible sin una plataforma integrada con un
repositorio comn.
5.3 Auditora
Proceso de control de gestin en diferentes mbitos (se denomina tambin auditora interna)
como:
Auditora informtica, proceso de control para determinar si un sistema de informacin mantiene la
integridad de los datos, se cumplen los niveles de servicio, detectar fraudes, grados de
vulnerabilidad y si se utilizan eficientemente los recursos.
Auditora medioambiental, cumplimento de regulaciones medioambientales de una organizacin.
Auditora jurdica, cumplimento de las clusulas de los contratos sujeta a penalidades, infracciones
y garantas.
Auditora de innovacin, proceso de comparacin de la situacin actual con la innovacin
esperada.
Pg. 53

Auditora presupuestaria y de operaciones (control de gestin), proceso que monitorea el
cumplimiento del ciclo presupuestario y los objetivos de negocio. En general, cualquier proceso de
control interno de una organizacin es coercitiva y su eficiencia puede evaluarse por medio de una
auditora.
El auditor necesita una referencia para evaluar y medir si existen desviaciones de los objetivos de
la auditora. Los modelos documentados en una AE presentan un excelente punto de partida para
estos fines. El auditor puede verificar si las aplicaciones y procesos implementados en
operaciones corresponden con los modelos validados por la direccin de la empresa. Recordemos
que la auditora consiste en apoyar a los miembros de la empresa en el desempeo de sus
actividades, objetivos que debieran estar documentados en una AE.
5.4 Portafolio de proyectos
Hoy en da es comn en las organizaciones desarrollar portafolios de proyectos para usarlos como
medio de evaluacin. Sin embargo, estos portafolios carecen de fundamento si stos no
consideran las mltiples dependencias que existen en y entre las capas de negocio, de integracin
y tecnologas de informacin. Este hecho aumenta la complejidad si consideramos que existen
tambin estados actuales y deseados en cada una de las capas y entre ellas[ Hitpass-Richter93].
5.5 ITIL (Information Technology Infrastructure Library)
ITIL es un modelo referencial de buenas prcticas para la gestin de servicios de tecnologas de la

informacin en operaciones. ITIL describe procedimientos detallados de las actividades en las
operaciones de TI. Estos procedimientos son independientes del proveedor y han sido
desarrollados para servir como gua facilitadora que abarque toda la infraestructura, el traspaso de
desarrollo a produccin y las operaciones de TI.
En una AE se puede documentar el modelo especfico de ITIL adoptado a la organizacin de la
misma forma como se documentan los modelos referenciales de los procesos de negocio. El
modelo de ITIL representado en la AE sirve como especificacin de implementacin, como manual
de procedimiento, material de capacitacin, manual de referencia para auditoras y documentacin
para el control de cambio de requerimientos.
Pg. 54
Tema N 6: Estndares de Gestin Empresarial.

6.1 Relacin Arquitectura Empresarial Business process Management - Service Oriented
Architecture (AE & BPM & SOA)
Persiguen los mismos objetivos generales de dejar disponibles tcnicas de planificacin,

modelamiento, alineamiento y control, pero en diferentes grados de abstraccin y objetivos
especficos. No obstante, estos tres conceptos no son independientes, encajan como un engranaje
que debe sincronizarse para su buen funcionamiento.
Modelos esenciales en la interseccin de un concepto integrado EA, BPM y SOA

Fuente: [Sthler-etal-09]
AE-BPM-SOA nos encontramos con una serie de artefactos (en AE se entiende como artefacto,
cualquier elemento, o modelo que representa un objeto real fsico o abstracto, como cargo,
proceso, datos, servicios, objetivo, topologa de red, etc.) comunes; los podramos denominar
modelos esenciales que comparten y traspasan informacin entre las capas.
Para satisfacer los objetivos especficos de la direccin de la empresa, operaciones y TI se deben
coordinar los puntos de interseccin. La integracin de las vistas especficas de EA, BPM y SOA
tiene por objetivo trabajar sobre un solo modelo integrado. Ha de considerarse que no es fcil
reducir los filtros de cada capa a los puntos de interseccin entre ellos, pero si tenemos en cuenta
qu responsabilidad tiene cada una de las reas podemos concluir:
La capa de AE es una representacin abstracta y descriptiva de la organizacin en general. Su

objetivo es describir las componentes de la organizacin y sus relaciones a muy alto nivel. La
descomposicin y descripcin en detalle no es el mbito de una AE.
La capa de BPM se focaliza en la descripcin de los procesos y su respectiva lgica de flujo. La

lgica de negocio se describe en detalle.
Pg. 55

La capa de SOA tiene el objetivo de disear una arquitectura de software basada en el concepto
de servicios para implementar tcnicamente los procesos de negocio.
Podemos resumir que hacia el mbito de una AE el nivel de abstraccin de los modelos de
negocio es mayor, y hacia la capa de SOA aumenta el nivel de detalle. Encontramos complejidad
en la capa de AE en las relaciones de negocio entre objetos de modelos y complejidad en la
interaccin de componentes de servicios en la capa de SOA. La complejidad en la capa de BPM la
encontramos en la lgica operacional de los procesos.
Niveles de abstraccin de modelos en capas de EA - BPM - SOA
El grado de abstraccin de modelos es siempre mayor hacia EA. A nivel de lnea de negocio o
corporativo se trabaja con mapas, es decir no perder la visin global. Lo que se busca es delimitar
el contexto de los procesos, expresado en desde - hasta y como se relacionan los procesos con
los otros tipos de objetos de negocio.
Grado de abstraccin de modelos EA - BPM - SOA
Pg. 56

Con el objetivo de evitar redundancias y de lograr un modelo de arquitectura integrado se deben
definir claramente qu tipo de modelos pertenecen a qu capa y cules tipos de objetos son los
que integran las siguientes capas. En nuestro ejemplo, tendramos como modelos de la AE los
mapas de la cadena de valor de los procesos y el tipo de proceso cadena de valor se sigue
descomponiendo y describiendo en la capa de BPM. La capa de BPM conoce dos niveles de
descomposicin por proceso de negocio, el nivel descriptivo y el nivel operacional.
El nivel descriptivo describe la lgica de negocio a muy alto nivel, por lo general a nivel de
subprocesos y no contiene casos de excepcin. Representa un modelo abstrado de la
complejidad y sirve para delimitar el contexto y la funcionalidad a nivel ejecutivo.
El nivel operacional (representado en la tabla por el tipo de objeto actividad) abarca toda la
lgica de negocio en detalle, incluyendo los casos de excepcin, identificando las reglas de
negocio, y la interaccin en detalle con todos los participantes. Es independiente de la tecnologa,
pero sirve como especificacin para la implementacin.
El tipo de objeto actividad es el qu se sigue especificando en el nivel tcnico y en este

concepto representado por el nivel y modelo SOA.
Es importante de mencionar, que en una arquitectura de modelos integrados, no es imperativo

modelar todo los tipos de objetos. Aqu rigen los mismos principios que para levantar y disear un
modelo de datos, slo se definen de acuerdo a los requerimientos de negocio las propiedades que
describen un objeto de dato. As por ejemplo si a una compaa de seguros generales no le
interesa saber el color del vehculo a asegurarse, no se define como atributo en el modelo de
datos.
Pg. 57
Tema N 7: Frameworks de Arquitectura Empresarial

7.1 Framework de AE
Marco estructural que define los modelos, los tipos de objetos pertenecientes a un modelo, las
relaciones de negocio entre los tipos de objetos y las relaciones entre los modelos del marco para
un rea de planificacin, especificacin y anlisis. Un framework de AE es por consiguiente un
modelo de referencia, pero estructural no procedural; define la estructura de un modelo, no los
procesos.
Los EA Frameworks no se pueden adoptar sin un estudio detallado de ellos y compararlos con la
realidad organizacional de cada caso. Por esta razn, muchas empresas se orientan en alguno de
ellos, pero finalmente definen su propio marco estructural de arquitectura empresarial; resulta ms
fcil que entender y adoptar estos compendios en detalle.
El Gobierno de EEUU promulg una ley en el ao 1996 para sus agencias federales, llamada
Clinger-Cohen Act. Esta ley obliga a organizaciones estatales en EEUU a desarrollar y
mantener una Arquitectura Empresarial (CIO Council, 2001 ).
Un estudio realizado en el ao 2007 , revela que los frameworks ms utilizados en la prctica son
el framework de Zachman (28 %), TOGAF (27 %) y FEA (8 %) de todas las encuestas realizadas a
empresas[ Schwarzer09], razn por la cual vamos a presentar en forma muy resumida estos
Frameworks. A pesar que ARIS, no est nombrado en el estudio, lo vamos a presentar en el
marco de este trabajo, porque es reconocidamente uno de los frameworks ms utilizados en
Europa y empresas globales sobre todo aquellas que son usuarias de SAP.
7.2 Framework de Zachman
Es un marco de trabajo para Enterprise Architecture (EA), creado y soportado por el instituto que
lleva su nombre Zachman International (anteriormente se llam ZIFA: Zachman Institute for
Framework Advancement). Este framework emplea modelos y vistas de los diferentes elementos
que forman parte de la arquitectura empresarial, contemplando dos dimensiones:
Perspectivas de participantes o modelos

Preguntas esenciales a responder o puntos de vista
Zachman sostiene que cada sistema (una organizacin tambin es un sistema) se puede describir
en forma completa respondiendo a las siguientes preguntas:
Qu? Los datos, sus relaciones y significados

Cmo? Los procesos y funciones de la corporacin
Dnde? La red, tecnologas, distribucin y localizacin de procesos, funciones y sistemas
Quin? La gente que forma parte de la compaa, considerando aspectos como seguridad y roles
hasta la organizacin de la compaa y los flujos de trabajo existentes
Pg. 58

Cundo? El tiempo, representando ciclos, estructuras de proceso, de control y eventos de
negocio
Por qu ? Las motivaciones en los diferentes segmentos de la compaa: objetivos de negocio,
planes estratgicos, diseo y especificacin de reglas, etc.
Las perspectivas captan todos los modelos requeridos para el desarrollo de sistemas. Cada
modelo est relacionado con un determinado perfil dentro de la compaa:
Alcance: perfil Visionario o Planificador

Negocio: perfil Propietario
Sistema: perfil Diseador
Tecnologa: perfil Constructor
Representacin Detallada: perfil de ejecucin (Adjudicatario de Contrato)
Configuracin de componentes: perfil Implementador
Instancias funcionales de la empresa: perfil Trabajador
De las preguntas del negocio y las perspectivas de los participantes, Zachman desarroll una
matriz, llamada The Zachman Framework. Lo que la matriz busca es ordenar la arquitectura y
que haya definiciones para cada uno de estos aspectos.
Al framework de Zachman se le reconocen los siguientes beneficios y ventajas:
Es simple y fcil de entender
Contempla la Empresa como un todo
Es independiente de herramientas y modelos
Presupone que se requieren multimodelos para describir la organizacin desde sus diferentes
perspectivas
Entre las desventajas nos encontramos con los siguientes aspectos:

El framework est muy orientado hacia TI, no cuenta con una perspectiva estratgica
No incluye los procesos de alineamiento
No cuenta con metamodelo
Los modelos son independientes, no existe asociacin entre ellos El framework es slo
descriptivo, no es posible reusar los modelos No incluye un proceso de anlisis
7.3 TOGAF (The Open Group Architecture Framework)
TOGAF son las siglas de The Open Group Architecture Framework y, por tanto, pertenece a
The Open Group, un consorcio que est formado por empresas y profesionales del sector TI, con
el objetivo de marcar directrices, independientes de fabricantes, en el mundo de la Arquitectura TI.
Pg. 59

TOGAF, a diferencia de otros frameworks, cuenta con un marco estructural y una metodologa de
procedimiento (ADM: Architecture Development Method) para la configuracin y el uso del
framework.
TOGAF est compuesto de cuatro dimensiones:
Arquitectura de Negocios (o de Procesos de Negocio), la cual define la estrategia de negocios, la

gobernabilidad, la estructura y los procesos clave de la organizacin.
Arquitectura de Aplicaciones, la cual provee un plano (blueprint , en ingls) para cada uno de los
sistemas de aplicacin que se requiere implantar, las interacciones entre estos sistemas y sus
relaciones con los procesos de negocio centrales de la organizacin.
Arquitectura de Datos, la cual describe la estructura de los datos fsicos y lgicos de la

organizacin y los recursos de gestin de estos datos.
Arquitectura Tecnolgica, la cual describe la estructura de hardware, software y redes requerida

para dar soporte a la implantacin de las aplicaciones principales, de misin crtica, de la
organizacin.
7.4 FEA (Federal Enterprise Architecture)
El Gobierno de EEUU obliga a organizaciones estatales en EEUU a desarrollar y mantener una

Arquitectura Empresarial. El objetivo principal del framework es lograr el desarrollo y mantencin
de una plataforma de entendimiento comn en la integracin de procesos y sistemas de
informacin entre las agencias estatales. La utilizacin del framework propone el uso de trminos
comunes para la construccin de las arquitecturas de las diferentes instituciones pertenecientes al
Gobierno.
FEA Se compone de varios modelos de referencias que crean una taxonoma y ontologa comn
para la descripcin de los recursos TI, generando la arquitectura empresarial. Entre estos modelos
se incluyen:
Performance Reference Model

Business Reference Model
Service Component Reference Model
Data Reference Model
Technical Reference Model
Pg. 60

7.5 ARIS (Architecture of Integrated Information Systems)
Es un marco estructural desarrollado por Scheer[ Scheer92] a principios de los aos 90, cuyo foco
principal fue el desarrollo de una arquitectura que permitiera relacionar y describir procesos de
negocio y sistemas de informacin en forma integrada. Para estos efectos Scheer presenta en su
concepto estructural la descomposicin de modelos en niveles y vistas en el marco de una
arquitectura llamada ARIS House, que distingue:
Cinco Vistas
Vista organizacional
Vista de datos
Vista funcional
Vista de control
Vista de productos y servicios
Tres Niveles
Definicin de requerimientos
Diseo y especificacin
Implementacin
ARIS House
Este mismo metamodelo fue implementado en una herramienta de AE que lleva el mismo nombre
de ARIS. El corazn de ARIS es una tcnica para modelar procesos llamada EPC (Event driven
Process Chains).
Pg. 61

7.6 Enterprise Architecture as Strategy (Ross et al)
Los expertos en gestin estratgica del MIT (Ross - Weill) y el Instituto de Gestin Estratgica St
Gallen en Suiza (Robertson) publicaron una metodologa de cmo plasmar la estrategia de una
empresa en los procesos crticos para introducir BPM en organizaciones, basado en un marco de
arquitectura empresarial (Enterprise Architecture as Strategy, Harward Press 2006)[ Ross et al 06].
La idea principal de este concepto es identificar primero el tipo de modelo de procesos o
configuracin de valor que tiene la empresa, de los cuales existen segn Ross et al
fundamentalmente cuatro tipos, diversificacin, coordinacin, replicacin y unificacin. Cada uno
de estos modelos de negocio determina un diferente grado de estandarizacin y grado de
integracin que se necesita en los procesos para lograr un rediseo de los modelos de negocio
que cumplan con un alto grado de eficiencia operacional en los procesos de negocio. A
continuacin se presentan en forma resumida los cuatro tipos de modelos operacionales, con las
siguientes caractersticas:
1. Diversificacin: Bajo grado de estandarizacin e integracin de procesos de negocio. Ejemplo:

Holding que agrupa diferentes empresas de un rubro o negocios complementarios, que tienen
necesidad de integracin en su logstica de transacciones, pero que son independientes en sus
operaciones y modelos de negocio.
2. Coordinacin: Alto grado de integracin de la informacin que se requiere compartir y bajo
grado de estandarizacin en los procesos de negocio. Ejemplo: Rubro financiero, en el cual se
concentran alrededor del cliente mltiples canales de venta de diferentes productos.
3. Replicacin: Alto grado de estandarizacin de los procesos de negocio y bajo grado de
integracin entre ellos. Ejemplo: Empresas de un holding que operan en mercados
independientes, es decir, se caracteriza por la ausencia de clientes y proveedores globales. Se
replican modelos de procesos altamente estandarizados, pero administran sus propias bases de
clientes y reglas de negocio.
4. Unificacin: Alto grado de estandarizacin e integracin de los procesos de negocio. Ejemplo:
Industria qumica con la caracterstica de poseer tanto clientes y proveedores locales como
globales. Centralizacin de los procesos de manufactura, gestin de orden de compra, finanzas,
recursos humanos, etc. El modelo diseado de acuerdo a estas dimensiones claves, que son la
combinacin de los diferentes grados de necesidades de estandarizacin e integracin de
procesos, se convierte en la base y el fundamento de un modelo referencial y a la vez una gua
para todos los proyectos de BPM que se desarrollen en el futuro.
Pg. 62

Tema N 8: Modelos de Madurez de BPM
8.1 Qu es un modelo de madurez?
Representa una gua facilitadora que permite evaluar el estado de desarrollo de un rea en
especial. La aplicacin de estas guas permite a las organizaciones:
Conocer su nivel actual de madurez
Identificar elementos ausentes y que son necesarios para alcanzar niveles superiores de madurez
Identificar las fortalezas ya establecidas en la organizacin
Poseer un mapa general de los elementos necesarios para mejorar
8.2 Modelo de Madurez BPM de la OMG (BPMM: Business Process Maturity Model)
BPMM se considera como un mapeo directo con el CMMI, sin embargo, los modelos presentan
orientaciones distintas: el primero se enfoca en los workflows y procesos de la organizacin y su
administracin, mientras que el segundo tiene su foco en la administracin de proyectos.
Los cinco niveles de madurez del modelo BPMM Fuente: [OMG08]
Cada etapa o nivel de madurez cimienta requerimientos con el cual futuras mejoras pueden ser
construidas Al igual que los otros modelos de madurez, BPMM est compuesto por niveles de
madurez, los cuales son (ver figura 4.1):
Nivel 1 - Inicial: Donde los procesos de negocios son ejecutados algunas veces de forma
inconsistente, con resultados difciles de predecir.
Nivel 2 - Gestionado: Donde la administracin de los procesos se liga a procedimientos
particulares dentro de unidades de trabajo, que aseguran que los procesos pueden ser ejecutados
en repetidas ocasiones satisfaciendo los compromisos asumidos por el grupo de trabajo. Sin
embargo, unidades de trabajo que ejecutan tareas similares pueden usar diferentes
procedimientos.
Nivel 3 - Estandarizado: Donde procesos comunes y estndares estn sintetizados desde las
mejores prcticas identificadas en el grupo de trabajo y guas de adaptacin son provistas para dar
Pg. 63

soporte a distintas necesidades del negocio. La estandarizacin de procesos provee de una
economa de escala y del principio para aprender desde comunes medidas y experiencias.
Nivel 4 - Predecible: Donde las capacidades que se disponen por procesos estndares son
explotadas y proveen retorno a las unidades de trabajo. El desempeo de los procesos es
gestionado estadsticamente a travs de workflow para comprender y controlar la variacin, de
modo que las salidas (o productos) de los procesos pueden ser predecidas desde estados
intermedios.
Nivel 5- Innovando: Donde tanto acciones de mejoramiento pro-activas como oportunas buscan
innovaciones que pueden acercar las brechas entre las capacidades actuales de la organizacin y
las requeridas para el logro de los objetivos del negocio.
8.3 Modelo de madurez BPM de Schmelzer
Tiene como base el modelo de madurez del EFQM (European Foundation for Quality
Management)
Modelo de Madurez de BPM para los procesos (Schmelzer)
Nivel 1: Definicin de los procesos

El proceso de negocio est identificado, documentado y validado.
Nivel 2: Responsabilidad de los procesos
Existe un dueo de proceso, roles y responsabilidades definidas
El proceso se encuentra insertado en la estructura organizacional
Nivel 3: Planificacin de los procesos
Planificacin y alineamiento de los procesos con los objetivos estratgicos de la organizacin
Nivel 4: Monitoreo y control de los procesos
El proceso se controla por medio de KPI (indicadores claves del proceso) y se mide el grado de
cumplimiento con los objetivos
Desviaciones inducen procesos de mejora
Nivel 5: Optimizacin de los procesos
Gestin orientada al proceso y mejora continua
El directorio apoya en forma activa la optimizacin permanente de los procesos de negocio
Pg. 64
UNIDAD III
BUSINESS PROCESS MANAGEMENT (BPM)
Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN)
Tema N 8: Evolucin de Business Process Model and Notation (BPMN)

8.1 Historia de tcnicas para modelado de sistemas y procesos
(HITPASS, 2013)
A partir de los aos 60 se empezaron a desarrollar tcnicas de modelado sobre todo orientadas al
desarrollo de sistemas y la mayora de stas, enfocadas al modelamiento de datos y funciones. Lo
que se buscaba encontrar eran vistas de datos normalizadas que deban ser administradas por la
funcionalidad que se requera para el negocio, razn por la cual dominaban las tcnicas centradas
en flujos de datos, como lo fue el anlisis estructurado (en ingls: Structured Analysis). El mtodo
de anlisis estructurado se convirti en su poca en sinnimo del anlisis de flujo de datos. Se
desarrollaron herramientas para documentar y administrar los flujos de datos. Las herramientas
eran esenciales para documentar los sistemas existentes y para determinar los requerimientos de
informacin por medio del mtodo estructurado.
Los analistas deseaban conocer las respuestas a cuatro preguntas especificas: Qu funciones
integran el sistema? Qu datos necesita cada funcin? Qu datos deben ser almacenados?
Qu datos ingresan y abandonan el sistema? De lo dicho anteriormente queda claro que se daba
gran importancia a los datos.
Objetos del Diagrama Anlisis Estructurado segn Yourdon o Gane y Sarson

Pg. 65
Ejemplo de Diagrama de Contexto con IDEF
Ejemplo de Descomposicin del Diagrama de Contexto con IDEF
Pg. 66

8.2 Clasificacin de las tcnicas de modelamiento
(HITPASS, 2013)
Formalmente podemos hacer la primera gran divisin en metodologas basadas en tcnicas de
lenguaje estructurado (script) y metodologas basadas en tcnicas de diagramacin.
Las metodologas basadas en tcnicas de diagramacin, las podemos clasificar en tcnicas
orientadas al flujo de datos, al flujo de control y orientadas al objeto.
Clasificacin de algunas tcnicas de diagramacin para modelamiento de procesos
8.3 Otras Tcnicas de Modelado
(HITPASS, 2013)
Antes que apareciera BPMN se difundieron bastante algunas tcnicas orientadas al objeto para
modelar procesos, sobre todo UML Activity Diagram (diagramas de los procesos a nivel
descriptivo) y diagramas UML Use Case (Casos de uso en un nivel ms detallado que describen el
flujo entre actividades y unidades organizacionales).
Pg. 67

Ejemplo de Use Case de UML
Ejemplo de Activity Diagrama de UML
8.4 Business Process Model and Notation (BPMN)
(HITPASS, 2013)
La primera versin de la Business Process Modeling Notation (BPMN) fue desarrollada por el
instituto Business Process Management Initiative (BPMI) principalmente bajo la tutela de Stephan
A. White profesional de la IBM en 2004.
Pg. 68

Desde un principio, el principal objetivo fue disponibilizar una notacin grfica, estandarizada, que
permitiera automatizar los procesos a partir del diseo grfico. En el ao 2005 fue trasladado el
proyecto a la Object Management Group (OMG ), debido a que el BPMI no era un instituto que
administra estndares. La OMG es muy conocida en el mundo informtico porque administra,
entre otros, el estndar del lenguaje para el diseo de software llamado Unified Modeling
Langauge (UML). A travs de la OMG, de la cual son miembros la mayora de los proveedores
ms importantes de TI, BPMN se difundi rpidamente a nivel mundial y casi todos los
proveedores sean grandes o pequeos, acadmicos o consultores empezaron a adoptar este
estndar. La ltima versin oficial 1.2 fue publicada en enero 2009 [OMG09]. La versin 2.0,
completamente nueva y ampliada, se termin a mediados del ao 2010 y a finales de ste, el
equipo de la OMG encargado de revisar y finalizar la nueva versin, llamada Finalization Task
Force (FTF), dio la recomendacin al gremio de decisin de oficializar la versin 2.0. A partir de la
versin 2.0 la sigla BPMN cambia levemente de nombre a: Business Process Model and Notation.
Paradojalmente hasta la versin 1.2 no se podan mapear los modelos directamente en un entorno
tcnico, porque an no estaban definidos los atributos tcnicos. Debido a esta falencia existieron
muchos problemas en convertir (mapear) los modelos a lenguajes de ejecucin como BPEL.
Recin con la versin 2.0 existe un metamodelo que permite ejecutar directamente los modelos de
BPMN. Estos dos hechos importantes de la nueva versin, es decir estandarizacin y habilidad de
ejecucin directa conlleva a los siguientes beneficios:
Al 2011 existen ms de 70 herramientas de modelacin de BPMN (tendencia en aumento) y
muchas de ellas se pueden adquirir gratis. La comunicacin con otros socios de negocio que
hayan aprendido BPMN (clientes, consultores, proveedores, etc.) ser ms rpida, fluida y
expresiva. Se puede esperar que nuevo personal traiga el conocimiento de BPMN.
Institutos de capacitacin, universidades y empresas consultoras van a invertir recursos para
formar profesionales en esta notacin. Empresas privadas van a desarrollar soluciones basadas
en este estndar, y proveedores de tecnologa se encuentran desarrollando herramientas para
ejecutar directamente el cdigo grfico de BPMN.
Fuente: http://bpmn-bayard.blogspot.com/2011/03/5-historia-del-bpmn.html
Pg. 69

Tema N 9: Los elementos bsicos de BPMN
9.1 Modelos, instancias, token y correlaciones
Como un diagrama puede Como un diagrama puede contener varios pools, se entiende que un
diagrama puede contener n procesos.
Modelo de procesos: En un diagrama pueden representarse uno o ms modelos de procesos.
Cada modelo constituye la descripcin de un proceso.
Instancia de proceso: Se entiende un proceso concreto en la realidad, es decir casos reales
como por ejemplo la reclamacin de un cliente crea una instancia del proceso de reclamaciones.
Algunos procesos se instancian slo un par de veces al ao y otros ms a menudo.
Token (marca): Se utiliza para visualizar y probar el comportamiento de los procesos diseados.
Las marcas recorren en forma de una animacin la lgica por los flujos normales y los de
excepcin.
Correlacin: Seguramente usted ha recibido muchas veces correspondencia de instituciones que
contienen un nmero de referencia, nmero de acta, nmero de ticket, etc.. Si usted responde a la
institucin tiene que indicar esta referencia para que pueda ser identificada. A esta asignacin en
forma de un identificador se le llama correlacin. Un caso siempre debe estar bien correlacionado
para que no ocurran errores o prdidas de datos.
9.2 Categoras de los elementos de BPMN
Los elementos grficos en BPMN se encuentran clasificados dentro de 4 categoras:
Fuente: http://bpmn-bayard.blogspot.com/2011/05/8-fundamentos-de-bpmn_28.html
Pg. 70
9.3 Actividades
Es cualquier trabajo que realiza la organizacin. Pueden ser atmicas o compuestas

Las actividades las que transforman el estado de un objeto de negocio para que el proceso puede
llegar a producir valor para los clientes.
Fuente: http://bpmn.16mb.com/conexionActividad.php
9.3.1 Tipos de Actividades
(HITPASS, 2014)
Hasta la versin BPMN 1.2 no exista una simbologa reservada para diferenciar los tipos de
actividades. Esta falencia se super a partir de BPMN 2.0, dando a las actividades indefinidas una
simbologa en su respresentacin.
a. Actividad Manual
Es ejecutada por una persona, cuyo control no lo lleva un sistema de workflow o Process Engine.
Ejemplos:
El guardar un acta en un archivo fsico
El aclarar por telfono una factura mal emitida
La conversacin de un ejecutivo con su cliente
b. Actividad Usuario
Tambin es ejecutada por una persona (usuario), pero en este caso el control lo lleva el sistema
de workflow o Process Engine.
Ejemplos:
Revisar una factura
Aprobar una solicitud de vacaciones
Administrar una solicitud de soporte
Pg. 71

c. Actividad Servicio
Es una actividad automtica que es ejecutada completamente por algn software. BPMN parte
normalmente de la base, que se trata de un servicio web, pero no es mandatorio. De todas formas
se trata de una componente de integracin de aplicaciones, con lo cual tenemos por esta va la
entrada al puente con las arquitecturas orientadas al servicio (SOA).
Ejemplo de servicios de integracin:

Solicitud de clasificacin de riesgo crediticio a un sistema interbancario
Verificacin de stock de bodega para una orden de compra
Disponibilidad de asiento para una reserva de pasajes
d. Actividad Enviar y Recibir
La recepcin de un mensaje en BPMN puede modelarse como una actividad aunque exista un tipo
de evento para estos fines.
Si se desea que un proceso sea instanciado por una actividad de tipo recepcin y de esta forma
reemplazar un evento del tipo mensaje al inicio de un proceso, se debe utilizar el smbolo de tipo
de carta con un crculo.
El mismo principio tiene validez para las actividades del tipo envo.
Este tipo de actividades son solamente tcnicas y se usan para invocar interfaces asincrnicas de
servicios web en colas de
mensajera (en ingls: message queues), etc., por lo que no se recomienda de usarlas en modelos
de negocio.
e. Actividad Script
Un script es un pequeo programa que puede interpretar y ejecutar directamente el sistema de
workflow. El script tiene que estar escrito en el lenguaje que pueda interpretar el entorno de
implementacin.
f. Actividad Regla de Negocio
Este tipo de actividad tambin es nuevo a partir de BPMN 2.0 y se interpreta de tal forma que slo
est destinada para ejecutar una regla de negocio, ya sea invocndola a un sistema independiente
(BRMS: Business Rule Management System) o ejecutando un motor de reglas que viene incluido
en el Process Engine.
Pg. 72
9.3.2 Propiedades de actividades
A las actividades, podemos marcarlas con ciertas propiedades (marcas), tales como repetitivas
(loop), mltiples (ms de una
instancia), o compensacin. Estas marcas pueden combinarse con los tipos de actividades,
convirtendose de cierta forma en actividades complejas.
a. Loop
Una actividad con la propiedad de loop (bucle) se va a repetir tantas veces hasta que se cumpla, o
no se cumpla la condicin especificada.
Tambin podemos modelar la condicin repetitiva con ayuda de Gateways, en combinacin con
Gateways o sin ellos.
Pg. 73

b. Actividad mltiple
La actividad con propiedad de mltiple ejecuta en forma simultnea la actividad tantas veces como
instancias existan.
c. Actividad de compensacin
Esta propiedad se utiliza exclusivamente en el contexto del evento intermedio de compensacin y
se relaciona con el evento a travs del flujo de asociacin y nunca a travs del flujo de secuencia.
9.4 Flujos de Secuencia

Los Conectores vinculan dos objetos en u n diagrama. Existen tres diferentes tipos de
conectores de BPMN:
a. Flujo de Secuencia
Define el orden
de los objetos de flujo en
un Proceso (Actividades, Eventos y
Gateways).
b. Flujo de Mensaje
Define el flujo de comunicacin entre dos participantes o entidad e s (p. ej., una
organizacin y sus proveedores). El objeto de la comunicacin es u n me n s aje.
c. Asociaciones
Se utilizan par a vincular Artefactos (d a tos e informacin) con otros objetos del
diagrama, incluyen do objetos de flujo (Actividades, Eventos y Gateways).
Pg. 74
9.5 Actividades globales
A partir de la versin BPMN 2.0 podemos definir actividades globales, las cuales se diferencian de
las actividades normales, en que las primeras pueden reutilizarse. Las actividades globales no se
diferencian grficamente de las normales. Slo las reconocemos al ver la existencia de actividades
invocables que llevan el mismo nombre que las globales, pero tienen una lnea de contorno ms
gruesa, es decir en negrita.
9.6 Un proceso simple en BPMN
9.7 Flujo de Procesos con Gatewatay
(HITPASS, 2014)
Casi ningn proceso tiene un flujo unifome. En la mayora de los casos, las instancias recorren
diferentes trayectorias, dependiendo de las condiciones y reglas que apliquen.
Pg. 75

9.7.1 Gateway exclusivo de datos (XOR)
La compuerta en que tenemos que tomar la decisin en BPMN se denomina Gateway.

No confunda un Gateway con una Actividad.
El Gateway requiere de un hecho (una variable). La actividad es la encargada de producir este
hecho y disponibilizar la variable para el Gateway.
Como esta decisin la tomamos de acuerdo a la informacin recibida y la compuerta permite

recorrer slo una alternativa.
La posibilidad que tenemos de utilizar el XOR-Gateway como elemento de bifurcacin (XOR-Split)

o unin (XOR-Join) puede que al principiante lo confunda.
La notacin permite incluso usar el XOR-Gateway como una unin de entrada y bifurcador de
salida con un slo smbolo.
9.7.2 Gateway paralelo
Por ejemplo indicamos el tiempo promedio que demora cada actividad. La suma de los tiempos de
cada una actividad nos arroja el tiempo de ciclo del proceso completo. (anlisis de indicadores de
tiempo de ciclo)
Pg. 76

Podramos pensar en paralelizar la preparacin de la comida y de esta forma acelarar el proceso
en general.
El paralelismo no significa que obligatoriamente las actividades tienen que ejecutarse exactamente
en forma simultnea, pero pueden comenzar cuando la condicin se de.
Con la instancia del proceso se crea simultneamente el token, el cual es clonado como en el caso
anterior en el AND-Split. Apenas est lista la ensalada se dirige el token a la actividad comer
preparacin y ejecuta la tarea, es decir la ensalada se consume sin esperar la pasta, como se
muestra en la figura:
Otro caso en que la instancia vive el tiempo que corresponde con el tiempo de ciclo del proceso
(ejemplo 45 das). A pesar que el primer token se consume luego de 30 das, el segundo token
an est activo durante 15 das ms en la actividad 2.
Pg. 77

9.7.3 Gateway inclusivo de datos (OR)
Con un OR-Gateway podemos formular una situacin que responde a las preguntas y/o, en la
cual podemos escoger uno, muchos o simplemente todos los flujos de salida (Para consumir
tokens de una o ms ramas de entrada (Inclusive Merge) o para propagar tokens a, al menos, una
de las ramas de salida (Inclusive Desicion).
Podemos Seguir compactando el modelo, con las diferentes opciones:
Veamos las opciones:

Comemos slo pasta.
Comemos slo steaks.
Comemos slo ensalada.
Comemos pasta y ensalada
Comemos steak y ensalada.
Comemos pasta y steaks.
Comemos pasta, steaks y ensalada.
Pg. 78

El flujo por defecto
Nos protege ante situaciones indeseadas. Primero se contemplan todos los flujos salientes con
sentido de negocio; slo si ninguna de las opciones anteriores es vlida se emplea el flujo por
defecto.
9.7.4 Gateway complejo
Se utiliza cuando un caso de negocio no se puede representar con ningn otro Gateway.
Se da en un punto del proceso donde aparecen varios caminos y solo uno de ellos es vlido.
Esta decisin esta basada en la informacin registrada en Metadata.
En el ejemplo, en el momento de tomar la decisin, por cualquiera de ambas alternativas, pedimos
la pizza y desechamos la otra opcin.
Vamos a suponer que vamos a ejecutar cuatro actividades en forma simultnea. La quinta
actividad debe ejecutarse apenas se disponga del resultado de tres actividades, independiente de
algn orden correlativo. Este tipo de comportamiento de sincronizacin se puede representar con
un Gateway complejo, agregndole si la condicin en forma de un artefacto del tipo comentario.
Pg. 79
9.8 Eventos
Las tareas (actividades) cambian el estado de un objeto, bajo ciertas condiciones (Gateways).
Eventos son cosas que ocurren. Indican que al inicio, en forma intermedia o al final del proceso
algo significativo ocurri.
Eventos de inicio nos indican que tipo de ocurrencias suceden para que un proceso comience.
Eventos intermedios muestran un estado que el proceso ha alcanzado y que en el modelo por
alguna razn lo queremos retener. No se utilizan muy a menudo, pero pueden ser muy tiles, por
ejemplo si el estado representa un hito y se quiere medir el tiempo transcurrido hasta alcanzar el
hito.
Eventos finales indican que se logr al finalizar una trayectoria del proceso.
Los eventos de captura se les denomina en BPMN catching events e indican ocurrencias que
vienen de afuera y a los que un proceso debe reaccionar cuando estos suceden, independiente si
este tipo de eventos gatillan (en ingls: trigger) el inicio de un proceso o suceden durante un
proceso.
Lo importante de entender es que este tipo de sucesos tienen un impacto sobre el proceso y que
este debe reaccionar.
Eventos de captura pueden tener el siguiente impacto sobre los procesos:
Inician el proceso, el proceso o el flujo del proceso contina, una actividad o un subproceso que se
encuentra en ejecucin es interrumpida o cancelada, durante la ejecucin de una actividad o un
subproceso, impulsa el inicio de otra actividad o subproceso
Los eventos del tipo disparador se les denomina en BPMN throwings events e indican eventos
creados dentro del proceso. Es decir a diferencia a los eventos del tipo de captura a los cuales el
proceso debe reaccionar, en este caso el mismo proceso acta como gatillador de nuevos
eventos. Eventos del tipo disparador: pueden crearse durante el proceso, o al final del proceso
(eventos de trmino).
Para que un proceso que est en espera pueda continuar, puede hacerse necesario que ocurra un
evento intermedio, como lo muestra la figura, Si la actividad 1 ha terminado, tiene que ocurrir
primero el evento 1, antes que puede iniciarse la actividad 2.
En BPMN tambin podemos representar casos en que existe un flujo normal, pero puede ocurrir
un evento inesperado que interrumpa una actividad o un subproceso. A estos eventos intermedios
Pg. 80

se les llama sobrepuestos (en ingls: attached), ya que van superpuestos a un costado de la
actividad.
Primero avanza hacia la actividad 1, la cual se inicia.
Si sucede el evento 1, durante la ejecucin de la actividad 1, esta se interrumpe inmediatamente y
el token sigue su flujo en la actividad 3 (caso de excepcin). Si no sucede el evento 1, la actividad
1 se ejecuta en forma normal y el token sigue su flujo regular e inicia la actividad 2.
Si sucede el evento 1, despus que se haya ejecutado la actividad 1, el suceso no impacta en el
proceso.
En BPMN hasta la versin 1.2 los eventos sobrepuestos (a excepcin de los eventos del tipo de
compensacin), siempre cancelan la actividad en ejecucin. Este comportamiento no siempre
refleja la realidad, por lo que en la versin 2.0 se introdujo un nuevo smbolo: un evento intermedio
sobrepuesto, pero del tipo no interrupcin.
El token inicia la actividad 1. Si sucede el evento 1, durante la ejecucin de la actividad 1, el token
es clonado: La actividad 1 sigue en proceso, pero al mismo tiempo avanza el segundo token (el
clonado) a la actividad 3, la cual tambin es iniciada y ejecutada. Este evento puede suceder
incluso en forma repetitiva, y el token vuelve a clonarse hasta que la actividad 1 haya terminado.
Si no sucede el evento 1, la actividad 1 se ejecuta en forma normal y el token sigue su flujo regular
e inicia la actividad 2.
Si sucede el evento 1, despus que se haya ejecutado la actividad 1, el suceso no impacta en el
proceso.
9.8.1 Evento de Mensaje
Eventos que portan informacin (no se restringe a ciertos portadores de informacin como cartas,
emails o llamadas, sino a cualquier objeto que porte informacin: orden de compra, gua de
despacho, boleta o factura.)
Pg. 81

Ejemplo:
O tambin:
Otro ejemplo, el cliente nos llama haciendo un reclamo que el sitio no responde o est abajo. El
operador busca el problema o verifica si existe algn error. Es posible que el cliente se haya
equivocado y el problema lo tenga l, porque en algn instante se le haya
cado internet. l llama nuevamente para que no nos preocupemos. Este llamado entra al proceso
como un evento de mensaje del tipo interrupcin, al ocurrir todas las dems actividades se
cancelan y el flujo sigue a la actividad asignada por el evento de interrupcin.
9.8.2 Evento de tiempo
Tambin llamado temporizador, se utiliza cuando una condicin de tiempo ocurre.

Como evento de inicio se puede utilizar para: iniciar cada ciertos intervalos un proceso, iniciar un
proceso regularmente en una fecha y hora indicada, iniciar un proceso en una relacin temporal
con otro evento e iniciar un proceso por nica vez en una fecha y hora determinada.
Como evento intermedio el temporizador puede detener el proceso, hasta que: un tiempo definido
se haya alcanzado, un perodo de tiempo haya transcurrido, se haya alcanzado un tiempo, que se
encuentre en relacin a otro evento.
Pg. 82
Un evento de tiempo no puede ser impulsado por un proceso, porque sobre el tiempo no tenemos
influencia, razn por la cual este evento existe slo en forma de evento de captura.
Muy a menudo se utiliza el temporizador sobrepuesto como timeout, tiempo mximo permitido
para la ejecucin de una actividad.
Tambin se pueden utilizar temporizadores sobrepuestos que no interrumpen la actividad.
9.8.3 Evento de error
Si usted identifica los puntos donde pueden ocurrir errores, los puede interceptar utilizando este
tipo de eventos.
En BPMN se considera un error como un evento excepcional, razn por la cual slo se puede
modelar como evento intermedio sobrepuesto y que adems requiere de un tratamiento
excepcional. Como tipo disparador slo se debe usar como evento final, indicando que el proceso
ha sido cancelado por error, o bien el evento es capturado por un subproceso superior que lo lleva
a un tratamiento especial.
Pg. 83
9.8.4 Evento Condicional
Un proceso puede iniciarse o continuar bajo ciertas condiciones. La condicin debe ocurrir en
forma independiente del proceso.
Este evento es junto al evento de tiempo el nico tipo que slo existe en forma de evento de
captura.
9.8.5 Evento de seal
Tienen un cierto parecido con los de mensajes, razn por la cual en BPMN las reglas de
modelamiento para ambos eventos son iguales.
La nica y gran diferencia es que los mensajes tienen un destino definido, por ejemplo un e-mail
indica una direccin a quin se dirige y una llamada telefnica indica un nmero identificador,
mientras que una seal es un mensaje con destino indefinido. Un anuncio en el diario, un reclame
en la televisin, o un llamado de emergencia por radio son ejemplos de seales.
Cualquiera persona o sistema que capte la seal puede reaccionar si es que quiere.
El ejemplo que al ver un comercial en la televisin nos abri el apetito de probar la pizza tras el
anuncio. Entonces llamamos y hacemos el pedido de la pizza (reaccin a la seal), pero slo la
comemos cuando tengamos deseo de probarla (evento de condicin). Luego evaluamos si nos
gust la pizza en un sitio web de gourmes. Es decir, tambin los comensales envan una seal
(destino indefinido) al evaluar la pizza en un sitio pblico.
Pg. 84

9.8.6 Evento de trmino
El evento terminador luego de consumir todos los tokens activos se encarga tambin de finalizar la
instancia del proceso. Como consecuencia este evento especial slo debe usarse como evento
final, debido a que termina todos los tokens activos del proceso, independiente de donde se
encuentren.
9.8.7 Evento de conexin
Conexin o de vnculo (en ingls: link) es un evento tcnico, no tiene ningn significado de
negocio. El evento no tiene otra finalidad que poder dividir diagramas muy grandes, sin perder el
vnculo de un flujo de secuencia.
9.8.8 Evento de compensacin
Compensar en BPMN significa volver al estado inicial de una actividad.

En la prctica utilizamos el evento de compensacin slo en el contexto de transacciones que
tienen que ser reversadas.
Un ejemplo de un proceso de una persona que desea organizar una salida el da viernes despus
de su jornada laboral.
La persona se pone de acuerdo con su pareja despus de medio da (13:00 hrs) de organizar una
salida al teatro o de invitar a unos amigos a salir. En ambos casos tenemos que comprometernos
a reservar las entradas el teatro o de llamar a amigos para invitarlos. Al atardecer o al llegar a la
casa, puede darse la situacin de estar muy cansados, cambiar de parecer y quedarnos en casa
Pg. 85

viendo televisin. Entonces tenemos que cancelar las entradas o llamar a los amigos para
manifestarles que no habr salida.
9.8.9 Evento Mltiple
Con el evento mltiple podemos incluir la captura de varios eventos alternativos con un smbolo.
Si se utiliza como evento de captura, inicia o contina el proceso, con el slo hecho de ocurrir uno
o el primero de los eventos posibles.
Como evento del tipo disparador reacciona como un disparador mltiple, es decir impulsa todos
los eventos contenidos.
9.8.10 Evento de Gateway exclusivo basado en eventos
En BPMN contamos con una posibilidad adicional para disear comportamientos especiales, como
es el evento de Gateway exclusivo basado en eventos (abreviado: Event-Gateway). Este
Gateway no reacciona ante datos sino a eventos, especficamente al primer evento que suceda.
Qu situaciones se pueden dar para utilizar este Event-Gateway? Para este efecto
Pg. 86

REVISAR:
1.
Evento Mltiple Paralelo
2.
Evento de Escalacin
3.
Evento de Cancelacin
4.
Evento de Gateway paralelo basado en eventos
9.9 Lane
An no hemos visto quin o quienes son los responsables de ejecutar las actividades. BPMN
utiliza carriles llamados lanes para la asignacin de responsables.
Segn las reglas de BPMN, un objeto de flujo (actividad, evento, Gateway) slo se puede
posicionar dentro de un lane y no entre ellos.
La solucin para este escenario, sera crear la actividad tantas veces como personas participan.
Pg. 87

9.10 Artefactos
BPMN contiene tambin una categora de elementos que sirven para una mejor explicacin o
visualizacin grfica, pero que de ninguna forma tiene alguna influencia en la lgica de los
procesos, por lo cual los artefactos no son interpretados por un motor de workflow.
9.11 Participantes y flujos de mensajes
Si se hace necesaria una coordinacin entre participantes en un proceso de negocio, la

metodologa de BPMN obliga a separar los pools y la comunicacin entre ellos se lleva a cabo a
travs de flujos de mensajes. Entonces tendramos en el ejemplo que ilustra la figura 6.9 cuatro
dirigentes, cada uno con su propio mini-proceso y su propio flujo de control. Entre ellos no pueden
hacer otra cosa que intercambiar informacin a travs de flujos de mensajes. Es posible que un
proceso dependa de un mensaje externo para que pueda continuar, pero eso lo define el propio
proceso (pool) dentro de su lgica.
Figura 6.9: Flujo de cuatro participantes en pools propios Fuente: [FreRueHit11]
Es posible que el analista no se sienta muy cmodo con este principio de modelamiento porque en
otras tcnicas de modelamiento no se interpreta as. En muchas ocasiones no es necesario
Pg. 88

separar a todos los participantes para representar una determinada lgica en un proceso, eso va a
depender fundamentalmente si el dirigente tiene el control sobre ellos. Si un pool o dirigente no
tiene control sobre un participante, entonces s tiene que obligadamente separarlo y representarlo
como un pool propio, por ejemplo clientes y proveedores.
Por qu BPMN introdujo este principio de separar los participantes a pools propios para
representar la lgica en sus diagramas? El objetivo principal que tienen los autores del BPMN en
mente es la automatizacin de los procesos a partir de los diagramas.
9.12 Subprocesos
Un subproceso describe en su interior la lgica en detalle, pero en el diagrama del proceso

superior no toma ms lugar que una propia actividad. Ambos elementos, la actividad y el
subproceso, pertenecen a la clase de las actividades y se representan en forma de rectngulo con
esquinas redondeadas. La nica caracterstica que los diferencia es un signo ms (+) en la
actividad del tipo subproceso, que indica la existencia de una lgica dentro de este.
El proceso superior se inicia y nace un nuevo token.

El token pasa por la actividad y llega al subproceso. Esto conlleva a que el proceso superior cree
una instancia del subproceso.
Dentro del subproceso se crea un nuevo token que sigue la lgica del flujo del subproceso desde
el evento de inicio hasta el evento que termina el subproceso. El token del evento superior espera
el arribo del token del subproceso.
Pg. 89
Tema N 10: Diferentes vistas de un proceso

BPMN parte de la base que en un diagrama pueden representarse uno o ms participantes.
Ha de tener cuidado de no confundir un participante con un rol, un departamento o usuario. Un

participante es para BPMN en primer lugar un elemento lgico, cuya aplicacin obedece a las
siguientes reglas:
En un proceso existe un slo participante (Este principio confunde a menudo al lector)

Este participante posee el control absoluto sobre la lgica del proceso
Otros participantes no pueden influenciar este proceso, en algunas ocasiones ni siquiera saben
cmo est organizado
El participante es por definicin el responsable del proceso
Si varios participantes deben interactuar con otros procesos, deben de hacerlo por medio del
intercambio de informacin (flujo de mensaje), informacin que lgicamente apoya la operacin del
proceso
Debido a estos principios, se da que cada participante tenga su propia vista sobre el proceso
general, es decir diferentes perspectivas. Este hecho nos lleva a deducir que un proceso de
negocio puede y por lo general tiene varios modelos de procesos, tantos procesos como
participantes existan. El objeto que en BPMN representa un participante es un pool.
Pg. 90

Tema N 11: Categora de Procesos
(White 20009)
Des de su descripcin, BPMN ha tratado de dar soporte a tres categoras principales de Procesos:
Orquestacin
Coreografa
Colaboracin
Estos trminos han variad o, usualmente con conflictivos significados en los distintos contextos de
negocio en los que son aplicados.
11.1 Orquestacin
Los modelos de orquestacin tienden a implicar una perspectiva nica de coordinacin.

Por ejemplo, representan una vista especfica del negocio u organizacin del Proceso.
Como tal, un Proceso de orquestacin describe cmo una nica entidad de negocio lleva
a cabo las cosas.
Sin embargo, un diagrama BPMN puede contener m s de una orquestacin. En tal caso,
cada orquestacin aparece dentro su propio con tenedor llamado Pool.
11.2 Coreografa
Un modelo de proceso de coreografa es una definicin del comporta miento esperado

(una clase de
contrato
procedimientos
o protocolo)
entre
los participantes que
interacta n . Estos participantes pueden ser roles de negocio generales (por ejemplo,
un despachador) o una entidad especfica de negocio (por ejemplo, FedEx como
empresa de transporte).
Una coreografa describe las interacciones de los participantes.

Incluye tantos caminos alternativos y paralelos, as como Sub Procesos. De esta
man e r a, los objetos de flujo (Actividades, Eventos, y Gateways) de los modelos de
orquestacin tambin aplica n a los modelos de coreografa.
Pg. 91

Los conectores entre los Pools son el Flujo de Mensajes.
11.3 Colaboracin
Mientras que la coreografa muestra el conjunto ordenado (protocolo) de interacciones

entre los participantes.
Un a colaboracin puede contener tambin una coreografa (cuando est disponible en
BPMN) y una o ms orquestaciones.
Una colaboracin es cualquier diagrama BPMN que contenga dos o m s participantes
como se muestra con los Pools. Los Pools tienen Flujo de Mensajes entre ellos.
Cualquiera de los Pools puede llegar a contener una orquestacin (un Proceso), pero
no est requerido.
Pg. 92
UNIDAD IV
AUTOMATIZACIN DE PROCESOS CON BUSINESS PROCESS
MANAGEMENT (BPMN)
Tema N 12: Automatizacin de Procesos

(HITPASS, 2013)
Una de las mayores novedades que trae la nueva versin 2.0 de BPMN [OMG11] es la
introduccin de la definicin de una semntica de ejecucin como tambin un formato de
serializacin de XML. Qu significado tienen estas expresiones? Los modelos de BPMN pueden
almacenarse en un archivo de XML, pero la especificacin norma como hacerlo. Existen dos tipos
de esquemas de XML:
Para el intercambio de modelos: El XML contiene toda la informacin que se necesita para
exportar e importar modelos de una herramienta a otra. La definicin incluye informacin grfica
sobre el posicionamiento de los objetos (layout).
Para la ejecucin de la semntica: La especificacin norma cmo deben archivarse todos los
detalles tcnicos del proceso.
La especificacin norma cmo deben ser almacenados los esquemas de XML para que se pueda
interpretar la sintctica, pero tambin la interpretacin de la semntica y el metamodelo.
Pg. 93

12.1 Niveles de Procesos
12.1.1 Nivel 1: Modelo de Procesos Descriptivos
Describe la lgica de negocio lo ms compacta posible. El objetivo principal en este nivel es
describir el alcance que tienen los procesos de principio a fin. Le sirve al propietario del negocio.
Los principales objetivos relacionados con el primer nivel son:
Definicin del alcance de los procesos (Lmites definidos en los trminos desde/hasta )
Asignacin de las responsabilidades y recursos del proceso
Definicin de los principales KPIs (Key Performance Indicators: Indicadores crticos del negocio),
por ejemplo tiempos de ciclo mximo por proceso
Requerimientos generales que se esperan para mejorar el rendimiento de los procesos
Cundo requerimos o se hace necesario modelar los procesos en el nivel descriptivo? Si

tenemos que levantar por primera vez la situacin actual de un proceso, si tenemos que disear
un proceso nuevo o redisear uno existente.
La siguiente pregunta es si es necesario modelar la lgica de los subprocesos que se encuentran

cerrados. Por lo general desistimos de ello en el nivel descriptivo, porque no es objetivo del nivel 1
conocer los detalles de la lgica de negocio.
Ejemplo:
Modelo de proceso de contratacin de personal con cada participante en Pool propio.
Pg. 94

Ejemplo:
Caso de modelo de colaboracin utilizando Pool cerrado
12.1.2 Nivel 2: Modelo de Procesos Operacional
Es la esencia del BPMN-Framework. Este nivel abarca toda la lgica de negocio en detalle,
incluyendo los casos de excepcin, identificando las reglas de negocio, y la interaccin en detalle
con todos los participantes. El modelo operativo le sirve al usuario de negocio (Process
Participants) como gua o manual de procedimiento en su trabajo diario. Al analista de proceso
(Process Analyst) le sirve como input para evaluar la eficiencia del proceso y poder desarrollar
propuestas de mejora. Por ltimo, el modelo operativo constituye la base y el punto de partida para
el diseo de una implementacin tcnica por medio de TI.
Su pregunta esencial es:

Cmo se trabaja y cmo podra hacerse mejor? El usuario de negocio en cambio slo se
interesa en aquellos aspectos del proceso que le conciernen a l.
Su pregunta esencial es:
Cmo tengo que trabajar? Llegado el momento de querer implementar tcnicamente el
proceso, entra en juego el ingeniero de procesos (Process Engineer).
El ingeniero de procesos no es parte integrante del equipo para el modelamiento en el segundo
nivel, su rol activo comienza en el tercer nivel, pero l debe enterarse sobre los requerimientos
funcionales que debern implementarse.
Su pregunta esencial en este nivel es:
Qu debe cumplir el sistema de TI? Uno de los desafos principales en el nivel operativo es de
coordinar satisfactoriamente estos tres roles principales contestando a cada una de sus preguntas.
Nada de sencillo, pero si lo logra, obtendr una serie de beneficios: El modelo operativo
corresponde en su lgica principal completamente a la lgica que ser implementada
tcnicamente. Logramos un buen alineamiento entre la capa de negocio y la capa de TI. La
documentacin elaborada no se deja de lado y se empieza de nuevo a modelar como sucede en
muchos proyectos.
Pg. 95

Los diagramas de proceso tienen que estar en nivel 2 sintcticamente correctos igual que en el
nivel 1, pero adicionalmente al nivel 1 su semntica debe ser consistente.
En el nivel 2 se describe como realmente se trabaja, razn por la cual no se pueden aceptar
contradicciones o faltas formales, como lo admitimos en el nivel 1, pero tampoco debe llevarse a
un grado de complejidad tan alto que se torne inentendible: A cada rol le asignamos una vista
propia del proceso completo.
Ejemplo:
Diagrama de colaboracin para proceso de licitacin de cargo
Preparacin de la Automatizacin de los Procesos

La descripcin de la lgica de negocio es slo uno de los objetivos en el nivel operativo de nuestro
framework de BPMN.
El asunto es el traspaso o el mapeo sin variaciones de aquella parte de la lgica de negocio que
se quiere implementar por un sistema de workflow, es decir el traspaso del nivel 2 (diseo lgico)
al nivel 3 (diseo tcnico).
Pg. 96

Ejemplo:
Representacin del proceso de licitacin en un sistema de workflow
Otros requerimientos
Pg. 97
12.1.3 Nivel 3: Modelo de Procesos Tcnico
Es finalmente automatizar los procesos por medio de software.

Modelos tcnicos bien diseados pueden ejecutarse directamente en el nivel 3 con un Process
Engine. Dicho de otra forma, el modelo tcnico (diagrama tcnico) es sinnimo de cdigo fuente
para el Process Engine, lo que tiene una importante implicancia: Los modelos tienen que estar
sintcticamente y semnticamente correctos y lo suficientemente detallados como para ejecutarse.
Lo que en el modelo no est formalmente claro, no lo puede interpretar el Process Engine.
El procedimiento incluye por lo general los siguientes pasos:

1. Aclarar y validar el modelo de proceso to be en el nivel 2. Este punto lo tratamos
extensamente en el captulo anterior.
2. Decisin sobre una plataforma y arquitectura tecnolgica (Nota: Normalmente la definicin y
disposicin de una plataforma tecnolgica debera ser un proyecto separado de informtica y ser
un input dado para un proyecto de BPM).
3. Si se utiliza una Engine BPMN 2.0, slo debera ampliarse el modelo de procesos en aspectos
tcnicos. Si se utiliza otro tipo de modelo tcnico (BPEL, XPDL u otro) se har necesario incluir
una nueva capa y realizar un mapping entre el nivel 2 y el nivel 3.
4. Rediseo iterativo del modelo del nivel operativo en caso que surgan problemas que no
permitan implementar el modelo de negocio.
5. Testear y ejecutar marcha blanca de acuerdo a los mtodos tradicionales del ciclo de desarrollo
de software.
Forma de trabajo de un Process Engine

Pg. 98
12.2 BPMN comparado con otras notaciones
(HITPASS, 2013)
Muchos lectores que se interesan por BPMN conocen algunas otras notaciones para modelar
procesos. Seguramente tambin se preguntarn si tiene sentido cambiarse a BPMN y qu
aspectos hay que considerar en esta nueva tcnica de modelamiento. Segn la regin donde est
radicado el lector y la escuela por la que ha pasado, habr conocido o aplicado diferentes
notaciones.
Cuando se empez a desarrollar BPMN se revisaron muchas otras notaciones de modelamiento.

Los miembros de la OMG aportaron con sus conocimientos y experiencias con muchas notaciones
existentes, de las cuales algunas de ellas influyeron en el desarrollo del estndar, como por
ejemplo UML Activity Diagram, IDEF, ActivityDecision Flow (ADF) Diagram, y Event-Process
Chains (EPCs)[ OMG11].
Otras notaciones ms orientadas al negocio se revisaron para extraer ideas en la parte conceptual
del modelamiento de procesos de negocio, como EPC, IDEF y UML Activity Diagram.
Pg. 99
REFERENCIAS BIBLIOGRFICAS
Y DIRECCIONES ELECTRNICAS
Bsica
HITPASS, Bernard, BPM: Business Process Management Fundamentos y
Conceptos de Implementacin, Segunda Edicin. Chile: Editorial BHH Ltda, 2013.
Complementaria
BERND RUKER, Jakob. Manual de Referencia y Gua Prctica BPMN 2,0.
Cuarte Educion, Chile: Editorial
Dimacofi,
2014.Joyanes Aguilar, Luis.
Estructura de Datos. 1ra. ed. Espaa: McGraw-Hill; 2000.
BPMN 2.0, Bizagi Suite [en lnea]. [Consulta: 20 de junio de 2015]. Disponible en
Web: https://www.bizagi.com/docs/BPMNbyExampleSPA.pdf
Gua especificacin BPMN [en lnea], [Consulta: 03 de junio de 2015].Disponible
en Web: http://www.bpmn.org
Pg. 100

Texto Universitario NOTACION de PROCESOS

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Texto Universitario NOTACION de PROCESOS

Enviado por

Direitos autorais:

Formatos disponíveis

NOTACIN DE

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

El presente material consta de cuatro unidades: Unidad I: ENFOQUE: BUSINESS

MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN

Es recomendable que el estudiante desarrolle una permanente lectura de estudio junto a la

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Tema N 1: Introduccin al BPM

1.1 Antecedentes de BPM

1.2 Historia y Evolucin

Evolucin de la Ingeniera de Procesos hacia el BPM

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

1.2.1 La ingeniera de procesos nace con Frederick Taylor

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

El cambio del mercado de la oferta al mercado de la demanda

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Tema N 2: Conceptos Bsicos de BPM

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Ejemplo de proceso: Proceso de Elaboracin de calzado artesanal

2.2 Proceso de Negocio

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Cmo se pueden identificar entonces los procesos de negocio?

Los siguientes ejemplos no se pueden clasificar como procesos de negocio.

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Figura Estructura de Cadena de Valor segn Porter

Figura Estructura de procesos de negocio

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

2.4 Gestin tradicional sin BPM

Para conceptualizar y entender la diferencia entre la gestin de y por procesos es importante

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

2.5 Bussiness Process Management (BPM)

Es una metodologa corporativa y disciplina de gestin, cuyo objetivo es mejorar el desempeo

Detallamos otros conceptos de BPM:

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Una definicin ms amplia la encontramos en la gua de referencia de la Asociacin Internacional

Business Process Management (BPM) es un enfoque sistemtico para identificar, levantar,

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Tema N 3: Organizacin y Estructura del BPM

3.1.1 BPM Governance

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Harmon (Harmon, 2007)] discrimina primero entre governance y management, explicando

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

3.1.2 BPM Operacional

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

3.1.3 Gestin de Casos - Case Management

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Ejemplo Gestion de caso Clinica

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

3.1.4 Case Management versus BPM?

La gestin de casos aporta flexibilidad y directrices. Se centra en informacin de casos, no en los

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

3.2 La automatizacin de procesos (BPA)

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Automatizacin de un proceso con un Proceso Engine

3.3 Los participantes en BPM

Asignatura: NOTACION DE PROCESOS DE NEGOCIO

Dueo de Proceso (Process Owner): El dueo de proceso es un miembro de la alta direccin de la

Gestor de Proceso (Process Manager): El gestor del proceso es el responsable en operaciones,

Usuario de Negocio o Ejecutivo de Negocio (Process Participant): Es el que trabaja en