Diseo de Flujos de Trabajo

Capacidades a desarrollar propuestas para

el curso
1. Utiliza los modelos de procesos como una
herramienta para la mejora continua de los
procesos y para la creacin de mejores
sistemas de informacin
2. Utiliza BPMN para modelar procesos
3. Entiende la diferencia entre los niveles de
modelado descriptivo y analtico
4. Reconoce
la
importancia
de
modelar
adecuadamente los procesos de negocio
5. Reconoce el valor del modelado del proceso
en la gestin por procesos de la organizacin

TEMARIO SESIN 1
Conceptos bsicos de flujo de trabajo y su relacin
con los procesos de negocio.

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 1

Conoce las formas ms usadas de BPMN

Crea modelos bsicos de proceso de negocio

Contenido de la Sesin
Caractersticas de los buenos modelos
Definiciones
Actividades
Procesos
Lgica de procesos
Orquestacin
Niveles de BPMN
Modelado de un proceso bsico
Smbolos para modelos descriptivos (primera parte)
Actividades

Caractersticas de los buenos modelos

Correctos
El diagrama no viola ninguna especificacin de BPMN
Claros
La lgica de proceso no debe ser ambigua
Completos
El diagrama debe indicar como inicia el proceso, sus

estados finales y la comunicacin con las entidades

externas y procesos internos
Consistentes
Ante el mismo conjunto de hechos sobre la lgica de
proceso, todos los modeladores deberan crear ms o
menos el mismo modelo

Qu es un modelo?
Es ms que slo un grfico
Su propsito es transmitir el significado de la lgica

especfica del flujo de actividades desde que el

proceso inicia hasta que termina
La lgica de proceso debe ser entendible para una
persona de negocios, pero tambin semnticamente
precisa para su uso por parte de los desarrolladores
La lgica de proceso es una descripcin de todas las
rutas desde un estado inicial hasta cada uno de sus
posibles estados finales

Actividades
En BPMN una actividad es una accin, una unidad de

trabajo realizado, es el nico elemento de BPMN que

tiene un ejecutor o realizador.
Ms especficamente, una actividad en BPMN es una
accin que se ejecuta repetidamente en el desarrollo de
los negocios
Cada instancia de la actividad representa la misma
accin en una diferente pieza de trabajo.
El modelador debe tener claro el significado de la
instancia de la actividad, tal como una orden, una
solicitud de servicio o una revisin mensual
Una actividad es una accin discreta con un bien
definido inicio y fin

Procesos
En BPMN un proceso es una secuencia de actividades

dirigindose desde un estado inicial de una instancia del

proceso hacia un estado final definido
El inicio del proceso es sealado por un evento
disparador tal como la recepcin de una solicitud
El modelo del proceso es un mapa con todos los
posibles caminos (secuencias de actividades) desde el
evento inicial hasta cualquier estado final exitoso o de
excepcin.
Al igual que las tareas los procesos son discretos no
continuos y son ejecutados repetidamente en el
desarrollo de los negocios
Cada instancia del proceso sigue algn camino en el
modelo de proceso desde el inicio hasta el fin

Lgica de procesos
El modelo de proceso es ms que slo la

documentacin de una instancia del proceso

El modelo no necesita tener todas los rutas que sean
posibles sino los estados y rutas que ocurran con una
frecuencia significativa
La lgica del proceso puede ser definida con la ayuda
de algunas preguntas como:
Cmo el proceso inicia realmente?
Qu evento lo dispara?
Hay ms de una manera en que inicie?
Qu determina cuando est completo el proceso?

Lgica de procesos
Existen diferentes estados finales del proceso como

uno de xito y otros que expresan fallas o abandono?

Cmo el proceso llega de la tarea X a la tarea Y?
El proceso podra eventualmente ir de la tarea X a otra
tarea diferente a Y? Qu reglas gobiernan este flujo?
Cmo sabemos que la tarea X ya fue hecha?
Las respuestas a estas preguntas no son siempre fciles
de obtener, la lgica est oculta, incluso algunas veces en
la cabeza de alguien.
El valor de un diagrama es hacer que la lgica del proceso
sea explcita de modo que los stakeholders la entiendan

Orquestacin
BPMN slo describe procesos en los que la lgica de

procesos es explicita
Cada instancia del proceso debe seguir alguna ruta en
el modelo de proceso.
El trmino tcnico utilizado en BPMN es orquestacin
Cmo la lgica del proceso puede ser definida por
adelantado si el resultado de una Aprobacin no se
puede conocer de antemano?
Cmo el ejecutor decide aprobar o rechazar no es
parte de la lgica del proceso. Esto es parte de la
lgica del paso de Aprobacin. BPMN no describe la
lgica de la tarea, slo la lgica del proceso

Orquestacin
La lgica del proceso dice: Si el paso de Aprobacin

termina en el estado aprobado entonces sigue esta

ruta, si termina en el estado rechazado entonces
sigue esta otra ruta
La ruta tomada por cualquier instancia del proceso
depende de la informacin acumulada por la
instancia dentro de su flujo
Esta informacin incluye
Mensajes recibidos
Datos producidos en las actividades del proceso
Estados finales de las actividades completadas

Orquestacin
BPMN asume que los datos de todas las instancias

estn disponibles para la lgica del proceso

Con esta informacin el proceso sabe como fue
cada paso completado y a que paso debe ir
El modelo del proceso gua de manera inteligente la
instancia a travs de cada paso
Este guiado a travs de los pasos del proceso
ayuda a disminuir la variabilidad de los procesos y
permite su mejora

Niveles de BPMN
Existen tres niveles de modelado en BPMN, que

ayudan a separar las formas y smbolos que sern

usados para crear el modelo, as como el propsito
del modelo y los stakeholders que lo utilizarn:
Nivel 1, llamado descriptivo
Nivel 2, llamado analtico
Nivel 3, llamado ejecutable
Existen otras clasificaciones, pero para los objetivos
de este curso nos enfocaremos en los modelos de
nivel 1 y nivel 2 de esta clasificacin.

