1. Diseño de Flujos de Trabajo

2. 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 creación de mejores sistemas de
información
2. Utiliza BPMN para modelar procesos
3. Entiende la diferencia entre los niveles de modelado
descriptivo y analítico
4. Reconoce la importancia de modelar adecuadamente
los procesos de negocio
5. Reconoce el valor del modelado del proceso en la
gestión por procesos de la organización

3. TEMARIO SESIÓN 1
Conceptos básicos de flujo de trabajo y su relación
con los procesos de negocio.

4. PRODUCTO DE APRENDIZAJE ESPERADO
SESIÓN 1
Conoce las formas más usadas de BPMN
Crea modelos básicos de proceso de negocio

5. Contenido de la Sesión
• Características de los buenos modelos
• Definiciones
• Actividades
• Procesos
• Lógica de procesos
• Orquestación
• Niveles de BPMN
• Modelado de un proceso básico
• Símbolos para modelos descriptivos (primera parte)
• Actividades

6. Características de los buenos modelos
• Correctos
• El diagrama no viola ninguna especificación de BPMN
• Claros
• La lógica de proceso no debe ser ambigua
• Completos
• El diagrama debe indicar como inicia el proceso, sus
estados finales y la comunicación con las entidades
externas y procesos internos
• Consistentes
• Ante el mismo conjunto de hechos sobre la lógica de
proceso, todos los modeladores deberían crear más o
menos el mismo modelo

7. ¿Qué es un modelo?
• Es más que sólo un gráfico
• Su propósito es transmitir el significado de la lógica
específica del flujo de actividades desde que el
proceso inicia hasta que termina
• La lógica de proceso debe ser entendible para una
persona de negocios, pero también semánticamente
precisa para su uso por parte de los desarrolladores
• La lógica de proceso es una descripción de todas las
rutas desde un estado inicial hasta cada uno de sus
posibles estados finales

8. Actividades
• En BPMN una actividad es una acción, una unidad de
trabajo realizado, es el único elemento de BPMN que
tiene un ejecutor o realizador.
• Más específicamente, una actividad en BPMN es una
acción que se ejecuta repetidamente en el desarrollo de
los negocios
• Cada instancia de la actividad representa la misma
acción 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 revisión mensual
• Una actividad es una acción discreta con un bien
definido inicio y fin

9. Procesos
• En BPMN un proceso es una secuencia de actividades
dirigiéndose desde un estado inicial de una instancia del
proceso hacia un estado final definido
• El inicio del proceso es señalado por un evento
disparador tal como la recepción 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
excepción.
• 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 algún camino en el
modelo de proceso desde el inicio hasta el fin

10. Lógica de procesos
• El modelo de proceso es más que sólo la
documentación 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 lógica del proceso puede ser definida con la ayuda
de algunas preguntas como:
• ¿Cómo el proceso inicia realmente?
• ¿Qué evento lo dispara?
• Hay más de una manera en que inicie?
• ¿Qué determina cuando está completo el proceso?

11. Lógica de procesos
• ¿Existen diferentes estados finales del proceso como
uno de éxito y otros que expresan fallas o abandono?
• ¿Cómo el proceso llega de la tarea X a la tarea Y?
• ¿El proceso podría eventualmente ir de la tarea X a otra
tarea diferente a Y? ¿Qué reglas gobiernan este flujo?
• ¿Cómo sabemos que la tarea X ya fue hecha?
• Las respuestas a estas preguntas no son siempre fáciles
de obtener, la lógica está oculta, incluso algunas veces en
la cabeza de alguien.
• El valor de un diagrama es hacer que la lógica del proceso
sea explícita de modo que los stakeholders la entiendan

12. Orquestación
• BPMN sólo describe procesos en los que la lógica de
procesos es explicita
• Cada instancia del proceso debe seguir alguna ruta en
el modelo de proceso.
• El término técnico utilizado en BPMN es orquestación
• ¿Cómo la lógica del proceso puede ser definida por
adelantado si el resultado de una Aprobación no se
puede conocer de antemano?
• Cómo el ejecutor decide aprobar o rechazar no es
parte de la lógica del proceso. Esto es parte de la
lógica del paso de Aprobación. BPMN no describe la
lógica de la tarea, sólo la lógica del proceso

