Monografía BPMN

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/346009020
MONOGRAFÍA: Primeros pasos para el modelado de procesos con BPMN
Book · November 2020
CITATIONS READS
0 54
11 authors, including:
Yanelis Pavón-González Yadary C. Ortega-González

Universidad Tecnológica de la Habana, José Antonio Echeverría Universidad Tecnológica de la Habana, José Antonio Echeverría
16 PUBLICATIONS 8 CITATIONS 24 PUBLICATIONS 11 CITATIONS
SEE PROFILE SEE PROFILE
Sajay Souchay Alzugaray Marta Beatriz Infante Abreu

Universidad Tecnológica de la Habana, José Antonio Echeverría Universidad Tecnológica de la Habana, José Antonio Echeverría
4 PUBLICATIONS 0 CITATIONS 54 PUBLICATIONS 112 CITATIONS
SEE PROFILE SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Competencias y roles asociados a la Getión de Arquitecturas Empresariales View project
Proyecto PBKM View project
All content following this page was uploaded by Yanelis Pavón-González on 18 November 2020.
The user has requested enhancement of the downloaded file.

Universidad Tecnológica de la Habana
“José Antonio Echeverría”
FACULTAD DE INGENIERÍA INDUSTRIAL

DEPARTAMENTO DE INFORMÁTICA EMPRESARIAL
MONOGRAFÍA
Primeros pasos para el modelado de procesos
con BPMN.
AUTORES
Yanelis Pavón González
Yadary Cecilia Ortega González
Sajay Souchay Alzugaray
Marta Beatriz Infante Abreu
Dayron Cruz Hondal
Lourdes Santos Planas
Luis Ramiro Mendiburo Martínez
Jose Raul Lorenzo Sanchez
Patricia Airela Abreu Fong
Nancy Arencibia Álvarez
Jeffrey Blanco González

CONTENIDO
1. INTRODUCCIÓN........................................................................................................................................ 3
2. NOTACIÓN PARA EL MODELADO DE PROCESOS DE NEGOCIO ......................................................... 4
2.1. Representación de actividades ............................................................................................................ 7
2.2. Uso de eventos en el flujo de secuencia.............................................................................................. 9
2.3. Uso de compuertas en el flujo de sencuencia.................................................................................... 11
2.4. Representación de responsables de ejecutar las atividades.............................................................. 14
2.5. Representación del flujo de información del proceso ......................................................................... 15
3. EJERCICIO DEMOSTRATIVO DE MODELADO DE PROCESO ............................................................. 17
4. COLECCIÓN DE EJERCICIOS DE MODELACIÓN DE PROCESOS....................................................... 29
4.1. Parte I: Interpretación y análisis del funcionamiento del proceso. ...................................................... 29
4.1.1. Descripción de reglas ................................................................................................................. 29
4.1.2. Gestión de multas ...................................................................................................................... 29
4.1.3. Gestión contrato ......................................................................................................................... 30
4.1.4. Taller de Laptops........................................................................................................................ 31
4.1.5. Centro quirúrgico ........................................................................................................................ 33
4.2. Parte II: Modelación de procesos organizacionales con la notación BPMN. ...................................... 35
4.2.1. Representación de reglas ........................................................................................................... 35
4.2.2. Encendido del teléfono celular.................................................................................................... 35
4.2.3. Tienda discos duros ................................................................................................................... 35
4.2.4. Gestión de solicitudes de compra. .............................................................................................. 36
4.2.5. Aseguramiento para eventos. ..................................................................................................... 37
4.2.6. Lavanderías Sirenas................................................................................................................... 38
4.2.7. Servicios de Auditoría................................................................................................................. 39
4.2.8. Reservación de asientos en un cine. .......................................................................................... 40
4.2.9. Gestión del proceso clave de un restaurante. ............................................................................. 41
4.2.10. Servicios a proyectos. ................................................................................................................ 42
5. REFERENCIAS ........................................................................................................................................ 46
1. INTRODUCCIÓN
Soportar la flexibilidad y competitividad es un desafío que las organizaciones enfrentan en la
actualidad debido a los contantes cambios que ocurren en el entorno, marcado por el desarrollo
tecnológico y las exigencias del mercado (clientes, competidores y el gobierno) (Ayad, 2013, Michael
et al., 2018, Erol, 2017). En este sentido, se hace más emergente desarrollar capacidades de gestión
de procesos organizacionales orientados a la mejora continua y a la innovación (Dumas et al., 2018,
ISO-9001, 2015, Satyal et al., 2018, Martin et al., 2017), al mismo ritmo en que ocurren los cambios
del entorno (Mojca et al., 2018).
Los procesos especifican el conocimiento de cómo la organización funciona (Know how) (Rahimi, 2016).
En este sentido, se necesita sistematicidad en la gestión del cambio de su diseño orientado a la
innovación (Satyal et al., 2018, Martin et al., 2017, Delgado Fernández, 2018), de modo que las
organizaciones estén en capacidad de adaptarse a los cambios del entorno e incorporar el desarrollo
tecnológico (AbdEllatif et al., 2017, Mojca et al., 2018, Lagos et al., 2017).
Una de las aproximaciones que abordan la innovación de procesos, son las desarrolladas en el marco de
los sistemas de gestión de procesos de negocio (BPMS, por sus siglas en inglés) (Satyal et al., 2018,
Ouali et al., 2018, Karle and Teichenthaler, 2018, Dumas et al., 2018) con vistas a la automatización
(Gómez Estupiñan, 2014). Asimismo, se han desarrollado soluciones en el marco de aplicación de un
sistema de gestión de la calidad a través de la norma ISO 9001:2015. Dicha norma aplica el principio de
enfoque a proceso y el pensamiento basado en riesgos, que conduzca al aprovechamiento de las
oportunidades y la prevención de las situaciones no deseadas (ISO-9001, 2015). Por otro lado, también se
han desarrollado soluciones en el marco de la reingeniería de procesos (Dachyar and Sanjiwo, 2018,
Maryam and Khan, 2017), cuyo propósito es el cambio radical de los procesos como consecuencia de la
adopción de tecnologías de la información en la organización (Vilasdechanon and Sopadang, 2018,
Antonella et al., 2018, Kruger, 2017).
Cada una de estas aproximaciones están enmarcadas en la disciplina de gestión de procesos

organizacionales (BPM, por sus siglas en inglés) o también conocido como la gestión por proceso. BPM
concibe el principio de enfoque a procesos para brindar un soporte integral para mejorar, innovar y
administrar los procesos organizacionales aprovechando las capacidades de las tecnologías de la
información (Ortbach et al., 2012, GARIMELLA et al., 2012).
Ciertamente para mejorar los procesos organizacionales es preciso ser consiente del objeto de mejora
y los factores que afectan su comportamiento. Para ello, el analista de proceso, quien es el
3
responsable del análisis, diseño y mejora, emplea herramientas de modelado como técnica
fundamental del trabajo ingenieril (Krogstie, 2016). Por ello es importante que este analista adquiera
conocimiento y desarrolle habilidades para la modelación de procesos (Deb and Chaki, 2018).
La siguiente monografía tiene el propósito de abordar el estándar de modelado de procesos de

negocio, conocido como BPMN por sus singlas en inglés. Para ello se presenta la resolución de un
caso de estudio que ayude a los modeladores a detectar reglas de modelado en diferentes formatos
y convertirlos en especificaciones de un modelo de proceso representado con BPMN. Asimismo, se
proponen un compendio de ejercicios con diferentes niveles de complejidad para el desarrollo de
habilidades de modelado.
2. NOTACIÓN PARA EL MODELADO DE PROCESOS DE NEGOCIO

Desarrollar capacidades de modelado de procesos organizacionales es fundamental para el éxito de
proyectos BPM. Dicha capacidad se realiza para representar procesos organizacionales diseñados.
Realizar conscientemente el modelado de procesos antes de que los procesos sean implementados
o ejecutados, permite que se favorezcan los comportamientos deseados y se eviten aquellos que no
lo son. De no ser así, se pueden incurrir en elevados costos de desplegar sistemas software para un
proceso que no tenga el comportamiento adecuado (Xu et al., 2018), o ejecutar procesos mal
concebidos que no conduzcan a los resultados y en consecuencia genere pérdidas de recursos.
Los modelos de proceso que son obtenidos en la etapa de diseño constituyen entradas al resto de las
etapas BPM (Xu et al., 2018), requerido para que puedan ejecutar sus actividades e incluso las propias
etapas de análisis o diseño cuando se necesite incorporar cambios al diseño actual cerrando el ciclo
de BPM. En este sentido, el modelo de proceso, el cual es una explicitación del diseño, constituye una
herramienta de trabajo y comunicación, que debe ser manipulado por todas las partes interesadas
que operan con el conocimiento del diseño de los procesos organizacionales.
Varias son las funciones de BPM que demandan el uso de modelos de procesos, tales como: a)
alineación de las operaciones a la estrategia del negocio, b) mejora de las capacidades de negocio, c)
aseguramiento de la calidad de los resultados, d) prevención y disminución del efecto de riesgos, e)
incrementar el control y la consistencia, f) estandarización y comunicación de los procesos de negocio,
g) gestión del conocimiento del proceso, h) mejora de la eficiencia operacional, i) informatización del
proceso y j) alineación del proceso con las capacidades de aplicaciones (de Oca et al., 2015, Alotaibi,
2016).
4
El modelado de los procesos organizacionales, se ha convertido en una práctica común de las
organizaciones que adoptan un enfoque a procesos. Como consecuencia, muchas organizaciones
mantienen una gran cantidad de documentación de procesos acompañado de modelos gráficos, para
consolidar, compartir y reutilizar el conocimiento del proceso entre las partes interesadas (Erol, 2018).
Para el modelado de gráfico de proceso se han desarrollado varios lenguajes tales como: BPMN
(Leopold et al., 2016), EPC (Loos and Allweyer, 1998), UML (Gu et al., 2012), IDEF0 (Peters and
Peters, 1997), Redes Petri (van der Aalst and van Hee, 1996), entre otros. Cada uno de ellos tiene
artefactos diferentes para la representación gráfica de los procesos, los cuales focalizan la atención
en algún punto de vista del conocimiento de diseño del proceso que se desee analizar. Con el propósito
de estandarizar los diferentes puntos de vistas y aproximaciones que ofrece cada lenguaje, se ha
adoptado mundialmente como un estándar en el campo de la modelación de procesos, BPMN.
BPMN a lo largo de los últimos años ha impulsado como el candidato más prominente para una
industria estándar en el modelado de procesos, similar al ejemplo de la notación UML en el software
ingeniería. Business Process Modelling Notation (BPMN) es un estándar del OMG (Object
Management Group). Es una notación gráfica entendible por los analistas e implementadores,
gestores, clientes, proveedores, etc. Esta notación reduce la distancia entre el diseño de un proceso
de negocio y su implementación. También habilita la visualización de las especificaciones en el
lenguaje XML para la ejecución de procesos.
La principal meta de BPMN es suministrar una notación que sea de fácil entendimiento por todos los
usuarios de procesos de negocio. Esto incluye a los analistas de procesos organizacionales que crean
las versiones iniciales de los modelos de negocio, a los desarrolladores encargados de la
implementación que dará cabida a dichos modelos en forma de sistema de información, o a los
encargados de dirigir y gestionar los procesos. Por tanto, BPMN crea un estándar que intenta llenar
el hueco entre el modelado de negocio y su implementación.
BPMN ayuda a las organizaciones a comprender sus procedimientos internos mediante una notación
gráfica, y les proporciona la capacidad de comunicar estos procedimientos en una forma estándar.
Además, facilita la comprensión de las colaboraciones y transacciones de negocio entre
organizaciones, permitiendo así a las empresas ajustarse más rápidamente a nuevas condiciones
tanto internas como externas. La notación consiste básicamente en un diagrama, llamado BPD
(Business Process Diagram), que no debe ser ambiguo. Un BPD da cabida a uno o varios procesos
según el nivel de abstracción que se use, es decir, un diagrama con varios procesos se podría ver
5
como un conjunto de procesos o un sólo proceso formado por otros. A su vez, los procesos están
compuestos por distintos elementos gráficos.
Una de las razones para el desarrollo de BPMN fue crear un mecanismo sencillo para el desarrollo de
modelos, a la vez de ser capaz de manejar la complejidad inherente a los procesos organizacionales.
La aproximación tomada para la consecución de estos dos requerimientos fue organizar los aspectos
gráficos de la notación en categorías específicas. Así, se consigue un grupo pequeño de categorías
para la notación de manera que alguien que vea un BPD pueda reconocer fácilmente los tipos básicos
de elementos y comprender su comportamiento.
Cuadro 2-1: Elementos básicos de la notación BPMN – OMG 2011
OBJETOS DE OBJETOS DE
CANALES (SWINLANES) DATOS
FLUJO CONEXIÓN
Piscina
Actividades Flujo de secuencia Objeto de dato
Piscinas
Compuertas Flujo de mensaje Mensaje