Ejercicio de modelado
Proceso de pedidos

Smbolos para modelos descriptivos

Para modelar procesos de nivel 1 son necesarios solo algunas

formas y smbolos, estos han sido creados sobre la base de las

figuras tradicionales de los flujogramas
Esta es la lista de los elementos de la paleta de nivel 1
Actividad: Tarea (None, Usuario, Servicio), Subproceso, Call
Activity
Compuertas: Exclusiva, paralela
Eventos de Inicio: None, Mensaje, Timer
Eventos de fin: None, Mensaje, Terminate
Flujos de secuencia y flujos de mensaje
Pools y lanes
Data object, data store y data association
Documentacin
Artefactos: Text anotation, association y group

Actividades
Una actividad representa una unidad de trabajo

realizado en el proceso. Es siempre representada por

un rectngulo redondeado
Es el nico elemento en BPMN que tiene un ejecutor
Cada actividad o es una tarea o es un subproceso
Una tarea es atmica, vale decir que no tiene subpartes
internas que sean descritas por el modelo de proceso
Las acciones y estados finales posibles de una tarea
son sugeridos por su nombre
Un subproceso si tiene subpartes definidas en el
modelo, estas subpartes se modelan como un proceso
hijo, un flujo de actividades desde un inicio a uno o ms
estados finales

Tarea
Una tarea es representada en el diagrama por la forma

actividad, un rectngulo redondeado con el tipo de tarea

indicado por un pequeo cono en la esquina superior
izquierda
Una tarea representa una accin, no una funcin ni un
estado
El nombre de la tarea debera ser de la forma VERBONOMBRE

Tarea

Fila superior: Tarea de usuario, tarea de servicio, tarea abstracta

Fila inferior: Tarea de envo de mensaje, tarea de recepcin de
mensaje, tarea manual, tarea de script, tarea de regla de negocio

Tarea
Una tarea de usuario representa a una tarea realizada

por una persona

Una tarea de servicio representa a una tarea
automtica, es decir, que al llegar el flujo de secuencia
la tarea se inicia automticamente sin intervencin
humana
Si una persona tan slo hace click a un botn y el resto
es automtico, esto sera una tarea de usuario no una
tarea de servicio
Una tarea abstracta (sin ningn cono) no tiene un tipo
definido

Tarea manual vs. Tarea de usuario

Una tarea manual, slo debera ser usada en procesos

que son o sern automatizados

En este contexto una tarea manual es realizada fuera
del control del motor de procesos
En cambio una tarea de usuario es manejada por el
motor de procesos
Si el proceso no es ejecutable, es decir, no ser
ejecutado por un motor de procesos, el modelo no
debera incluir tareas manuales
En procesos no ejecutables slo deben usarse tareas
de usuario para cualquier tarea hecha por personas

Tarea script vs. Tarea de servicio

Una tarea script debera usarse en procesos

ejecutables
En un proceso no ejecutable una tarea de servicio
representa a cualquier actividad automatizada
En un proceso ejecutable es el proceso el que emite
una peticin de servicio a un sistema externo o entidad
para realizar esta funcin
La implementacin del servicio no es definida por
BPMN, sino por el sistema que lo realiza
Una tarea de script representa a una funcin
automatizada realizada por el mismo motor de procesos
y mediante un pequeo programa, tpicamente en
javascript

Tarea script vs. Tarea de servicio

Debido a que los motores de proceso estn usualmente

muy ocupados ejecutando la lgica de los procesos, no

tienen muchos recursos disponibles para realizar tareas
complejas.
Las tareas de scripts son usadas para procedimientos
sencillos tales como el mapeo de los datos
Si el proceso es no ejecutable no debera incluir tareas
de script, slo deberan usarse tareas de servicio para
cualquier tarea automatizada

Subprocesos
Un subproceso es una actividad compuesta, que

representa a una actividad con subpartes que pueden

ser descritas como un proceso hijo.
Un subproceso puede ser representado de mltiples
formas dentro del diagrama. Un subproceso colapsado
es dibujado en el diagrama padre usando una forma d
actividad de tamao normal con un smbolo + en el
centro de la parte inferior
Un subproceso expandido es dibujado en un diagrama
separado enlazado

Subprocesos

Figura superior: Subproceso colapsado en un diagrama

padre
Figura inferior: Subproceso expandido en un diagrama
separado

Subprocesos
Alternativamente un subproceso expandido puede

aparecer en un diagrama padre como una forma de

actividad agrandada que lo incluye
Un evento de inicio de subproceso debe ser del tipo
None
No se debe usar un evento de inicio de tipo mensaje o
timer en un subproceso
La razn es que el inicio no es disparado por un evento,
siempre es disparado por lo mismo: el arribo del flujo de
secuencia

Subprocesos
Los subprocesos son muy valiosos en BPMN cuando son
diagramados y usados correctamente, su valor se manifiesta:
1.Permite visualizar los procesos de principio a fin

La disciplina de BPM enfatiza la gestin y monitoreo de

procesos de negocio de principio a fin, significando que
de cara al cliente el flujo atraviesa los lmites
tradicionales de las reas de la organizacin

La habilidad para poder ver el proceso de principio a fin

en una pgina ayuda a este objetivo

Desde el proceso padre se puede hacer zoom sobre los

proceso colapsados para expandirlos si es necesario
revisar mayor detalle

Subprocesos
2. Permite el modelado top down o jerrquico

Esto permite empezar desde el diagrama de alto

nivel , en el los subprocesos colapsados
representan los mayores pasos del proceso y
luego adicionar los detalles de cada uno en
diagramas hijo
Tambin sirve para mantener la integridad del
modelo de principio a fin cuando los detalles de un
subproceso no son conocidos

Subprocesos
3.

Permite hacer claros los lmites de gobierno

Los subprocesos facilitan la distribucin de la propiedad

y el gobierno

Los procesos de principio a fin frecuentemente

atraviesan lmites de gobierno dentro de la empresa