13. Orquestación
• La lógica del proceso dice: Si el paso de Aprobación
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 información acumulada por la
instancia dentro de su flujo
• Esta información incluye
• Mensajes recibidos
• Datos producidos en las actividades del proceso
• Estados finales de las actividades completadas

14. Orquestación
• BPMN asume que los datos de todas las instancias
están disponibles para la lógica del proceso
• Con esta información el proceso sabe como fue
cada paso completado y a que paso debe ir
• El modelo del proceso guía de manera inteligente la
instancia a través de cada paso
• Este guiado a través de los pasos del proceso
ayuda a disminuir la variabilidad de los procesos y
permite su mejora

15. Niveles de BPMN
• Existen tres niveles de modelado en BPMN, que
ayudan a separar las formas y símbolos que serán
usados para crear el modelo, así como el propósito
del modelo y los stakeholders que lo utilizarán:
• Nivel 1, llamado descriptivo
• Nivel 2, llamado analítico
• 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 clasificación.

16. Ejercicio de modelado
Proceso de pedidos

17. Símbolos para modelos descriptivos
• Para modelar procesos de nivel 1 son necesarios solo algunas
formas y símbolos, 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
• Documentación
• Artefactos: Text anotation, association y group

18. Actividades
• Una actividad representa una unidad de trabajo
realizado en el proceso. Es siempre representada por
un rectángulo redondeado
• Es el único elemento en BPMN que tiene un ejecutor
• Cada actividad o es una tarea o es un subproceso
• Una tarea es atómica, 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 más
estados finales

19. Tarea
• Una tarea es representada en el diagrama por la forma
actividad, un rectángulo redondeado con el tipo de tarea
indicado por un pequeño ícono en la esquina superior
izquierda
• Una tarea representa una acción, no una función ni un
estado
• El nombre de la tarea debería ser de la forma VERBO-NOMBRE

20. Tarea
Fila superior: Tarea de usuario, tarea de servicio, tarea abstracta
Fila inferior: Tarea de envío de mensaje, tarea de recepción de
mensaje, tarea manual, tarea de script, tarea de regla de negocio

21. Tarea
• Una tarea de usuario representa a una tarea realizada
por una persona
• Una tarea de servicio representa a una tarea
automática, es decir, que al llegar el flujo de secuencia
la tarea se inicia automáticamente sin intervención
humana
• Si una persona tan sólo hace click a un botón y el resto
es automático, esto sería una tarea de usuario no una
tarea de servicio
• Una tarea abstracta (sin ningún ícono) no tiene un tipo
definido

22. Tarea manual vs. Tarea de usuario
• Una tarea manual, sólo debería ser usada en procesos
que son o serán 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
debería incluir tareas manuales
• En procesos no ejecutables sólo deben usarse tareas
de usuario para cualquier tarea hecha por personas

23. Tarea script vs. Tarea de servicio
• Una tarea script debería 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 petición de servicio a un sistema externo o entidad
para realizar esta función
• La implementación del servicio no es definida por
BPMN, sino por el sistema que lo realiza
• Una tarea de script representa a una función
automatizada realizada por el mismo motor de procesos
y mediante un pequeño programa, típicamente en
javascript

24. Tarea script vs. Tarea de servicio
• Debido a que los motores de proceso están usualmente
muy ocupados ejecutando la lógica 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 debería incluir tareas
de script, sólo deberían usarse tareas de servicio para
cualquier tarea automatizada

25. 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 múltiples
formas dentro del diagrama. Un subproceso colapsado
es dibujado en el diagrama padre usando una forma d
actividad de tamaño normal con un símbolo + en el
centro de la parte inferior
• Un subproceso expandido es dibujado en un diagrama
separado enlazado

26. Subprocesos
Figura superior: Subproceso colapsado en un diagrama
padre
Figura inferior: Subproceso expandido en un diagrama
separado

27. 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 razón es que el inicio no es disparado por un evento,
siempre es disparado por lo mismo: el arribo del flujo de
secuencia