Carril
Piscina
Carril
Almacén de
Eventos Asociasión Carriles
datos
Objetos de flujos: Son los elementos principales que se describen en BPMN:
- Actividades. Describen el trabajo desarrollado dentro de un proceso de negocio, pueden ser

atómicas o compuestas, se utilizan para modelar tareas y subprocesos y pueden ser iterativas.
- Eventos. Describen algo que sucede durante el desarrollo de un proceso y que afecta su flujo,
genera un disparo a resultado. El borde del elemento determina el tipo de evento. Según el
momento en que ocurra, existen tres tipos básicos de eventos: inicial, intermedio y final.
- Compuertas (Gateways): Controles de secuencia de flujo dentro de un proceso, como un punto de
convergencia o divergencia. Determinan si se bifurca o se combinan las rutas dependiendo de las
condiciones expresadas.
Objetos de conexión: Relacionan los objetos de flujo, y son:
6
- Flujo de Secuencia. Enlaza dos elementos, permiten mostrar la secuencia en que las actividades
se llevarán a cabo. Pueden ser flujos normales, condicionales o por defecto.
- Flujo de Mensaje. Indica el envío de un mensaje entre dos elementos ubicados en piscinas
diferentes. Un flujo de mensaje no puede ser utilizado para conectar objetos de flujos dentro de
una misma piscina.
- Asociación. Se utiliza para conectar artefactos o elementos de datos a un objeto de flujo.
Canales (Swimlanes): Representan los responsables de las actividades en un proceso, por ejemplo,
organizaciones, roles, áreas funcionales o sistemas. Estos son:
- Piscina: Identifica cada uno de los participantes en un proceso. Una piscina puede contener uno o
más carriles. Puede ser abierta (muestra los detalles internos), o cerrada (esconde los detalles
internos).
- Carril: Muestra un rol o área funcional dentro de una piscina, se utiliza para organizar y categorizar
las actividades de acuerdo a funciones o roles de las personas o áreas involucradas en un proceso.
Datos: Representan archivos de datos, objetos de datos o documentos que son producidos y/o
consultados por un proceso o actividad. Los tipos de datos son: dato de entrada, dato de salida, dato
de tipo objeto, colección de objetos de datos, almacén y mensaje.
2.1. Representación de actividades
Una actividad representa algo realizado en un proceso de negocio. Tiene una forma rectangular con
esquinas redondeadas. Las actividades son atómicas (nivel más bajo de detalle representado en el
diagrama) o compuesta (no es atómica, pues existe un nivel más bajo de detalle cuando se expande).
Las actividades atómicas se denominan tareas y las compuestas, subprocesos. En un diagrama BPMN
las actividades se representan de manera secuencial utilizado la línea de secuencia, donde queda
claro cuáles son las actividades que deben ejecutarse primero y cuáles después de acuerdo con las
reglas del proceso. Con BPMN es posible expresar más detalles sobre las actividades, a través de
símbolos ubicados en el artefacto de la actividad como se muestra en el cuadro 2-2. En el libro “BPMN:
Guía de Referencia y Modelado”, puede profundizar más sobre los usos de marcadores de actividad
y tipos de tareas.
7
Cuadro 2-2: BPMN 2.0 – Actividades
Marcador de actividad Tipos de tareas
Tarea Subproceso Compensación Envío Recibir Manual Servicio
Instancias Instancias Ciclo Usuario Regla de Ejecución

múltiples múltiples en negocio de Script
en paralelo
secuencia
En el cuadro 2-3 puede verse un ejemplo donde queda representado una secuencia de actividades.
Note que en el primer diagrama se representa tres actividades. La primera y la segunda son tareas
atómicas de tipo usuario, lo cual significa que la actividad se realiza por un usuario en interacción con
un software. La actividad “Arreglar equipo” es compuesta lo cual se representa con el signo de +. Ello
significa que se puede expresar más detalles sobre esa actividad como luego se muestra en el
segundo diagrama. Por otro lado, la actividad compuesta también es multi-instancia, representado por
tres líneas verticales paralelas. Ello significa que mientras la primera y tercera actividad ocurre solo
una vez, la segunda puede ocurrir múltiples veces antes de pasar a la tercera. En la práctica, para ese
ejemplo se pudiera decir que en única orden trabajo, pudiera constar el arreglo de varios equipos.
Cuadro 2-3: Ejemplo de diagrama de secuencia de actividades

En un taller de reparaciones de laptop se arreglan los equipos de acuerdo con la orden de trabajo. El proceso se ejecuta como sigue
Generar orden de Cerrar orden de

Arreglar equipos
trabajo trabajo
La orden de trabajo puede contener muchos equipos para ser arreglados, por lo que la orden de trabajo se realiza solo una vez, sin
embargo, el arreglo de los equipos se realiza tantas veces como equipos contenga la orden de trabajo; por esta razón se define
“Arreglar equipos” como una actividad de múltiples instancias en paralelo.
Por otra parte, la actividad arreglar equipo puede ser descrito a un nivel más bajo de detalles, por lo que es un subproceso. El
siguiente diagrama muestra el subproceso expandido que permite visualizar el nivel de detalle.
8
Arreglar equipos
Registrar
diagnóstico del Registrar resultado
equipo
Generar orden de Cerrar orden de
trabajo trabajo
Arreglar equipo
Como es un subproceso múltiple, las actividades contenidas en él, deben realizarse por cada instancia de equipos.
2.2. Uso de eventos en el flujo de secuencia
Un evento es algo que sucede durante el curso de un proceso. Estos eventos afectan el flujo del
proceso y usualmente tienen un disparador o resultado. Pueden iniciar, retrasar, interrumpir o finalizar
el flujo del proceso. Se representan por círculos, el estilo del borde es en dependencia del momento
en que se ejecuta el evento, lo cual define los tipos de eventos: Evento de inicio (línea fina única),
Evento intermedio (Línea fina doble), Evento de Fin (línea gruesa única).
Considerar los eventos en la representación de un proceso hace que el diagrama sea más complejo,
pero también más cercano a la realidad. Ello se debe a que durante la ejecución de un proceso es
preciso prever posibles situaciones externas o intercambios que pudieran cambiar o interferir en la
secuencia normal de un proceso.
Al igual que las actividades, los eventos tienen marcadores que indican el tipo de evento, cuya decisión
de representación está en dependencia de las reglas del proceso. En el cuadro 2-4 se muestran los
tipos de eventos, lo cuales están mejor abordados en el libro En el libro “BPMN: Guía de Referencia y
Modelado”.
9
Cuadro 2-4: BPMN 2.0 – Eventos
Intermedio de
Inicio captura,
EVENTOS lanzamiento y Fin
adjunto
Simple: Eventos sin especificar. Indican puntos de inicio, de fin y situaciones
intermedias.
Mensaje: Recepción y envío de mensajes. Representa los flujos de información entre
los procesos
Señal: Intercambio de señales entre procesos. Una señal puede ser capturada varias
veces.
Temporal: Puntos en el tiempo, lapsos, límites (timeouts). Pueden ser eventos únicos o
cíclicos.
Condicional: Reacción a cambios en las condiciones de negocios o integración de
reglas de negocio.
Enlace: Dos conectores de enlace equivalen a un flujo de secuencia. se utiliza cuando
no alcanza la hoja de trabajo o cuando hay muchos cruces de líneas de flujo.
Error: Captura y lanzamiento de errores conocidos con nombre.
Cancelación: Reacción a la cancelación de una transacción/ Solicitud de cancelación.
Compensación: Solicitud de compensación. Los eventos de compensación se

adjuntan a la tarea y se utiliza para sustituir una tarea por otra.
Múltiple: Captura uno de un conjunto de eventos. Lanza todos los eventos definidos.
Terminación: Terminación inmediata del proceso.
Los procesos representados a través de BPMN, siempre tienen un evento de inicio y un evento de fin
que indica cuando inicia el proceso o cuando finaliza. Asimismo, los eventos intermedios se
representan a partir del reconocimiento y tratamiento de situaciones o intercambios externos que
deben ser considerados para decidir cómo continua el flujo de un proceso.
En el Cuadro 2-5 se ilustra un ejemplo de diagrama de proceso donde quedan representados eventos.
Puede verse que, por el uso de eventos, este diagrama tiene más alternativas de flujo que el diagrama
representado en el ejemplo anterior. El evento puede responder la pregunta ¿Cuándo ocurre una
actividad? Note que la actividad “ejecutar instalador” solo ocurre si hay una “orden de instalación”. La
actividad “mostrar error de instalación” solo ocurre si existe un error que interrumpe la actividad “iniciar
instalación” y la actividad “llenar encuesta de satisfacción ocurre cuando hayan transcurrido 30 días
después que la actividad “iniciar instalación”, haya terminado.
10
Cuadro 2-5: Ejemplo de diagrama usando eventos
A continuación, se muestra el proceso de instalación de software para someterlo al período de prueba. El proceso se inicia
por se da la orden de instalación, se ejecuta la instalación y automáticamente se instala el software. Durante el proceso
de instalación si ocurre un erro se interrumpe la instalación, se muestra el resultado del error y se envían a una entidad
externa. Si la instalación finaliza satisfactoriamente se espera 30 días (tiempo de duración de la prueba), cuando finaliza
el tiempo de prueba se llena la encuesta de satisfacción en el sistema de encuesta; si el sistema no está funcionando
entonces se llena la encuesta manualmente.
Llenar encuesta de
Ejecutar instalador Iniciar instalación
satisfacción
Orden de 30 días
instalación
Mostrar error de Llenar encuesta de

instalación satisfacción
Errores
2.3. Uso de compuertas en el flujo de secuencia
Las compuestas son elementos de modelado que controlan como el proceso diverge o converge, es
decir, dividen y unifican el flujo de un proceso (a través de líneas de secuencia). Todas las compuertas
tienen en común la forma de un diamante. El cuadro 2-6 muestra los tipos de compuertas que existen
en BPMN.
Cuadro 2-6: BPMN 2.0 – Compuertas
COMPUERTAS
En un punto de bifurcación, selecciona exactamente un flujo de secuencia de
entre las alternativas existentes. En un punto de convergencia, la compuerta
espera a que un flujo incidente complete para activar el flujo saliente.
Dato exclusivo
Esta compuerta siempre será seguida por eventos o tareas de recepción, y
sólo activará un flujo saliente dependiendo del evento que ocurra en primer
lugar.
Evento exclusivo
En un punto de bifurcación, todos los caminos salientes serán activados
simultáneamente. En un punto de convergencia, la compuerta espera a que
Paralelo todos los flujos incidentes completen antes de activar el flujo saliente.
En un punto de bifurcación, al menos un flujo es activado. En un punto de
convergencia, espera a todos los flujos que fueron activados para activar al
Inclusiva saliente.
Comportamiento complejo de convergencia/bifurcación no capturado por el

resto de compuertas.
Compleja
11
Al igual que lo eventos, las compuertas pueden complejizar el diagrama de proceso e ilustra las
diferentes alternativas de flujo que pueden existir en un proceso. Es preciso conocer la diferencia para
poder tomar mejores decisiones sobre cuál artefacto usar ante una regla del proceso.
La compuerta de dato exclusivo se utiliza para bifurcar los flujos en el momento del proceso donde se
deba tomar una única decisión entre varias alternativas de flujo salientes, donde solo una debe ser
evaluada como verdadera. Dicha decisión se toma sobre la base del resultado que tuve la actividad
que antecede a la compuerta. Esto último es lo que lo hace diferir de la compuerta de evento exclusivo,
que al igual que la exclusiva basada en datos, solo se ejecuta uno de los flujos salientes. La diferencia
es que se representa con eventos intermedios luego de cada flujo saliente de la compuerta, y la
ocurrencia o no del evento es el que indica que flujo saliente debe ocurrir. Ello quiere decir que la
compuerta de dato exclusivo se utiliza cuando la decisión de que flujo saliente debe ocurrir, se toma
en la actividad que precede la compuerta. Mientras que, en la compuerta de evento exclusivo, la
decisión depende de la ocurrencia de posibles eventos externos, los cuales son ajenos a la actividad
que precede la compuerta. Para comprender un poco más está explicación veamos el ejemplo del
cuadro 2-7.
Cuadro 2-7: Ejemplo de diagrama usando compuertas exclusivas
A continuación, se describe un proceso de gestión de oportunidades de negocio que inicia con la recepción de una solicitud
de negocio al cual se le realiza una evaluación de factibilidad. De acuerdo con los indicadores del estudio se decide si el
negocio es factible o no. En caso que sea factible se le envía las especificaciones al partner del negocio y se espera por
una respuesta. Las posibles respuestas pueden ser: “El partner acepta”, “El partner rechaza” y “El partner envía una
contraoferta”. La contraoferta se vuelve a evaluar, si se acepta finaliza el proceso con el envío de las especificaciones del
negocio al comité de contratación. En los casos que el negocio no sea factible o el partner rechace la oferta se cierra el
negocio y finaliza el proceso. La situación descrita se muestra en el siguiente diagrama.
Comunicar que no
Cerrar negocio
es factible
No
¿El negocio es
factible?
Evaluar factibilidad Rechaza negocio