Diferentes partes del proceso pueden ser controlados

por diferentes ejecutivos quienes cuidan celosamente
sus reas

Pueden ocurrir problemas cuando los lmites entre las

actividades del proceso son borrosas

En el diagrama padre se describe la interaccin entre

subprocesos gobernados independientemente.

Subprocesos
4. Permite definir el alcance del evento manejador

Los subprocesos son muy tiles para definir los

lmites de un evento manejador
Un evento atachado a un subproceso define un
evento manejador que es iniciado si el evento
disparador ocurre durante cualquier paso del
subproceso

Call Activity

Si un subproceso es usado en ms de un proceso es

mejor definirlo independientemente y llamarlo desde
cada proceso que lo usa
Lo anterior es mejor que incrustarlo repetidamente en
cada proceso que lo llama
El subproceso tiene un borde delgado, mientras que
call activity tiene un borde grueso

TEMARIO SESIN 2
Elementos de la paleta de modelado de
nivel descriptivo

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 2
Utiliza los elementos de BPMN para crear modelos
descriptivos

Contenido de la Sesin
Smbolos para modelos descriptivos (segunda parte)
Compuertas
Eventos de inicio y de fin
Flujos de secuencia y de mensaje
Pools y lanes
Otros elementos
Modelado de un proceso a nivel descriptivo

Compuertas

Una compuerta controla el flujo del proceso,

dividindolo en rutas alternativas
Si no existe una compuerta y el flujo tiene ms de una
ruta el proceso se divide y va por todas las rutas a la
vez
En BPMN a diferencia de los flowcharting, no es
suficiente con ponerle etiquetas que indiquen que ruta
deber ser seguida, es necesario una compuerta para
que el flujo siga una ruta o la otra.

Compuertas

Incorrecto: Las rutas alternativas requieren una

compuerta en BPMN

Compuertas

Correcto: Las rutas alternativas requieren una compuerta

en BPMN

Compuerta Exclusiva

BPMN define varios tipos de compuertas, distinguidas por

el smbolo dentro del rombo
Si el rombo no muestra ningn smbolo se trata de una
compuerta exclusiva y es la compuerta ms comn
El nombre oficial es: exclusive data-based gateway,
tambin se le conoce como compuerta XOR
Exclusiva significa que solo una ruta puede ser tomada
Cuando la compuerta tiene dos salidas, es recomendable
etiquetarla como una pregunta y etiquetar los flujos de
secuencia de salida como SI y NO
Tambin es representada con una X dentro del rombo.

Compuerta exclusiva

Incorrecto: Una compuerta no puede hacer una decisin,

solo examina una condicin de los datos

Compuerta exclusiva

Correcto: La compuerta examina una condicin de los

datos registrados en la tarea Revisar reporte

Compuerta Paralela

Esta compuerta tiene un flujo de secuencia de

entrada y mltiples flujos de secuencia de salida y
divide el flujo y contina en paralelo
incondicionalmente.
Se diferencia de la compuerta exclusiva porque lleva
un smbolo [+] dentro del rombo
Las rutas paralelas pueden ser juntadas ms adelante
en el proceso o pueden conducir a eventos de fin
separados
Flujos de secuencia mltiples pueden salir de un
evento de inicio o de una actividad de manera que
una compuerta paralela es innecesaria en este caso

Compuerta Paralela

Flujo validado con rutas paralelas sin usar compuertas

Compuerta Paralela

Una compuerta paralela con mltiples flujos de entrada y

uno de salida es llamado parallel join o AND-join
Esta compuerta requiere que todos los flujos entrantes
lleguen antes de habilitar el flujo de salida
Una compuerta AND-join puede solo ser usada para
juntar rutas que son incondicionalmente paralelas
A diferencia de la compuerta AND de split, la
compuerta AND-join no puede ser omitida
Si los flujos de secuencia llegan directamente a una
actividad, sin juntarlos previamente, dispararn la actividad
y lo que sigue luego, mltiples veces.
Estas compuertas y sus salidas no se deben etiquetar

Compuerta Paralela

La compuerta es necesaria para juntar los flujos

Evento de inicio

Un evento de inicio es siempre representado con un

crculo con un borde delgado
Su propsito es indicar donde y como un proceso o
subproceso inicia
Normalmente un proceso o subproceso tiene solo un
evento de inicio
En un proceso de alto nivel o proceso padre el cono
dentro del crculo llamado trigger, identifica el tipo de
seal que instancia el proceso
Un subproceso debe tener un evento de inicio None
pues siempre es iniciado por un flujo de secuencia
entrante

Evento de inicio

BPMN 2.0 define siete eventos de inicio, en la paleta

de nivel 1 se incluyen slo cuatro de ellos

Evento de inicio none

Un evento de inicio none no tiene un trigger

En un proceso de alto nivel esto quiere decir que el
disparador del proceso no est especificado o que
debe ser iniciado por un usuario.
Los eventos de inicio none normalmente no son
etiquetados
Un subproceso debe tener un evento de inicio none

Evento de inicio mensaje

Un evento de inicio mensaje, con un cono de sobre

dentro, indica que el proceso es disparado despus
de recibir un mensaje desde fuera del proceso
Esto significa que el proceso es iniciado a peticin de
un requerimiento y que la instancia del proceso
representa el manejo de esta peticin
Este evento debera etiquetarse de la forma: Recibir
(nombre del mensaje)
Tambin debe graficarse el flujo del mensaje y
etiquetarlo con el nombre del mensaje

Evento de inicio timer

Un evento de inicio timer, con un cono de reloj

dentro, indica que el proceso es calendarizado o
programado en base a tiempo
Este evento debera etiquetarse para indicar la
programacin, tal como: Lunes a las 08:00 o el 30 de
cada mes

Evento de inicio mltiple

Un evento de inicio mltiple, con un pentgono