28. 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 gestión y monitoreo de
procesos de negocio de principio a fin, significando que
de cara al cliente el flujo atraviesa los límites
tradicionales de las áreas de la organización
• La habilidad para poder ver el proceso de principio a fin
en una página ayuda a este objetivo
• Desde el proceso padre se puede hacer zoom sobre los
proceso colapsados para expandirlos si es necesario
revisar mayor detalle

29. Subprocesos
2. Permite el modelado top down o jerárquico
• 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
• También sirve para mantener la integridad del
modelo de principio a fin cuando los detalles de un
subproceso no son conocidos

30. Subprocesos
3. Permite hacer claros los límites de gobierno
• Los subprocesos facilitan la distribución de la propiedad
y el gobierno
• Los procesos de principio a fin frecuentemente
atraviesan límites 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 límites entre las
actividades del proceso son borrosas
• En el diagrama padre se describe la interacción entre
subprocesos gobernados independientemente.

31. Subprocesos
4. Permite definir el alcance del evento manejador
• Los subprocesos son muy útiles para definir los
límites 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

32. Call Activity
• Si un subproceso es usado en más 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

33. TEMARIO SESIÓN 2
Elementos de la paleta de modelado de
nivel descriptivo

34. PRODUCTO DE APRENDIZAJE ESPERADO
SESIÓN 2
Utiliza los elementos de BPMN para crear modelos
descriptivos

35. Contenido de la Sesión
• Símbolos 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

36. Compuertas
• Una compuerta controla el flujo del proceso,
dividiéndolo en rutas alternativas
• Si no existe una compuerta y el flujo tiene más 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.

37. Compuertas
Incorrecto: Las rutas alternativas requieren una
compuerta en BPMN

38. Compuertas
Correcto: Las rutas alternativas requieren una compuerta
en BPMN

39. Compuerta Exclusiva
• BPMN define varios tipos de compuertas, distinguidas por
el símbolo dentro del rombo
• Si el rombo no muestra ningún símbolo se trata de una
compuerta exclusiva y es la compuerta más común
• El nombre oficial es: exclusive data-based gateway,
también 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
• También es representada con una X dentro del rombo.

40. Compuerta exclusiva
Incorrecto: Una compuerta no puede hacer una decisión,
solo examina una condición de los datos

41. Compuerta exclusiva
Correcto: La compuerta examina una condición de los
datos registrados en la tarea Revisar reporte

42. Compuerta Paralela
• Esta compuerta tiene un flujo de secuencia de
entrada y múltiples flujos de secuencia de salida y
divide el flujo y continúa en paralelo
incondicionalmente.
• Se diferencia de la compuerta exclusiva porque lleva
un símbolo [+] dentro del rombo
• Las rutas paralelas pueden ser juntadas más adelante
en el proceso o pueden conducir a eventos de fin
separados
• Flujos de secuencia múltiples pueden salir de un
evento de inicio o de una actividad de manera que
una compuerta paralela es innecesaria en este caso

43. Compuerta Paralela
Flujo validado con rutas paralelas sin usar compuertas

44. Compuerta Paralela
• Una compuerta paralela con múltiples 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, dispararán la actividad
y lo que sigue luego, múltiples veces.
• Estas compuertas y sus salidas no se deben etiquetar

45. Compuerta Paralela
La compuerta es necesaria para juntar los flujos

46. Evento de inicio
• Un evento de inicio es siempre representado con un
círculo con un borde delgado
• Su propósito 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 círculo llamado trigger, identifica el tipo de
señal que instancia el proceso
• Un subproceso debe tener un evento de inicio None
pues siempre es iniciado por un flujo de secuencia
entrante

47. Evento de inicio
• BPMN 2.0 define siete eventos de inicio, en la paleta
de nivel 1 se incluyen sólo cuatro de ellos

48. 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

49. Evento de inicio mensaje
• Un evento de inicio mensaje, con un ícono de sobre
dentro, indica que el proceso es disparado después
de recibir un mensaje desde fuera del proceso
• Esto significa que el proceso es iniciado a petición de
un requerimiento y que la instancia del proceso
representa el manejo de esta petición
• Este evento debería etiquetarse de la forma: Recibir
(nombre del mensaje)
• También debe graficarse el flujo del mensaje y
etiquetarlo con el nombre del mensaje

