Ejercicios adicionales de BPMN

Ejercicio 1
En el ejemplo siguiente se omite el modelo correspondiente al cliente…
Suponemos una organización que recibe solicitudes (a través de formularios) de potenciales clientes para la
concesión de hipotecas. La empresa realiza una evaluación de si ofrecer o no la hipoteca, y en función de eso
comunican el rechazo o realizan la oferta de hipoteca.
Ahora asumamos que queremos representar el hecho de que un cliente contacta la empresa para pedir un
formulario de solicitud, la empresa se lo envía y activa un temporizador para enviarle un recordatorio al cliente si no
recibe la solicitud en un periodo de tiempo de siete días.
Para que la empresa no se encuentre con iteraciones infinitas, puesto que un formulario de solicitud podría no llegar
nunca, decide establecer un contador de iteraciones en la espera del formulario para que si se ha avisado al cliente
ya tres veces se archiven los detalles del pedido de solicitud y no se espere más el formulario.
Se decide contemplar la situación de que el cliente informe que no está interesado en realizar la solicitud de
evaluación una vez que recibe el formulario. En ese caso, al igual que cuando se le envía recordatorio 3 veces se
archivan los detalles del pedido de solicitud.

Ejercicio 2
Construir el modelo de colaboración que describe la interacción entre un cliente y una pizzería. En el proceso los
clientes y los trabajadores de la pizzería son participantes y deben tener un pool cada uno.
El proceso comienza cuando el cliente tiene hambre. Entonces selecciona una pizza y realiza el pedido. Después de
eso el cliente espera a que algún trabajador de la pizzería le entregue su pizza horneada y preparada para comérsela.
Previamente a comérsela deberá pagar la pizza!
Sin embargo este proceso no siempre será perfecto, y puede suceder que el cliente lleve 60 minutos esperando y no
sepa nada de su pizza. En ese caso deberá preguntar a un empleado por su pizza. El empleado le calmará y el cliente
volverá a esperar (esto puede volver a repetirse).
Ejercicio 3
Modelar el proceso de préstamo de libros de una biblioteca. El proceso comienza con la recepción de un pedido de
libro. En la biblioteca se comprueba el estado del libro. En el caso de que el libro esté disponible se registra la salida
del libro y se envía mail con la confirmación de la salida. En el caso de que el libro no esté disponible se informa al
usuario de que el libro está en préstamo y de que si lo desea puede ponerse a la espera. Si el usuario declina la
espera o no responde en una semana se cancela la petición y finaliza el proceso. Si el usuario desea esperar, se
registra la petición de espera, se responde al usuario y pasadas dos semanas se vuelve a comprobar el estado del
libro (iniciando de nuevo el proceso).

Ejercicio 4
Cada mañana de lunes a viernes, la base de datos se respalda (se hace un backup) y luego se revisa para ver si la
tabla de "Cuentas de morosos” (Account Defaulter) tiene nuevos registros. Si no hay nuevos registros, entonces el
proceso debe revisar el sistema CRM para ver si se han presentado nuevas declaraciones. Si existen nuevas
declaraciones, entonces se registran todas las cuentas y nombres de clientes morosos. Si los códigos de clientes
morosos no han sido informados previamente, producir otra tabla de cuentas morosas y enviar a la administración
de cuentas. Todo esto debe ser completado antes de las 14:30, sino, entonces se enviara una alerta al supervisor.
Una vez finalizado el nuevo informe de cuentas morosas, comprobar el sistema CRM para ver si se han presentado
nuevas declaraciones. Si se han presentado nuevas declaraciones, conciliar con la tabla cuentas de morosos
existente. Esto debe ser completado antes de las 16:00, de lo contrario debe enviarse un mensaje a un supervisor.
Esta solución reconoce que existe una diferencia entre ocuparse de la actividad de lote (respaldo de la base de datos)
y ocuparse de cada instancia preguntando si han sido morosos anteriores. También utiliza una serie de eventos de
temporizador intermedios paralelos para enviar la alerta, en combinación con los eventos de finalización.
Ejercicio 4
El Representante de Servicio al Cliente envía una oferta de hipoteca al cliente y espera una respuesta. Si el cliente
llama o responde al mensaje rechazando la oferta, el caso se actualizan y el trabajo se archiva como paso previo a su
cancelación. Si el cliente devuelve la solicitud rellenada y adjunta los documentos necesarios el caso se traslada al
departamento de administración para que complete el proceso. Si falta algún documento necesario como requisito
previo se genera un mensaje al cliente solicitando los documentos faltantes. Si no se recibe ninguna respuesta
después de 2 semanas, se actualizan los detalles del caso antes de su archivo y cancelación