dentro, indica que el proceso podra ser iniciado por
cualquiera de mltiples triggers, como por ejemplo el
Mensaje A o el Mensaje B o por una programacin
semanal
Este evento debera etiquetarse con todos las
posibles condiciones que pueden disparar el proceso

Evento de inicio mltiple

Eventos de inicio alternativos

En algunas ocasiones la actividad inicial del proceso

depende de que disparador fue el que ocurri
En este caso se debe usar ms de un evento de inicio,
generalmente de tipo mensaje
Esto puede hacerse slo en un diagrama de alto nivel,
cada evento de inicio representa un disparador
alternativo para el proceso
Un caso comn se da cuando el inicio es dependiente
del canal, as por ejemplo el pedido de un cliente podr
requerir un diferente paso inicial si lleg por el call center
o por la web, los pasos siguientes del proceso (el
backend) si es el mismo independientemente del canal
de contacto

Eventos de inicio alternativos

Inicio dependiente del canal

Evento fin

Un evento de fin es representado por un crculo con

un borde grueso e indica el fin de una ruta en un
proceso o subproceso
A diferencia del evento de inicio es comn ver ms de
un evento de fin en un proceso o subproceso
BPMN 2.0 define nueve tipos de evento de fin, para la
paleta de nivel 1 revisaremos cuatro de ellos

Evento de fin none

Un evento de fin none no lleva un cono dentro e indica

que no es enviado ningn resultado cuando el proceso
llega al evento fin
En un proceso con flujos paralelos, es permitido terminar
los flujos paralelos en eventos de fin separados, pero
ellos no representan distintos estados finales, por esta
razn si todos terminan en eventos de fin de tipo none es
mejor juntar las rutas en un solo evento fin none
No es necesario diagramar una compuerta para juntar los
flujos paralelos en un evento de fin none
En realidad lo que hara la compuerta sera esperar hasta
que todos los flujos lleguen antes de pasar al evento fin

Evento de fin mensaje

Un evento de fin mensaje, con un cono de sobre

negro dentro, indica que un mensaje es enviado al
llegar al evento fin
Es una buena practica dibujar un flujo de mensaje
dirigido desde el evento fin hacia el pool que recibe el
mensaje
Si se juntan flujos paralelos directamente en un
evento de fin mensaje, el mensaje ser enviado
mltiples veces
Si lo que se desea es enviar el mensaje una sola vez
debe usarse una compuerta join antes del evento de
fin mensaje

Evento de fin terminate

Un evento de fin terminate, con un cono circular

negro dentro, indica que el proceso o subproceso
debe terminar inmediatamente aunque otro flujo
paralelo est an en ejecucin
El evento de fin terminate no termina los procesos
padre
Su uso ms recomendado es cuando se produce una
excepcin en un flujo paralelo que debe terminar
todos los flujos paralelos en curso

Evento de fin mltiple

Un evento de fin mltiple, con un cono de pentgono

negro dentro es similar al evento de inicio mltiple e
indica que el proceso o subproceso enva ms de un
resultado por ejemplo dos mensajes diferentes

Flujos de secuencia

Es un conector dibujado como una lnea slida y

representa la ejecucin secuencial de los pasos de un
proceso
Cuando el nodo ligado al inicio del flujo de secuencia es
completado, el nodo ligado al final del flujo de secuencia
(la cabeza de flecha) es habilitado para empezar
En un proceso ejecutable este flujo representa un
verdadero flujo de control
Los nicos elementos que pueden conectarse a los flujos
de secuencia son actividades, compuertas y eventos,
llamados nodos de flujo en el metamodelo de BPMN 2.0
Los flujos de secuencia representan la orquestacin

Flujos de mensaje

Es un conector dibujado como una lnea discontinua y

representa la comunicacin entre el proceso y una
entidad externa
Un mensaje de flujo puede conectarse a cualquier
tipo de actividad, un evento mensaje o mltiple o un
pool representando una caja negra
No es posible conectar un flujo de mensaje al lmite
de un pool conteniendo un proceso, debe conectarse
directamente a una actividad o evento dentro del pool

Flujos de mensaje

En algunos casos un flujo de mensaje indica la

posibilidad de envo del mensaje no la certeza del
envo
En el caso de una tarea de usuario con flujo de
mensaje de salida indica que la tarea puede enviar el
mensaje no que debe enviar el mensaje
Si siempre se quiere enviar o recibir el mensaje debe
usarse un evento mensaje o una tarea de enviar
mensaje o recibir mensaje

Pool

Es una caja de forma rectangular, puede ser

horizontal con la etiqueta sobre la izquierda, o vertical
con la etiqueta en la parte superior
Un pool conteniendo elementos de flujo es llamado un
pool de proceso o caja blanca y debera ser
etiquetado con el nombre del proceso
Un pool vaco, es llamado un pool de caja negra y
debera ser etiquetado con el nombre de la entidad de
negocios o el rol como por ejemplo Cliente

Pool

Figura superior: Pool de caja negra

Figura inferior: Pool de proceso

Lane

En BPMN 2.0 un lane es una subdivisin opcional de

un proceso
Se usa generalmente para asociar actividades de un
proceso con particulares actores (departamentos o
roles), aunque pueden usarse para cualquier
categorizacin
Si se usa lanes en un proceso todos sus nodos de
flujo deben quedar dentro de algn lane, no puede
quedar ninguno fuera de un lane

Data object y Data store

Un data object representa una variable local en un

proceso, un dato temporal dentro de la instancia del
proceso mientras esta ejecutndose. Similar a una
variable en un programa de computacin
Su valor es visible a otros elementos en el mismo nivel de
proceso o en uno de sus subprocesos hijo, pero es
invisible a los elementos que estn en un proceso de nivel
superior
Un data store representa data persistente como los datos
grabados en bases de datos o en un sistema de negocios
Estos datos pueden ser consultados o actualizados por el
proceso y por entidades fuera del proceso
Estos datos no desaparecen cuando el proceso termina

Data object y Data store

Un conector de asociacin dirigido al data store

representa una actualizacin y una asociacin
saliendo del data store representa una consulta