50. 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 debería etiquetarse para indicar la
programación, tal como: Lunes a las 08:00 o el 30 de
cada mes

51. Evento de inicio múltiple
• Un evento de inicio múltiple, con un pentágono
dentro, indica que el proceso podría ser iniciado por
cualquiera de múltiples triggers, como por ejemplo el
Mensaje A o el Mensaje B o por una programación
semanal
• Este evento debería etiquetarse con todos las
posibles condiciones que pueden disparar el proceso

52. Evento de inicio múltiple

53. 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 más de un evento de
inicio, generalmente de tipo mensaje
• Esto puede hacerse sólo en un diagrama de alto
nivel, cada evento de inicio representa un disparador
alternativo para el proceso
• Un caso común 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

54. Eventos de inicio alternativos
Inicio dependiente del canal

55. Evento fin
• Un evento de fin es representado por un círculo con
un borde grueso e indica el fin de una ruta en un
proceso o subproceso
• A diferencia del evento de inicio es común ver más 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

56. Evento de fin none
• Un evento de fin none no lleva un ícono dentro e
indica que no es enviado ningún 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 razón 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 haría la compuerta sería esperar
hasta que todos los flujos lleguen antes de pasar al
evento fin

57. 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
múltiples veces
• Si lo que se desea es enviar el mensaje una sola vez
debe usarse una compuerta join antes del evento de
fin mensaje

58. 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é aún en ejecución
• El evento de fin terminate no termina los procesos
padre
• Su uso más recomendado es cuando se produce una
excepción en un flujo paralelo que debe terminar
todos los flujos paralelos en curso

59. Evento de fin múltiple
• Un evento de fin múltiple, con un ícono de pentágono
negro dentro es similar al evento de inicio múltiple e
indica que el proceso o subproceso envía más de un
resultado por ejemplo dos mensajes diferentes

60. Flujos de secuencia
• Es un conector dibujado como una línea sólida y
representa la ejecución 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 orquestación

61. Flujos de mensaje
• Es un conector dibujado como una línea discontinua y
representa la comunicación entre el proceso y una
entidad externa
• Un mensaje de flujo puede conectarse a cualquier
tipo de actividad, un evento mensaje o múltiple o un
pool representando una caja negra
• No es posible conectar un flujo de mensaje al límite
de un pool conteniendo un proceso, debe conectarse
directamente a una actividad o evento dentro del pool

62. Flujos de mensaje
• En algunos casos un flujo de mensaje indica la
posibilidad de envío del mensaje no la certeza del
envío
• 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

63. 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 debería ser
etiquetado con el nombre del proceso
• Un pool vacío, es llamado un pool de caja negra y
debería ser etiquetado con el nombre de la entidad de
negocios o el rol como por ejemplo Cliente

64. Pool
Figura superior: Pool de caja negra
Figura inferior: Pool de proceso

65. Lane
• En BPMN 2.0 un lane es una subdivisión opcional de
un proceso
• Se usa generalmente para asociar actividades de un
proceso con particulares actores (departamentos o
roles), aunque pueden usarse para cualquier
categorización
• Si se usa lanes en un proceso todos sus nodos de
flujo deben quedar dentro de algún lane, no puede
quedar ninguno fuera de un lane

66. 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 ejecutándose. Similar a una
variable en un programa de computación
• 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 están 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

67. Data object y Data store
• Un conector de asociación dirigido al data store
representa una actualización y una asociación
saliendo del data store representa una consulta
La tarea Process Order actualiza el balance contable en el data
store Customer Account

68. Text annotation y Group
• El artefacto text annotation permite agregar texto,
este debe estar atachado por una asociación no
direccional a un elemento gráfico del modelo
• El artefacto group permite agrupar un conjunto de
elementos del modelo para indicar alguna relación
entre ellos
• Un artefacto en BPMN soporta información que no
afecta el flujo del proceso

69. Text annotation y Group
Text annotation y
association
Group

70. Ejercicio de modelado
Modelado de un proceso a nivel descriptivo

71. TEMARIO SESIÓN 3
Aplicación de la metodología de modelado de
procesos de nivel descriptivo