de negocio
Enviar
Solicitud Sí especificaciones del Firmar contrato
de negocio negocio
Acepta negocio
Contraoferta
En el ejemplo puede verse una primera compuerta exclusiva basada en datos cuyos flujos salientes
ocurren en dependencia de si el negocio es factible o no. Dicha decisión se toma a partir del resultado
de la actividad que precede dicha compuerta que es donde se evalúa la factibilidad del negocio. Para
12
cada flujo saliente de la compuerta exclusiva basada en datos, se debe indicar cuál es la condición
que debe cumplirse para que el flujo se ejecute. Por su parte la compuerta basada en eventos
representada en el proceso está continuada de tres eventos cuya ocurrencia está en dependencia de
la decisión que debe tomar un socio externo al proceso (el proceso no controla la decisión), a diferencia
de la otra compuerta donde la decisión se toma durante una actividad propia del proceso (el proceso
controla la decisión). Cuando la decisión se que flujo saliente debe ocurrir depende de situaciones o
decisiones externas, se utiliza la compuerta basada en eventos, lo cual indica que el proceso debe
esperar por la ocurrencia de uno de los eventos definidos. Las compuertas exclusivas también pueden
ser utilizados para unificar flujos de secuencia de un proceso como se puede ver en el ejemplo. Esta
puede tener múltiples caminos entrantes, pero con que uno llegue es suficiente para ejecutar el camino
saliente. En este punto no hay evaluación de condiciones.
La compuerta inclusiva soporta decisiones donde es posible más de un resultado en el punto de

decisión. Al igual que las compuertas exclusivas, las inclusivas con múltiples flujos de secuencia
salientes crea caminos alternativos basado en las condiciones de estos flujos de secuencia. La
diferencia es que las compuertas inclusivas activan uno o más caminos, mientras que el exclusivo solo
activa uno. La decisión de cuáles condiciones deben activarse está en dependencia del resultado de
la actividad que precede la compuerta, es decir que son decisiones internas controladas por el proceso.
En el cuadro 2-8 pueden verse variantes de la cantidad de flujo que pueden activarse con el uso de
este artefacto.
Cuadro 2-8: Variantes de comportamiento de flujo de la compuerta inclusiva.
Condición 1 Tarea 1 Condición 1 Tarea 1 Condición 1 Tarea 1
Por su parte, la compuerta paralela inserta una división en el proceso para crear dos o más flujos de
ejecución paralelo. Cuando una línea de flujo llega a una compuerta paralela, significa que todos los
flujos salientes se ejecutan, no hay ninguna condición en los flujos salientes. Esta compurta también
se utiliza como unificador cuando caminos paralelos deban ser sincronizados para poder continuar el
proceso. En este caso, el proceso no continúa hasta que todos los flujos entrantes lleguen al punto de
sincronización. En el cuadro 2-9 se muestra un ejemplo del uso de compuertas inclusivas y paralelas.
13
Cuadro 2-9: Ejemplo de diagrama usando compuertas paralelas e inclusivas
En un taller de laptop se brindar servicios de mantenimiento y reparación de fallas, también se vende componentes y
accesorios de laptop. El proceso de venta se inicia cuando un cliente llega al taller donde se le brinda asistencia técnica.
Luego se crea la orden de pedido y paralelamente se brindan los servicios o se entregan los productos (o ambos) de
acuerdo al pedido de los clientes. Finalmente se cobra cuando hayan terminado las tareas de factura y entrega de
productos y servicios. El proceso descrito se muestra en el siguiente diagrama.
Crear orden de
pedido
Brindar asistencia Cobrar importe

técnica
Llegado de
un cliente
Requiere
Brindar servicio
servicios
Requiere
Entregar productos
productos
2.4. Representación de responsables de ejecutar las actividades
Con BPMN también es posible representar los roles y actores quienes ejecutan las actividades de un
proceso a través de las piscinas o canales. La piscina se representa como caja rectangular que actúan
como contenedor de los objetos de flujo. Las piscinas crean sub-particiones (carriles) para los objetos
contenidos en ella. Estas particiones se utilizan para visualizar cuales roles son los responsables de
ejecutar las actividades que se diagraman dentro de la piscina. Los carriles a menudo representan
roles de una organización (administrador, vendedor, comercial, etc.) pero puede representar cualquier
clasificación deseada (tecnología subyacente, departamento, ubicación, etc.). En el cuadro 2-10 se
muestra el mismo ejemplo del cuadro 2-7, pero a este se le incorpora piscina y canales para ilustrar
quienes son los responsables de ejecutar las actividades del proceso.
14
Cuadro 2-10 Ejemplo de diagrama utilizando piscinas y carriles
Gestor de
clientes
Comunicar que no
Cerrar negocio
es factible
No
Dirección comercial
¿El negocio es
factible?
Director comercial

de negocio
Enviar
Solicitud Sí especificaciones del Firmar contrato
de negocio negocio
Acepta negocio
Contraoferta
2.5. Representación del flujo de información del proceso
El flujo de información de un proceso puede ser representado con BPMN a través de los objetos de
datos. Con ello se ilustra qué información necesita una actividad para ser ejecutada, así como la
información que las actividades crean y actualizan. El cuadro 2-11 muestra los artefactos que debe ser
utilizados.
Cuadro 2-11: BPMN 2.0 – Objetos de datos
DATOS
Un Dato de Entrada es una entrada externa a todo el proceso.
Tarea
Puede ser leído por una actividad. Un Dato de Salida es una
variable disponible como resultado del proceso.
Dato de entrada o salida
Un Dato de Tipo Objeto representa información que fluye a
través del proceso tales como documentos, correos electrónicos
o cartas.
Dato de tipo objeto
Una Colección de Objetos de Datos representa una colección

de información.
Colección de objetos de datos
Un Almacén es un lugar donde el proceso puede leer o escribir

datos. La información en un almacén persiste más allá de la vida
de la instancia del proceso.
Almacén
Un Mensaje es utilizado para representar el contenido de una

comunicación entre dos participantes.
Mensaje
15
En el cuadro 2-12 se presenta el mismo ejemplo anterior enriquecido con un flujo de información donde
se maneja el objeto “Negocio” como una entidad de información que fluye por el proceso adoptando
diferentes estados. Cada actividad que manipula el objeto de información le aporta nuevos datos
modificando su estado. Puede verse que el flujo de actividades debe ser coherente con el flujo de
información, ya que, si una actividad requiere una información para ser ejecutada, debe existir una
actividad que le anteceda que cree dicha información.
Para representar el flujo de información interno, se utilizan los objetos de datos y las líneas de
asociación direccionales, con las cuales se indica si el objeto de datos sale o entra de la actividad. Con
los objetos de datos es posible representar la información interna (horizontal) que fluye por el proceso.
Sin embargo, si lo que se requiere es presentar la información que se intercambia con entidades
externas (vertical), entonces para ello se utiliza los eventos de envío y recepción de mensajes.
Cuadro 2-12: Ejemplo de diagrama utilizando flujo de información interno

Gestor de clientes
Negocio Negocio
(Rechazado) (Cerrado)
Negocio Comunicar que no
Cerrar negocio
(Nuevo) No es factible
¿El negocio es
factible?

Director comercial
de negocio
Enviar
Sí
Solicitud especificaciones del Firmar contrato
de negocio negocio
Acepta negocio
Contraoferta
Negocio
(Factible)
Contrato
Negocio
(Factible)
Para representar el flujo de información externo se utilizan los eventos de envío y recepción de
mensaje, las actividades de envío y recepción, los objetos de mensajes y los flujos de mensaje. De
acuerdo al ejemplo anterior, si se requiere representar el intercambio de información entre el proceso
y el socio, el diagrama quedaría como se muestra en el cuadro 2-13. Los artefactos añadidos se
resaltan en rojo.
16
Cuadro 2-13: Ejemplo de diagrama utilizando flujo de información externo
Gestor de clientes
Negocio Negocio
(Rechazado) (Cerrado)
Negocio Comunicar que no
Cerrar negocio
(Nuevo) No es factible
¿El negocio es
Solicitud factible?
de negocio
Director comercial
de negocio
Enviar
Sí
especificaciones del Firmar contrato
negocio
Acepta negocio
Negocio Contraoferta
(Factible)
Contrato
Negocio
(Factible)
Funció
Socio
n
3. EJERCICIO DEMOSTRATIVO DE MODELADO DE PROCESO

En el siguiente apartado se muestra un caso resuelto de modelado de proceso. Uno de los propósitos
del caso es ilustrar cómo las reglas para modelar un proceso se pueden presentar en diferentes
formatos y no necesariamente de manera organizada. En este caso, las reglas se presentan en forma
de texto, tabla y gráfico. Para la resolución del caso el modelador debe ser capaz de identificar y
modelar la totalidad de las reglas que se presentan, de acuerdo al alcance que se pide. El cuadro 3-1
muestra la orientación del caso, y más adelante se presenta su resolución dividida en partes, de modo
que facilite explicar la lógica de modelado.
Cuadro 3-1: Orientación del caso de estudio

Una empresa consultora de sistemas contable-financieros ejecuta un riguroso proceso de evaluación y selección de recursos
humanos como mecanismo para garantizar la calidad de los empleados que son contratados. El proceso inicia cuando llega un
formulario de solicitud llenado por un aspirante. El formulario de solicitud está diseñado para evaluar principios básicos y psicológicos
de cualquier tipo de aspirante, así como criterios técnicos en dependencia del tipo de trabajo al cual está aspirando. Dichas
evaluaciones dan garantía de la calidad de las decisiones de selección tomadas.
Los aspirantes son entrevistados por los jefes de los departamentos técnicos a donde
pertenece el puesto de trabajo demandado. Sin embargo, ellos perciben que invierten
mucho tiempo en entrevistar aspirantes que ni siquiera cumplen con los requisitos básicos,
lo cual afecta la eficiencia de su trabajo. Además, se está violando la política de que la
decisión final de selección del aspirante que se desea contratar, debe ser tomada por un
comité de contratación. Dicho comité debe seleccionar al candidato más competente para
17
el puesto, de entre todos los aspirantes preseleccionados por los departamentos técnicos. Considerando lo anterior, se ha rediseñado
el proceso (véase vista como caja negra a la derecha) de modo que se ayude a mejorar su desempeño.
Como resultado del rediseño, se han dividido las etapas del proceso teniendo en cuenta que existen cuatro categorías que agrupan
los tipos de criterios a evaluar (ver columna 3). Puede observar en la tabla que, con el nuevo diseño, antes de hacer una entrevista
presencial, primero hay dos filtros que se realizan basado en el formulario de solicitud llenado por los aspirantes (columna 2), lo cual
permite que sólo vayan a las entrevistas, en las fechas planificadas, los aspirantes con potencialidades. El procesamiento de las
solicitudes puede conducir a dos decisiones fundamentales (vea columnas 4 y 5) que son: 1) aprobación del aspirante y, en tal caso,
se le envía la oferta de contrato, o 2) rechazo del aspirante y, en este caso, se le envía una carta de rechazo. Ambas comunicaciones
con el aspirante es responsabilidad del Departamento de recursos humanos.
1 2 3 4 5
Condiciones Condiciones
Responsable de Categorías de criterios necesarias para suficientes para
Información utilizada
evaluar criterios evaluados enviar oferta de enviar carta de
trabajo rechazo
Departamento de Basado en el formulario Cumplimiento de principios
APROBADA RECHAZADA
recursos humanos de solicitud básicos
Departamento Basado en el formulario
Calidad técnica APROBADA RECHAZADA
técnico de solicitud
Departamento Basado en una entrevista
Habilidades competitivas
APROBADA RECHAZADA
técnico presencial de cada aspirante
Basado en el Conocimientos y
ordenamiento de habilidades demostrados
Comité de
aspirantes de acuerdo arespecto a otros aspirantes APROBADA RECHAZADA
contratación
sus habilidades preseleccionados en la
competitivas entrevista.
CONDICIONES SUFICIENTES: AL MENOS UNA DEBE
CONDICIONES NECESARIAS: TODAS DEBEN CUMPLIRSE
CUMPLIRSE
Con el nuevo diseño del proceso, basado en la información que se registra durante su ejecución, se pueden llevar las estadísticas
relacionadas con el procesamiento de solicitudes, como se muestra en el gráfico de barras.
Estados de las solicitudes procesadas en el año 2017
20000 17081
15000
10000 5101
5000 2129 1521 541 469 1452 412
0
Solicitudes Solicitudes Solicitudes Solicitudes Solicitudes Solicitudes Contratos Contratos
rechazadas por rechazadas por rechazadas rechazadas por canceladas por canceladas por firmados rechazados por
el departamento los después de las el comité de los aspirantes ausencia de los los aspirantes
de recursos departamentos entrevistas contratación aspirantes a las
humanos técnicos entrevistas
Teniendo en cuenta la información ofrecida realice los siguientes ejercicios:

a) Identifique 2 problemas, cuya relación entre ellos sea causa-efecto, y que hayan quedado resueltos con el nuevo diseño. Indique
cuál es la causa y cuál es el efecto.
b) Identifique los requisitos y reglas de negocio que deben quedar resueltos en el modelo de proceso organizacional.
c) Modele con BPMN la secuencia de actividades y el flujo de datos del nuevo proceso diseñado. Tenga en cuenta que los
aspirantes y el comité de contratación son roles externos; en tal sentido, represente el intercambio de información que
evidencie la colaboración de ellos con el proceso.
18
El primer cuestionamiento que se realiza el modelador es ¿Quiénes participan en el proceso? Ello
ayuda a delimitar el alcance del modelo. Con la respuesta es posible modelar los carriles de BPMN y
definir cuáles deben ir abiertos o colapsados. Para ello es preciso identificar en la orientación del caso,
los participantes que se mencionan. En el cuadro 3-2 se muestran diferentes partes de la orientación
del caso que indica quiénes son los participantes del proceso. En total son 4 participantes: el aspirante,
el departamento de recursos humanos, el departamento técnico y el comité de contratación. Sin
embargo, en el inciso c de las preguntas de caso, se aclara que el aspirante y el comité de contratación
son roles externos y solo interesa representar el intercambio de información. Ello significa que las
piscinas asociado a estos participantes deben estar colapsados y las actividades que ellos ejecutan
no serán representadas en el modelo de proceso. El cuadro 3-3 muestra cómo quedan modelados los
participantes
Cuadro 3-2: Reglas del proceso. Parte 1
El proceso inicia cuando llega un formulario de solicitud llenado por un aspirante.

Responsable de evaluar criterios
Departamento de recursos humanos
Departamento técnico
Comité de contratación
Tenga en cuenta que los aspirantes y el comité de contratación son roles externos; en tal sentido, represente el intercambio de
información que evidencie la colaboración de ellos con el proceso.
Cuadro 3-3: Respuesta. Parte 1
Aspirante
Aspirante
Proceso de evaluación y selección de empleados
recursos humanos
Departamento de
Departamento de
recursos humano
Departamento
técnico
Comité de
contratación
Luego de definir los participantes se procede a identificar las actividades claves del proceso, las cuales,
de acuerdo con el propósito del proceso son aquellas que estén relacionadas con la evaluación de
aspirante para un puesto de trabajo. Definir dichas actividades ayuda a crear una línea base que
oriente al modelador sobre el orden en que debe identificar las reglas del proceso. En este caso las
19
actividades pueden inferirse de la información que ofrece la tabla del caso. Se pudiera pensar que una
de las actividades es el llenado del formulario por los aspirantes, sin embargo, es preciso recordar que
las actividades realizadas por el aspirante no se representan en el alcance del proceso que se está
modelado. El cuadro 3-4 muestran la tabla del caso y las actividades que se infiere de dicha tabla. La
actividad “Evaluar respecto a otros participantes” realizada por el comité de contratación no debe
quedar representada en el modelo de proceso, ya que ese rol se encuentra colapsado en el modelo.
Aunque no se debe olvidar las reglas que le antecede y le procede en el proceso, lo cual veremos más
adelante.
Cuadro 3-4: Análisis de reglas basada en la tabla del caso
Responsable de Categorías de criterios Departamento • Evaluar

Información utilizada de recursos principios
evaluar criterios evaluados humanos básicos
Departamento de Basado en el formulario Cumplimiento de principios
recursos humanos de solicitud básicos
Departamento • Evaluar calidad
Departamento Basado en el formulario técnico técnica
Calidad técnica
Departamento Basado en una entrevista Habilidades competitivas de • Evaluar
Departamento
técnico presencial cada aspirante técnico
habilidades
competitivas
Comité de Comité de
• Evaluar
aspirantes de acuerdo a respecto a otros aspirantes respecto a
contratación contratación
sus habilidades preseleccionados en la otros aspirantes
Otro cuestionamiento importante es en qué orden deben ocurrir las actividades claves. Para ello es
preciso identificar las reglas del caso que sugieran el orden. En el caso se plantean dos situaciones
(ver cuadro 3-5): la primera indica una problemática, la cual manifiesta que han llegado a la entrevista
aspirantes que ni siquiera cumplen con los requisitos básico, lo cual sugiere que antes de las
entrevistas, dichos requisitos sean evaluados. Ello se confirma en la segunda situación donde se
enuncia que antes de la entrevista, se realicen dos filtros basado en el formulario de solicitud y la tabla
del caso indica que dichos filtros se corresponden con “evaluar principios básicos” y “evaluar calidad
técnica”. En tal sentido, el orden de las actividades claves que se modelan debe quedar como se ilustra
en el cuadro 3-6.
Cuadro 3-5: Análisis de reglas basado en enunciados del caso
• Los aspirantes son entrevistados por los jefes de los departamentos técnicos a donde pertenece el puesto de trabajo demandado.
Sin embargo, ellos perciben que invierten mucho tiempo en entrevistar aspirantes que ni siquiera cumplen con los
requisitos básicos, lo cual afecta la eficiencia de su trabajo.
• Antes de hacer una entrevista presencial, primero hay dos filtros que se realizan basado en los formularios de solicitud
llenados por los aspirantes.
20
Cuadro 3-6: Actividades principales del caso
Evaluar principios Evaluar habilidades

Evaluar calidad técnica
básicos competitivas
Seguidamente se procede al modelado de las actividades usado BPMN, para lo cual hay que tener en
cuenta las precondiciones y postcondiciones de las actividades. Para ello hay dos preguntas
importantes que se deben realizar: “qué condiciones deben darse para que inicie la actividad” y “qué
condiciones pueden darse luego que termine la actividad”. La primera actividad que será modelada es
“Evaluar principios básicos”. El cuadro 3-7 indica las reglas relacionadas con dicha actividad y el
cuadro 3-8 la respuesta asociada a esta primera parte.
Cuadro 3-7: Identificación de reglas del caso
• El proceso inicia cuando llega un formulario de solicitud llenado por un aspirante.

Responsable de Categorías de criterios
Información utilizada necesarias para enviar suficientes para enviar
evaluar criterios evaluados
oferta de trabajo carta de rechazo
Departamento de Basado en el formulario de Cumplimiento de principios
APROBADA RECHAZADA
recursos humanos solicitud básicos
• …rechazo del aspirante y, en este caso, se le envía una carta de rechazo.
De acuerdo con la regla, la actividad inicia con la llegada de un formulario de solicitud del aspirante, lo
cual se representa como un evento de inicio del proceso, ya que es la primera actividad. Luego se
representa la actividad y la información de entrada que es el “Formulario de solicitud”, ya que dicha
información es necesaria para ejecutar la actividad. Dichas precondiciones pueden verse en la parte
1 del modelo representado en el cuadro. La actividad termina con una decisión basada en la
información analizada, por lo que es preciso representar una compuerta basada en datos, cuyos flujos
salientes se asocian a las dos alternativas de decisión como se indica en la tabla del caso: aprobación
de la solicitud o rechazo de la solicitud. En el caso se indica que cuando un formulario es rechazado
en el alguno de los filtros (condición suficiente), entonces se le envía una carta de rechazo al cliente,
lo cual se convierte en una actividad dentro del proceso en relación a los flujos saliente de rechazo.
Por otra parte, si el formulario es aprobado entonces debe proceder a la siguiente evaluación para
chequear el resto de las condiciones necesarias. En tal sentido, los flujos salientes relacionados con
la primera actividad quedan representados como se muestra en el modelo de la parte 2 del cuadro 3-
8.
21
Cuadro 3-8: Respuesta. Continuación
PARTE 1 PARTE 2
Aspirante Aspirante
recursos humanos
Proceso de evaluación y selección
Departamento de
Formulario Formulario
recursos humanos
de solicitud de solicitud
Departamento de
[Nuevo] [Rechazado] Enviar carta

Formulario No de rechazo
Evaluar
de solicitud
requisitos
[Nuevo] Aprobado?
No básicos del
Formulario
aspirante
Evaluar de solicitud
Sí
requisitos
Departamento
Aprobado?
básicos del
técnico
Evaluar
Formulario
de solicitud
aspirante requisitos
Formulario técnicos del
Sí de solicitud aspirante
[Básico]
Rol que Resultado

Flujo de
Actividad ejecuta la de la
información
actividad actividad
Ahora corresponde la evaluación de la calidad técnica del aspirante, para lo cual se define la actividad
“Evaluar requisitos técnicos del aspirante”. El cuadro 3-9 ilustra el fragmento de la tabla del caso
relacionado con la actividad.
Cuadro 3-9: Identificación de reglas del caso
Departamento Basado en el formulario
Calidad técnica APROBADA RECHAZADA
• “…sólo vayan a las entrevistas, en las fechas planificadas, los aspirantes con potencialidades.”
La precondición para que esta actividad se ejecute es que el aspirante sea aprobado en la evaluación
anterior, por lo que se conecta con el flujo saliente de aprobación. Igualmente, cuando esta actividad
termina se debe tomar una decisión de aprobación o rechazo basada en la información analizada, por
lo que nuevamente se incorpora al modelo, una compuerta de decisión basada en datos, las cual tiene
asociada dos flujos salientes relacionados con la aprobación o el rechazo como se ilustra en la parte
1 del cuadro 3-10. En caso de rechazo, se le envía la carta de rechazo y en caso de aprobación se
procede con el siguiente filtro que es evaluar las habilidades competitivas a través de una entrevista
presencial. Sin embargo, no se puede representar el flujo saliente de aprobación directamente a la
ejecución de la entrevista como se muestra en la parte 2 del cuadro 3-10; ya que es preciso, de acuerdo
con la regla, representar las fechas planificada de las entrevistas. Dichas fechas, también deben ser
22
Aspirante
recursos humanos
Departamento de
Formulario
No Enviar carta
comunicadas al aspirante para que sepa en quédeFormulario
momento de solicitud
le toca su entrevista. En tal sentido, el
solicitud de rechazo
recursos humanos
[Rechazado]
Departamento de
Formulario No
Formulario de solicitud Enviar carta [Nuevo]
de rechazo Evaluar
modelo de proceso va quedando
de solicitud
[Nuevo]
[Rechazado]hasta el momento comorequisitos
se muestra en el cuadro 3-10.
Evaluar Aprobado?
básicos del
requisitos aspirante
Aprobado? Formulario
básicos del Cuadro 3-10:deRespuesta.
solicitud Continuación No
Formulario aspirante
de solicitud Sí
PARTE 1 Sí
PARTE 2
Departame
nto técnico
No Evaluar
Departame
nto técnico
Evaluar requisitos Ejecutar

requisitos Formulario Sí
entrevista
Formulario Sí técnicos del
técnicos del de solicitud
de solicitud
aspirante Aprobado?
[Básico] aspirante Aprobado?
[Básico]
PARTE 3
Aspirante
recursos humanos
Departamento de
Formulario
Formulario No Enviar carta
de solicitud
de solicitud de rechazo
[Rechazado]
[Nuevo]
Evaluar
requisitos
Aprobado?
básicos del
de solicitud No
Sí
Departamento
Evaluar
técnico
requisitos Comunicar Ejecutar

Formulario Sí fecha de la
técnicos del entrevista
de solicitud entrevista Fecha de la
[Básico] aspirante Aprobado? entrevista
Rol que Resultado

Flujo de
Actividad ejecuta la de la
información
actividad actividad
Como resultado de la entrevista también deben tomarse una decisión de aprobación o rechazo del
aspirante como se ilustra en el cuadro 3-11. El flujo saliente de rechazo conecta con la actividad de
envío de carta de rechazo, mientras que el flujo saliente de aprobación debe conectar con el siguiente
filtro. El próximo filtro es realizado por el comité de contratación, cuyas actividades no están en el
alcance del modelo por lo cual no se representa. Aunque en el caso indica que se deben representar
las interacciones con dicho rol externo. En este caso se representa el intercambio de información con
el comité de contratación, para lo cual se ha representado la actividad “Enviar formulario de aspirante
seleccionado” con un flujo de mensaje que conecta con el carril de comité de contratación. El modelo
correspondiente a este fragmento del proceso se muestra en el cuadro 3-12.
23
Cuadro 3-11: Análisis de reglas del caso
Departamento Basado en una entrevista Habilidades competitivas
APROBADA RECHAZADA
técnico presencial de cada aspirante
• Tenga en cuenta que los aspirantes y el comité de contratación son roles externos; en tal sentido, represente el intercambio de
información que evidencie la colaboración de ellos con el proceso.
Cuadro 3-12. Respuesta. Continuación
Aspirante
Departamento
de RRHH
Formulario
Actividad
Enviar carta
de solicitud
de rechazo
[Rechazado]
No
Rol que ejecuta
la actividad
Comunicar Ejecutar Eviar formulario