La tarea Process Order actualiza el balance

contable en el data store Customer Account

Text annotation y Group

El artefacto text annotation permite agregar texto,

este debe estar atachado por una asociacin no
direccional a un elemento grfico del modelo
El artefacto group permite agrupar un conjunto de
elementos del modelo para indicar alguna relacin
entre ellos
Un artefacto en BPMN soporta informacin que no
afecta el flujo del proceso

Text annotation y Group

Text annotation y
association

Group

Ejercicio de modelado
Modelado de un proceso a nivel descriptivo

TEMARIO SESIN 3
Aplicacin de la metodologa de modelado de
procesos de nivel descriptivo

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 3
Modela procesos descriptivos siguiendo los pasos de una
metodologa

Contenido de la Sesin
Objetivos de la metodologa
Modelado top-down
Estados finales
Pasos de la metodologa
Modelado de un proceso aplicando la metodologa

Objetivos de la metodologa

La metodologa es como una receta para ir desde una

pgina en blanco hasta un modelo en BPMN consistente,
completo y bien estructurado
Esta basado en modelo de estilo jerrquico que revela los
hechos importantes del proceso en un diagrama de alto
nivel
Los detalles se agregan en diagramas hijo manteniendo el
enlace con el proceso padre
Un buen modelo BPMN cumple con cuatro caractersticas:

Es completo

Es claro

Es entendible por el negocio y por TI

Tiene consistencia estructural

Objetivos de la metodologa
Completo
Los elementos esenciales de la lgica de proceso de
principio a fin deben ser capturados en el diagrama:
Cmo inicia el proceso
Sus diferentes estados finales
Qu es lo que representa la instancia
Las interacciones con entidades externas, como
clientes, proveedores u otros procesos internos

Objetivos de la metodologa
Claro
No debera existir ambigedad en el diagrama y debera
ser fcil de entender an para los que no tienen
familiaridad con el proceso y su terminologa particular
Qu actividades son condicionales
Cules son realizadas en paralelo con otras
Cmo son manejadas cada una de las
excepciones
La lgica debe ser trazable desde el diagrama de
alto nivel a los diagramas hijo

Objetivos de la metodologa
Entendible por el negocio y por TI
EL lenguaje BPMN puede ser compartido por
usuarios de negocio, analistas de negocio y
desarrolladores
Los usuarios de negocio y analistas de negocio deben
poner ms rigor a los detalles de los modelos
Los desarrolladores deben describir las actividades de
los procesos en trminos de funciones de negocio
ms que en especificaciones de implementacin

Objetivos de la metodologa
Tiene consistencia estructural
Ante el mismo conjunto de hechos acerca de como el
proceso trabaja, los modeladores deberan crear ms o
menos el mismo modelo de proceso
Como mnimo la estructura general debera ser la misma
Conseguir esta consistencia en la organizacin mejorar
la habilidad para entender modelos creados por otros

Modelado Top-down

Top-down puede entenderse como jerrquico

El modelo es representado de principio a fin como un
conjunto de diagramas de procesos enlazados
representando diferentes niveles de procesos
Esto quiere decir que un subproceso colapsado en el
diagrama padre es expandido en un diagrama hijo
separado
Los subprocesos colapsados representados en el
diagrama hijo pueden tambin expandirse en otro
diagrama nieto
En contraste un modelo de proceso plano coloca todos
los pasos del proceso, incluyendo los de detalle ms fino
en un solo diagrama

Estados finales

Cuando una instancia de una tarea termina es

importante saber como termin, quiz la actividad tiene
ms de un estado final de excepcin o posiblemente
ms de un estado final de xito
Si existen tres diferentes posibles pasos siguientes en
el proceso, entonces es necesario distinguir los tres
estados finales
Una compuerta a continuacin de la actividad examina
el estado final y dirige el flujo
Si la actividad es una tarea sus estados finales no
sern visibles en el modelo, pero sabemos que tiene
ms de un estado por la compuerta que sigue a la tarea

Estados finales

Sin embargo, si la actividad es un subproceso es posible

hacer sus estados finales visibles en el diagrama definiendo
un evento de fin separado para cada distinto estado final y
etiquetando cada uno con el nombre del estado final.
Esto permite que la lgica del proceso sea trazable de arriba
hacia abajo a travs de los diagramas
Si el subproceso tiene dos estados finales, es recomendable
etiquetar la compuerta a continuacin como una pregunta y
sus salidas como SI y NO
La etiqueta de esta compuerta debera corresponder con la
etiqueta de uno de los estados finales del subproceso
En caso que el subproceso tenga tres estados finales, cada
salida de la compuerta a continuacin deber etiquetarse
con la misma etiqueta de cada estado final.

Estados finales

Distinguir los estados finales de un subproceso ayuda a la trazabilidad

Paso 1: Determinar el alcance del

proceso
El modelado jerrquico inicia con un acuerdo del

alcance del proceso, donde comienza y donde termina

Este acuerdo debe darse antes de iniciar el modelado
Esto no es algo simple de obtener y puede tomar algn
tiempo y algunas discusiones, pero es mejor tener estas
discusiones antes de entrar en los detalles del proceso
Algunas preguntas que nos ayudan:
Cmo inicia el proceso?
Qu determina cuando el proceso est completo?
Qu representa cada instancia del proceso?
Hay diferentes formas en que el proceso pueda
terminar?

Paso 2: Crear el mapa de alto nivel

Esto consiste en una lista de las principales actividades

del proceso, idealmente alrededor de diez que sern
diagramadas en un BPMN a nivel padre en una pgina
En lugar de pensar en tareas detalladas es mejor pensar
en contenedores donde estos detalles sern agregados
posteriormente
Los pasos en el mapa de alto nivel deben ser
actividades BPMN, es decir acciones que se ejecutan
repetidamente cada una con un bien definido inicio y fin
Cuando la salida de una actividad afecta a la ruta
subsecuente debemos tener en cuenta los estados
finales de cada actividad