72. PRODUCTO DE APRENDIZAJE
ESPERADO SESIÓN 3
Modela procesos descriptivos siguiendo los pasos de una
metodología

73. Contenido de la Sesión
• Objetivos de la metodología
• Modelado top-down
• Estados finales
• Pasos de la metodología
• Modelado de un proceso aplicando la metodología

74. Objetivos de la metodología
• La metodología es como una receta para ir desde una
página en blanco hasta un modelo en BPMN
consistente, completo y bien estructurado
• Esta basado en modelo de estilo jerárquico 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
características:
• Es completo
• Es claro
• Es entendible por el negocio y por TI
• Tiene consistencia estructural

75. Objetivos de la metodología
Completo
• Los elementos esenciales de la lógica de proceso de
principio a fin deben ser capturados en el diagrama:
• Cómo 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

76. Objetivos de la metodología
Claro
• No debería existir ambigüedad en el diagrama y
debería ser fácil de entender aún para los que no
tienen familiaridad con el proceso y su terminología
particular
• Qué actividades son condicionales
• Cuáles son realizadas en paralelo con otras
• Cómo son manejadas cada una de las
excepciones
• La lógica debe ser trazable desde el diagrama de
alto nivel a los diagramas hijo

77. Objetivos de la metodología
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 más rigor a los detalles de los modelos
• Los desarrolladores deben describir las actividades
de los procesos en términos de funciones de negocio
más que en especificaciones de implementación

78. Objetivos de la metodología
Tiene consistencia estructural
• Ante el mismo conjunto de hechos acerca de como el
proceso trabaja, los modeladores deberían crear más
o menos el mismo modelo de proceso
• Como mínimo la estructura general debería ser la
misma
• Conseguir esta consistencia en la organización
mejorará la habilidad para entender modelos creados
por otros

79. Modelado Top-down
• Top-down puede entenderse como jerárquico
• 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 también expandirse en otro
diagrama nieto
• En contraste un modelo de proceso plano coloca
todos los pasos del proceso, incluyendo los de detalle
más fino en un solo diagrama

80. Estados finales
• Cuando una instancia de una tarea termina es
importante saber como terminó, quizá la actividad
tiene más de un estado final de excepción o
posiblemente más 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 continuación de la actividad
examina el estado final y dirige el flujo
• Si la actividad es una tarea sus estados finales no
serán visibles en el modelo, pero sabemos que tiene
más de un estado por la compuerta que sigue a la
tarea

81. 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 lógica del proceso sea trazable de
arriba hacia abajo a través de los diagramas
• Si el subproceso tiene dos estados finales, es
recomendable etiquetar la compuerta a continuación como
una pregunta y sus salidas como SI y NO
• La etiqueta de esta compuerta debería 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 continuación deberá
etiquetarse con la misma etiqueta de cada estado final.

82. Estados finales
Distinguir los estados finales de un subproceso ayuda a
la trazabilidad

83. Paso 1: Determinar el alcance del
proceso • El modelado jerárquico 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
algún tiempo y algunas discusiones, pero es mejor
tener estas discusiones antes de entrar en los
detalles del proceso
• Algunas preguntas que nos ayudan:
• ¿Cómo 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?

84. Paso 2: Crear el mapa de alto nivel
• Esto consiste en una lista de las principales
actividades del proceso, idealmente alrededor de diez
que serán diagramadas en un BPMN a nivel padre en
una página
• En lugar de pensar en tareas detalladas es mejor
pensar en contenedores donde estos detalles serán
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

85. 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á después de una compuerta que
evalúa 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

86. Paso 3: Diagramar el proceso de alto
nivel
Diagrama BPMN de alto nivel – Happy path

87. Paso 3: Diagramar el proceso de alto
nivel
Diagrama BPMN de alto nivel – Incluyendo rutas de
excepción

88. Paso 3: Diagramar el proceso de alto
nivel
Diagrama BPMN de alto nivel – Mostrando pool y lanes

89. 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
podrían 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