fecha de la Sí de aspirante Resultado de la
entrevista Fecha de la
entrevista preseleccionado actividad
entrevista Aprobado?
Formulario
Formulario Flujo de
de solicitud
de solicitud [Preseleccionado]
información
[Técnico]
Aunque las actividades del comité de contratación no se representan en el alcance del modelo, el
proceso aún no ha terminado, ya que es preciso comunicarle al cliente si fue aprobado por el comité
de contratación, lo cual es responsabilidad de recursos humanos como indican las reglas del cuadro
3-13.
24
Cuadro 3-13: Análisis de reglas del caso.
Comité de
aspirantes de acuerdo a respecto a otros aspirantes APROBADA RECHAZADA
contratación
sus habilidades preseleccionados en la
• El procesamiento de las solicitudes puede conducir a dos decisiones fundamentales (vea columnas 4 y 5) que son: 1) aprobación
del aspirante y, en tal caso, se le envía la oferta de trabajo, o 2) rechazo del aspirante y, en este caso, se le envía una carta de
rechazo. Ambas comunicaciones con el aspirante es responsabilidad del Departamento de recursos humanos.
En tal sentido, se debe representar la respuesta del comité de contratación (ver cuadro 3-14). Para
ese caso se debe representar a continuación de la actividad “Enviar formulario de aspirante
preseleccionado” una compuerta basada en eventos. Se utiliza este tipo de compuerta ya que el
resultado depende de una actividad externa al proceso, a diferencia de los filtros anteriores cuyos
resultados eran una decisión de la actividad anterior. Entonces, seguidamente de la compuerta basada
en evento se representan dos flujos salientes con un evento de recepción de mensaje en ambos flujos,
uno de ellos captura la decisión de rechazo del comité de contratación. Dicho flujo se conecta con la
actividad de envío de carta de rechazo. El otro evento de recepción de mensaje captura la decisión de
aprobación. Como este es el último filtro, entonces se representa la actividad de “Enviar oferta de
trabajo” seguidamente de la decisión de aprobación.
Cuadro 3-14. Respuesta. Continuación.
Aspirante
Actividad
Departamento
de RRHH
Rechazado
Enviar
Formulario
Enviar carta oferta de
de solicitud
de rechazo contrato
[Rechazado]
Contrato
No [Oferta] Rol que ejecuta
la actividad
Comunicar Ejecutar Eviar formulario

Sí de aspirante
fecha de la
entrevista
entrevista preseleccionado
Aprobado
Resultado de la
Fecha de la
entrevista Aprobado? actividad
Formulario
Formulario de solicitud
de solicitud
[Técnico]
[Preseleccionado] Flujo de
información
25
Hasta el momento el modelo representado cumple con las reglas descritas antes del gráfico. A
continuación, se procede a chequear si el modelo obtenido hasta el momento es capaz de proveer la
información solicitada por el gráfico del caso. El cuadro 3-15 se muestra los indicadores solicitados por
el gráfico y una marca de cumplimiento de la regla del indicador en relación al modelo obtenido.
Cuadro 3-15. Análisis de reglas del caso.
Solicitudes rechazadas por el departamento de

recursos humanos Solicitudes canceladas por los aspirantes
Solicitudes rechazadas por los departamentos Solicitudes canceladas por ausencia de los
técnicos aspirantes a la entrevista
Solicitudes rechazadas después de la Contratos firmados

entrevista
Solicitudes rechazadas por el comité de

contratación
Contratos rechados por los aspirantes
El primer indicador que no se cumple es “Solicitudes canceladas por los aspirantes”. Sin embargo,
aunque no se ha trabajado en el modelo para que se cumpla, en la orientación del caso existe una
representado del proceso como caja negra o colapsado donde queda representado la posibilidad de
que el aspirante pueda cancelar su solicitud en cualquier momento del proceso (ver cuadro 3-16).
Solicitudes canceladas por los aspirantes
Hasta el momento se asume que todos los aspirantes que se convocan, asisten a la entrevista. Sin
embargo, el gráfico solicita que se contabilicen las solicitudes que se cancelan por ausencia de los
aspirantes a la entrevista. Con ello es preciso modelar la posibilidad de que el aspirante no asista. En
este caso, se debe regresar al modelar las precondiciones de la actividad “Ejecutar entrevista”. Para
modelar dicha posibilidad, se incorpora una compuerta basada en eventos, ya que la manera de
proceder depende de una situación ajena al proceso (ver cuadro 3-17). Los flujos salientes de esta
compuerta son las dos posibles situaciones, una es que llegue el aspirante en la fecha en que fue
planificada la entrevista, lo cual se representa con un evento intermedio condicional que se conecta
con la ejecución de la entrevista. La otra posible situación es que finalice el tiempo de entrevistas y el
aspirante aun no haya llegado, tal situación se representa con un evento intermedio temporizador que
se conecta con la actividad “Enviar carta de rechazo”.
26
Aspirante
Departamento
de RRHH
Enviar carta
de rechazo
Finalización
del tiempo
de la entrevista
No
Solicitudes canceladas por ausencia de
los aspirantes a la entrevista
Departamento
Ejecutar Eviar formulario

técnico
Comunicar
fecha de la Sí de aspirante
entrevista Fecha de la Llegada del
entrevista preseleccionado
entrevista aspirante Aprobado?
Por último, también se contemplan las posibles respuestas del aspirante, luego de recibir una oferta
de contrato (ver cuadro 3-18). Las posibles respuestas es que envíe el contrato firmado o el contrato
rechazado. Para modelar ambas posibilidades, se incorpora una compuerta basada en eventos luego
de que el Departamento de RRHH haya enviado la oferta de contrato. Seguidamente de la compuerta
se representan dos flujos salientes, cada uno con un evento intermedio de captura de mensaje. Uno
de ellos captura el contrato firmado y el otro el contrato rechazo. Ante los diferentes tipos de respuesta,
en necesario darle un cierre al proceso, por lo que si el aspirante firma el contrato entonces este de
archiva y si el aspirante rechaza el contrato entonces este se cancela. Para ello se modelan las
actividades “Archivar contrato” y “Cancelar contrato”. Ambas actividades conducen a la finalización del
proceso. Una vista completa y organizada del modelo de proceso puede verse en la ilustración 3-1.
Aspirante
recursos humanos
Departamento de
Contrato
Enviar
Archivar [Confirmado]
oferta de
contrato
contrato Contrato
firmado
Contratos firmados
Cancelar
Contrato contrato
[Oferta] Contrato
rechazado Contrato
[Cancelado] Contratos rechados por
los aspirantes
Departamento
técnico
27
Aspirante
Departamento de recursos
Proceso de evaluación y selección de empleados
Formulario
de solicitud Formulario Contrato
Enviar
[Nuevo] de solicitud Archivar [Confirmado]
oferta de
humanos
[Rechazado] contrato
Aprobado? contrato Contrato
Evaluar Rechazado firmado
requisitos
No Enviar carta
básicos del
de rechazo Cancelar
contrato
de solicitud Finalización Contrato
del tiempo rechazado
Contrato Contrato
de la entrevista
Sí [Oferta] [Cancelado]
No
Evaluar
requisitos Comunicar Formulario
Sí fecha de la
Formulario técnicos del de solicitud
de solicitud aspirante entrevista Fecha de la [Preseleccionado]
[Básico] Aprobado? entrevista
Enviar formulario
Ejecutar
Sí de aspirante Aprobado
Formulario entrevista
seleccionado
de solicitud Llegada del
aspirante Aprobado?
[Técnico]
Ilustración 3-1: Modelo de proceso del caso de estudio
28
4. COLECCIÓN DE EJERCICIOS DE MODELACIÓN DE PROCESOS
En el siguiente apartado se presenta una colección de ejercicios dividido en dos grupos. El primer
grupo está orientado a la interpretación de diagramas de procesos y análisis de funcionamiento a
partir de un diagrama dado. El segundo grupo está orientado a generar diagramas de procesos a
partir de un conjunto de reglas y descripciones, con los cual se debe obtener un modelo de proceso.
4.1. Parte I: Interpretación y análisis del funcionamiento del proceso.
4.1.1. Descripción de reglas
Mencione todos los posibles recorridos de los siguientes modelos, y explique las reglas contenidas
en ellos.
a) b) CONDICIÓN A TAREA 4
TAREA 1 TAREA 3
TAREA 2 CONDICIÓN B TAREA 5
4.1.2. Gestión de multas
La figura representa el diagrama del proceso de gestión de multas de los infractores de tránsito.
Multa Comprobante
Enviar (Confirmada) de pago
Actualizar
Multa confirmación
estado de la
Multa (Registrada) del monto total
multa
(Nueva) de la multa Comprobante
de pago
Registrar datos de la multa
de la multa
Nueva Multa Multa
multa (Actualizada) (Pagada)
Aumentar
monto de la
multa por
demora 1 mes
A partir del diagrama a usted se le pide que: Responda verdadero (V) o falso (F) a las proposiciones
siguientes. Justifique su respuesta en caso de que sea falso.
a) _____ La actividad encargada de aumentar el monto de la multa por demora del infractor se
realiza de manera automática.
29
b) _____ Durante su ciclo de vida, una nueva multa siempre se registra, se confirma, se actualiza
y se paga.
c) _____ Después de enviada la confirmación del monto de la multa, se recibe el comprobante de
pago de la multa.
d) _____ La actividad aumentar monto de la multa por demora puede ocurrir indefinidamente
siempre que no se pague la multa.
e) _____ Para enviar la confirmación del monto de la multa se requiere que la misma haya sido
registrada.
f) _____ En el diagrama, la actividad registrar datos de la multa pudo haberse modelado como
una tarea manual en lugar de una tarea de usuario.
g) _____ Una vez que se registran los datos de la multa, siempre se envía la confirmación del
monto total de la multa.
h) _____ En el diagrama, la compuerta basada en eventos no pudiera ser sustituida por una
compuerta basada en datos
i) _____ Cuando se recibe el comprobante de pago de la multa, se actualiza la multa a estado
pagada y finaliza el proceso.
j) _____ Una vez que se envía la confirmación del monto de la multa, esta se recarga diariamente
por demora del infractor.
k) _____ El proceso inicia con la realización de la actividad registrar datos de la multa.
4.1.3. Gestión contrato
La figura representa el diagrama BPMN del proceso de gestión de la ejecución de un contrato de

servicio que ofrece una empresa.
Contrato
Contrato (Ejecutado) Facturar
Contrato (En proceso) Gestión de servicios servicios
(Confirmado) contratados realizados
No
Servicio no
Firmar contratado Generar
contrato suplemento al
Confirmación Contrato
de contrato
contrato ¿Suplemento (Cerrado)
aceptado?
Sí Cerrar
contrato
Gestión de atención
al cliente
30
A partir del diagrama, a usted se le pide que responda verdadero (V), falso (F) o no se dice (NSD) a
las proposiciones siguientes. Justifique su respuesta en caso de que sea falso.
a) ______ El proceso se inicia cuando se recibe el contrato en estado confirmado para que sea
firmado.
b) ______ Durante su ciclo de vida, un contrato confirmado se firma, se ejecuta, se le genera un
suplemento y se cierra.
c) ______ En el diagrama, la compuerta basada en datos pudiera ser sustituida por una compuerta
basada en eventos.
d) ______ Cuando se firma el contrato se ejecutan cada uno de lo(s) servicio(s) que el cliente
requiere dentro de las cláusulas establecidas en el contrato.
e) ______ La actividad Facturar servicios realizados siempre se ejecuta en caso de que el
suplemento a un contrato no sea aceptado.
f) ______ Una vez que se ha ejecutado el servicio, se le pregunta al cliente sobre su satisfacción,
lo que se realiza en el subproceso de gestión de atención al cliente.
g) ______ En el proceso se genera un contrato en estado confirmado.
h) ______ Cuando ya se hayan realizado todos los servicios requeridos dentro de las cláusulas del
contrato entonces se procede a facturar los servicios realizados.
i) ______ Luego de facturar los servicios realizados se cierra el contrato.
j) ______ Durante la generación de un suplemento a un contrato, se verifica si el servicio a
suplementar no había sido pactado en el contrato en proceso.
k) ______ La actividad Generar suplemento del contrato puede ocurrir indefinidamente durante la
ejecución de un contrato.
l) ______ Si el suplemento se acepta entonces puede continuar la ejecución del servicio, si no se
procede a facturar los servicios recibidos.
4.1.4. Taller de Laptops.
La figura representa el diagrama BPMN del proceso de compras de equipos que realiza un Taller de
Reparaciones de Laptops a individuos. Dichos equipos pueden ser laptop con pérdidas de atributos
cuyas piezas aún pueden reutilizarse, o laptops que aun funcionen que sean de interés del taller.
31
Oferta Registrar
Oferta (Comprada) Pago en
pago en
(Rechazada) efectivo
Oferta efectivo
Registrar Generar
(Registrada) Archivar
Comprador
No compra comprobante
oferta de pago
Taller de Reparación de Laptop
Registrar ¿Necesario? ¿Acuerdo? Pago en Registrar