Paso 3: Diagramar el proceso de alto

nivel
Cada actividad del mapa de alto nivel se convierte en

un una tarea o un subproceso en el diagrama, cada

subproceso ser expandido en un diagrama hijo
posteriormente
Cada actividad que es condicional en el mapa de alto
nivel se dibujar despus de una compuerta que
evala el estado final de la actividad precedente
Si una actividad se ejecuta concurrentemente con
otra en el mapa de alto nivel, dividimos el flujo en
rutas paralelas

Paso 3: Diagramar el proceso de alto

nivel

Diagrama BPMN de alto nivel Happy path

Paso 3: Diagramar el proceso de alto

nivel

Diagrama BPMN de alto nivel Incluyendo rutas de excepcin

Paso 3: Diagramar el proceso de alto

nivel

Diagrama BPMN de alto nivel Mostrando pool y lanes

Paso 4: Expandir los subprocesos

El diagrama de alto nivel muestra como inicia y

termina el proceso, pero dice muy poco respecto de
los detalles internos
El subproceso expandido debe tener un evento de
inicio none
Las actividades dentro de un subproceso expandido
pueden incluir subprocesos colapsados, los cuales
podran ser expandidos en otro nivel debajo a dos
niveles del padre
Debe crearse un separado evento de fin para cada
estado final de la actividad del mapa de alto nivel
identificado en el paso 2 y etiquetarlo con el nombre
del estado final

Paso 5: Adicionar flujos de mensaje

En estricto, los flujos de mensaje no son requeridos en

BPMN, la especificacin los establece como opcionales
Sin embargo es recomendable dibujarlos porque agregan
informacin valiosa al diagrama, lo que podramos
considerar un contexto de negocio
Estos flujos muestran como el proceso interacta con los
clientes, proveedores y otros procesos internos
Los flujos de mensaje deben ser consistentes entre los
diagramas padre e hijo, as si un proceso colapsado a
nivel padre tiene tres flujos de mensajes salientes y dos
flujos de mensajes entrantes, entonces el subproceso
expandido debera tener los mismos flujos de mensaje y
sus etiquetas deberan coincidir con las del proceso padre

Paso 5: Adicionar flujos de mensaje

Paso 5: Adicionar flujos de mensaje

Order car from factory de nivel hijo expandido con flujos de mensaje

Ejercicio de modelado
Modelado de un proceso aplicando la metodologa

TEMARIO SESIN 4
Reglas de estilo para modelos a nivel descriptivo

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 4
Aplica reglas de estilo para crear modelos de procesos

Contenido de la Sesin
Reglas de estilo para modelos a nivel descriptivo
Modelado de un proceso aplicando las reglas de estilo

Reglas de estilo
Regla 1: Usar conos y etiquetas para hacer la lgica

del proceso clara desde el diagrama impreso

Etiquete todas las actividades incluidos los
subprocesos
Etiquete los estados finales
Etiquete las salidas de las compuertas
Etiquete los pool, lanes y los flujos de mensaje
Identifique los tipos de tareas y eventos con conos
Use text annotation para eliminar la ambigedad del
diagrama

Reglas de estilo
Regla 2: Cree modelos jerrquicos, de modo que cada

proceso entre en una pgina

Regla 3: Use una caja negra para representar al cliente

o a proveedores

Reglas de estilo
Regla 4: Inicie los procesos que atienden al cliente con

un evento de inicio de mensaje recibiendo un mensaje

desde el pool del Cliente

Reglas de estilo
Regla 5: Modele las unidades internas de la organizacin

como lanes dentro de un mismo pool, no como pools

separados. Pools separados implican procesos
independientes

Reglas de estilo
Regla 6: Etiquete los pools del proceso con el nombre

del proceso, etiquete los pools de caja negra con los

roles de los participantes o entidades de negocio
Regla 7: Seale los estados finales de xito y
excepciones de un proceso o subproceso con eventos
de fin separados y etiqutelos para indicar el estado
final

Reglas de estilo
Regla 8: Etiquete las actividades en la forma Verbo-

Nombre
Regla 9: Use eventos de inicio disparadores en el

proceso de alto nivel para indicar como inicia el proceso

Regla 10: Si un subproceso es seguido por una

compuerta etiquetada como una pregunta el

subproceso debera tener mltiples eventos de fin y uno
de ellos debera coincidir con la etiqueta de la
compuerta

Reglas de estilo

Reglas de estilo
Regla 11: Mostrar los flujos de mensaje en todos los

eventos de mensaje
Regla 12: Haga coincidir los flujos de mensaje entre los

diagramas padre e hijo

Regla 13: Etiquete los flujos de mensaje directamente

con el nombre del mensaje

Reglas de estilo

Reglas de estilo
Regla 14: Dos eventos de fin en un proceso no

deberan tener el mismo nombre

Reglas de estilo
Regla 15: Dos actividades en un proceso no deberan

tener el mismo nombre

Reglas de estilo
Regla 16: Un subproceso debera tener un evento de

inicio none (no disparador)

Regla 17: Un pool de proceso en un diagrama hijo debe

ser etiquetado con el nombre del proceso de alto nivel

no con el nombre de la actividad subproceso
Regla 18: En un modelo jerrquico, un diagrama hijo no

puede contener ningn proceso de alto nivel

Reglas de estilo
Regla 19: No use una compuerta XOR para juntar rutas

alternativas, solo conecte los flujos directamente

Reglas de estilo
Regla 20: No use una compuerta AND para juntar rutas

paralelas en un evento de fin de tipo none, un evento de

fin none junta los flujos

Reglas de BPMN 2.0

Regla 21: Un flujo de secuencia no debe cruzar los

lmites de un pool

Reglas de BPMN 2.0

Regla 22: Un flujo de secuencia no debe cruzar los

lmites de un subproceso

Reglas de BPMN 2.0

Regla 23: Un flujo de mensaje no puede conectar nodos

en el mismo pool

Reglas de BPMN 2.0

Regla 24: Un flujo de secuencia slo puede conectarse

