UNIVERSIDAD NACIONAL DEL ALTIPLANO PUNO

FACULTAD DE INGENIERÍA MECÁNICA ELÉCTRICA, ELECTRÓNICA Y SISTEMAS

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

ASIGNATURA: INGIENERIA DE PROCESOS

INGENIERO: JESUS WALTER CORDERO

TRABAJO:

MODELAMIENTO DE PROCESOS

PRESENTADO POR:

Coila Ticona Jehan carlos

PUNO –PERÚ
 PRESENTACIÓN

Notación de Procesos de Negocio es una asignatura que proporciona conocimiento sobre los
fundamentos de Business Process Management, a través de un trasfondo histórico para comprender
mejor la evolución de la ingeniería de procesos. Asimismo se considera los conceptos de
implementación, para conocer y entender las definiciones que facilitan comprender el alcance de BPM,
la segunda parte integra a los modelos de procedimiento el apoyo tecnológico en cada una de las
capas del BPM y finalmente se muestra la notación 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 notación de Business Process Model and Notation
(BPMN), basado en una plataforma de diseño, simulación y automatización de procesos como
representación estándar para las necesidades de una organización.

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

MANAGEMENT (BPM)n presenta conceptos, y principios básicos, la organización y estructura de
BPM. Unidad II: ARQUITECTURA EMPRESARIAL (AE) EN EL CONTEXTO
BUSINESS PROCESS MANAGEMENT BPM presenta conceptos y las relaciones entre estándares
existentes para la gestión empresarial basada en procesos. Unidad III: BUSINESS PROCESS
MANAGEMENT (BPM) Y EL MODELADO BUSINESS PROCESS MODEL AND NOTATION (BPMN
presenta los elementos de notación de Business Process Model and Notation (BPMN). Unidad IV:
AUTOMATIZACIÓN DE PROCESOS CON BUSINESS PROCESS MANAGEMENT (BPMN),
presenta herramientas de simulación y automatización, desarrollados a partir del texto BPM: Business
Process Management Fundamentos y Conceptos de Implementación (HITPASS, Bernard, 2014).
Es recomendable que el estudiante desarrolle una permanente lectura de estudio junto a la
elaboración de los modelos de procesos, así como la investigación en otros textos y vía internet. El
contenido del material se complementará con las lecciones presenciales y a distancia que se
desarrollan en la asignatura.
 UNIDAD I
INTRODUCCION Y DEFINICION DEL BPM

Tema Nº 1: Introducción al BPM

1.1 Antecedentes de BPM

(HITPASS, 2013)
La globalización está demandando mayores exigencias, tanto a las empresas privadas como a las
organizaciones públicas, en su capacidad de reacción 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 común también existen
diferencias, sobre todo en el alcance. Algunos autores y expertos, en especial en Europa, restringen
el BPM a una disciplina de gestión sin incluir explícitamente el apoyo de TI. Otros autores, definen
BPM como el proceso hacia la automatización y operación de los procesos implícitamente con TI.
El concepto de BPM es incluso más 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 cómo enfrentar el proceso hacia el
logro de los objetivos y cada concepto parte por una definición, razón por la cual algunas definiciones
se diferencian de otras. La descripción de los objetivos es clara y bien definida.

1.2 Historia y Evolución

Evolución de la Ingeniería de Procesos hacia el BPM Fuente:

(HITPASS, 2013)
1.2.1 La ingeniería 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
“Administración Científica” (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 especialización y estandarización de los procesos en la producción
industrial elevándolos a una ciencia que podríamos llamar «ingeniería industrial y mejora de
procesos», razón por la cual muchos autores lo denominan como el padre de la ingeniería industrial.
Taylor aporta en métodos de observación de buenas prácticas, de medición del trabajo y a partir de
estos conocimientos de diseñar procesos industriales desagregados hasta el nivel de actividad
manual (Taylor hablaba de «administración de tareas») altamente especializados para lograr
mejoras sustanciales en la productividad.
Los principios de la administración científica que describe Taylor en su obra pueden resumirse según
(Bravo, 2011) en los siguientes cuatro pasos:
1. Desarrollar el estudio científico del trabajo, una “ciencia” según Taylor
2. Seleccionar científicamente al obrero más adecuado a la tarea, según sus capacidades, y luego
instruirlo en cómo hacer correctamente la tarea, según el punto anterior.
3. Cooperar con los obreros para que todo el trabajo sea hecho de acuerdo con los principios
científicos que se aplican. Se refiere a una cooperación de los investigadores y de los
administradores. Armonía es la palabra principal que emplea Taylor.
4. Distribuir equitativamente el trabajo y la responsabilidad entre la administración y los obreros.
Juan Bravo (Bravo, 2011) en su libro indica lo siguiente sobre Taylor:
Podemos resumir que el objetivo que perseguía Taylor al reunir hechos y mediciones era
proporcionar un fundamento científico para diseñar y mejorar los procesos. Con estos fundamentos
pretendía terminar con la improvisación que predominaban en aquella época. En vez de hacer que
cada trabajador hiciera la tarea a su manera, Taylor quería encontrar la forma óptima de hacerla y
estandarizar las buenas prácticas haciéndolas más eficientes y lograr economías de escala. Este
enfoque fue empleado con éxito durante toda la época de la industrialización (mercado de la oferta)
durante el siglo XIX y principios del siglo XX, pero esta técnica estaba restringida a los procesos
manuales y a la producción industrial y no incluía el seguimiento de los procesos de gestión.
1.2.2 El cambio del mercado de la oferta al mercado de la demanda

(HITPASS, 2013)
Más adelante, a principios de los 80, aparecieron enfoques estadísticos con el objetivo de mejorar
los procesos de control. Así nació el enfoque TQM (Total Quality Management) basado en una
gestión de control estadístico, pero aplicarlo requiere de una rigurosa disciplina en la organización
que es Management) basado en una gestión de control estadístico, pero aplicarlo requiere de una
rigurosa disciplina en la organización que es difícil de alcanzar.
Empresas japonesas, en particular Toyota, reconocieron a principios de los 90 el cambio hacia el
mercado de la demanda y enfocaron la gestión 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 economía
se deduce que la fuerza compradora es más 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 producción y con el encargo de resolver en forma autónoma propuestas de mejora
continua en los procesos de producción. A este sistema de trabajo se le llamó también Lean
Production, indicando en quitarle grasa a las estructuras organizacionales burocráticas y lentas en
sus procesos de decisiones.
Cuando en los años 90 muchas empresas occidentales fueron azotadas por la recesión, debido a
que los mercados habían llegado a una situación de la sobre oferta (saturación, cambio hacia el
mercado de la demanda) y el comienzo de la globalización, aparece el Business Process
Reengineering (BPR, Hammer and Champy, 1993) (Hammer, M. y Champy, J., 1993) como medida
de salvación para deburocratizar las empresas y ser más eficientes en sus procesos de negocios.
1.2.3 La reingeniería de procesos como precursor de BPM

(HITPASS, 2013)
El Business Process Reengineering BPR tiene como finalidad rediseñar y hacer más eficientes
los procesos, atacando las estructuras jerárquicas funcionales y alineándolos con los objetivos del
negocio, buscando alcanzar resultados de desempeño espectaculares a corto plazo. La reingeniería
de procesos se basa y apoya fuertemente en la incorporación de tecnologías de la información,
como elemento clave para la transformación esperada. El BPR es el primer enfoque end to end en
introducir como gestión los procesos de negocios transversales a las organizaciones funcionales,
centrados en las necesidades del cliente y no en los procesos de producción, pero esto no fue fácil,
muchos proyectos de BPR terminaron siendo proyectos de racionalización de recursos con una
fuerte reducción de personal. Perdiendo, muchas veces, la perspectiva de agregación de valor para
el cliente. BPR no fue el único enfoque en aparecer en dichas décadas, a principio de los años 80
apareció Six Sigma como una opción para mejorar la eficacia y eficiencia de los procesos de
negocio. Este enfoque surgió en Motorola Inc. y el caso práctico de aplicación más conocido fue
General Electric en los ’90. Como TQM, Six Sigma se basa en principios estadísticos 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 técnicas 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.
Aún no se puede predecir cómo va a seguir evolucionando Six Sigma, pero a pesar que se detectan
signos de cansancio aún 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 ERP’s (Enterprise Resource Planning). Los ERP’s se vendieron como la solución para
todos los problemas en la organización, pero los ERP’s no generaron la eficiencia y eficacia
esperada en los procesos de negocios, estaban diseñados para mejorar la eficiencia administrativa.
A fines de los años 90 y a principios del 2000 aparecieron los sistemas Customer Relation
Management (CRM) como medida para mejorar los servicios a los clientes, pero aún no contábamos
con una integración entre los procesos del front office (CRM) con los del back office (ERP).
Tema Nº 2: Conceptos Básicos de BPM

2.1 Definición de Proceso

(HITPASS, 2013)
En principio, un proceso corresponde a la representación de un conjunto de acciones (actividades)
que se hacen, bajo ciertas condiciones (reglas) y que puede gatillar o ejecutar cosas (eventos). En
forma genérica se puede definir un proceso como:
«Una concatenación lógica de actividades que cumplen un determinado fin, a través del tiempo y
lugar, impulsadas por eventos.» Esta definición 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í sólo, algo tiene que ocurrir y el proceso reacciona ante el suceso. El proceso debe
cumplir un determinado fin, en las ciencias económicas 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 «acción sobre un objeto», es decir el proceso de transformación
ocurre a través de las actividades en un proceso.
Las actividades en un proceso están encadenadas a través de una secuencia lógica que determinan
en su conjunto las condiciones del negocio.
Estos elementos básicos describen en su conjunto los procesos y están contenidos en la mayoría
de las notaciones para modelarlos, así también en el estándar BPMN. La definición es pura, no dice
nada respecto para qué objetivos se levantan y modelan procesos en una organización.

Ejemplo de proceso: Proceso de Matrícula Universidad

(Fuente: http://www.universidad.continental.edu.pe/sobre-matriculas/)
Ejemplo de proceso: Proceso de Elaboración de calzado artesanal
(Fuente: http://www.ejemplode.com/58-administracion/2438-ejemplo_de_proceso.html)

Paso 1: Selección y adquisición del material.

Paso 2: Selección 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 distribución.

2.2 Proceso de Negocio

(Hammer, M. y Champy, J., 1993) Introducen en su obra de Reingeniería de Procesos en el año 93,
el concepto de proceso de negocio:
«Un proceso de negocio es un conjunto de actividades que toman uno o más 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 definición está ligada
al concepto de creación de valor para el cliente. Siguiendo la definición 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 ejecutándolas
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
características de un proceso de negocio es que es gatillado por el cliente y los resultados de la
ejecución del proceso tienen que volver al cliente, entendiéndose en el sentido más amplio que el
cliente también puede ser interno, por ejemplo un área de negocio o externo un proveedor. En
Ingeniería 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 través 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 (logística). 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 mínimo los procesos de bodegaje
intermedio. Dell por ejemplo se hizo famoso en los años 90 aplicando este concepto al extremo.
Sólo se produce a pedido real (orden de compra) del cliente. Es normal encontrar en muchas
compañías 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 (también se usa mucho el término anglosajón «end
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, producción, bodega, venta, etc. Ningún 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 relación 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 organización 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 abstracción, y justamente éstos no son los procesos de negocio.

¿Cómo se pueden identificar entonces los procesos de negocio?

Para estos efectos se recomienda realizar un análisis del contexto y hacer un listado de todos los
eventos iniciados por el cliente. A continuación se nombran ejemplos de procesos de negocio:
Solicitudes de créditos, préstamos, devoluciones Solicitud de apertura de cuenta bancaria Compra
de pasajes Procesos de reclamaciones Seguimiento de resolución de problemas en Servicio a
Clientes Gestión de Hipotecas, Multas,... Recepción y pago de factura Recepción y confirmación
de orden de compra Elaboración de ofertas

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

Partida doble en contabilidad: • Se trata de una función 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 sería la compra del pasaje.
Ingreso de un nuevo empleado al sistema de RRHH: • Actividad manual del proceso de negocio
«contratación de personal». El cliente interno es el área de negocio, quién gatilla la solicitud de
contratación.
Ingreso de una orden de compra: • Actividad manual del proceso de negocio «compra de un
producto o servicio».
Envío de email: • Actividad técnica sin significado de negocio
Emitir una póliza: • Emitir puede significar imprimir, generar o extender una póliza de seguros, pero
de todas formas el proceso de negocio sería la «solicitud de un contrato de seguros»
 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 típica estructuración de una cadena de valor descompuesta en procesos de dirección,
procesos primarios y procesos de soporte, siendo los procesos primarios los procesos de la
«cadena de valor» porque están directamente relacionados con la creación 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 según 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

FUENTE: (HITPASS, 2013)

La cadena de valor muestra las dependencias en los pasos de producción, mientras que los procesos
de negocio muestran las dependencias de las políticas de negocio para atender las peticiones de los
clientes y llevarlos a un resultado satisfactorio que tiene una expresión de mercado, es decir el cliente
está dispuesto a pagar (creación de valor).
2.3 ¿Gestión de o por procesos de negocio?

Actualmente es muy utilizado ambos términos tanto Gestión por procesos como Gestión de
procesos, y es importante saber si existe diferencia entre ambos términos:

(HITPASS, 2013)
En una organización existen muchos procesos de negocio. Si nos referimos a gestionar un proceso
en particular hablamos de «gestión de proceso».
Generalmente el primer objetivo en las organizaciones es lograr un mayor control y desempeño
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 cuáles procesos
se encuentran estancados por alguna razón.
Esta información 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 desempeño de los procesos, por ejemplo acortar los tiempos de ciclo y en general mejorar
el grado de satisfacción de cliente.
Al introducir «gestión de procesos» en una organización tenemos la posibilidad de mejorar el grado
de cumplimiento de objetivos funcionales, pero no es un instrumento suficiente para alinear la
gestión de procesos con la estrategia de la organización y sus debidos objetivos de negocio.
La gestión de procesos se focaliza en medir y analizar el desempeño de los procesos en
operaciones, pero no incluye los conceptos de alineamiento con otras capas de la organización, por
ejemplo la integración a los procesos de alineamiento con la estrategia y la capa de tecnología.
Gestión por procesos significa incluir los procesos de planificación y alineamiento a la gestión de
procesos.
Entre académicos y profesionales de BPM es ampliamente conocido el principio que «los procesos
deben seguir la estrategia» y que «la tecnología debe seguir a los procesos ».
Gestión de procesos no incluye estos ciclos de planificación y de alineamiento a los procesos como
lo pide la disciplina de gestión BPM, pero si ampliamos el concepto de gestión e integramos las otras
disciplinas empresariales a la gestión de procesos, entonces hablamos de «gestión por procesos»
y en su definición más amplia en inglés de Business Process Management (BPM).

En la gestión de procesos nos centramos en el resultado de cada proceso y las acciones a realizar
(mejora continua, reingeniería o innovación).
Identificación de los procesos y planificación de los Objetivos a conseguir con cada proceso. (Fase
de Modelización y Planificación de Procesos)
Medición de los resultados de los indicadores en la ejecución o funcionamiento de los procesos
(Fases de Automatización y Ejecución de Procesos)
Control de la consecución de los indicadores al compararlos con los objetivos y definición de
acciones correctoras (Fase de Monitorización)
En la Gestión Por Procesos nos centramos en la alineación de la gestión de procesos con la estrategia
empresarial y con el resto de gestiones empresariales:
La gestión DE procesos para que cada proceso produzca el resultado esperado
La alineación de cada proceso con la Estrategia Empresarial, de esta forma sabremos qué aporta
cada proceso a cada objetivo estratégico, y definido un objetivo estratégico a qué procesos afecta y
si es necesario optimizarlos
La cultura de la empresa será coherente con un sistema de gestión de procesos
La gestión y dirección del personal se realizará con enfoque a procesos
Las diferentes gestiones de la empresa se alinearán con la gestión por procesos
Fuente: http://pedrorobledobpm.blogspot.com/2014/07/gestion-de-procesos-versus-gestion-por.html
2.4 Gestión tradicional sin BPM

Para conceptualizar y entender la diferencia entre la gestión de y por procesos es importante realizar
una retrospectiva, y saber cómo funcionaba una organización sin BPM.

(HITPASS, 2013)
Para responder a esta pregunta fundamental vamos a analizar primero cómo funciona la gestión
tradicional centrada en consolidar planes de negocio por área y no por procesos de negocio que son
transversales a la organización.
Por lo general, la formulación 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 misión de la empresa
y los objetivos de negocio que se formulan a través del ciclo presupuestario en un año comercial,
pero la estrategia es transversal a las áreas de negocio, igual que los procesos de negocio. Aquí
nos encontramos en la gestión empresarial tradicional con la primera brecha.

De alguna forma se traspasan los objetivos de negocio desde la alta dirección a la capa de
operaciones y a su vez operaciones formula, por medio de una especificación, los requerimientos
de cambio a la capa de tecnología, pero este proceso no está estandarizado y menos integrado bajo
una metodología común. Al no estar estandarizado ni integrado ocurren fricciones y por lo tanto
pérdida 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 pérdida de valor en tres grandes ámbitos de la gestión
empresarial tradicional, a saber:
1. Cómo plasmar la estrategia en la organización
2. Cómo lograr que los procesos se implementen con tecnología
3. Pérdida de valor en la estructuración misma de los procesos
Estas son las tres grandes razones (oportunidades) para implementar gestión por BPM. El aporte
del concepto de BPM como disciplina integrada es cerrar estas brechas.
2.5 Bussiness Process Management (BPM)

Es una metodología corporativa y disciplina de gestión, cuyo objetivo es mejorar el desempeño

(eficiencia y eficacia) y la optimización de los procesos de negocio de una organización, a través
de la gestión de los procesos que se deben diseñar, modelar, organizar, documentar y optimizar
de forma continua. Por lo tanto, puede ser descrito como un proceso de optimización de procesos.
El modelo de administración por procesos, se refiere al cambio operacional de la empresa, al
migrar de una operación funcional a una operación administrada por procesos.
El BPM es el entendimiento, visibilidad y control de los procesos de negocio de una organización.
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 deberían estar documentados (actualizados), para ayudar a entender a la organización
que están haciendo a través de su negocio.

Detallamos otros conceptos de BPM:

(John Jeston & Johan Nelis, 2008): «BPM es el logro de los objetivos empresariales a través de la
mejora, la gestión y el control de los procesos de negocio.»
En esta definición, se abstrae explícitamente, que la tecnología va a solucionar los problemas a las
organizaciones.

Paul Harmon (Harmon, 2007) también define BPM como: «Una disciplina de gestión focalizada en
la mejora del rendimiento corporativo por medio de la gestión por procesos de negocio.»

Finalmente Jeston y Nelis (John Jeston & Johan Nelis, 2008) concluyen, BPM es:
Más que sólo software, más que solo la mejora o la reingeniería de los procesos, no es solamente
una moda, es parte integral del management, más que sólo levantamiento y modelado de procesos,
también es la implementación y ejecución de los procesos, los cuales requieren ser analizados y
mejorados.
Factores críticos del BPM según Jeston y Nelis:
 El logro de la estrategia organizacional
 La organización está alineada con los procesos end to end
 Los objetivos están alineados con la estrategia organizacional
 Los procesos deben mejorar en su eficiencia y ser eficaces Gestión orientada a procesos
(Management)
 Controlar el ciclo completo de BPM
 Seleccionar los procesos críticos, no todos los procesos contribuyen al logro de los objetivos
estratégicos

Implementar BPM tiene que tener impacto en los beneficios del negocio Nuestra definición tiene un
alcance amplio y abarca tanto la disciplina de gestión como la incorporación de TI para la
automatización de los procesos.

Definimos en forma abreviada BPM como: «Disciplina de Gestión por Procesos de Negocio y de
Mejora Continua apoyada fuertemente por las Tecnologías de la Información»

Una definición más amplia la encontramos en la guía de referencia de la Asociación 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 sistemático para identificar, levantar,

documentar, diseñar, ejecutar, medir y controlar tanto los procesos manuales como automatizados,
con la finalidad de lograr a través de sus resultados en forma consistente los objetivos de negocio
que se encuentran alineados con la estrategia de la organización. 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 definición de la ABPMP, BPM es una disciplina integradora
que engloba técnicas y otras disciplinas organizacionales, que abarca las capas de negocio y
tecnología, que se comprende como un todo integrado en gestión a través de los procesos. Nos
inclinamos por esta definición porque diferencia entre procesos manuales y automatizados, pero
integra ambos casos a la disciplina de BPM. Con esta definición pretendemos lograr un
entendimiento común que es necesario para tener éxito en introducir BPM en una organización. 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.
Tema Nº 3: Organización y Estructura del BPM

3.1 Conceptos de Gestión en BPM

BPM ataca la automatización de procesos por toda la empresa, pero con total adherencia a las
modificaciones de negocios que un mercado de fuerte competición exige. No existe una combinación
única y exacta de los procesos, metodologías e indicadores, y en muchos casos estos existen
aisladamente.
Una herramienta de BPM debe soportar las actividades básicas de la gestión, que pueden ser
resumidas en:
• Definir una estrategia para conducir el performance;
• Traducir la estrategia en objetivos, indicadores y metas;
• Acompañar el progreso en relación 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 más eficiencia. Estos sistemas
dan al usuario más control sobre la automatización de procesos, lo que alivia el trabajo de la
informática. El BPM impone a la empresa un desafío muy grande, pues obliga el usuario a dos
acciones que, casi siempre, a él no le gusta hacer: repensar en las tareas del día-a-día y, al menos
en la fase de implementación, trabajar lado a lado con el personal de informática.

(HITPASS, 2013)
BPM como disciplina de gestión orientada a procesos abarca dos grandes áreas de la gestión
empresarial: BPM Governance y BPM Operacional.

3.1.1 BPM Governance

(HITPASS, 2013)
BPM Governance, también llamado gobierno corporativo, como un modelo de gestión
corporativo orientado a procesos, pero integrado con todas las capas de una organización
(capa de dirección, operacional y de tecnología), las fases del ciclo de gestión, la gestión del cambio
de nuevos requerimientos (en inglés: 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 gestión organizacional desde la
planificación y gestión estratégica, la definición de planes de negocio, el ciclo presupuestario, la
definición de perfiles y cargos, la gestión en operaciones, apoyo tecnológico hasta el alineamiento
con el portafolio de proyectos corporativo.
(Harmon, 2007) En la literatura se encuentran varias definiciones de BPM Governance, (John Jeston
& Johan Nelis, 2008), la mayoría de ellas muy amplias pero todas coinciden que se trata de un
concepto definido para una organización de cómo debe aplicarse «Gestión 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 organización del «management». Resumiendo a su entender cuando
hablamos de governance nos referimos a un modelo específico de gestión, mientras que
«gestión» es una actividad humana.

Para Jeston y (John Jeston & Johan Nelis, 2008)(pags. 323-324) en un modelo de BPM Governance
son clave la definición de roles y responsabilidades, los procesos de alineamiento con la estrategia
de la empresa, el control de gestión orientado a procesos y finalmente la estandarización de los
procesos de gestión.

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
3.1.2 BPM Operacional

(HITPASS, 2013)El BPM Operacional abarca la gestión del ciclo BPM por proceso y no los
mecanismos de alineamiento con las otras capas de la organización 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 rediseñarse. Se debe introducir un nuevo proceso, no existente en la organización.

En la fase de «Levantamiento del Proceso » primero se debe recoger la información sobre cómo

está organizado el flujo de trabajo. Esto se realiza con la ayuda de técnicas de moderación, talleres,
entrevistas, recolección de documentación, 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 información que lo apoyan
En la etapa de «Documentación del Proceso» el conocimiento adquirido en la etapa de
levantamiento se documenta en un modelo de procesos que refleja la situación actual. La
documentación resultante comprende los diagramas de los flujos, fichas de descripción, políticas de
negocio y procedimientos que se utilizan para ejecutar el trabajo.
Las debilidades identificadas en la fase de «Análisis de mejora» o las desviaciones que muestra el
«Monitoreo del Proceso» son por lo general el punto de partida para un rediseño de procesos.
Eventualmente, se pueden evaluar diferentes variantes o escenarios con ayuda de simuladores.
Esto aplica también si se está diseñando un proceso nuevo. En ambos casos el resultado o
entregable es un modelo de procesos deseado (To be).

La etapa de «Implementación del Proceso» abarca tanto la implementación técnica como también
las adaptaciones organizacionales que se requieren. La gestión del cambio (en inglés: Change
Management) y la estrategia de comunicación constituyen elementos fundamentales a considerar
para el éxito del proyecto. El modelo técnico puede implementarse por medio de una Suite de BPM
(en inglés: Business Process Management Suite, BPMS) o a través de un clásico desarrollo de
software. El resultado final de la implementación técnica del proceso es la situación actual (As is)
automatizada y documentada, corresponde con el modelo de proceso deseado (To be).

Las fases desde el «Levantamiento del Proceso» hasta la «Implementación del Proceso» se
administran por lo general por medio de la organización de un proyecto, mientras que el
«Monitoreo del Proceso» (inglés: Process Controlling) se concibe como un proceso continuo y forma
parte de todas las operaciones. Las actividades más importantes de «Monitoreo del Proceso» son
el control constante de las operaciones (técnicamente hablamos del control de instancias de los
procesos reales) y su respectiva evaluación de los indicadores. De acuerdo a la escuela de BPM, si
se detectan problemas puntuales debieran corregirse de inmediato o en línea. Si hay recursos
disponibles es posible solucionar problemas estructurales sin necesidad de formular un proyecto,
pero si sus causas no están claras o son complejas, se hace necesario planificar e implementar un
proyecto de mejora y rediseño. La decisión sobre si es necesario formular un proyecto nuevo o
instalar un equipo de trabajo en operaciones, debiera tomarla el responsable del proceso de común
acuerdo con los participantes.

El ciclo BPM muestra en sus principales fases cómo funciona el círculo virtuoso de mejora continua
de los procesos. Para aplicarlo es necesario:

Asignar responsabilidades a los procesos y a cada uno de sus pasos Emplear métodos de análisis
y gestión en él Contar con el apoyo de soluciones adecuadas de TI
Lograr una coordinación fluida entre estas tres componentes es tarea de gestión por procesos (BPM-
Governance). Gestión por procesos se encuentra por sobre cualquier proyecto de modelamiento y
tiene por consiguiente la misión de apoyar la «Gestión de Procesos», para el cumplimiento de los
objetivos estratégicos.
3.1.3 Gestión de Casos - Case Management

La gestión de casos es una forma de avanzar y mejorar la atención 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
finalización no está limitado a una secuencia del proceso como lo entendemos normalmente, de
principio a fin, aunque con una lógica compleja de anidación 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, tomarán esta
decisión. Las "reglas", por así decirlo, son conocimiento experto de los usuarios. En la literatura
también se habla de «adaptive case management (ACM) o dynamic case management», en donde
se argumenta que el foco se centra más en el tratamiento del caso que en el proceso mismo
[Lamont12].
Por ejemplo en un hospital toda la atención se centra en el paciente y el caso es lo que está
sucediendo con él. Los procesos clínicos apoyan la atención del caso, pero el médico o el equipo
médico decide qué procesos de diagnóstico o de apoyo terapéutico se van a emplear y cuándo
recurrir a ellos. El caso específico determina la secuencia. Sin embargo, en la industria de la salud
a medida que ha aumentado el conocimiento se han desarrollado guías de práctica clínica que
orientan la toma de decisiones por parte del equipo de salud, facilitando la estandarización de los
procesos clínicos. En algunos tratamientos, hoy en día lo normal es encontrarse con un proceso
conocido de principio a fin. En todo caso, el mismo proceso debe considerar en sus reglas la opción
de no continuar con el flujo estandarizado.

La gestión de casos no suele trabajar por la carpeta de enrutamiento del caso a la siguiente tarea
de forma secuencial en la línea. En su lugar, los avances son a través 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 realización de las tareas de los demás casos, o el vencimiento de los plazos de trabajo.
Así, de un flujo determinado, el modelo conceptual de un caso es una colección 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 típicas áreas en donde nos encontramos procesos del tipo de «gestión de casos» son:
Área salud
Trabajo social
Soporte
Educación
Proyectos que inducen al cambio
Exploraciones mineras

En general todos los negocios que requieren de conocimiento experto que aún no han alcanzo un
nivel de estandarización ¿Cuáles son las funcionalidades específicas que se requieren para apoyar
tecnológicamente la gestión de casos en el contexto de BPM? Tomando en consideración las
principales características que tiene la gestión de casos se requiere:
Derivación del caso a otros especialistas
Decisiones grupales Gestión de contenidos
Administración de documentos
Funcionalidades de búsqueda y filtros
Configuración de atributos
Adjudicación de recursos

Ejemplo Gestion de caso – Clinica

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

(HITPASS, 2013)
Luego de revisar las características distintivas de ambos enfoques, podemos indicar que, BPM
normalmente se focaliza en procesos repetitivos con flujos muy estrictos. La abstracción necesaria
debe gestionar tareas más complejas. Por su parte, la gestión 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 gestión de casos, permiten ir identificando patrones respecto a las
acciones, pero dada la naturaleza de la gestión de casos, no debiese estructurarse, pero es posible
generar manuales o guías de ejecución.

La gestión de casos aporta flexibilidad y directrices. Se centra en información de casos, no en los

procesos determinados. Un caso recoge toda la información necesaria para gestionarlo: los actores
(usuarios/ roles que participan en el caso), datos/ contenido, reglas y, por supuesto, procesos y
tareas. La gestión de casos habilita a los trabajadores calificados dándoles la posibilidad de tomar
decisiones dentro de las restricciones de las estrategias de negocio. La gestión de casos define
negocios y objetivos realizables, y los comunica de forma transparente mientras que los propios
usuarios añaden 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 progresión predecible y repetitiva, se mueven de un estado
menos ordenado a otro más ordenado por medio de la acción del usuario. Las decisiones tomadas
por los usuarios son compartidas al ser almacenadas en plantillas y están disponibles para otros
actores de la compañía como acciones propuestas. Este es el caso de lo que se llama ficha clínica
ú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 «gestión de un proceso de casos».

Fuente: http://www.slideshare.net/oracle_imc_team/webcast-bpm11g-ps6lukasz
3.2 La automatización de procesos (BPA)

Implica la utilización de sistemas tecnológicos para automatizar las actividades y/o servicios de una
función o unidad de negocio determinada. De esta manera, procesos de negocio tales como los que
desempeñan las áreas de ventas, administración, operaciones, abastecimiento y distribución,
cobranzas, recursos humanos o TI pueden ser automatizados mediante la utilización de paquetes
informáticos especializados para desarrollar tal función. 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 operación.

(HITPASS, 2013)
Para entender que puede abarcar la automatización, se va a describir primero un proceso simple de
solicitud de crédito organizado en forma manual y luego se va a describir como hoy en día se
automatizan (implementan técnicamente) este tipo de procesos.
El proceso se inicia cuando se hace ingreso de una solicitud de crédito 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 análisis de riesgo. Si el índice de riesgo
es positivo o aceptable, ingresa los datos de la solicitud en un sistema de crédito financiero y luego
envía la solicitud evaluada a su superior para que la apruebe. La automatización de este proceso
podría resultar de la siguiente forma: El arribo de la solicitud de crédito por correo, se digitaliza y vía
un programa de OCR (Optical Character Recognition ó reconocimiento de texto automático) se
extraen ciertas variables del formulario y se ingresan a un sistema de evaluación de crédito. Luego
se crea un documento electrónico que gatilla la creación 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 crédito en el Process Engine, la revisa formalmente y luego el Process Engine por
medio de un servicio web invoca el sistema de análisis de riesgo enviándole (técnicamente se
traspasan las variables) la información correspondiente. Si el resultado del análisis es positivo, el
Process Engine deriva automáticamente la solicitud de aprobación a su superior, ingresando los
datos en el sistema de crédito financiero por medio de un servicio web y depositándolo en la bandeja
de entrada de él para su debida aprobación. Podríamos discutir si este proceso podría ser mejorado,
pero este caso describe la diferencia entre un proceso manual y uno automatizado:

El Process Engine controla el proceso, a través 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 (Orquestación de
servicios).
Las decisiones sobre qué tipo de actividades o servicios deben invocarse, las toma el Process
Engine a través de la lógica técnica implementada (modelo de procesos técnico) y los puntos de
intervención de los usuarios. Dicho de otra forma, no siempre la lógica del proceso implementada
es mandatoria, en ciertas circunstancias puede ser influenciada por los participantes del proceso,
con la salvedad que debe quedar todo registrado.

Automatización de un proceso con un Proceso Engine

FUENTE: (HITPASS, 2013)

3.3 Los participantes en BPM

(HITPASS, 2013)
Si admitimos que BPM como disciplina de gestión integrada abarca todas las capas de una
organización desde la alta dirección hasta la tecnología 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 continuación debieran estar presente de alguna forma
en proyectos, gestión 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
también cuentan con roles bien definidos y estructuras orientadas a procesos. En el capítulo 9 se
va describir como se insertan estos roles en estructuras organizacionales orientadas a procesos.
Dueño de Proceso (Process Owner): El dueño de proceso es un miembro de la alta dirección de la
empresa y responsable de una línea 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 interés de todos los participantes en promover BPM
como un instrumento de gestión.

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

reporta directamente al dueño de proceso y es él quien normalmente impulsa las propuestas de
mejora. Él es responsable de mantener la comunicación con los clientes y/ o proveedores.
Normalmente al gestor de proceso lo encontramos inserto en un nivel de jerarquía 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 mayoría de las organizaciones
son usuarios de un área funcional, como ventas, finanzas o logística. En estos casos no existe un
gestor de proceso o actúa 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 común, 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 intersección.

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 técnica de
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 informática de la empresa. En muy pocas ocasiones
será el responsable de la implementación de los procesos, a pesar que posee buenos conocimientos
o una gran afinidad con las tecnologías de la información. El analista de procesos debiera de tener
una gran habilidad en materias de desarrollo organizacional y técnicas de comunicación. Pero sobre
todo es, como lo indica su rol, un analista. Se espera un gran dominio de la técnica 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 mayoría de los casos
porque les faltan las habilidades para este perfil. La calificación más 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 empatía,
como para poder ponerse en el lugar del cliente y representar sus inquietudes. A ellos no se les
escapa ningún detalle, pero al mismo tiempo poseen un buen sentido de abstracción 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 técnicas del proyecto, como fechas
de entrega y mantención del presupuesto de costos del proyecto, ante aspectos de calidad y
eficiencia. Por esta razón no se aconseja mezclar ambos roles en el sentido que un jefe de proyectos
actúe como analista o vice versa.

Ingeniero de Proceso (Process Engineer): El ingeniero de procesos implementa un modelo técnico

a partir de la especificación y el diseño operacional validado por él y los analistas de procesos. El
diseño técnico debe realizarse en el mismo entorno (process engine o BPMS) en donde se
implementarán los procesos. El ingeniero de procesos está bien capacitado en el entorno de
implementación, configura y construye la solución de BPM en la suite escogida. El ingeniero de
procesos también puede actuar como asesor en la fase de modelamiento de la lógica operacional.

Ingeniero de Desarrollo y Servicios (EAI Developer): Un programador puede asumir el rol de

ingeniero de desarrollo, si la solución requiere de ampliaciones o adaptaciones de desarrollo por
medio de programación (Servicios web, Java, C# u otros lenguajes).

Arquitecto SOA (SOA Architect): El arquitecto SOA es responsable de diseñar una arquitectura de
software que cumpla con los requerimientos técnicofuncionales de los procesos y servicios que se
van a automatizar y orquestar con los sistemas de información. La mayoría de los procesos de
negocio deben integrarse con los sistemas de información del back-office, desarrollar interfaces B2B
e integrar el BPMS a un portal corporativo.
 En empresas y organizaciones de menor tamaño, muchos de estos participantes tendrán que asumir
varios roles a la vez. Los siguientes roles en conjunto podrían por ejemplo asumir los participantes
en empresas Pyme:
Dueño 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 diseñar o modelar procesos, se trata de un proceso de análisis.

Si se está pensando en BPM Governance, se trata de una metodología de gestión.
Si se está pensando realizar un prototipo, se trata de probar un entorno de implementación o de
automatización de procesos.
Y si se está pensando en acortar el ciclo de duración de un proceso, se trata de técnicas de
optimización y control a través de indicadores.

Todos estos objetivos se refieren a diferentes áreas de aplicación en BPM. Cada área de aplicación
es una especialidad en BPM y se apoyan en diferentes conceptos. Entonces difícilmente se va a
encontrar una herramienta universal que cubra todos estos ámbitos; por el contrario sería una
aberración intentar de construir una suite universal para BPM.

(HITPASS, 2013)
Como comparación analicemos un ejemplo práctico: 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 Fórmula 1.

Así es también en BPM, una suite de BPMS no nos va a servir para representar un mapa estratégico
y alinearlos con los procesos de una empresa. Tampoco nos va a servir para describir las políticas
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 análisis y Gobierno Corporativo (BPM Governance)
llamadas plataformas BPA (Business Process Analysis) o también EA (Enterprise Architecture
Tools)
 Herramientas que apoyan la implementación técnica o automatización de los procesos
llamadas BPMS
  Herramientas que apoyan la administración y ejecución 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
gestión en tiempo real, llamadas BAM (Business Activity Monitoring)
 Herramientas que permiten la orquestación de servicios entre los BPMS con cualquier tipo de
sistemas, principalmente los del back office, llamadas SOA Suite Herramientas que permiten
analizar los datos históricos de los procesos ejecutados para detectar desviaciones del
comportamiento deseado o descubrir nuevos patrones. A estos entornos analíticos se les
llaman herramientas de Minería de Procesos o Process Mining Tools en inglés.
 Los expertos de BPM saben que dependiendo de la exigencias o la complejidad de una
organización puede hacerse necesario una descomposición más fina aun, por ejemplo de
separar la capa de presentación 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

FUENTE: (HITPASS, 2013)

La capa de negocio abarca todo el ciclo de planificación, análisis, gestión 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 común, se les denomina en inglés EA (Enterprise Architecture) o BPA (Business
Process Analysis) Tools.
Tema Nº 8: Evolución de Business Process Model and Notation (BPMN)

8.1 Historia de técnicas para modelado de sistemas y procesos

(HITPASS, 2013)
A partir de los años 60 se empezaron a desarrollar técnicas de modelado sobre todo orientadas al
desarrollo de sistemas y la mayoría de éstas, enfocadas al modelamiento de datos y funciones. Lo
que se buscaba encontrar eran vistas de datos normalizadas que debían ser administradas por la
funcionalidad que se requería para el negocio, razón por la cual dominaban las técnicas centradas
en flujos de datos, como lo fue el análisis estructurado (en inglés: Structured Analysis). El método
de análisis estructurado se convirtió en su época en sinónimo del análisis 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
información por medio del método estructurado.

Los analistas deseaban conocer las respuestas a cuatro preguntas especificas: ¿Qué funciones
integran el sistema? ¿Qué datos necesita cada función? ¿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 Análisis Estructurado según Yourdon o Gane y Sarson

Ejemplo de Diagrama de Contexto con IDEF

Ejemplo de Descomposición del Diagrama de Contexto con IDEF

8.2 Clasificación de las técnicas de modelamiento

(HITPASS, 2013)
Formalmente podemos hacer la primera gran división en metodologías basadas en técnicas de
lenguaje estructurado (script) y metodologías basadas en técnicas de diagramación.
Las metodologías basadas en técnicas de diagramación, las podemos clasificar en técnicas
orientadas al flujo de datos, al flujo de control y orientadas al objeto.

Clasificación de algunas técnicas de diagramación para modelamiento de procesos

8.3 Otras Técnicas de Modelado

(HITPASS, 2013)
Antes que apareciera BPMN se difundieron bastante algunas técnicas 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 más detallado que describen el flujo entre
actividades y unidades organizacionales).
Ejemplo de Use Case de UML

Ejemplo de Activity Diagrama de UML

8.4 Business Process Model and Notation (BPMN)

(HITPASS, 2013)
La primera versión 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.
Desde un principio, el principal objetivo fue disponibilizar una notación gráfica, estandarizada, que
permitiera automatizar los procesos a partir del diseño gráfico. En el año 2005 fue trasladado el
proyecto a la Object Management Group (OMG ), debido a que el BPMI no era un instituto que
administra estándares. La OMG es muy conocida en el mundo informático porque administra,
entre otros, el estándar del lenguaje para el diseño de software llamado Unified Modeling
Langauge (UML). A través de la OMG, de la cual son miembros la mayoría de los proveedores
más importantes de TI, BPMN se difundió rápidamente a nivel mundial y casi todos los
proveedores sean grandes o pequeños, académicos o consultores empezaron a adoptar este
estándar. La última versión oficial 1.2 fue publicada en enero 2009 [OMG09]. La versión 2.0,
completamente nueva y ampliada, se terminó a mediados del año 2010 y a finales de éste, el
equipo de la OMG encargado de revisar y finalizar la nueva versión, llamada Finalization Task
Force (FTF), dio la recomendación al gremio de decisión de oficializar la versión 2.0. A partir de la
versión 2.0 la sigla BPMN cambia levemente de nombre a: Business Process Model and Notation.
Paradojalmente hasta la versión 1.2 no se podían mapear los modelos directamente en un entorno
técnico, porque aún no estaban definidos los atributos técnicos. Debido a esta falencia existieron
muchos problemas en convertir (mapear) los modelos a lenguajes de ejecución como BPEL.
Recién con la versión 2.0 existe un metamodelo que permite ejecutar directamente los modelos de
BPMN. Estos dos hechos importantes de la nueva versión, es decir estandarización y habilidad de
ejecución directa conlleva a los siguientes beneficios:
Al 2011 existen más de 70 herramientas de modelación de BPMN (tendencia en aumento) y muchas
de ellas se pueden adquirir gratis. La comunicación con otros socios de negocio que hayan
aprendido BPMN (clientes, consultores, proveedores, etc.) será más rápida, fluida y expresiva. Se
puede esperar que nuevo personal traiga el conocimiento de BPMN.
Institutos de capacitación, universidades y empresas consultoras van a invertir recursos para formar
profesionales en esta notación. Empresas privadas van a desarrollar soluciones basadas en este
estándar, y proveedores de tecnología se encuentran desarrollando herramientas para ejecutar
directamente el código gráfico de BPMN.

Fuente: http://bpmn-bayard.blogspot.com/2011/03/5-historia-del-bpmn.html
Tema Nº 9: Los elementos básicos 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 más modelos de procesos.
Cada modelo constituye la descripción de un proceso.
Instancia de proceso: Se entiende un proceso concreto en la realidad, es decir casos reales como
por ejemplo la reclamación de un cliente crea una instancia del proceso de reclamaciones. Algunos
procesos se instancian sólo un par de veces al año y otros más a menudo.
Token (marca): Se utiliza para visualizar y probar el comportamiento de los procesos diseñados.
Las marcas recorren en forma de una animación la lógica por los flujos normales y los de excepción.
Correlación: Seguramente usted ha recibido muchas veces correspondencia de instituciones que
contienen un número de referencia, número de acta, número de ticket, etc.. Si usted responde a la
institución tiene que indicar esta referencia para que pueda ser identificada. A esta asignación en
forma de un identificador se le llama correlación. Un caso siempre debe estar bien correlacionado
para que no ocurran errores o pérdidas de datos.

9.2 Categorías de los elementos de BPMN

Los elementos gráficos en BPMN se encuentran clasificados dentro de 4 categorías:

Fuente: http://bpmn-bayard.blogspot.com/2011/05/8-fundamentos-de-bpmn_28.html
9.3 Actividades

Es cualquier trabajo que realiza la organización. Pueden ser atómicas 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 versión BPMN 1.2 no existía una simbología reservada para diferenciar los tipos de
actividades. Esta falencia se superó a partir de BPMN 2.0, dando a las actividades indefinidas una
simbología en su respresentación.

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 físico
El aclarar por teléfono una factura mal emitida
La conversación de un ejecutivo con su cliente

b. Actividad Usuario
También 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
c. Actividad Servicio
Es una actividad automática que es ejecutada completamente por algún 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 integración de aplicaciones, con lo cual tenemos por esta vía la
entrada al puente con las arquitecturas orientadas al servicio (SOA).

Ejemplo de servicios de integración:

Solicitud de clasificación de riesgo crediticio a un sistema interbancario
Verificación de stock de bodega para una orden de compra
Disponibilidad de asiento para una reserva de pasajes

d. Actividad Enviar y Recibir

La recepción 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 recepción y de esta forma
reemplazar un evento del tipo mensaje al inicio de un proceso, se debe utilizar el símbolo de tipo de
carta con un círculo.
El mismo principio tiene validez para las actividades del tipo envío.
Este tipo de actividades son solamente técnicas y se usan para invocar interfaces asincrónicas de
servicios web en colas de
mensajería (en inglés: message queues), etc., por lo que no se recomienda de usarlas en modelos
de negocio.

e. Actividad Script
Un script es un pequeño 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
implementación.

f. Actividad Regla de Negocio

Este tipo de actividad también es nuevo a partir de BPMN 2.0 y se interpreta de tal forma que sólo
está destinada para ejecutar una regla de negocio, ya sea invocándola a un sistema independiente
(BRMS: Business Rule Management System) o ejecutando un motor de reglas que viene incluido
en el Process Engine.
9.3.2 Propiedades de actividades

A las actividades, podemos marcarlas con ciertas propiedades (marcas), tales como repetitivas
(loop), múltiples (más de una
instancia), o compensación. Estas marcas pueden combinarse con los tipos de actividades,
convirtíendose 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 condición especificada.

También podemos modelar la condición repetitiva con ayuda de Gateways, en combinación con
Gateways o sin ellos.
b. Actividad múltiple
La actividad con propiedad de múltiple ejecuta en forma simultánea la actividad tantas veces como
instancias existan.

c. Actividad de compensación
Esta propiedad se utiliza exclusivamente en el contexto del evento intermedio de compensación y
se relaciona con el evento a través del flujo de asociación y nunca a través 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 comunicación entre dos participantes o entidades (p. ej., una
organización y sus proveedores). El objeto de la comunicación es u n mensaje.
c. Asociaciones
Se utilizan par a vincular Artefactos (d a tos e información) con otros objetos del
diagrama, incluyen do objetos de flujo (Actividades, Eventos y Gateways).
9.5 Actividades globales

A partir de la versión 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 gráficamente de las normales. Sólo las reconocemos al ver la existencia de actividades
invocables que llevan el mismo nombre que las globales, pero tienen una línea de contorno más
gruesa, es decir en negrita.

9.6 Un proceso simple en BPMN

9.7 Flujo de Procesos con Gatewatay

(HITPASS, 2014)
Casi ningún proceso tiene un flujo unifome. En la mayoría de los casos, las instancias recorren
diferentes trayectorias, dependiendo de las condiciones y reglas que apliquen.
9.7.1 Gateway exclusivo de datos (XOR)

La compuerta en que tenemos que tomar la decisión 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 decisión la tomamos de acuerdo a la información recibida y la compuerta permite

recorrer sólo una alternativa.

La posibilidad que tenemos de utilizar el XOR-Gateway como elemento de bifurcación (XOR-Split)

o unión (XOR-Join) puede que al principiante lo confunda.
La notación permite incluso usar el XOR-Gateway como una unión de entrada y bifurcador de
salida con un sólo símbolo.

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. (análisis de indicadores de
tiempo de ciclo)
Podríamos pensar en paralelizar la preparación 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 simultánea, pero pueden comenzar cuando la condición se de.
Con la instancia del proceso se crea simultáneamente 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
preparación 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 días). A pesar que el primer token se consume luego de 30 días, el segundo token aún
está activo durante 15 días más en la actividad 2.
9.7.3 Gateway inclusivo de datos (OR)

Con un OR-Gateway podemos formular una situación 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 más 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 sólo pasta.
Comemos sólo steaks.
Comemos sólo ensalada.
Comemos pasta y ensalada
Comemos steak y ensalada.
Comemos pasta y steaks.
Comemos pasta, steaks y ensalada.
El flujo por defecto

Nos protege ante situaciones indeseadas. Primero se contemplan todos los flujos salientes con
sentido de negocio; sólo si ninguna de las opciones anteriores es válida se emplea el flujo por
defecto.

9.7.4 Gateway complejo

Se utiliza cuando un caso de negocio no se puede representar con ningún otro Gateway.
Se da en un punto del proceso donde aparecen varios caminos y solo uno de ellos es válido.
Esta decisión esta basada en la información registrada en Metadata.
En el ejemplo, en el momento de tomar la decisión, por cualquiera de ambas alternativas, pedimos
la pizza y desechamos la otra opción.

Vamos a suponer que vamos a ejecutar cuatro actividades en forma simultánea. La quinta actividad
debe ejecutarse apenas se disponga del resultado de tres actividades, independiente de algún orden
correlativo. Este tipo de comportamiento de sincronización se puede representar con un Gateway
complejo, agregándole si la condición en forma de un artefacto del tipo comentario.
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 razón 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 inglés: 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 continúa, una actividad o un subproceso que se
encuentra en ejecución es interrumpida o cancelada, durante la ejecución 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 actúa como gatillador de nuevos eventos.
Eventos del tipo disparador: pueden crearse durante el proceso, o al final del proceso (eventos de
término).

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 también 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
se les llama «sobrepuestos» (en inglés: 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 ejecución de la actividad 1, esta se interrumpe inmediatamente y
el token sigue su flujo en la actividad 3 (caso de excepción). 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, después que se haya ejecutado la actividad 1, el suceso no impacta en el
proceso.

En BPMN hasta la versión 1.2 los eventos sobrepuestos (a excepción de los eventos del tipo de
compensación), siempre cancelan la actividad en ejecución. Este comportamiento no siempre refleja
la realidad, por lo que en la versión 2.0 se introdujo un nuevo símbolo: un evento intermedio
sobrepuesto, pero del tipo «no interrupción».
El token inicia la actividad 1. Si sucede el evento 1, durante la ejecución 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 también 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, después que se haya ejecutado la actividad 1, el suceso no impacta en el
proceso.

9.8.1 Evento de Mensaje

Eventos que portan información (no se restringe a ciertos portadores de información como cartas,
emails o llamadas, sino a cualquier objeto que porte información: orden de compra, guía de
despacho, boleta o factura.)
Ejemplo:

O también:

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 algún error. Es posible que el cliente se haya
equivocado y el problema lo tenga él, porque en algún instante se le haya
caído internet. Él llama nuevamente para que no nos preocupemos. Este llamado entra al proceso
como un evento de mensaje del tipo interrupción, al ocurrir todas las demás actividades se cancelan
y el flujo sigue a la actividad asignada por el evento de interrupción.

9.8.2 Evento de tiempo

También llamado temporizador, se utiliza cuando una condición 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 relación 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 período de tiempo haya transcurrido, se haya alcanzado un tiempo, que se
encuentre en relación a otro evento.
Un evento de tiempo no puede ser impulsado por un proceso, porque sobre el tiempo no tenemos
influencia, razón por la cual este evento existe sólo en forma de «evento de captura».

Muy a menudo se utiliza el temporizador sobrepuesto como «timeout», tiempo máximo permitido
para la ejecución de una actividad.

También 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, razón por la cual sólo se puede
modelar como evento intermedio sobrepuesto y que además requiere de un tratamiento excepcional.
Como tipo disparador sólo 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.
9.8.4 Evento Condicional

Un proceso puede iniciarse o continuar bajo «ciertas condiciones». La condición debe ocurrir en
forma independiente del proceso.
Este evento es junto al evento de tiempo el único tipo que sólo existe en forma de evento de captura.

9.8.5 Evento de señal

Tienen un cierto parecido con los de mensajes, razón 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 dirección a quién se dirige y una llamada telefónica indica un número identificador,
mientras que una señal es un mensaje con destino indefinido. Un anuncio en el diario, un reclame
en la televisión, o un llamado de emergencia por radio son ejemplos de señales.
Cualquiera persona o sistema que capte la señal puede reaccionar si es que quiere.

El ejemplo que al ver un comercial en la televisión nos abrió el apetito de probar la pizza tras el
anuncio. Entonces llamamos y hacemos el pedido de la pizza (reacción a la señal), pero sólo la
comemos cuando tengamos deseo de probarla (evento de condición). Luego evaluamos si nos gustó
la pizza en un sitio web de gourmes. Es decir, también los comensales envían una señal (destino
indefinido) al evaluar la pizza en un sitio público.
9.8.6 Evento de término

El evento terminador luego de consumir todos los tokens activos se encarga también de finalizar la
instancia del proceso. Como consecuencia este evento especial sólo 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 conexión

Conexión o de vínculo (en inglés: link) es un evento técnico, no tiene ningún significado de negocio.
El evento no tiene otra finalidad que poder dividir diagramas muy grandes, sin perder el vínculo de
un flujo de secuencia.

9.8.8 Evento de compensación

Compensar en BPMN significa volver al estado inicial de una actividad.

En la práctica utilizamos el evento de compensación sólo en el contexto de transacciones que tienen
que ser reversadas.
Un ejemplo de un proceso de una persona que desea organizar una salida el día viernes después
de su jornada laboral.
La persona se pone de acuerdo con su pareja después de medio día (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 situación de estar muy cansados, cambiar de parecer y quedarnos en casa
viendo televisión. Entonces tenemos que cancelar las entradas o llamar a los amigos para
manifestarles que no habrá salida.

9.8.9 Evento Múltiple

Con el evento múltiple podemos incluir la captura de varios eventos alternativos con un símbolo.
Si se utiliza como evento de captura, inicia o continúa el proceso, con el sólo hecho de ocurrir uno
o el primero de los eventos posibles.
Como evento del tipo disparador reacciona como un disparador múltiple, 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 diseñar comportamientos especiales, como
es el «evento de Gateway exclusivo basado en eventos (abreviado: Event-Gateway)». Este Gateway
no reacciona ante datos sino a eventos, específicamente al primer evento que suceda.
¿Qué situaciones se pueden dar para utilizar este Event-Gateway? Para este efecto
REVISAR:

1. Evento Múltiple Paralelo

2. Evento de Escalación
3. Evento de Cancelación
4. Evento de Gateway paralelo basado en eventos

9.9 Lane

Aún no hemos visto quién o quienes son los responsables de ejecutar las actividades. BPMN
utiliza carriles llamados «lanes» para la asignación de responsables.

Según las reglas de BPMN, un objeto de flujo (actividad, evento, Gateway) sólo se puede
posicionar dentro de un lane y no entre ellos.
La solución para este escenario, sería crear la actividad tantas veces como personas participan.
9.10 Artefactos

BPMN contiene también una categoría de elementos que sirven para una mejor explicación o
visualización gráfica, pero que de ninguna forma tiene alguna influencia en la lógica 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 coordinación entre participantes en un proceso de negocio, la metodología

de BPMN obliga a separar los pools y la comunicación entre ellos se lleva a cabo a través de flujos
de mensajes. Entonces tendríamos 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 información a través 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
lógica.

Figura 6.9: Flujo de cuatro participantes en pools propios Fuente: [FreRueHit11]

Es posible que el analista no se sienta muy cómodo con este principio de modelamiento porque en
otras técnicas de modelamiento no se interpreta así. En muchas ocasiones no es necesario
separar a todos los participantes para representar una determinada lógica 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 lógica en sus diagramas? El objetivo principal que tienen los autores del BPMN en mente es la
automatización de los procesos a partir de los diagramas.

9.12 Subprocesos

Un subproceso describe en su interior la lógica en detalle, pero en el diagrama del proceso superior
no toma más 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 rectángulo con esquinas
redondeadas. La única característica que los diferencia es un signo más (+) en la actividad del tipo
subproceso, que indica la existencia de una lógica 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 lógica 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.
Tema Nº 10: Diferentes vistas de un proceso

BPMN parte de la base que en un diagrama pueden representarse uno o más 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 lógico, cuya aplicación obedece a las
siguientes reglas:

En un proceso existe un sólo participante (Este principio confunde a menudo al lector)

Este participante posee el control absoluto sobre la lógica del proceso
Otros participantes no pueden influenciar este proceso, en algunas ocasiones ni siquiera saben
cómo está organizado
El participante es por definición el responsable del proceso
Si varios participantes deben interactuar con otros procesos, deben de hacerlo por medio del
intercambio de información (flujo de mensaje), información que lógicamente apoya la operación 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.
Tema Nº 11: Categoría de Procesos

(White 20009)
Des de su descripción, BPMN ha tratado de dar soporte a tres categorías principales de Procesos:
 Orquestación
 Coreografía
 Colaboración
Estos términos han variad o, usualmente con conflictivos significados en los distintos contextos de
negocio en los que son aplicados.

11.1 Orquestación

Los modelos de orquestación tienden a implicar una perspectiva única de coordinación. Por
ejemplo, representan una vista específica del negocio u organización del Proceso.
Como tal, un Proceso de orquestación describe cómo una única entidad de negocio lleva
a cabo las cosas.

Sin embargo, un diagrama BPMN puede contener m ás de una orquestación. En tal caso, cada
orquestación aparece dentro su propio con tenedor llamado Pool.

11.2 Coreografía

Un modelo de proceso de coreografía es una definición del comporta miento esperado (una
clase de contrato procedimientos o protocolo) entre los participantes que interactúa n .
Estos participantes pueden ser roles de negocio generales (por ejemplo, un despachador)
o una entidad específica de negocio (por ejemplo, FedEx como empresa de transporte).

Una coreografía describe las interacciones de los participantes.

Incluye tantos caminos alternativos y paralelos, así como Sub Procesos. De esta man
era, los objetos de flujo (Actividades, Eventos, y Gateways) de los modelos de orquestación
también aplica n a los modelos de coreografía.
Los conectores entre los Pools son el Flujo de Mensajes.

11.3 Colaboración

Mientras que la coreografía muestra el conjunto ordenado (protocolo) de interacciones entre

los participantes.
Un a colaboración puede contener también una coreografía (cuando esté disponible en
BPMN) y una o más orquestaciones .
Una colaboración 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 orquestación (un Proceso), pero no está requerido.
 REFERENCIAS BIBLIOGRÁFICAS

Básica

HITPASS, Bernard, BPM: Business Process Management Fundamentos y

Conceptos de Implementación, Segunda Edición. Chile: Editorial BHH Ltda, 2013.

Complementaria

BERND RUKER, Jakob. Manual de Referencia y Guía Práctica BPMN 2,0. Cuarte
Educion, Chile: Editorial Dimacofi, 2014.Joyanes Aguilar, Luis. Estructura de
Datos. 1ra. ed. España: McGraw-Hill; 2000.

BPMN 2.0, Bizagi Suite [en línea]. [Consulta: 20 de junio de 2015]. Disponible en
Web: https://www.bizagi.com/docs/BPMNbyExampleSPA.pdf

Guía especificación BPMN [en línea], [Consulta: 03 de junio de 2015].Disponible

en Web: http://www.bpmn.org