Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Diseño de Flujos de Trabajo
Capacidades a desarrollar propuestas para el curso 
1. Utiliza los modelos de procesos como una 
herramienta para la mejor...
TEMARIO SESIÓN 1 
Conceptos básicos de flujo de trabajo y su relación 
con los procesos de negocio.
PRODUCTO DE APRENDIZAJE ESPERADO 
SESIÓN 1 
Conoce las formas más usadas de BPMN 
Crea modelos básicos de proceso de negoc...
Contenido de la Sesión 
• Características de los buenos modelos 
• Definiciones 
• Actividades 
• Procesos 
• Lógica de pr...
Características de los buenos modelos 
• Correctos 
• El diagrama no viola ninguna especificación de BPMN 
• Claros 
• La ...
¿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...
Actividades 
• En BPMN una actividad es una acción, una unidad de 
trabajo realizado, es el único elemento de BPMN que 
ti...
Procesos 
• En BPMN un proceso es una secuencia de actividades 
dirigiéndose desde un estado inicial de una instancia del ...
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 ...
Lógica de procesos 
• ¿Existen diferentes estados finales del proceso como 
uno de éxito y otros que expresan fallas o aba...
Orquestación 
• BPMN sólo describe procesos en los que la lógica de 
procesos es explicita 
• Cada instancia del proceso d...
Orquestación 
• La lógica del proceso dice: Si el paso de Aprobación 
termina en el estado aprobado entonces sigue esta 
r...
Orquestación 
• BPMN asume que los datos de todas las instancias 
están disponibles para la lógica del proceso 
• Con esta...
Niveles de BPMN 
• Existen tres niveles de modelado en BPMN, que 
ayudan a separar las formas y símbolos que serán 
usados...
Ejercicio de modelado 
Proceso de pedidos
Símbolos para modelos descriptivos 
• Para modelar procesos de nivel 1 son necesarios solo algunas 
formas y símbolos, est...
Actividades 
• Una actividad representa una unidad de trabajo 
realizado en el proceso. Es siempre representada por 
un re...
Tarea 
• Una tarea es representada en el diagrama por la forma 
actividad, un rectángulo redondeado con el tipo de tarea 
...
Tarea 
Fila superior: Tarea de usuario, tarea de servicio, tarea abstracta 
Fila inferior: Tarea de envío de mensaje, tare...
Tarea 
• Una tarea de usuario representa a una tarea realizada 
por una persona 
• Una tarea de servicio representa a una ...
Tarea manual vs. Tarea de usuario 
• Una tarea manual, sólo debería ser usada en procesos 
que son o serán automatizados 
...
Tarea script vs. Tarea de servicio 
• Una tarea script debería usarse en procesos 
ejecutables 
• En un proceso no ejecuta...
Tarea script vs. Tarea de servicio 
• Debido a que los motores de proceso están usualmente 
muy ocupados ejecutando la lóg...
Subprocesos 
• Un subproceso es una actividad compuesta, que 
representa a una actividad con subpartes que pueden 
ser des...
Subprocesos 
Figura superior: Subproceso colapsado en un diagrama 
padre 
Figura inferior: Subproceso expandido en un diag...
Subprocesos 
• Alternativamente un subproceso expandido puede 
aparecer en un diagrama padre como una forma de 
actividad ...
Subprocesos 
Los subprocesos son muy valiosos en BPMN cuando son 
diagramados y usados correctamente, su valor se manifies...
Subprocesos 
2. Permite el modelado top down o jerárquico 
• Esto permite empezar desde el diagrama de alto 
nivel , en el...
Subprocesos 
3. Permite hacer claros los límites de gobierno 
• Los subprocesos facilitan la distribución de la propiedad ...
Subprocesos 
4. Permite definir el alcance del evento manejador 
• Los subprocesos son muy útiles para definir los 
límite...
Call Activity 
• Si un subproceso es usado en más de un proceso es 
mejor definirlo independientemente y llamarlo desde 
c...
TEMARIO SESIÓN 2 
Elementos de la paleta de modelado de 
nivel descriptivo
PRODUCTO DE APRENDIZAJE ESPERADO 
SESIÓN 2 
Utiliza los elementos de BPMN para crear modelos 
descriptivos
Contenido de la Sesión 
• Símbolos para modelos descriptivos (segunda parte) 
• Compuertas 
• Eventos de inicio y de fin 
...
Compuertas 
• Una compuerta controla el flujo del proceso, 
dividiéndolo en rutas alternativas 
• Si no existe una compuer...
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 símbolo dentro del rombo 
• Si el romb...
Compuerta exclusiva 
Incorrecto: Una compuerta no puede hacer una decisión, 
solo examina una condición de los datos
Compuerta exclusiva 
Correcto: La compuerta examina una condición de los 
datos registrados en la tarea Revisar reporte
Compuerta Paralela 
• Esta compuerta tiene un flujo de secuencia de 
entrada y múltiples flujos de secuencia de salida y 
...
Compuerta Paralela 
Flujo validado con rutas paralelas sin usar compuertas
Compuerta Paralela 
• Una compuerta paralela con múltiples flujos de entrada y 
uno de salida es llamado parallel join o A...
Compuerta Paralela 
La compuerta es necesaria para juntar los flujos
Evento de inicio 
• Un evento de inicio es siempre representado con un 
círculo con un borde delgado 
• Su propósito es in...
Evento de inicio 
• BPMN 2.0 define siete eventos de inicio, en la paleta 
de nivel 1 se incluyen sólo 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...
Evento de inicio mensaje 
• Un evento de inicio mensaje, con un ícono de sobre 
dentro, indica que el proceso es disparado...
Evento de inicio timer 
• Un evento de inicio timer, con un ícono de reloj 
dentro, indica que el proceso es calendarizado...
Evento de inicio múltiple 
• Un evento de inicio múltiple, con un pentágono 
dentro, indica que el proceso podría ser inic...
Evento de inicio múltiple
Eventos de inicio alternativos 
• En algunas ocasiones la actividad inicial del proceso 
depende de que disparador fue el ...
Eventos de inicio alternativos 
Inicio dependiente del canal
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 
proc...
Evento de fin none 
• Un evento de fin none no lleva un ícono dentro e 
indica que no es enviado ningún resultado cuando e...
Evento de fin mensaje 
• Un evento de fin mensaje, con un ícono de sobre 
negro dentro, indica que un mensaje es enviado a...
Evento de fin terminate 
• Un evento de fin terminate, con un ícono circular 
negro dentro, indica que el proceso o subpro...
Evento de fin múltiple 
• Un evento de fin múltiple, con un ícono de pentágono 
negro dentro es similar al evento de inici...
Flujos de secuencia 
• Es un conector dibujado como una línea sólida y 
representa la ejecución secuencial de los pasos de...
Flujos de mensaje 
• Es un conector dibujado como una línea discontinua y 
representa la comunicación entre el proceso y u...
Flujos de mensaje 
• En algunos casos un flujo de mensaje indica la 
posibilidad de envío del mensaje no la certeza del 
e...
Pool 
• Es una caja de forma rectangular, puede ser 
horizontal con la etiqueta sobre la izquierda, o vertical 
con la eti...
Pool 
Figura superior: Pool de caja negra 
Figura inferior: Pool de proceso
Lane 
• En BPMN 2.0 un lane es una subdivisión opcional de 
un proceso 
• Se usa generalmente para asociar actividades de ...
Data object y Data store 
• Un data object representa una variable local en un 
proceso, un dato temporal dentro de la ins...
Data object y Data store 
• Un conector de asociación dirigido al data store 
representa una actualización y una asociació...
Text annotation y Group 
• El artefacto text annotation permite agregar texto, 
este debe estar atachado por una asociació...
Text annotation y Group 
Text annotation y 
association 
Group
Ejercicio de modelado 
Modelado de un proceso a nivel descriptivo
TEMARIO SESIÓN 3 
Aplicación de la metodología de modelado de 
procesos de nivel descriptivo
PRODUCTO DE APRENDIZAJE 
ESPERADO SESIÓN 3 
Modela procesos descriptivos siguiendo los pasos de una 
metodología
Contenido de la Sesión 
• Objetivos de la metodología 
• Modelado top-down 
• Estados finales 
• Pasos de la metodología 
...
Objetivos de la metodología 
• La metodología es como una receta para ir desde una 
página en blanco hasta un modelo en BP...
Objetivos de la metodología 
Completo 
• Los elementos esenciales de la lógica de proceso de 
principio a fin deben ser ca...
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 pa...
Objetivos de la metodología 
Entendible por el negocio y por TI 
• EL lenguaje BPMN puede ser compartido por 
usuarios de ...
Objetivos de la metodología 
Tiene consistencia estructural 
• Ante el mismo conjunto de hechos acerca de como el 
proceso...
Modelado Top-down 
• Top-down puede entenderse como jerárquico 
• El modelo es representado de principio a fin como un 
co...
Estados finales 
• Cuando una instancia de una tarea termina es 
importante saber como terminó, quizá la actividad 
tiene ...
Estados finales 
• Sin embargo, si la actividad es un subproceso es posible 
hacer sus estados finales visibles en el diag...
Estados finales 
Distinguir los estados finales de un subproceso ayuda a 
la trazabilidad
Paso 1: Determinar el alcance del 
proceso • El modelado jerárquico inicia con un acuerdo del 
alcance del proceso, donde ...
Paso 2: Crear el mapa de alto nivel 
• Esto consiste en una lista de las principales 
actividades del proceso, idealmente ...
Paso 3: Diagramar el proceso de alto 
nivel • Cada actividad del mapa de alto nivel se convierte en 
un una tarea o un sub...
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 
excepción
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 poc...
Paso 5: Adicionar flujos de mensaje 
• En estricto, los flujos de mensaje no son requeridos 
en BPMN, la especificación lo...
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 metodología
TEMARIO SESIÓN 4 
Reglas de estilo para modelos a nivel descriptivo
PRODUCTO DE APRENDIZAJE 
ESPERADO SESIÓN 4 
Aplica reglas de estilo para crear modelos de procesos
Contenido de la Sesión 
• Reglas de estilo para modelos a nivel descriptivo 
• Modelado de un proceso aplicando las reglas...
Reglas de estilo 
• Regla 1: Usar íconos y etiquetas para hacer la lógica 
del proceso clara desde el diagrama impreso 
• ...
Reglas de estilo 
• Regla 2: Cree modelos jerárquicos, de modo que cada 
proceso entre en una página 
• Regla 3: Use una c...
Reglas de estilo 
• Regla 4: Inicie los procesos que atienden al cliente con 
un evento de inicio de mensaje recibiendo un...
Reglas de estilo 
• Regla 5: Modele las unidades internas de la organización 
como lanes dentro de un mismo pool, no como ...
Reglas de estilo 
• Regla 6: Etiquete los pools del proceso con el nombre 
del proceso, etiquete los pools de caja negra c...
Reglas de estilo 
• Regla 8: Etiquete las actividades en la forma Verbo- 
Nombre 
• Regla 9: Use eventos de inicio dispara...
Reglas de estilo
Reglas de estilo 
• Regla 11: Mostrar los flujos de mensaje en todos los 
eventos de mensaje 
• Regla 12: Haga coincidir l...
Reglas de estilo
Reglas de estilo 
• Regla 14: Dos eventos de fin en un proceso no 
deberían tener el mismo nombre
Reglas de estilo 
• Regla 15: Dos actividades en un proceso no deberían 
tener el mismo nombre
Reglas de estilo 
• Regla 16: Un subproceso debería tener un evento de 
inicio none (no disparador) 
• Regla 17: Un pool d...
Reglas de estilo 
• Regla 19: No use una compuerta XOR para juntar rutas 
alternativas, solo conecte los flujos directamen...
Reglas de estilo 
• Regla 20: No use una compuerta AND para juntar rutas 
paralelas en un evento de fin de tipo none, un e...
Reglas de BPMN 2.0 
• Regla 21: Un flujo de secuencia no debe cruzar los 
límites de un pool
Reglas de BPMN 2.0 
• Regla 22: Un flujo de secuencia no debe cruzar los 
límites 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 sólo puede conectarse 
a una actividad, compuerta o evento 
• Regla ...
Ejercicio de modelado 
Modelado de un proceso aplicando las reglas de estilo
TEMARIO SESIÓN 5 
Modelado de procesos a nivel analítico con 
eventos
PRODUCTO DE APRENDIZAJE 
ESPERADO SESIÓN 5 
Utiliza eventos intermedios en el modelado de procesos
Contenido de la Sesión 
• Eventos 
• Evento Temporizador 
• Evento Mensaje 
• Gateway de eventos 
• Evento Error 
• Modela...
Comportamiento de eventos disparadores 
• Un evento de inicio de tipo mensaje crea una nueva 
instancia de proceso cuando ...
Eventos intermedios 
• Son dibujados como un doble anillo y ocurren luego que 
el proceso ya inició y antes de que termine...
Eventos intermedios 
• Un evento intermedio catching, dibujado en el límite de 
una actividad es llamado un evento límite ...
Eventos intermedios 
• Hay dos tipos de eventos límite 
• evento límite interruptor: dibujado con doble anillo 
sólido, in...
Eventos timer 
• Evento timer catching 
• Un evento timer intermedio significa un aplazamiento 
• Puede esperar durante un...
Eventos timer
Eventos timer 
• Evento límite timer 
• Si la actividad no está completa cuando sucede el 
evento especificado en el timer...
Eventos timer 
• El evento límite timer no interruptor es generalmente 
más usado que el interruptor 
• Así, si alguna act...
Evento mensaje 
• Send y receive (enviar y recibir) son algo así como 
palabras reservadas en BPMN, usadas específicamente...
Tarea enviar y Evento de envío de 
mensaje • Un mensaje puede ser enviado desde pool de caja 
negra, un evento de mensaje ...
Evento mensaje 
No debe usarse una tarea enviar para comunicarse 
dentro de un proceso, el envío está implícito por el flu...
Evento mensaje 
• Las notificaciones que no tienen necesidad de una 
acción por parte del receptor para continuar con el 
...
Tarea recibir y Evento atrapar mensaje 
• El término recibir se aplica solo a mensajes, 
comunicaciones desde participante...
Compuerta de eventos 
• Una compuerta de eventos tiene el ícono de evento 
intermedio múltiple dentro y en cada salida hay...
Compuerta de eventos 
La compuerta de evento espera por la respuesta o timeout, lo que ocurra 
primero
Evento mensaje 
• Evento límite de mensaje 
• Es atachado a una actividad inicia la respuesta al mensaje si 
este llega mi...
Evento mensaje 
El mismo mensaje puede ser recibido en múltiples eventos límite
Evento mensaje 
Si la acción disparada es la misma para cada actividad debe 
usarse un evento límite de mensaje sobre un s...
Evento error 
• Representa un estado final de excepción de una 
actividad dentro de un proceso 
• Solo existen: 
• Evento ...
Evento error 
• Pueden existir varios eventos de error sobre una misma 
tarea representando diferentes excepciones y estad...
Evento error 
• Un evento fin de error en un subproceso lanza una señal de 
error al límite del subproceso, donde es captu...
Evento error
Ejercicio de modelado 
Modelado de un proceso con eventos intermedios
TEMARIO SESIÓN 6 
Iteración y alineamiento de instancias 
Simulación de procesos
PRODUCTO DE APRENDIZAJE 
ESPERADO SESIÓN 6 
Utiliza actividades que se realizan repetidas veces 
Comprende los principios ...
Contenido de la Sesión 
• Bucles 
• Multi-instancias 
• Actividades repetidas 
• Uso de múltiples pools 
• Simulación de m...
Bucles 
• Una actividad repetida se representa por una flecha circular 
en la parte inferior central de la actividad 
• Es...
Bucles 
• Es recomendable indicar la condición en un text annotation 
• Con las actividades en bucle la iteración es siemp...
Multi instancias 
• Se representa con un ícono de tres líneas paralelas en la 
parte inferior central de una actividad 
• ...
Multi instancias 
• Conocer el numero de iteraciones al inicio de la actividad es 
una diferencia fundamental entre activi...
Multi instancias 
Los dos gráficos representan lo mismo
Ejercicio de modelado 
Modelado de un proceso de contratación para un puesto de 
trabajo
Ejercicio de modelado
Ejercicio de modelado
Ejercicio de modelado
Uso de múltiples pools 
• En algunas ocasiones no es posible modelar un proceso de 
negocio de principio a fin en un solo ...
Ejercicio de modelado 
Modelado de un proceso de contratación para un 
puesto de trabajo utilizando múltiples pools
Ejercicio de modelado
Simulación de modelos de negocio 
• Ventajas de la simulación sobre las pruebas reales: 
• Velocidad 
• Menor costo 
• No ...
Tipos de simulación 
• Descripción visual 
• Se presenta al usuario una descripción animada 
del modelo de negocios 
• Esc...
Descripción visual 
• Usado principalmente en: 
• Enseñanza y aprendizaje 
• Verificación y validación 
• Ejemplos: 
• Se ...
Escenario de simulación 
• Usado principalmente en: 
• Enseñanza y aprendizaje 
• Ejemplos: 
• En gestión de procesos 
• E...
Simulación numérica 
• Usado principalmente en: 
• Enseñanza y aprendizaje 
• Persuasión y ventas 
• Análisis de situación...
Simulación de modelos de negocio 
• Demo número 1
Referencias bibliográficas 
• BPMN Method and Style – Bruce Silver 
• Modeling and Simulation in Business Process 
Managem...
Curso completo bpmn
Próxima SlideShare
Cargando en…5
×