a una actividad, compuerta o evento

Regla 25: Un flujo de mensaje solo puede conectarse a

una actividad, evento mensaje o mltiple o pool de cada

negra

Ejercicio de modelado
Modelado de un proceso aplicando las reglas de estilo

TEMARIO SESIN 5
Modelado de procesos a nivel analtico con
eventos

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 5
Utiliza eventos intermedios en el modelado de procesos

Contenido de la Sesin
Eventos
Evento Temporizador
Evento Mensaje
Gateway de eventos
Evento Error
Modelado de un proceso con eventos intermedios

Comportamiento de eventos
disparadores
Un evento de inicio de tipo mensaje crea una nueva

instancia de proceso cuando recibe el mensaje

representado por el flujo de mensaje entrante
Un evento de inicio de tipo timer crea una nueva instancia
de proceso cuando se cumple la programacin o
calendario
La creacin de la instancia ocurre inmediatamente luego
de detectar el disparador
En un proceso ejecutable la instanciacin es inmediata y
automtica
En un proceso no automatizado, se utiliza los eventos de
inicio de mensaje y timer incluso cuando la instanciacin
es a travs de personas

Eventos intermedios
Son dibujados como un doble anillo y ocurren luego que

el proceso ya inici y antes de que terminen.

El significado preciso de un evento intermedio depende
de los detalles de su representacin:
el cono dentro
el color del cono
el estilo del doble anillo
su colocacin en el diagrama
Un evento intermedio throwing, con el cono negro
dentro, significa que el proceso genera el disparador
Un evento intermedio catching, con el cono blanco
dentro, significa que el proceso espera por el disparador

Eventos intermedios
Un evento intermedio catching, dibujado en el lmite de

una actividad es llamado un evento lmite

Mientras la actividad est en ejecucin el proceso est
escuchando por la seal
Si la seal ocurre antes que la actividad este completa el
flujo de secuencia de salida del evento, llamado flujo de
excepcin, es disparado
Si la actividad es completada sin que ocurra la seal, el
flujo de excepcin es ignorado y el proceso contina con
el flujo normal
Un evento lmite no tiene un flujo de secuencia entrante y
tiene solo un flujo de secuencia de salida: el flujo de
excepcin

Eventos intermedios
Hay dos tipos de eventos lmite
evento lmite interruptor: dibujado con doble anillo

slido, interrumpe la actividad al que esta atachado el

evento inmediatamente despus de producido el
disparador, el flujo del proceso sigue por el flujo de
excepcin del evento, el flujo normal ya no contina
evento lmite no interruptor: dibujado con doble anillo
con lnea discontinua, no interrumpe la actividad al
que esta atachado el evento cuando se ha producido
el disparador, el flujo del proceso sigue por el flujo
normal y adems se genera un flujo paralelo

Eventos timer
Evento timer catching
Un evento timer intermedio significa un aplazamiento
Puede esperar durante un tiempo especificado en el evento, o
Esperar hasta que llegue la fecha y hora establecida en el evento

Un evento timer no se usa para indicar que una

actividad usualmente toma tres das, se usa para

decir que sucede si es que la actividad toma ms de
tres das

Eventos timer

Eventos timer
Evento lmite timer
Si la actividad no est completa cuando sucede el

evento especificado en el timer (la duracin

especificada o la fecha/hora establecida) entonces el
flujo de excepcin es disparado

Eventos timer
El evento lmite timer no interruptor es generalmente

ms usado que el interruptor

As, si alguna actividad toma ms tiempo de lo
establecido se puede hacer algo en adicin a la tarea tal
como notificar al solicitante, notificar al supervisor o
solicitar ayuda

Evento mensaje
Send y receive (enviar y recibir) son algo as como

palabras reservadas en BPMN, usadas especficamente

para enviar y recibir un mensaje, representada en el
diagrama por un flujo de mensaje

Tarea enviar y Evento de envo de

mensaje
Un mensaje puede ser enviado desde pool de caja
negra, un evento de mensaje throwing o cualquier tipo
de actividad
Si dentro del flujo se necesita enviar siempre un
mensaje debe usarse una tarea enviar (send task)
Tambin podra usarse un mensaje intermedio, pues
hace la misma cosa que una tarea enviar

Evento mensaje

No debe usarse una tarea enviar para comunicarse dentro de un

proceso, el envo est implcito por el flujo de secuencia

Evento mensaje
Las notificaciones que no tienen necesidad de una

accin por parte del receptor para continuar con el

proceso tampoco se representan con una tarea enviar
Lo ms adecuado es agregar una tarea de usuario en el
lane del que enva la notificacin e identificando al
receptor en la etiqueta de la tarea

Tarea recibir y Evento atrapar mensaje

El trmino recibir se aplica solo a mensajes,

comunicaciones desde participantes externos

Es posible recibir un mensaje en el medio de un
proceso, un flujo de mensaje entrando a una tarea de
usuario slo sugiere la posibilidad de recibir un
mensaje, no la certeza de recibirlo
Si se necesita siempre recibir una tarea debe usarse la
tarea recibir, una tarea recibir espera por el mensaje

Compuerta de eventos
Una compuerta de eventos tiene el cono de evento

intermedio mltiple dentro y en cada salida hay un

evento intermedio de catching (atrapar)
Usualmente las salidas son un evento de mensaje y un
evento de timer

Compuerta de eventos

La compuerta de evento espera por la respuesta o timeout, lo que ocurra primero

Evento mensaje
Evento lmite de mensaje
Es atachado a una actividad inicia la respuesta al mensaje si
este llega mientras la tarea est en ejecucin
Un evento limite interruptor aborta la actividad inmediatamente y
sale sobre el flujo de excepcin
Un evento limite no interruptor deja que la tarea termine y que
siga el flujo principal del proceso e inicia el flujo de excepcin e
forma paralela
Si la actividad es completada antes que llegue el mensaje el flujo
de excepcin no es ejecutado y el flujo sigue su ruta normal