Verificar No cheque cheque
oferta de Sí
necesidad
Oferta equipo
nueva
Oferta Oferta
Sí (Aceptada)
(Rechazada)
Registrar la
Evaluar Separar entrada de
Negociar No
características detalladas por piezas productos
oferta
del equipo ¿Equipo
Técnico
Oferta funcionando?
(Necesaria)
Sí
Base de datos
de productos
Oferta
(Evaluada)
A partir del diagrama representado, responda las preguntas que se enuncian a continuación:
a) Complete los datos que se le solicitan en la siguiente tabla tomando como base para ello el
diagrama anterior.
ELEMENTO A IDENTIFICAR CANTIDAD ETIQUETA(S) DE LOS ELEMENTOS GRÁFICOS

Actividad simple
Evento de finalización
Contenedor/Pool/Piscina
Compuerta paralela
Entrada de datos
Carril/Lane
Actividad de usuario
Compuerta exclusiva basada en datos
Actividad automática
Objeto de datos
Compuerta inclusiva
b) Responda verdadero (V), falso (F) o no se dice (NSD) a las proposiciones siguientes en
función de su cumplimiento en el diagrama anterior. Justifique su respuesta para cada uno de
los enunciados.
I. ______ Una misma oferta puede ser pagada en efectivo y por cheque.
II. ______ El registro de la compra puede realizarse simultáneamente con la separación por
piezas en caso requerido.
32
III. ______ Una oferta puede experimentar 6 transformaciones de estado durante la ejecución de
una instancia del proceso.
IV. ______ Solo se archivan las ofertas cuando el equipo o las piezas que incluye no son
necesarias para el taller.
V. ______ Se debe registrar la entrada de los productos, independientemente de que se requiera
separar por piezas o no.
VI. ______ Existen dos causas por las que una oferta puede ser archivada.
VII. ______ Una oferta calificada como necesaria puede convertirse en una oferta rechazada.
c) Obtenga un gráfico de barras que muestre todas las estadísticas del funcionamiento del
proceso en el año 2018.
Al taller le interesan tanto las estadísticas relacionadas con los estados de las ofertas y
compras, como con las formas de pago a dichas compras. También, las relativas al trabajo
del técnico, porque de estas depende el pago por resultados a este especialista al finalizar el
año. Se sabe que en el año 2018 se inicializaron 500 instancias del proceso. De ellas, fueron
necesarias para el taller el 38% de las ofertas. La mitad de las ofertas negociadas se
compraron, y en 64 ocasiones no hubo que separar las laptops compradas por piezas y
componentes. En relación a las formas de pago, en la quinta parte de los casos ocurrió
mediante una combinación de ambas variantes. En los restantes casos se dividió por igual el
pago mediante cheque y el pago en efectivo.
d) Compare los resultados del 2018 con los obtenidos en 2017.
Para ello se le informa que en el año 2017 se inicializaron 636 instancias del proceso. De
ellas, fueron necesarias para el taller la tercera parte de las ofertas. El 75% de las ofertas
negociadas se compraron, y en 59 ocasiones no hubo que separar las materias primas
compradas por piezas y componentes. En relación con las formas de pago, en 17 casos se
pagó mediante una combinación de ambas variantes. En los restantes casos se dividió por
igual el pago mediante cheque y el pago en efectivo.
4.1.5. Centro quirúrgico
La figura representa el diagrama del proceso de gestión de operaciones de un centro quirúrgico que
funciona bajo dos modalidades: operaciones ambulatorias y operaciones más complejas que
requieren estadías hospitalarias más largas.
33
Reprogramar Solicitud
de ingreso
fecha de
(Pendiente) Reservar
Solicitud Registro de No ingreso Nueva
de ingreso camas Transfusión transfusión
(Recibida) fecha de ingreso sanguínea
Verificar Verificar Reservar
Registrar ¿Camas Equipo de Reservar
disponibilidad necesidades de equipo de paro
paciente disponibles? respiración quirófano
Nueva de camas la operación respiratorio
solicitud de
ingreso Larga estadía Reservar Reservar
Plasma
Sí plasma equipo médico
Solicitud Verificar tipo Tipo de
de ingreso de operación operación
(Registrada)
Realizar Indicar
Ambulatoria operación cuidados post-
operatorios
a) Sobre el diagrama diga si las siguientes afirmaciones son verdaderas (V), falsas (F) o no se dice
(NSD). Justifique en caso de que sean falsas.
I. ______ Todo paciente registrado es operado
II. ______ Siempre que al paciente se le realice una operación de larga estadía, se reserva el
equipo de paro respiratorio.
III. ______ Cuando se ingresa a un paciente para operar en la modalidad de larga estadía, se
garantiza que la próxima operación programada sea ambulatoria.
Obtenga un gráfico de barras que muestre todas las estadísticas del funcionamiento del proceso en
el año 2018. Considere las siguientes métricas: pacientes registrados, pacientes reprogramados,
pacientes con operaciones de larga estadía, transfusiones de sangre reservadas, equipos de paro
respiratorios reservados, cantidad de unidades de plasma reservadas, cantidad de operaciones
ambulatorias reservadas, cantidad de equipos médicos reservados, cantidad de quirófanos
reservados, cantidad de pacientes operados. Para ello, tenga en cuenta los siguientes datos que
fueron registrados sobre el comportamiento del proceso: En el 2018 se registraron 120 pacientes.
De ellos, al 30% hubo que reprogramarles una nueva fecha de ingreso por falta de camas disponibles
al momento de su arribo. La mitad de las operaciones programadas fueron de larga estadía. De
estas, solo a un tercio requirieron que se les reservara plasma. A todas hubo que reservarles el
equipo de paro respiratorio y transfusión sanguínea.
34
4.2. Parte II: Modelación de procesos organizacionales con la notación BPMN.
4.2.1. Representación de reglas
Represente, utilizando la notación para la modelación de proceso de negocio (BPMN), las siguientes
reglas:
a) La tarea Z solo puede ejecutarse cuando hayan terminado las tareas M, N y L. Estas tres últimas
son independientes secuencialmente.
b) La tarea A es interrumpida cuando excede las tres horas, en ese caso finaliza el proceso. Si la
tarea A termina en menos tiempo entonces continúa hacia la tarea B.
c) Cuando culmina la tarea M el flujo de salida está condicionado de la siguiente forma:
▪ siempre debe ir hacia la tarea N y,
▪ simultáneamente debe ir hacia la tarea P solo en el caso que termine satisfactoriamente,

si no va hacia la tarea Q.
4.2.2. Encendido del teléfono celular
Cuando un usuario enciende su teléfono celular debe introducir el código PIN para inicializar el
teléfono, si el código es incorrecto vuelve a solicitar el código y puede intentar hasta 3 veces, si en
las tres oportunidades falla se le solicita el código PUNK. Para introducir el código PUNK tiene 6
oportunidades, si tiene 6 intentos fallidos entonces se cancela el servicio y no puede inicializar el
teléfono. Complete el modelo del proceso, logrando comunicar todo lo que ocurre en el proceso.
Encender Introducir
Solicitar PIN Verificar PIN
teléfono PIN
¿PIN
correcto?
Solicitar Introducir Verificar

PUNK PUNK PUNK
¿PUNK
correcto?
4.2.3. Tienda discos duros
En una tienda de discos duros de Laptop, el servicio de venta inicia con el recibo de una solicitud del
cliente, el vendedor registra los datos del pedido para verificar su disponibilidad en la base de datos.
Si no existe, puede optar por un nuevo pedido; si existe, se muestra información de la ubicación del
producto en los estantes de la tienda, busca el producto y llegan a un acuerdo de la venta del
producto, en este caso el cliente puede decidir comprar, no comprar, o cambiar al pedido. Luego que
el cliente decide comprar, para agregarle valor al servicio, se le propone instalar los softwares del
35
sistema. Finalmente se facturan los productos adquiridos y los servicios de instalación (si el cliente
lo solicita), para luego efectuar el cobro.
a) Complete el modelo del proceso, logrando comunicar todo lo que ocurre en el proceso.
¿Hacer otro
pedido?
No
Registrar Mostrar
Recibir Verificar Buscar Negociar Decide
datos del Sí ubicación de
solicitud disponibilidad producto producto comprar
pedido los productos Proponer
¿Disponible?
servicio
Proponer servicio de Instalar software

instalar software de de sistema Cobrar
Proponer sistema
servicio
4.2.4. Gestión de solicitudes de compra.
A continuación, se describen las reglas para el proceso de gestión de solicitudes de compra de

productos para abastecer un mercado
I. El proceso se inicia cuando el inventario de algún producto es igual o menor al stock de

seguridad.
II. El sistema cuando detecta la condición anterior genera, automáticamente, un nuevo

pedido de compra, de acuerdo a los requerimientos de compra del producto.
III. Luego el gestor de compra con el nuevo pedido de compra envía la solicitud al proveedor.
IV. Cuando el pedido de compra está en estado enviado, el gestor espera por la respuesta.
V. Si la respuesta es el rechazo del pedido, entonces se selecciona un proveedor alternativo

de la base de datos y se ajusta el pedido a los requerimientos del nuevo proveedor.
VI. Si la respuesta del proveedor es el envío de la prefactura, entonces se le envía una

confirmación a dicho proveedor, convirtiéndose la prefactura de estado nueva a recibida.
36
A usted se le pide que:
a) Complete el diagrama de proceso utilizando la información ofrecida en el ejercicio.
b) Represente el flujo de información del proceso representado.
4.2.5. Aseguramiento para eventos.
La empresa de Aseguramientos para Eventos, brinda un servicio asociado a la gestión reservaciones

que garantice que empresas de otras provincias participen en los eventos que se desarrollan en La
Habana. Con el objetivo de mejorar el proceso de reserva, se ha realizado un estudio que permitió
levantar las siguientes reglas de negocio y el flujo de información:
I. El proceso se inicia cuando llega una nueva solicitud de reserva.
II. Cuando la solicitud es registrada se inician las reservaciones de transporte y hospedaje

paralelamente.
III. Para reservar el transporte, primero se genera la solicitud de transporte a partir de la solicitud
de reserva inicial.
IV. Si el medio de transporte es en tren, entonces se reserva el pasaje del tren y un almuerzo
para el viaje.
V. Si el medio de transporte es en ómnibus, entonces solamente se realiza la reservación del

pasaje. Para reservar la habitación, primero se genera la solicitud de hospedaje a partir de la
solicitud de reserva inicial y luego se reserva la habitación.
VI. Luego de realizar ambas reservaciones, transporte y hospedaje, se conforma un informe que
refleja que la solicitud de reserva ha sido realizada.
37
VII. Las tareas y la información que fluye por el proceso se muestran con sus correspondientes
estados a continuación:
Registrar solicitud Reservar pasaje

de reserva en tren
Solicitud Solicitud Solicitud Solicitud Solicitud
de reserva de transporte de almuerzo de transporte de hospedaje
(Nueva) en tren (Nueva) en ómnibus (Nueva)
(Nueva) (Nueva) Generar solicitud
Reservar almuerzo
de transporte
Solicitud Solicitud Solicitud Solicitud Solicitud

de reserva de transporte de almuerzo de transporte de hospedaje Generar solicitud Reservar
(Registrada) en tren (Realizada) en ómnibus (Realizada) de hospedaje habitación
(Realizada) (Realizada)
Enviar informe Reservar pasaje

Solicitud de reserva en ómnibus
de reserva
(Realizada)
a) Modele el proceso descrito utilizando BPMN.
b) Represente el flujo de información del proceso.
4.2.6. Lavanderías Sirenas.
Las Lavanderías Sirenas, tiene como misión brindar servicios de lavado de lencería a todos los
hoteles del sector turístico. Con el objetivo de mejorar el proceso de recepción de envíos de lencería
para darle tratamiento, se ha realizado un estudio que permitió levantar las siguientes reglas de
negocio y el flujo de información:
I. El proceso se inicia con la llegada de un nuevo envío que viene acompañado del informe de
envío.
II. Cuando se recibe la mercancía se registra los responsables del proceso de recepción, en
esta tarea se genera una nueva orden de conteo.
III. Luego se registra, detalladamente, la información del envío transformándose de estado