Curso completo bpmn

7.258 visualizaciones

Publicado el

  • Sé el primero en comentar

Curso completo bpmn

  1. 1. Diseño de Flujos de Trabajo
  2. 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. 3. TEMARIO SESIÓN 1 Conceptos básicos de flujo de trabajo y su relación con los procesos de negocio.
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Ejercicio de modelado Proceso de pedidos
  17. 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. 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. 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. 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. 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. 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. 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. 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. 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. 26. Subprocesos Figura superior: Subproceso colapsado en un diagrama padre Figura inferior: Subproceso expandido en un diagrama separado
  27. 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. 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. 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. 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. 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. 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. 33. TEMARIO SESIÓN 2 Elementos de la paleta de modelado de nivel descriptivo
  34. 34. PRODUCTO DE APRENDIZAJE ESPERADO SESIÓN 2 Utiliza los elementos de BPMN para crear modelos descriptivos
  35. 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. 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. 37. Compuertas Incorrecto: Las rutas alternativas requieren una compuerta en BPMN
  38. 38. Compuertas Correcto: Las rutas alternativas requieren una compuerta en BPMN
  39. 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. 40. Compuerta exclusiva Incorrecto: Una compuerta no puede hacer una decisión, solo examina una condición de los datos
  41. 41. Compuerta exclusiva Correcto: La compuerta examina una condición de los datos registrados en la tarea Revisar reporte
  42. 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. 43. Compuerta Paralela Flujo validado con rutas paralelas sin usar compuertas
  44. 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. 45. Compuerta Paralela La compuerta es necesaria para juntar los flujos
  46. 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. 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. 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. 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. 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. 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. 52. Evento de inicio múltiple
  53. 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. 54. Eventos de inicio alternativos Inicio dependiente del canal
  55. 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. 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. 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. 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. 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. 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. 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. 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. 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. 64. Pool Figura superior: Pool de caja negra Figura inferior: Pool de proceso
  65. 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. 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. 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. 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. 69. Text annotation y Group Text annotation y association Group
  70. 70. Ejercicio de modelado Modelado de un proceso a nivel descriptivo
  71. 71. TEMARIO SESIÓN 3 Aplicación de la metodología de modelado de procesos de nivel descriptivo
  72. 72. PRODUCTO DE APRENDIZAJE ESPERADO SESIÓN 3 Modela procesos descriptivos siguiendo los pasos de una metodología
  73. 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. 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. 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. 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. 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. 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. 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. 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. 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. 82. Estados finales Distinguir los estados finales de un subproceso ayuda a la trazabilidad
  83. 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. 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. 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. 86. Paso 3: Diagramar el proceso de alto nivel Diagrama BPMN de alto nivel – Happy path
  87. 87. Paso 3: Diagramar el proceso de alto nivel Diagrama BPMN de alto nivel – Incluyendo rutas de excepción
  88. 88. Paso 3: Diagramar el proceso de alto nivel Diagrama BPMN de alto nivel – Mostrando pool y lanes
  89. 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. 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. 91. Paso 5: Adicionar flujos de mensaje
  92. 92. Paso 5: Adicionar flujos de mensaje Order car from factory de nivel hijo expandido con flujos de mensaje
  93. 93. Ejercicio de modelado Modelado de un proceso aplicando la metodología
  94. 94. TEMARIO SESIÓN 4 Reglas de estilo para modelos a nivel descriptivo
  95. 95. PRODUCTO DE APRENDIZAJE ESPERADO SESIÓN 4 Aplica reglas de estilo para crear modelos de procesos
  96. 96. Contenido de la Sesión • Reglas de estilo para modelos a nivel descriptivo • Modelado de un proceso aplicando las reglas de estilo
  97. 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. 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. 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. 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. 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. 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. 103. Reglas de estilo
  104. 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. 105. Reglas de estilo
  106. 106. Reglas de estilo • Regla 14: Dos eventos de fin en un proceso no deberían tener el mismo nombre
  107. 107. Reglas de estilo • Regla 15: Dos actividades en un proceso no deberían tener el mismo nombre
  108. 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. 109. Reglas de estilo • Regla 19: No use una compuerta XOR para juntar rutas alternativas, solo conecte los flujos directamente
  110. 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. 111. Reglas de BPMN 2.0 • Regla 21: Un flujo de secuencia no debe cruzar los límites de un pool
  112. 112. Reglas de BPMN 2.0 • Regla 22: Un flujo de secuencia no debe cruzar los límites de un subproceso
  113. 113. Reglas de BPMN 2.0 • Regla 23: Un flujo de mensaje no puede conectar nodos en el mismo pool
  114. 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. 115. Ejercicio de modelado Modelado de un proceso aplicando las reglas de estilo
  116. 116. TEMARIO SESIÓN 5 Modelado de procesos a nivel analítico con eventos
  117. 117. PRODUCTO DE APRENDIZAJE ESPERADO SESIÓN 5 Utiliza eventos intermedios en el modelado de procesos
  118. 118. Contenido de la Sesión • Eventos • Evento Temporizador • Evento Mensaje • Gateway de eventos • Evento Error • Modelado de un proceso con eventos intermedios
  119. 119. 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
  120. 120. 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
  121. 121. 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
  122. 122. 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
  123. 123. 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
  124. 124. Eventos timer
  125. 125. 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
  126. 126. 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
  127. 127. 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
  128. 128. 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
  129. 129. 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
  130. 130. 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
  131. 131. 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
  132. 132. 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
  133. 133. Compuerta de eventos La compuerta de evento espera por la respuesta o timeout, lo que ocurra primero
  134. 134. 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
  135. 135. Evento mensaje El mismo mensaje puede ser recibido en múltiples eventos límite
  136. 136. 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
  137. 137. 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
  138. 138. 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
  139. 139. 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
  140. 140. Evento error
  141. 141. Ejercicio de modelado Modelado de un proceso con eventos intermedios
  142. 142. TEMARIO SESIÓN 6 Iteración y alineamiento de instancias Simulación de procesos
  143. 143. PRODUCTO DE APRENDIZAJE ESPERADO SESIÓN 6 Utiliza actividades que se realizan repetidas veces Comprende los principios de la simulación de procesos
  144. 144. Contenido de la Sesión • Bucles • Multi-instancias • Actividades repetidas • Uso de múltiples pools • Simulación de modelos de negocio
  145. 145. 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
  146. 146. 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
  147. 147. 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
  148. 148. 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
  149. 149. Multi instancias Los dos gráficos representan lo mismo
  150. 150. Ejercicio de modelado Modelado de un proceso de contratación para un puesto de trabajo
  151. 151. Ejercicio de modelado
  152. 152. Ejercicio de modelado
  153. 153. Ejercicio de modelado
  154. 154. 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
  155. 155. Ejercicio de modelado Modelado de un proceso de contratación para un puesto de trabajo utilizando múltiples pools
  156. 156. Ejercicio de modelado
  157. 157. 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
  158. 158. 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
  159. 159. 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
  160. 160. Escenario de simulación • Usado principalmente en: • Enseñanza y aprendizaje • Ejemplos: • En gestión de procesos • Específicos a la industria
  161. 161. 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
  162. 162. Simulación de modelos de negocio • Demo número 1
  163. 163. Referencias bibliográficas • BPMN Method and Style – Bruce Silver • Modeling and Simulation in Business Process Management – Denis Gagné

×