90. Paso 5: Adicionar flujos de mensaje
• En estricto, los flujos de mensaje no son requeridos
en BPMN, la especificación los establece como
opcionales
• Sin embargo es recomendable dibujarlos porque
agregan información valiosa al diagrama, lo que
podríamos considerar un contexto de negocio
• Estos flujos muestran como el proceso interactúa 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 debería tener los
mismos flujos de mensaje y sus etiquetas deberían
coincidir con las del proceso padre

91. Paso 5: Adicionar flujos de mensaje

92. Paso 5: Adicionar flujos de mensaje
Order car from factory de nivel hijo expandido con flujos de
mensaje

93. Ejercicio de modelado
Modelado de un proceso aplicando la metodología

94. TEMARIO SESIÓN 4
Reglas de estilo para modelos a nivel descriptivo

95. PRODUCTO DE APRENDIZAJE
ESPERADO SESIÓN 4
Aplica reglas de estilo para crear modelos de procesos

96. Contenido de la Sesión
• Reglas de estilo para modelos a nivel descriptivo
• Modelado de un proceso aplicando las reglas de estilo

97. Reglas de estilo
• Regla 1: Usar íconos y etiquetas para hacer la lógica
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 ambigüedad del
diagrama

98. Reglas de estilo
• Regla 2: Cree modelos jerárquicos, de modo que cada
proceso entre en una página
• Regla 3: Use una caja negra para representar al cliente
o a proveedores

99. 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

100. Reglas de estilo
• Regla 5: Modele las unidades internas de la organización
como lanes dentro de un mismo pool, no como pools
separados. Pools separados implican procesos
independientes

101. 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: Señale los estados finales de éxito y
excepciones de un proceso o subproceso con eventos
de fin separados y etiquételos para indicar el estado
final

102. 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 debería tener múltiples eventos de fin y uno
de ellos debería coincidir con la etiqueta de la
compuerta

103. Reglas de estilo

104. 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

105. Reglas de estilo

106. Reglas de estilo
• Regla 14: Dos eventos de fin en un proceso no
deberían tener el mismo nombre

107. Reglas de estilo
• Regla 15: Dos actividades en un proceso no deberían
tener el mismo nombre

108. Reglas de estilo
• Regla 16: Un subproceso debería 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 jerárquico, un diagrama hijo no
puede contener ningún proceso de alto nivel

109. Reglas de estilo
• Regla 19: No use una compuerta XOR para juntar rutas
alternativas, solo conecte los flujos directamente

110. 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

111. Reglas de BPMN 2.0
• Regla 21: Un flujo de secuencia no debe cruzar los
límites de un pool

112. Reglas de BPMN 2.0
• Regla 22: Un flujo de secuencia no debe cruzar los
límites de un subproceso

113. Reglas de BPMN 2.0
• Regla 23: Un flujo de mensaje no puede conectar nodos
en el mismo pool

114. Reglas de BPMN 2.0
• Regla 24: Un flujo de secuencia sólo puede conectarse
a una actividad, compuerta o evento
• Regla 25: Un flujo de mensaje solo puede conectarse a
una actividad, evento mensaje o múltiple o pool de cada
negra

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

116. TEMARIO SESIÓN 5
Modelado de procesos a nivel analítico con
eventos

117. PRODUCTO DE APRENDIZAJE
ESPERADO SESIÓN 5
Utiliza eventos intermedios en el modelado de procesos

118. Contenido de la Sesión
• Eventos
• Evento Temporizador
• Evento Mensaje
• Gateway de eventos
• Evento Error
• Modelado de un proceso con eventos intermedios

120. 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
programación o calendario
• La creación de la instancia ocurre inmediatamente
luego de detectar el disparador
• En un proceso ejecutable la instanciación es inmediata
y automática
• En un proceso no automatizado, se utiliza los eventos
de inicio de mensaje y timer incluso cuando la
instanciación es a través de personas

121. 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 representación:
• el ícono dentro
• el color del ícono
• el estilo del doble anillo
• su colocación 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