Ejercicio 5
En noviembre de cada año, la Unidad De Coordinación De La Autoridad De Planificación de la ciudad elabora un
calendario de reuniones para el próximo año y añade fechas provisionales a todos los calendarios. El Oficial De
Apoyo comprueba las fechas y sugiere modificaciones. Después la Unidad De Coordinación verifica todas las fechas y
busca posibles conflictos. El programa definitivo de las fechas de la reunión se envía a todos los Miembros del
Comité por correo electrónico, los cuales comprueban sus diarios e informan la unidad de coordinación de cualquier
conflicto. Una vez que la revisión de las fechas ha finalizado (por la unidad de coordinación), el Oficial de Apoyo
actualiza todos los calendarios de grupo y crea carpetas de reunión para cada reunión y asegura que todos los
documentos apropiados se suben al sistema. Los miembros del Comité reciben una notificación una semana antes la
reunión recordándoles los documentos relacionados que deben leer. Los miembros del Comité celebra sus reunión,
y el Oficial de Apoyo entonces produce minutas (“minutes”) incluyendo los puntos de acción para cada Miembro del
Comité. Dentro de 5 días hábiles, la unidad de coordinación debe llevar a cabo una comprobación Pregunta-
Respuesta sobre las minutas y enviarla a todos los miembros del Comité. Finalmente, el Oficial de Apoyo entonces
actualiza todos los registros departamentales,

Si el modelador intenta usar un solo proceso es extraordinariamente difícil, sin embargo si se utilizan dos procesos, la
respuesta es obvia y relativamente simple. Observe el uso del flujo de mensajes para comunicarse entre piscinas
(como los miembros del Comité de trabajo fuera de la autoridad de planificación de la ciudad).
Tenga en cuenta que la reunión se indica con un grupo a través de las dos piscinas. También hemos usado un evento
intermedio sin tipo (plain event) para representar a los miembros del Comité a la espera de las actas de la reunión.
Tenga en cuenta que este evento intermedio no se hará esperar realmente. Será inmediatamente disparado y pasará
el flujo al evento mensaje, el cual hará la espera real.
Ejercicio 6
Tras recibir el informe de gastos, se debe crear una nueva cuenta si el empleado no tiene ya una. El informe luego se
revisa para aprobación automática. Cantidades menores a $200 están aprobados automáticamente, mientras que
cantidades iguales o superiores a $200 requieren la aprobación del supervisor. En caso de rechazo, el empleado
debe recibir una notificación de rechazo por correo electrónico. El reembolso va a la cuenta bancaria del empleado.
Si la solicitud no se completa en 7 días, el empleado debe recibir un correo electrónico de "aprobación en progreso",
si la solicitud no ha terminado dentro de 30 días, entonces el proceso se detiene y el empleado recibe por correo
electrónico un aviso de cancelación y debe volver a enviar el informe de gastos.

Ejercicio 7
Después de que el proceso se inicia, se realiza una tarea para ubicar y distribuir cualquier diseño existente relevante,
tanto eléctrico como físico. A continuación, el diseño de los sistemas eléctricos y físicos comienza en paralelo.
Cualquier diseño existente o previo se usa como entrada para ambas actividades (diseñó eléctrico y diseño físico). El
desarrollo de cualquier diseño es interrumpido por una actualización correcta del otro diseño. Si se interrumpe,
entonces todo el trabajo actual se detiene y el diseño se debe reiniciar.
En cada departamento (diseño eléctrico y diseño físico), cualquier diseño existente se repasa, dando como resultado
un Plan de actualización para sus respectivos diseños. Mediante el plan de actualización y el proyecto existente, se
crea un diseño revisado. Una vez completado el diseño revisado es probado. Si el diseño no pasa las pruebas,
entonces se envía a la primera actividad (en el Departamento) para revisar y crear un nuevo Plan de actualización. Si
el diseño pasa la prueba, se informa al otro departamento de que necesitan reiniciar su trabajo.
Cuando ambos diseños han sido revisados, se combinan y prueban. Si el diseño combinado no pasa las pruebas,
entonces ambos diseños retornan al comienzo del proceso para iniciar otro ciclo de diseño. Si los diseños pasan la
prueba, entonces se consideran completados y son enviados al proceso de fabricación [un proceso separado].

Aunque parece que nunca terminará el ejemplo anterior, de hecho el primer subproceso en acabar con éxito llegará a
la pasarela de evento de señal, y allí esperará que termine el otro subproceso. Mientras tanto, el otro subproceso se
reiniciará antes de pasar a través de su propio evento de terminación basado en señal. Aunque se activará la señal, el
otro subproceso ha completado ya y no podrá "capturar" la señal. Cuando ambos subprocesos han completado con
éxito, el proceso padre se mueve para probar el diseño combinado antes de reiniciar o terminar con éxito. El enlace
para el proceso de fabricación separado no se muestra, probablemente se implementaría mediante un evento final
de señal o un evento final de mensaje.