asignado a registrado; paralelamente se inicia el conteo a ciegas con la nueva orden de
conteo.
IV. Luego de contar a ciegas los productos (orden de conteo realizada), se inspecciona de
manera integral el envío; si tiene deficiencias se registran, si no se aprueba la calidad del
envío.
38
V. Finalmente, luego de concluir la inspección y el registro de la información del envío, se cotejan
los resultados de la orden aprobada u orden deficiente, con la información del envío
registrada, obteniendo como resultado la información del envío cotejada.
VI. El proceso finaliza enviando tales resultados a todos los interesados.
VII. Las tareas y la información que fluye por el proceso se muestran con sus correspondientes
estados se muestran a la derecha.
Registrar Contar a ciega los

información de los productos
Información Información Información Información responsables
del envió del envió del envió del envió
(Nueva) (Asignada) (Registrada) (Cotejada) Inspección integral
Aprobar calidad del de la calidad del
envío envío
Orden Orden Orden Orden Orden Cotejar resultados

de conteo de conteo de conteo de conteo de conteo Registrar deficiencias
del conteo con la
(Nueva) (Realizada) (Inspeccionada) (Aprobada) (Deficiente)
información del
Registrar envío
información del envío
a) Modele el proceso descrito utilizando la notación BPMN.
b) Represente el flujo de información del proceso.
4.2.7. Servicios de Auditoría.
Los auditores de la ONAT provincial de la Habana tienen como misión verificar la correcta
determinación y pago de los aportes en materia tributaria al Presupuesto del Estado. A continuación,
se describe el proceso de verificación del Impuesto sobre el Transporte Terrestre que debe pagar
una Empresa.
El proceso se inicia cuando el Equipo de Auditores recibe la orden trabajo para auditar una Empresa.
Previo a la auditoría el equipo estudia las referencias de la Empresa a auditar. Luego el Equipo de
Auditores solicita a la PNR el registro de vehículos que debería tener la Empresa, lo registra en el
software de auditoría y este calcula, según las tasas para cada vehículo, el total de impuesto a pagar
por concepto de transporte terrestre. Paralelo a ello se le solicita los modelos de pago de vehículos
a la empresa, lo cual constituye la evidencia de pago de los vehículos al banco. Una vez registrado
los modelos de pago y calculado el total a pagar, el software coteja lo que realmente pagó con lo
que debería pagar para detectar alguna anomalía. Si las cuentas están correctas se cierra el informe
39
de auditoría y se le notifica el resultado a la empresa; si han pagado de más se le notifica a la
empresa el exceso y se cierra el informe de auditoría; y si hay un pago por debajo de lo establecido
o fuera de fecha, el software calcula un recargo por demora y una multa fiscal de sanción que
posteriormente se notica a la Empresa y se cierra el informe de auditoría.
a) Modele utilizando BPMN el proceso que ejecuta el Equipo Auditores (Especifique siempre el
tipo de tarea que se ejecuta y el flujo de información a través del proceso).
b) Agregue a la representación del proceso que ejecuta la Empresa a auditar la siguiente regla:
Si el subproceso de Ejecutar pago de deuda dura más de 15 días, la empresa recibe una
notificación de que su cuenta está congelada.
c) Coreografiar el proceso que ejecutan el Equipo de Auditores y la Empresa que se audita.
Recibir
notificación de
Recibir Enviar devolución Solicitud
Empresa auditada
solicitud de modelo de pagos de devolución

Arribo del modelos de pago de vehículos Recibir
equipo de cierre de
auditoría auditoría
Recibir Ejecutar pago de

notificación de deuda
deuda
4.2.8. Reservación de asientos en un cine.
La reservación de asientos en un cine se realiza asistida por un sistema informático, que opera el
personal de la taquilla. El sistema ayuda a identificar, pre-reservar y reservar asientos disponibles;
también, a establecer ofertas de precios a partir de la aplicación de descuentos. El flujo de trabajo
comienza cuando el cliente solicita una reservación, momento en el que se registran los datos de la
reservación (datos personales, día de la función deseada, forma de pago, cantidad de asientos,
cantidad de niños, cantidad de estudiantes, lugar preferido dentro del cine). En la taquilla, con la
ayuda del sistema, se determinan si existen asientos disponibles. En caso de que no haya, se le
comunica al cliente que se agotaron, de lo contrario, los asientos libres encontrados se bloquean
automáticamente para que no puedan ser asignados a otros clientes, dado que ya han sido pre-
reservados por el cliente solicitante. El sistema, teniendo en cuenta los datos de la reservación y de
los asientos bloqueados, ejecuta una regla para determinar el descuento que puede ser aplicable.
La regla aplica descuentos progresivos por la cantidad de niños, y el 50% del precio del asiento por
40
cada estudiante; también, por la forma de pago y por la cantidad de veces que el titular de la cuenta
ha asistido al cine. Esas condiciones para aplicar las reglas están almacenadas en una base de
datos. Una vez determinado el descuento aplicable se calcula automáticamente el precio por los
asientos pre-reservados.
Esta oferta de precios se le comunica al cliente, y se espera por su respuesta. En caso de que acepte
la oferta, el sistema reserva automáticamente los asientos, y culmina el proceso comunicándole al
cliente la confirmación de la reservación. Puede darse el caso de que el cliente desee modificar los
datos de la reservación. En esta situación, el sistema libera los asientos que habían sido bloqueados
y le permite al cliente comenzar de nuevo el flujo de trabajo. El sistema también libera los asientos
que habían sido prereservados en los casos en que el cliente no esté de acuerdo con la oferta, o
cuando pasados dos minutos de enviada la oferta, el cliente no ha respondido. En este último caso,
el sistema considera que la culminación del proceso es un error, a causa de que se venció el tiempo
para confirmar la reservación.
a) Diagrame la secuencia de actividades y el flujo de datos del proceso de reservación de

asientos, utilizando la notación BPMN. Tenga en cuenta que el cliente es un rol externo; en
tal sentido, represente el intercambio de información que evidencie la colaboración de este
rol con el proceso. También, que existe una call activity (actividad de llamada) que permite la
liberación de los asientos bloqueados.
4.2.9. Gestión del proceso clave de un restaurante.
Se desea obtener un diagrama BPMN del proceso clave de un restaurante. El proceso transcurre
por 3 etapas importantes: la reservación, la ejecución del servicio y, por último, el cobro a los clientes.
El proceso se inicia con la recepción de una nueva solicitud de reservación que posteriormente es
registrada por el capitán del restaurante. En la solicitud de reservación los clientes declaran su
nombre completo, los detalles deseados para la reservación entre los que se encuentran: la fecha,
hora, la cantidad de comensales, cantidad de niños menores de 2 años, el tipo de mesa
(fumadores/no fumadores, pasillo o vista al mar), entre otros datos. A continuación, se verifica la
disponibilidad de mesas teniendo en cuenta las características deseadas. En caso de que no se
encuentren mesas disponibles de acuerdo a las exigencias de los clientes, se le comunica la falta
de disponibilidad y se finaliza el proceso. En caso contrario, se realiza la reserva, se le comunica al
cliente y se espera por el día de la reservación.
Cuando llega la fecha de la reservación, se espera por el arribo del cliente. En caso de que pase el
horario límite para mantener las reservaciones sin que el cliente llegue, se libera la mesa que se
41
encontraba reservada, quedando así la reservación cancelada. Cuando el cliente se presenta en el
restaurante, se ejecuta el servicio gastronómico de acuerdo a las normas de la casa. En la ejecución
del servicio están contenidas actividades como dar la bienvenida a los clientes, mostrarles el menú
de ofertas, generar la cuenta de los servicios, entre otras. Durante la ejecución del servicio, el capitán
puede detectar alguna inconformidad o queja por parte del cliente, sin que esto implique la
interrupción del servicio. Ante esta situación, el capitán registra la inconformidad o queja y el gerente
del restaurante la valora.
En caso de que la inconformidad o queja sea válida, se genera una orden de descuento para los
clientes. De lo contrario, se registran las razones por las que no procede. En cualquiera de los dos
casos: a) en el que se genera la orden de descuento, o b) en la que se registra la queja como no
válida, se sigue a la etapa de cobro. Pero esta etapa de cobro siempre ocurrirá una vez que el
servicio ha sido ejecutado, tanto si hay inconformidades como si no las hay. Cuando se cobra, se
genera un recibo. La información del recibo se le envía al cliente, con lo cual culmina el proceso.
a) Diagrame la secuencia de actividades y el flujo de datos del proceso del restaurante. Tenga
en cuenta que el cliente es un rol externo; en tal sentido, represente el intercambio de
información que evidencie la colaboración de este rol con el proceso.
4.2.10. Servicios a proyectos.
La empresa de servicios ingenieros SERVIPROY trabaja por proyectos, lo que significa que la
empresa, ante el arribo de un cliente, debe identificar las necesidades preliminares de éste, para luego
generar el diseño lógico del proyecto que satisfaga dichas necesidades, asignar recursos al proyecto,
ejecutar el proyecto y, por último, facturar los servicios (ver figura).
Identificar de Generar Asignar

Ejecutar Facturar
necesidades diseño lógico recursos al
proyecto servicios
del cliente del proyecto proyecto
Diseño Identificación de Análisis de

Valoración del
preliminar del nuevos puestos factibilidad del
presupuesto
proyecto de trabajo proyecto
Durante el diseño lógico, la empresa puede identificar la necesidad de diseñar nuevos puestos de
trabajo, de modo que se ajusten a las demandas de competencias profesionales que en el proyecto
se requieran. Luego, si el puesto de trabajo se crea, entonces la empresa evalúa los candidatos a
42
ocupar los puestos, los selecciona, les asigna tareas en el proyecto y evalúa sus desempeños, todo
esto como parte de las etapas de asignación de recursos y ejecución del proyecto.
Para el diseño de los puestos, SERVIPROY colabora con la empresa GRHCONS. GRHCONS tiene
la función de generar el diseño de dichos puestos, previa evaluación de la necesidad de éstos en el
proyecto. También actúa como agencia empleadora, lo que significa que tiene la responsabilidad de
publicar las ofertas de plazas para cubrir los puestos, contratar a los trabajadores seleccionados
para los puestos, y remunerarlos.
Ud. debe modelar:
a) La secuencia de actividades que ejecuta la empresa SERVIPROY en colaboración con

GRHCONS, para la identificación de nuevos puestos de trabajo, garantizando que se
represente el intercambio de información entre ambas empresas, así como el flujo de datos.
Tenga en cuenta que GRHCONS es una entidad independiente a SERVIPROY.
A continuación, se describen algunas reglas de este proceso:
I. El proceso comienza cada vez que se identifica la necesidad de un nuevo puesto de

trabajo para un proyecto.
II. El jefe del proyecto debe especificar los requisitos del nuevo puesto de trabajo que
se desea. El documento que se genera de esta actividad es enviado a GRHCONS
para su evaluación, y en caso de ser aprobado, sirve de base para el diseño del
puesto de trabajo.
III. Como resultado de la evaluación realizada, puede determinarse que la información

aportada por SERVIPROY no es suficiente para tomar una decisión sobre el puesto
de trabajo, en cuyo caso el jefe de proyecto debe volver a especificar los requisitos
del puesto, prestando atención a la información adicional que GRHCONS requiere.
IV. Si la decisión de GRHCONS es que el puesto de trabajo no es necesario, entonces

SERVIPROY recibe un documento con la argumentación del por qué el puesto no
es aprobado. Este documento es asociado al proyecto, para que forme parte de su
documentación.
V. El diseño del puesto de trabajo que recibe SERVIPROY es sometido a una

valoración por parte del Consejo Técnico Asesor (CTA) de la entidad. Este consejo
está compuesto por un grupo de expertos que revisan la calidad del diseño desde el
punto de vista técnico, legal, si es fácil de entender, entre otros aspectos. En caso
43
de que el CTA no avale el diseño, emite una notificación de no conformidad a
GRHCONS. En este caso, GRHCONS tiene hasta 15 días para enviar las mejoras
al diseño para que el CTA vuelva a valorarlo. De no recibirse al cabo de este plazo,
el CTA comunica la necesidad de prescindir los servicios de GRHCONS y el proceso
culmina con la no aprobación del puesto de trabajo. Esta comunicación se hace
pública y llega a contabilidad, a la dirección de la empresa, a otras partes interesadas
y, por supuesto, a la propia empresa GRHCONS.
VI. Si el CTA avala el diseño se actualiza el proyecto con la información del diseño del
puesto de trabajo.
VII. SERVIPROY cuenta con una base de datos donde se almacenan las informaciones
de los proyectos. Todas las consultas y escrituras en esta base de datos son
realizadas por el jefe de proyecto.
b) La secuencia de actividades que ejecuta la empresa GRHCONS para satisfacer la necesidad