122. Eventos intermedios
• Un evento intermedio catching, dibujado en el límite de
una actividad es llamado un evento límite
• Mientras la actividad está en ejecución el proceso está
escuchando por la señal
• Si la señal ocurre antes que la actividad este completa
el flujo de secuencia de salida del evento, llamado flujo
de excepción, es disparado
• Si la actividad es completada sin que ocurra la señal, el
flujo de excepción es ignorado y el proceso continúa
con el flujo normal
• Un evento límite no tiene un flujo de secuencia entrante
y tiene solo un flujo de secuencia de salida: el flujo de
excepción

123. Eventos intermedios
• Hay dos tipos de eventos límite
• evento límite interruptor: dibujado con doble anillo
sólido, interrumpe la actividad al que esta atachado el
evento inmediatamente después de producido el
disparador, el flujo del proceso sigue por el flujo de
excepción del evento, el flujo normal ya no continúa
• evento límite no interruptor: dibujado con doble anillo
con línea 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 además se genera un flujo paralelo

124. 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 días, se usa para
decir que sucede si es que la actividad toma más de
tres días

125. Eventos timer

126. Eventos timer
• Evento límite timer
• Si la actividad no está completa cuando sucede el
evento especificado en el timer (la duración
especificada o la fecha/hora establecida) entonces el
flujo de excepción es disparado

127. Eventos timer
• El evento límite timer no interruptor es generalmente
más usado que el interruptor
• Así, si alguna actividad toma más tiempo de lo
establecido se puede hacer algo en adición a la tarea
tal como notificar al solicitante, notificar al supervisor o
solicitar ayuda

128. Evento mensaje
• Send y receive (enviar y recibir) son algo así como
palabras reservadas en BPMN, usadas específicamente
para enviar y recibir un mensaje, representada en el
diagrama por un flujo de mensaje

129. Tarea enviar y Evento de envío 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)
• También podría usarse un mensaje intermedio, pues
hace la misma cosa que una tarea enviar

130. Evento mensaje
No debe usarse una tarea enviar para comunicarse
dentro de un proceso, el envío está implícito por el flujo
de secuencia

131. Evento mensaje
• Las notificaciones que no tienen necesidad de una
acción por parte del receptor para continuar con el
proceso tampoco se representan con una tarea enviar
• Lo más adecuado es agregar una tarea de usuario en el
lane del que envía la notificación e identificando al
receptor en la etiqueta de la tarea

132. Tarea recibir y Evento atrapar mensaje
• El término 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 sólo 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

133. Compuerta de eventos
• Una compuerta de eventos tiene el ícono de evento
intermedio múltiple 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

134. Compuerta de eventos
La compuerta de evento espera por la respuesta o timeout, lo que ocurra
primero

135. Evento mensaje
• Evento límite de mensaje
• Es atachado a una actividad inicia la respuesta al mensaje si
este llega mientras la tarea está en ejecución
• Un evento limite interruptor aborta la actividad inmediatamente y
sale sobre el flujo de excepción
• Un evento limite no interruptor deja que la tarea termine y que
siga el flujo principal del proceso e inicia el flujo de excepción e
forma paralela
• Si la actividad es completada antes que llegue el mensaje el flujo
de excepción no es ejecutado y el flujo sigue su ruta normal

136. Evento mensaje
El mismo mensaje puede ser recibido en múltiples eventos límite

137. Evento mensaje
Si la acción disparada es la misma para cada actividad debe
usarse un evento límite de mensaje sobre un subproceso que
agrupe las actividades

138. Evento error
• Representa un estado final de excepción de una
actividad dentro de un proceso
• Solo existen:
• Evento límite de error interruptor
• Evento fin de error
• Una señal de error no puede ser lanzada ni atrapada en
un evento intermedio y no existe un evento de inicio e
error
• Un evento límite de error hace que al producirse el error
en la ejecución de la actividad se ejecute el flujo de
excepción
• Si la actividad se ejecuta correctamente el evento error
no se produce

139. Evento error
• Pueden existir varios eventos de error sobre una misma
tarea representando diferentes excepciones y estados
finales
Un evento límite de error sobre una tarea es equivalente a
evaluar el resultado del estado de la tarea con una
compuerta

140. Evento error
• Un evento fin de error en un subproceso lanza una señal de
error al límite del subproceso, donde es capturado por el
evento límite de error y continúa por el flujo de excepción
• Este es llamado el patrón 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
límite de error referencian al mismo código de error
• Como el código de error no aparece en el diagrama y
aplicamos el principio que dice que las etiquetas del throw y
del catch deben coincidir