Evento mensaje

El mismo mensaje puede ser recibido en mltiples eventos lmite

Evento mensaje

Si la accin disparada es la misma para cada actividad debe usarse un evento

lmite de mensaje sobre un subproceso que agrupe las actividades

Evento error
Representa un estado final de excepcin de una actividad

dentro de un proceso
Solo existen:
Evento lmite de error interruptor
Evento fin de error
Una seal de error no puede ser lanzada ni atrapada en un
evento intermedio y no existe un evento de inicio e error
Un evento lmite de error hace que al producirse el error en
la ejecucin de la actividad se ejecute el flujo de excepcin
Si la actividad se ejecuta correctamente el evento error no
se produce

Evento error
Pueden existir varios eventos de error sobre una
misma tarea representando diferentes
excepciones y estados finales

Un evento lmite de error sobre una tarea es equivalente a

evaluar el resultado del estado de la tarea con una compuerta

Evento error
Un evento fin de error en un subproceso lanza
una seal de error al lmite del subproceso,
donde es capturado por el evento lmite de error
y contina por el flujo de excepcin
Este es llamado el patrn de error throw-catch y
es como si el error se propagara de un
subproceso hijo a un proceso padre
En el caso anterior el evento de fin de error y el
evento lmite de error referencian al mismo
cdigo de error
Como el cdigo de error no aparece en el
diagrama y aplicamos el principio que dice que
las etiquetas del throw y del catch deben
coincidir

Evento error

Ejercicio de modelado
Modelado de un proceso con eventos intermedios

TEMARIO SESIN 6
Iteracin y alineamiento de instancias
Simulacin de procesos

PRODUCTO DE APRENDIZAJE
ESPERADO SESIN 6
Utiliza actividades que se realizan repetidas veces
Comprende los principios de la simulacin de procesos

Contenido de la Sesin
Bucles
Multi-instancias
Actividades repetidas
Uso de mltiples pools
Simulacin de modelos de negocio

Bucles
Una actividad repetida se representa por una
flecha circular en la parte inferior central de la
actividad
Es similar a un lazo Do While en programacin
La actividad se realiza una vez y entonces se
evala la condicin del bucle (una expresin
booleana), si la condicin es verdadera se
realiza la actividad una siguiente vez y se
evala la condicin otra vez
Esta iteracin puede continuar indefinidamente
o puede establecerse un lmite superior
Cuando la condicin es falsa el flujo de
secuencia de salida de la actividad es habilitado

Bucles
Es recomendable indicar la condicin en un text
annotation
Con las actividades en bucle la iteracin es
siempre secuencial, la segunda iteracin no
puede empezar hasta que la primera ha
finalizado y la condicin del bucle es verdadera
Los dos grficos siguiente representan lo mismo

Multi instancias
Se representa con un cono de tres lneas
paralelas en la parte inferior central de una
actividad
Es similar al For-Each en programacin y
significa realizar la actividad una vez por cada
item en una lista
Una actividad de mltiples instancias slo tiene
sentido cuando la data de las instancias del
proceso tiene algn tipo de coleccin, tal como
los items en una orden
Cada orden no tiene el mismo nmero de items
pero cuando se inicia la tarea para una orden en
particular ya se conoce cuantos items tiene esa
orden y la cantidad de iteraciones que sern
requeridas

Multi instancias
Conocer el numero de iteraciones al inicio de la
actividad es una diferencia fundamental entre
actividades de bucle y de multi instancias
Otra diferencia es que las multi instancias
pueden ser realizadas en paralelo
Si las instancias son siempre realizadas de
manera secuencial entonces las tres lneas son
dibujadas de forma horizontal

Multi instancias

Los dos grficos representan lo mismo

Ejercicio de modelado
Modelado de un proceso de contratacin para un
puesto de trabajo

Ejercicio de modelado

Ejercicio de modelado

Ejercicio de modelado

Uso de mltiples pools

En algunas ocasiones no es posible modelar un
proceso de negocio de principio a fin en un solo
proceso
La razn es que las instancias de las actividades
no estn alineadas a lo largo de todo el proceso
de principio a fin, no hay una correspondencia
1:1 entre ellos
En este caso es necesario modelar el proceso de
principio a fin en mltiples pools, esto es un
proceso BPMN mltiple

Ejercicio de modelado
Modelado de un proceso de contratacin para un
puesto de trabajo utilizando mltiples pools

Ejercicio de modelado

Simulacin de modelos de negocio

Ventajas de la simulacin sobre las pruebas reales:
Velocidad
Menor costo
No interfiere con las operaciones reales
Usos
Entrenamiento y aprendizaje
Persuasin y ventas
Anlisis de situaciones de negocios
Verificacin y validacin

Tipos de simulacin
Descripcin visual
Se presenta al usuario una descripcin animada
del modelo de negocios
Escenario de simulacin
Se muestran entornos de negocios simulados
para tomar accin y hacer decisiones
Simulacin numrica
Se presentan al usuario valores de entrada y
parmetros de decisin de un modelos de
negocios simulado

Descripcin visual
Usado principalmente en:
Enseanza y aprendizaje
Verificacin y validacin
Ejemplos:
Se presenta al usuario una animacin para
comprender mejor algn patrn complejo
El usuario sigue el flujo de proceso durante la
simulacin y valida la lgica

Escenario de simulacin
Usado principalmente en:
Enseanza y aprendizaje
Ejemplos:
En gestin de procesos
Especficos a la industria

Simulacin numrica
Usado principalmente en:
Enseanza y aprendizaje
Persuasin y ventas
Anlisis de situacin de negocios
Verificacin y validacin
Ejemplos:
Anlisis de capacidad y ciclos de tiempo
Requerimientos de productos
Evaluacin del riesgo financiero
Contexto econmico para hacer pronsticos

Simulacin de modelos de negocio

Demo nmero 1

Referencias bibliogrficas
BPMN Method and Style Bruce Silver
Modeling and Simulation in Business Process

Management Denis Gagn