de SERVIPROY de identificación de nuevos puestos de trabajo. Garantice la representación
del intercambio de información entre ambas empresas, así como el flujo de datos. Tenga en
cuenta que SERVIPROY es una entidad independiente a GRHCONS.
A continuación, se describen algunas reglas que deben cumplirse en el proceso que ejecuta
GRHCONS:
I. El proceso comienza cada vez se recibe los requisitos especificados para el diseño de un
nuevo puesto de trabajo requerido en un proyecto.
II. El especialista debe evaluar los requisitos del nuevo puesto de trabajo que se desea. Como
resultado de la evaluación realizada, puede determinarse que la información recibida no es
suficiente para tomar una decisión sobre el puesto de trabajo, por lo que SERVIPROY debe
volver a especificar los requisitos del puesto para que sea evaluada nuevamente.
III. Si la decisión de GRHCONS es que el puesto de trabajo no es necesario, entonces

SERVIPROY recibe un documento con la argumentación del por qué el puesto no es
aprobado.
IV. Si el puesto es considerado necesario, se genera el diseño del puesto. El documento que
se obtiene de esta actividad es enviado a SERVIPROY para su aprobación por el Consejo
Técnico Asesor (CTA) de esa entidad.
44
V. El diseño del puesto es realizado por un equipo de consultores. Estos deben definir los
conocimientos, habilidades y niveles de experticia requeridos para poder ocupar el puesto,
así como las condiciones de iluminación, clima, entre otros requisitos técnicos que el puesto
necesite.
VI. Como resultado de la valoración que realiza el CTA, SERVIPROY puede emitir una no
conformidad, en cuyo caso debe realizarse una mejora al diseño, teniendo en cuenta el
diseño previo y las observaciones que justifican la no conformidad.
VII. Para enviar la documentación de la no conformidad, SERVIPROY tiene 15 días de plazo.

En caso de no recibirse observación alguna el equipo de consultores aprueba un plan de
plazas para el puesto de trabajo (es decir, para un puesto de trabajo pueden necesitarse
varias plazas en el proyecto. Por ejemplo: un puesto puede ser especialista en realidad
virtual, y el proyecto podría demandar 3 de estos especialistas).
VIII. El plan de plazas se registra en una base de datos donde GRHCONS almacena la
información de las plazas vacantes asociadas a cada puesto de trabajo; la oferta de plazas
vacantes se publica de manera automática. El proceso culmina garantizando que la
información de las plazas en oferta sea comunicada a varios procesos de ambas entidades,
así como a los profesionales que potencialmente pudieran contratarse como recursos
humanos del proyecto.
45
5. REFERENCIAS
ABDELLATIF, M., FARHAN, M. S. & SHEHATA, N. S. 2017. Overcoming Business Process
Reengineering Obstacles Using Ontology-based knowledge Map Methodology. Future
Computing and Informatics Journal.
ALOTAIBI, Y. 2016. Business process modelling challenges and solutions: a literature review. Journal
of Intelligent Manufacturing, 27, 701-723.
ANTONELLA, P., GIANPAOLO, D. B., ANTONIO, F. & ALESSANDRO, S. 2018. Building excellence
through the Agile Reengineering Performance Model (ARPM): A strategic business model for
organizations. Business Process Management Journal, 24, 128-157.
AYAD, S. 2013. Business Process Models Quality: evaluation and Improvement. Paris, CNAM.
DACHYAR, M. & SANJIWO, Z. 2018. Business Process Re-Engineering of Engineering Procurement
Construction (EPC) Project in Oil and Gas Industry in Indonesia. Indian Journal of Science and
Technology, 8.
DE OCA, I. M.-M., SNOECK, M., REIJERS, H. A. & RODRÍGUEZ-MORFFI, A. 2015. A systematic
literature review of studies on business process modeling quality. Information and Software
Technology, 58, 187-205.
DEB, D. & CHAKI, N. 2018. A framework for goal compliance of business process model. Progress in
Intelligent Computing Techniques: Theory, Practice, and Applications. Springer.
DELGADO FERNÁNDEZ, M. 2018. Proyectos de innovación en Administración Pública y Empresarial
en Cuba / Innovation projects in Public and Business Administration in Cuba. Folletos
Gerenciales, XXII, 71-84.
DUMAS, M., LA ROSA, M., MENDLING, J. & REIJERS, H. A. 2018. BPM as an Enterprise Capability.
Fundamentals of Business Process Management. Berlin, Heidelberg: Springer Berlin
Heidelberg.
EROL, S. 2017. Recalling the rationale of change from process model revision comparison – A change-
pattern based approach. Computers in Industry, 87, 52-67.
EROL, S. 2018. A process model of business process model reuse. in press.
GARIMELLA, K., LEES, M. & WILLIAMS, B. 2012. BPM (Gerencia de procesos de negocio). Tomado
del Libro BPM.
GÓMEZ ESTUPIÑAN, J. F. 2014. Análisis de BPMN como herramienta integral para el modelado de
procesos de negocio. Ventana Informática, 9-25.
GU, V. C., CAO, Q. & DUAN, W. 2012. Unified Modeling Language (UML) IT adoption — A holistic
model of organizational capabilities perspective. Decision Support Systems, 54, 257-269.
ISO-9001 2015. ISO-9001:2015 Sistemas de gestión de la calidad — Requisitos. ISO 9001:2015.
KARLE, T. & TEICHENTHALER, K. 2018. Collaborative BPM for Business Transformations in
Telecommunications: The Case of “3”. In: VOM BROCKE, J. & MENDLING, J. (eds.) Business
Process Management Cases: Digital Innovation and Business Transformation in Practice.
Cham: Springer International Publishing.
KROGSTIE, J. 2016. Quality of business process models. Quality in Business Process Modeling.
Springer.
KRUGER, D. Application of Business Process Reengineering as a Process Improvement Tool: A Case
Study. 2017 Portland International Conference on Management of Engineering and Technology
(PICMET), 9-13 July 2017 2017. 1-9.
LAGOS, N., MOS, A. & VION-DURY, J.-Y. 2017. Multi-Context Systems for Consistency Validation and
Querying of Business Process Models. Procedia Computer Science, 112, 225-234.
LEOPOLD, H., MENDLING, J. & GÜNTHER, O. 2016. Learning from Quality Issues of BPMN Models
from Industry. IEEE, 1.
46
LOOS, P. & ALLWEYER, T. Object-orientation in business process modeling through applying event
driven process chains (EPC) in UML. Proceedings Second International Enterprise Distributed
Object Computing (Cat. No.98EX244), 3-5 Nov 1998 1998. 102-112.
MARTIN, L., ALEXANDER, L. & MAXIMILIAN, R. 2017. Exploring the intersection of business process
improvement and BPM capability development: A research agenda. Business Process
Management Journal, 23, 275-292.
MARYAM, N. & KHAN, S. A. Business process re-engineering for smart manufacturing. 2017 IEEE
8th Annual Ubiquitous Computing, Electronics and Mobile Communication Conference
(UEMCON), 19-21 Oct. 2017 2017. 424-430.
MICHAEL, L., ANN-KATHRIN, H. & JUERGEN, M. 2018. Achieving sustainable behavioral changes of
daily work practices: The effect of role plays on learning process-oriented behavior. Business
Process Management Journal, 24, 1050-1068.
MOJCA, I. Š., BRINA, B., LJUBICA, M. G. & JAN, M. 2018. Propositions on the interaction of
organizational culture with other factors in the context of BPM adoption. Business Process
Management Journal, 24, 425-445.
ORTBACH, K., PLATTFAUT, R., PÖPPELBUß, J. & NIEHAVES, B. 2012. A Dynamic Capability-based
Framework for Business Process Management: Theorizing and Empirical Application. IEEE, 10.
OUALI, S., MHIRI, M. & GARGOURI, F. A Meta-modeling Approach to Create a Multidimensional
Business Knowledge Model Based on BPMN. 2018 Cham. Springer International Publishing,
806-815.
PETERS, L. & PETERS, J. Using IDEF0 for dynamic process analysis. Proceedings of International
Conference on Robotics and Automation, 20-25 Apr 1997 1997. 3203-3208 vol.4.
RAHIMI, F. 2016. Management of business process design in global implementation of enterprise
resource planning systems.
SATYAL, S., WEBER, I., PAIK, H.-Y., DI CICCIO, C. & MENDLING, J. 2018. Business Process
Improvement with the AB-BPM Methodology. Information Systems.
VAN DER AALST, W. M. P. & VAN HEE, K. M. 1996. Business process redesign: A Petri-net-based
approach. Computers in Industry, 29, 15-26.
VILASDECHANON, S. & SOPADANG, A. Business process reengineering for the saline management
in hospitals. 2018 5th International Conference on Industrial Engineering and Applications
(ICIEA), 26-28 April 2018 2018. 84-88.
XU, W., XUAN, Z., TONG, L., JUNHUI, L. & QINGYI, C. 2018. Correctness of aspect-oriented business
process modeling. Business Process Management Journal, 24, 537-566.
47
View publication stats

Monografía BPMN

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Monografía BPMN

Cargado por

Copyright:

Formatos disponibles

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

MONOGRAFÍA: Primeros pasos para el modelado de procesos con BPMN

Book · November 2020

Yanelis Pavón-González Yadary C. Ortega-González

SEE PROFILE SEE PROFILE

Sajay Souchay Alzugaray Marta Beatriz Infante Abreu

SEE PROFILE SEE PROFILE

Competencias y roles asociados a la Getión de Arquitecturas Empresariales View project

Proyecto PBKM View project

The user has requested enhancement of the downloaded file.

FACULTAD DE INGENIERÍA INDUSTRIAL

Yanelis Pavón González

Yadary Cecilia Ortega González

Sajay Souchay Alzugaray

Marta Beatriz Infante Abreu

Dayron Cruz Hondal

Lourdes Santos Planas

Luis Ramiro Mendiburo Martínez

Jose Raul Lorenzo Sanchez

Patricia Airela Abreu Fong

Nancy Arencibia Álvarez

Jeffrey Blanco González

Cada una de estas aproximaciones están enmarcadas en la disciplina de gestión de procesos

La siguiente monografía tiene el propósito de abordar el estándar de modelado de procesos de

2. NOTACIÓN PARA EL MODELADO DE PROCESOS DE NEGOCIO

Cuadro 2-1: Elementos básicos de la notación BPMN – OMG 2011

Actividades Flujo de secuencia Objeto de dato

Compuertas Flujo de mensaje Mensaje

Objetos de flujos: Son los elementos principales que se describen en BPMN:

- Actividades. Describen el trabajo desarrollado dentro de un proceso de negocio, pueden ser

Objetos de conexión: Relacionan los objetos de flujo, y son:

2.1. Representación de actividades

Marcador de actividad Tipos de tareas

Tarea Subproceso Compensación Envío Recibir Manual Servicio

Instancias Instancias Ciclo Usuario Regla de Ejecución

Cuadro 2-3: Ejemplo de diagrama de secuencia de actividades

Generar orden de Cerrar orden de

2.2. Uso de eventos en el flujo de secuencia

Cancelación: Reacción a la cancelación de una transacción/ Solicitud de cancelación.

Compensación: Solicitud de compensación. Los eventos de compensación se

Terminación: Terminación inmediata del proceso.

Mostrar error de Llenar encuesta de

2.3. Uso de compuertas en el flujo de secuencia

Cuadro 2-6: BPMN 2.0 – Compuertas

Comportamiento complejo de convergencia/bifurcación no capturado por el

Cuadro 2-7: Ejemplo de diagrama usando compuertas exclusivas

Evaluar factibilidad Rechaza negocio

La compuerta inclusiva soporta decisiones donde es posible más de un resultado en el punto de

Cuadro 2-8: Variantes de comportamiento de flujo de la compuerta inclusiva.

Condición 1 Tarea 1 Condición 1 Tarea 1 Condición 1 Tarea 1

Condición 2 Tarea 2 Condición 2 Tarea 2 Condición 2 Tarea 2

Condición 3 Tarea 3 Condición 3 Tarea 3 Condición 3 Tarea 3

Brindar asistencia Cobrar importe

2.4. Representación de responsables de ejecutar las actividades

Evaluar factibilidad Rechaza negocio

2.5. Representación del flujo de información del proceso

Cuadro 2-11: BPMN 2.0 – Objetos de datos

Una Colección de Objetos de Datos representa una colección

Un Almacén es un lugar donde el proceso puede leer o escribir

Un Mensaje es utilizado para representar el contenido de una

Cuadro 2-12: Ejemplo de diagrama utilizando flujo de información interno

Evaluar factibilidad Rechaza negocio

3. EJERCICIO DEMOSTRATIVO DE MODELADO DE PROCESO