141. Evento error

142. Ejercicio de modelado
Modelado de un proceso con eventos intermedios

143. TEMARIO SESIÓN 6
Iteración y alineamiento de instancias
Simulación de procesos

144. PRODUCTO DE APRENDIZAJE
ESPERADO SESIÓN 6
Utiliza actividades que se realizan repetidas veces
Comprende los principios de la simulación de procesos

145. Contenido de la Sesión
• Bucles
• Multi-instancias
• Actividades repetidas
• Uso de múltiples pools
• Simulación de modelos de negocio

146. 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 programación
• La actividad se realiza una vez y entonces se evalúa la
condición del bucle (una expresión booleana), si la
condición es verdadera se realiza la actividad una siguiente
vez y se evalúa la condición otra vez
• Esta iteración puede continuar indefinidamente o puede
establecerse un límite superior
• Cuando la condición es falsa el flujo de secuencia de salida
de la actividad es habilitado

147. Bucles
• Es recomendable indicar la condición en un text annotation
• Con las actividades en bucle la iteración es siempre
secuencial, la segunda iteración no puede empezar hasta
que la primera ha finalizado y la condición del bucle es
verdadera
• Los dos gráficos siguiente representan lo mismo

148. Multi instancias
• Se representa con un ícono de tres líneas paralelas en la
parte inferior central de una actividad
• Es similar al For-Each en programación y significa realizar la
actividad una vez por cada item en una lista
• Una actividad de múltiples instancias sólo tiene sentido
cuando la data de las instancias del proceso tiene algún tipo
de colección, tal como los items en una orden
• Cada orden no tiene el mismo número 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 serán requeridas

149. 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 líneas son dibujadas de forma
horizontal

150. Multi instancias
Los dos gráficos representan lo mismo

151. Ejercicio de modelado
Modelado de un proceso de contratación para un puesto de
trabajo

152. Ejercicio de modelado

153. Ejercicio de modelado

154. Ejercicio de modelado

155. Uso de múltiples pools
• En algunas ocasiones no es posible modelar un proceso de
negocio de principio a fin en un solo proceso
• La razón es que las instancias de las actividades no están
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 múltiples pools, esto es un proceso BPMN múltiple

156. Ejercicio de modelado
Modelado de un proceso de contratación para un
puesto de trabajo utilizando múltiples pools

157. Ejercicio de modelado

158. Simulación de modelos de negocio
• Ventajas de la simulación sobre las pruebas reales:
• Velocidad
• Menor costo
• No interfiere con las operaciones reales
• Usos
• Entrenamiento y aprendizaje
• Persuasión y ventas
• Análisis de situaciones de negocios
• Verificación y validación

159. Tipos de simulación
• Descripción visual
• Se presenta al usuario una descripción animada
del modelo de negocios
• Escenario de simulación
• Se muestran entornos de negocios simulados
para tomar acción y hacer decisiones
• Simulación numérica
• Se presentan al usuario valores de entrada y
parámetros de decisión de un modelos de
negocios simulado

160. Descripción visual
• Usado principalmente en:
• Enseñanza y aprendizaje
• Verificación y validación
• Ejemplos:
• Se presenta al usuario una animación para
comprender mejor algún patrón complejo
• El usuario sigue el flujo de proceso durante la
simulación y valida la lógica

161. Escenario de simulación
• Usado principalmente en:
• Enseñanza y aprendizaje
• Ejemplos:
• En gestión de procesos
• Específicos a la industria

162. Simulación numérica
• Usado principalmente en:
• Enseñanza y aprendizaje
• Persuasión y ventas
• Análisis de situación de negocios
• Verificación y validación
• Ejemplos:
• Análisis de capacidad y ciclos de tiempo
• Requerimientos de productos
• Evaluación del riesgo financiero
• Contexto económico para hacer pronósticos

163. Simulación de modelos de negocio
• Demo número 1

164. Referencias bibliográficas
• BPMN Method and Style – Bruce Silver
• Modeling and Simulation in Business Process
Management – Denis Gagné