Proyectos de Sistemas de Software
Ingeniería en Sistemas de Información
Administración de procesos de negocio
Profesor: Gerardo I. Simari
Depto. de Ciencias e Ingeniería de la Computación
Universidad Nacional del Sur – Bahía Blanca, Argentina
2do. Cuatrimestre de 2019
Procesos de negocio
• Administración de procesos de negocio (BPM): análisis del
trabajo realizado para asegurar resultados consistentes y
optimizar los recursos.
• Esta “optimización” busca:
– Reducir costos
– Reducir tiempos
– Reducir cantidad y frecuencia de errores
• Enfoque en procesos: sistemas de actividades y decisiones
que agregan valor a la organización:.
2
Procesos de negocio
• Toda organización funciona en base a procesos.
• Éstos pueden ser manuales, parcialmente automatizados o
completamente automatizados.
Algunos ejemplos comunes:
• Pedido-compra: realizado por un vendedor; comienza cuando un
cliente envía un pedido para comprar un producto o servicio y
termina cuando éste se entrega y el cliente abona.
Engloba actividades relacionadas con verificación de pedidos,
envío, entrega, facturación, pago y confirmación.
3
Procesos de negocio
Algunos ejemplos comunes (cont.):
• Presupuesto-pedido: generalmente precede a los procesos
pedido-compra. Comienza cuando un proveedor recibe un
pedido de presupuesto y termina cuando se entrega.
El cliente puede enviar un pedido en base al presupuesto
recibido, y en este caso se combinan los procesos.
• Procuración-pago: comienza cuando se determina que se
necesita adquirir un producto o servicio, y termina cuando éste
es entregado y abonado.
Incluye actividades como obtención de presupuestos, recepción
de bienes/servicios, facturación, etc. Similar al primero, pero
entre negocios.
4
Procesos de negocio
Algunos ejemplos comunes (cont.):
• Asunto-resolución: comienza cuando un cliente plantea un
problema o asunto a resolver, y termina cuando (idealmente)
ambas partes están de acuerdo en que fue resuelto.
Una variante típica es el proceso de pedido de cobertura a
empresas de seguros.
• Solicitud-aprobación: una persona solicita un beneficio o
privilegio, el cual puede ser otorgado o denegado.
Ejemplos típicos: pedidos de licencias a entidades
gubernamentales, becas o licencias en el trabajo.
5
Procesos de negocio
• El diseño y ejecución de los procesos determina la calidad
del servicio otorgado por la organización.
• Una organización puede superar a otra con productos y
servicios similares si tiene mejores procesos y/o los ejecuta
mejor.
• Esto vale tanto para procesos que tienen contacto con
clientes como aquellos puramente internos.
• A continuación vemos un ejemplo inspirado en un proceso
que ocurre muy a menudo en compañías del mundo real…
6
Procuración-Pago en BuildIT (1)
BuildIT es una compañía de construcción que se especializa
en obras públicas (caminos, puentes, cañerías, túneles,
ferrocarriles, etc.).
Suele suceder que los ingenieros de la compañía necesitan
equipamiento especial (camión, excavadora, topadora,
bomba de agua, etc.); BuildIT no dispone en general de este
tipo de equipos, y opta por alquilarlos de proveedores.
El proceso de negocio existente para alquilar equipamiento
sigue los siguientes pasos: los ingenieros llenan un formulario
llamado “Pedido de alquiler de equipo” y se lo envían por
correo electrónico a un empleado de la central.
7
Procuración-Pago en BuildIT (2)
El empleado recibe el pedido, consulta los catálogos de
proveedores y elige la mejor opción calidad-precio.
Luego, verifica la disponibilidad del equipo con el proveedor
vía correo electrónico o teléfono. A veces sucede que no hay
disponibilidad, y el empleado itera nuevamente.
Una vez encontrado un equipo adecuado y disponible, el
empleado agrega los detalles del equipo al pedido.
Todo pedido debe ser aprobado por un ingeniero de la
central. A veces, los pedidos son rechazados, lo que puede
llevar a alteraciones en el pedido o que no se alquile nada.
8
Procuración-Pago en BuildIT (3)
Cuando se aprueba el pedido, el empleado le envía una
confirmación al proveedor, incluyendo una pedido de compra
para el servicio de alquiler del equipo.
El pedido se genera por el sistema financiero de BuildIT
usando información ingresada por el empleado. El empleado
a su vez ingresa el alquiler en una planilla general.
Puede suceder que, mientras se lleva a cabo este proceso, el
ingeniero de campo decide que ya no necesita el equipo; en
este caso, pide que el empleado cancele el pedido.
El proveedor entrega el equipo en el momento acordado, y el
ingeniero de campo inspecciona el equipo.
9
Procuración-Pago en BuildIT (4)
Si todo está en orden, el ingeniero acepta el equipo y
comienza a utilizarlo. En algunos casos, el equipo es devuelto
por no cumplir con los requerimientos; en este caso, el
ingeniero comienza nuevamente todo el proceso.
Cuando termina el período acordado, el proveedor vuelve a
retirar el equipo; el ingeniero a veces pide una extensión,
contactando por correo electrónico o teléfono al proveedor
uno o dos días antes del fin, y éste puede aceptar o no.
10
Procuración-Pago en BuildIT (5)
Unos días después de devuelto el equipo, el proveedor envía
por correo electrónico una boleta al empleado, quien le pide
al ingeniero de campo que confirme los datos; él también
verifica que la boleta concuerde con los datos registrados en
su planilla.
Luego de que se realizan todos estos controles, el empleado
envía la boleta al departamento de finanzas, quien se
encarga de realizar el pago.
A continuación veremos cómo modelar este proceso...
11
Ingredientes de un proceso
• Ingredientes: eventos y actividades.
– Evento: cosas que ocurren en forma atómica (es decir, su
duración es nula).
– Actividad: cosas que llevan tiempo.
• Ejemplos:
– Evento: entrega de un equipo.
– Actividad: inspección del equipo por parte del ingeniero.
• Las actividades simples (una unidad de tiempo) se llaman
tareas.
12
Ingredientes de un proceso
• Ingredientes: puntos de decisión.
– En estos puntos se toman decisiones que afectan la manera
en la cual se ejecuta el proceso.
– Ejemplo: el ingeniero toma la decisión de aceptar o rechazar
el equipo entregado.
• Ingredientes: actores (humanos, organizaciones, sistemas),
objetos físicos, objetos inmateriales.
• Ingredientes: uno o más resultados (“outcomes”);
idealmente, el resultado entrega valor a los actores.
• El actor que consume la salida del proceso es el “cliente”.
13
Ingredientes de un proceso
14
[Dumas, 2018]
Procesos
Podemos definir un proceso como:
Un conjunto de eventos, actividades y puntos de decisión
interrelacionados que involucran una cantidad de actores y
objetos, y que juntos llevan a un resultado que es de valor
para al menos un cliente.
Esta definición nos ayuda a definir BPM como:
Conjunto de métodos. técnicas, y herramientas para
descubrir, analizar, rediseñar, ejecutar y monitorear procesos
de negocio.
15
Otras disciplinas
BPM no es la única disciplina que se encarga de mejorar el
desempeño operacional de las organizaciones:
• “Total Quality Management” (TQM): históricamente anterior a
BPM. Se enfoca en el mejoramiento continuo de la calidad de
productos y servicios. Se puede considerar que BPM es una de
las actividades que componen TQM.
• Administración de operaciones: campo dedicado al manejo de
funciones físicas y técnicas de una organización. En general
controla procesos existentes sin necesidad de cambiarlos.
16
Otras disciplinas
BPM no es la única disciplina que se encarga de mejorar el
desempeño operacional de las organizaciones (cont.):
• “Lean”: disciplina originada en la compañía Toyota, con enfoque
en eliminar el desperdicio (actividades que no agregan valor).
Muchos de sus principios han sido absorbidos en BPM.
• Six Sigma: otra disciplina originada en la industria (Motorola).
Su enfoque es en la minimización de defectos y errores,
midiendo la salida de procesos y actividades, especialmente en
términos de calidad. Puede aplicarse en conjunto con otras.
17
Historia de BPM (1)
• Un breve repaso de la historia de la disciplina nos ayuda a
comprender su relevancia hoy en día.
• El primer hito de importancia es el surgimiento de
“organizaciones funcionales”:
– Desde tiempos prehistóricos hasta ese momento, los
trabajadores se fueron especializando.
– Surgieron los supervisores (“managers”), que no son
especialistas en las tareas que supervisan sino que buscan
optimizar la productividad.
– El próximo paso fue la creación de unidades funcionales
agrupando personas con enfoques similares.
18
Historia de BPM (2)
• El primer hito de importancia es el surgimiento de
“organizaciones funcionales” (cont.):
– Ésta es la raíz de las unidades que nos son familiares hoy:
compras, ventas, depósito, finanzas, RR.HH., etc.
– Estas organizaciones emergieron de la 2da revolución
industrial y dominaron el paisaje corporativo de gran parte de
los siglos XIX y XX.
• Hacia el fin de la década de 1980, grandes compañías de
EE.UU. identificaron esta área como responsable de su
pérdida de competitividad.
• Las compañías japonesas se estaban llevando los clientes.
19
Historia de BPM (3)
• Próximo hito: Ford compró una parte de Mazda, lo que
llevó a una transferencia de conocimiento.
• Ejecutivos de Ford observaron que las unidades en Mazda
tenían menos personas, pero operaban bien.
Ejemplo: Compras en Ford
20
[Dumas, 2018]
Historia de BPM (3)
• Cada documento de compra tenía unos 14 ítems de datos.
• Las inconsistencias y discrepancias eran manejadas por
cientos de personas en Ford; ¡Mazda empleaba sólo 5!
• Ford rediseñó entonces su proceso de compras:
21
[Dumas, 2018]
Historia de BPM (3)
• Cada documento de compra tenía unos 14 ítems de datos.
• Las inconsistencias y discrepancias eran manejadas por
cientos de personas en Ford; ¡Mazda empleaba sólo 5!
• Ford rediseñó entonces su proceso de compras:
22
Esta BD reemplazó
varios flujos basados en
papel. Se instalaron
terminales con acceso
directo a la BD.
[Dumas, 2018]
Historia de BPM (3)
• Cada documento de compra tenía unos 14 ítems de datos.
• Las inconsistencias y discrepancias eran manejadas por
cientos de personas en Ford; ¡Mazda empleaba sólo 5!
• Ford rediseñó entonces su proceso de compras:
23
Esta nueva
configuración permitió
reducir el personal de
500 a 120 (una
reducción del 76%)
[Dumas, 2018]
Historia de BPM (4)
• Este caso nos muestra que un problema de performance
se puede mejorar al considerar todo el proceso:
– Si bien el problema estaba centrado en el departamento de
cuentas, el proceso involucra tareas de compras, depósito y ventas.
– Las mejoras incluyen modificaciones en intercambios de
información, tecnológicos y estructurales.
• Nació así el pensamiento basado en procesos.
• Emergió un concepto de administración llamado “Business
Process Redesign/Re-engineering” (BPR).
• Fue un boom en la década de 1990.
24
Historia de BPM (5)
Una serie de factores llevaron a la caída de BPR al final de
esa misma década:
• Mal uso de conceptos: algunas compañías abusaban del término
BPR, incluyendo prácticamente cualquier cambio.
• Muchas reducciones de personal fueron hechas bajo la bandera
de BPR, creando resentimiento.
• Radicalización: algunos proponentes de BPR enfatizaron que el
rediseño debía ser radical (“Don’t automate, obliterate”).
• Poca madurez: las herramientas necesarias no estaban
maduras. Por ejemplo, el soporte de IT tenía mucha lógica de
proceso “cableada”.
25
Historia de BPM (6)
• Afortunadamente, estudios empíricos subsecuentes dieron
nueva vida a la idea de mejoras basadas en procesos.
• En estos tiempos también surgieron nuevas herramientas
de IT para alivianar el trabajo:
– Enterprise Resource Planning (ERP): sistemas que
almacenan datos relacionados con operaciones de negocio.
– Workflow Management Systems (WfMSs): distribuyen trabajo
a los actores de una compañía basándose en modelos de
procesos.
• Estos sistemas facilitan los cambios a los procesos.
26
Historia de BPM (7)
BPR es entonces un subconjunto de BPM:
• BPR se enfoca en la planificación y organización.
• BPM incluye conceptos, métodos, técnicas y herramientas que
cubren todos los aspectos de la administración de procesos.
27
[Dumas, 2018]
Historia de BPM (7)
BPR es entonces un subconjunto de BPM:
• BPR se enfoca en la planificación y organización.
• BPM incluye conceptos, métodos, técnicas y herramientas que
cubren todos los aspectos de la administración de procesos.
28
BPR es el subconjunto del ciclo
de vida de BPM que se encarga
de la planificación, organización e
implementación de procesos.
[Dumas, 2018]
El ciclo de vida de BPM
El siguiente esquema muestra las tareas que generalmente
forman parte del ciclo de vida de BPM:
29
[Dumas, 2018]
(1) Identificación de procesos
• Generalmente, la primera pregunta que surge es “¿qué
procesos queremos mejorar?”.
• Es probable que haya algún problema operacional ya
identificado.
• Ejemplo:
– Los ingenieros de campo en BuildIT se quejan de que su
trabajo se dificulta cuando necesitan equipo de construcción.
– Dado que la mayoría del equipo se alquila, el proceso de
alquiler estará bajo la lupa.
• El proceso a analizar debe estar delimitado adecuadamente.
30
(1) Identificación de procesos
• Dependiendo de cuánta experiencia ha tenido la compañía
con BPM, el proceso será más o menos fácil de comenzar.
• El propósito de las iniciativas BPM es de asegurar que los
procesos llevan consistentemente a resultados positivos.
• Medir el valor entregado por un proceso es un paso crucial.
• Las métricas tienen por lo tanto un rol central una vez más:
– Medición de los costos
– Métricas enfocadas en el tiempo
– Factores que hacen a la calidad
31
(2) Descubrimiento de procesos
• La próxima etapa se enfoca en la comprensión de los
detalles del proceso en cuestión.
• Uno de los resultados típicos de esta etapa es uno o más
modelos de procesos “as-is” (tal como están actualmente).
• Estos modelos reflejan la comprensión del proceso por
parte de los actores relevantes.
• Deben ser fáciles de comprender para facilitar la
comunicación entre los participantes de la iniciativa BPM.
• Una posibilidad es una descripción textual, pero éstas son
generalmente poco claras y difíciles de procesar.
32
(2) Descubrimiento de procesos
• Una mejor opción son los diagramas:
– Comprensión a simple vista (estructura y notación estándar)
– Herramientas disponibles para crearlos y luego usarlos
• Los diagramas de flujo son un ejemplo muy conocido:
33
[Dumas, 2018]
(2) Descubrimiento de procesos
• Una mejor opción son los diagramas:
– Comprensión a simple vista (estructura y notación estándar)
– Herramientas disponibles para crearlos y luego usarlos
• Los diagramas de flujo son un ejemplo muy conocido:
34
Actores involucrados en el
proceso de adquisición de
equipos en la compañía.
[Dumas, 2018]
(2) Descubrimiento de procesos
• Una mejor opción son los diagramas:
– Comprensión a simple vista (estructura y notación estándar)
– Herramientas disponibles para crearlos y luego usarlos
• Los diagramas de flujo son un ejemplo muy conocido:
35
Los eventos se representan con
círculos.
[Dumas, 2018]
(2) Descubrimiento de procesos
• Una mejor opción son los diagramas:
– Comprensión a simple vista (estructura y notación estándar)
– Herramientas disponibles para crearlos y luego usarlos
• Los diagramas de flujo son un ejemplo muy conocido:
36
Las actividades se representan
con rectángulos con esquinas
redondeadas.
[Dumas, 2018]
(2) Descubrimiento de procesos
• Una mejor opción son los diagramas:
– Comprensión a simple vista (estructura y notación estándar)
– Herramientas disponibles para crearlos y luego usarlos
• Los diagramas de flujo son un ejemplo muy conocido:
37
Los puntos de decisión se
representan mediante diamantes
con arcos salientes para cada
posible resultado.
[Dumas, 2018]
(3) Análisis de procesos
• Una vez comprendido el proceso as-is, el próximo paso es
el análisis de sus problemas.
• Ejemplos:
– la métrica de “tiempo de ciclo” (turnaround time) es
demasiado alta.
– la métrica de “cantidad de alquileres fallidos” es muy alta.
• Esto puede deberse a muchas factores, que deben ser
identificados para poder mejorar al proceso.
• En general, esta etapa es conducida por el análisis de
métricas de performance con niveles inaceptables.
38
(4) Rediseño de procesos
• Ya reunida la información acerca de los problemas y sus
causas, la próxima etapa es encontrar soluciones.
• Se deben analizar múltiples soluciones, teniendo en cuenta
su impacto en el resto de los procesos:
– Los actores están acostumbrados al proceso actual.
– Los cambios pueden afectar a los sistemas de IT que
soportan al proceso.
– Los cambios pueden afectar a otras compañías que
participan en el proceso.
• Esta etapa produce un proceso “to-be” (próximo a ser).
39
(5) Implementación de procesos
• En la siguiente etapa se pone en funcionamiento el
proceso to-be en reemplazo del as-is.
• Involucra dos etapas:
– Administración del cambio organizacional:
• explicar los cambios a los participantes (cuáles son y por qué)
• poner en funcionamiento un plan de cambios
• entrenamiento de usuarios en el nuevo proceso
– Automatización del proceso: configuración o implementación
de sistemas IT para brindar soporte al nuevo proceso.
• La salida suele ser un modelo del nuevo proceso.
40
(6) Monitoreo y control de procesos
• La salida de la etapa anterior se utiliza para realizar un
escrutinio del nuevo proceso.
• Pueden necesitarse ajustes para resolver problemas que
persisten, o para evitar degradación.
• Dado que el cambio es constante, el ciclo de vida tiene
forma circular, comenzando nuevamente con la etapa de
descubrimiento.
• El ciclo de vida nos ayuda a comprender el rol de la
tecnología en BPM: sinergia entre IT y administración de
negocios.
41
El ciclo de vida de BPM
42
[Dumas, 2018]
43
Modelado de procesos
Usos del modelo
• Como primer paso, antes de construir un modelo es
necesario tener en claro el uso que tendrá.
• Dependiendo de quién lo usará, hay muchos aspectos que
pueden variar:
– El nivel de detalle
– Documentación adicional (anotaciones, descripciones de
soporte).
– Detalles para su implementación en sistemas automatizados.
• Veremos una introducción al lenguaje BPMN: “Business
Process Model and Notation” del Object Management Group.
44
• Ya vimos que un proceso está compuesto principalmente
por eventos, actividades y relaciones entre ellos.
• La relación más elemental es la secuencia: un evento o
actividad A es seguido por otro evento o actividad B:
• Aparte de la notación básica ya vista, los bordes
finos/gruesos de los eventos denotan su condición de
comienzo o fin.
• Los rótulos en los eventos comunican sus condiciones de
disparo.
Componentes básicas
45
[Dumas, 2018]
Componentes básicas
• Los “tokens” denotan el estado actual de un proceso, o una
instancia de proceso:
• Como convención (en idioma inglés):
– Los nombres de actividades comienzan con verbos
imperativos seguidos por un sustantivo (que puede ser
precedido por un adjetivo).
– Los eventos comienzan con sustantivos y terminan con un
verbo en tiempo pasado.
46
[Dumas, 2018]
Branching y merging
• Muchas actividades son excluyentes (no obedecen a la
estructura de secuencia).
• Las actividades pueden ser independientes y se realizan en
forma concurrente.
• Los “gateways” se usan para modelar estas situaciones:
– Estas “puertas” dejan o no pasar tokens.
– Los tokens pueden separarse en ramas diferentes, o ser
unidos.
– Se denotan con diamantes.
• A continuación vemos cómo se modelan algunos ejemplos...
47
• Aquí vemos un ejemplo de un gateway XOR.
• El diamante con una X indica que es exclusivo.
• Los rótulos de los arcos indican las condiciones que deben
cumplirse para que el token tome esa ruta.
Branching y merging
48
[Dumas, 2018]
Branching y merging
• Aquí vemos un ejemplo de un gateway XOR.
• El diamante con una X indica que es exclusivo.
• Los rótulos de los arcos indican las condiciones que deben
cumplirse para que el token tome esa ruta.
49
Esta notación indica el
camino default; éste se
toma si todas las
condiciones son falsas.
[Dumas, 2018]
Ejecución paralela
• El gateway AND paralelo se usa para modelar la situación
de actividades independientes.
• Similar al diamante con X, esta situación se modela con un
diamante con un signo +:
• El correspondiente merge espera un token de cada arco
entrante (XOR espera sólo uno).
50
[Dumas, 2018]
Branching y merging
• Este modelo representa una versión más completa del
proceso de realizar un pedido.
• Note que hay dos posibles eventos de fin.
51
[Dumas, 2018]
Branching y merging
Aquí vemos que también puede haber más de un evento de
comienzo:
52
[Dumas, 2018]
Decisiones inclusivas
• Hay casos en los que más de una rama puede ser tomada
como resultado de una decisión.
• Ejemplo: pedidos a más de un depósito; esto podría
modelarse con las herramientas vistas:
53
[Dumas, 2018]
• Sin embargo, esto lleva a replicar actividades, y no es
escalable.
• Existen gateways de OR inclusivo: más de una rama puede
ser tomada.
• Se generan tantos tokens nuevos como ramas tomadas.
Decisiones inclusivas
54
[Dumas, 2018]
Decisiones inclusivas
• Sin embargo, esto lleva a replicar actividades, y no es
escalable.
• Existen gateways de OR inclusivo: más de una rama puede
ser tomada.
• Se generan tantos tokens nuevos como ramas tomadas.
55
La semántica del nodo de
sincronización es más
compleja: debe esperar
recibir tokens de todas las
ramas activas.
[Dumas, 2018]
Branching y merging
Volvamos al ejemplo de los pedidos, pero suponiendo que se
pueden fabricar los productos faltantes:
56
[Dumas, 2018]
Repetición
• Otra componente básica de los procesos es la repetición.
• Se debe identificar el bloque que se repite con un punto de
comienzo y de terminación; este último debe ser una
decisión (seguir o volver a comenzar).
• El merge XOR al comienzo se debe a que para seguir le
alcanza con recibir un token (o bien del inicio o de la rama
de repetición).
57
[Dumas, 2018]
Artefactos de información
• Hasta ahora nos hemos enfocado en la perspectiva
funcional y de flujo de control.
• Otra perspectiva de suma importancia es la de datos, que
modela los artefactos de información necesarios para llevar
a cabo un proceso.
• Volviendo al ejemplo de los pedidos, vemos que hay
objetos como las órdenes de compra:
– se llaman objetos de datos, y pueden ser físicos o virtuales
– en BPMN se denotan con un rectángulo con la esquina
doblada, y se unen a otras partes del modelo con líneas
punteadas terminadas en flechas con punta abierta.
58
Artefactos de información
59
Artefactos de información
60
Estos vínculos se denominan
“asociaciones de datos” en BPMN.
En este caso, Purchase order es
una entrada para la actividad
Check stock availability
Artefactos de información
61
Para evitar complicaciones en el
diagrama, se pueden repetir los
artefactos de información; sin
embargo, estos símbolos se
refieren al mismo objeto.
Artefactos de información
62
Otra simplificación gráfica se usa
cuando un artefacto es la salida de
una actividad y la entrada de otra.
El estado de un artefacto se puede
denotar entre corchetes. En este
caso, la actividad Confirm order
tiene como salida una orden
confirmada.
Los almacenamientos persistentes
(que perduran más allá de la
instancia del proceso) se denotan
con el símbolo habitual para bases
de datos.
Se pueden incluir anotaciones
adicionales para aclarar lo que
sea necesario. Éstas no tienen
semántica formal y por lo tanto
no afectan el flujo de tokens.
Perspectiva de recursos
• Otro aspecto que debe modelarse es la de recursos,
también llamada “perspectiva organizacional”.
• Ésta modela los participantes del proceso, que pueden ser:
– Personas
– Sistemas de software (servers, aplicaciones, etc.)
– Equipamiento (impresoras, maquinaria, etc.)
• Se distingue entre recursos activos y pasivos.
• Pueden modelarse clases enteras de recursos (como
equipos de personas, o roles).
63
Perspectiva de recursos
• BPMN posee dos constructores para modelar recursos:
– “Pools” (conjuntos): modelan clases de recursos.
– “Lanes” (carriles): dividen a los pool en sub-clases, o
recursos individuales. Pueden aplicarse recursivamente.
• Ambos son representados por rectángulos; en ellos se
pueden ubicar todos los objetos vistos hasta ahora.
• La ubicación puede ser horizontal o vertical.
• Se pueden crear matrices con lanes dentro de pools, pero
cada tarea puede ser realizada por un único recurso.
• Un diagrama con más de un pool se llama diagrama de
colaboración.
64
Recursos
65
Recursos
66
Anidamiento de lanes.
La ubicación de las actividades y eventos
en las lanes adecuadas es importante;
aquí, la verificación del stock lo hace el
sistema ERP en forma automática.
La ubicación de los objetos de
datos no es importante.
La ubicación de los gateways de división
XOR debe ser consistente con la
ubicación de la actividad precedente.
Para divisiones AND no es relevante.
Recursos
67
Recursos
68
Los pools con detalles se llaman
de caja blanca; los que no tienen
detalles se llaman de caja negra.
Los mensajes representan flujo
de información entre pools. El
rótulo indica el contenido del
mensaje.
El tipo de pool (caja blanca o
negra) afecta cómo se
representan los mensajes.
Las actividades que emiten
mensajes se llaman “de emisión”,
y las que reciben, “de recepción”.
Modelado avanzado
• Los constructores vistos hasta el momento permiten el
modelado de procesos básicos.
• Existen constructores avanzados que son necesarios
cuando los procesos son complejos:
– Descomposición de procesos: cuando un proceso es
demasiado complejo para ser comprendido, se puede
descomponer en procesos más simples.
– Reuso de procesos: un sub-proceso puede ser declarado
“global” y ser invocado por otros procesos.
69
Modelado avanzado
• Repetición con sub-procesos: algunos subprocesos
pueden ser marcados como ciclos (“loops”), con
especificación de detalles internos o en forma abstracta.
• Repetición paralela: para modelar que múltiples instancias
de un proceso se deben ejecutar a la vez.
• Repetición no controlada: se repiten actividades, sin orden
específico, hasta que se dé una condición.
• Eventos de mensaje: pueden marcar el comienzo o fin de
instancias de procesos, o ser simplemente eventos
intermedios.
70
Modelado avanzado
• Eventos temporales:
– Suceden como respuesta a una acción relacionada con el
tiempo; por ejemplo, “todos los lunes a las 8:00”, o “una
semana después de que suceda el evento X”.
– pueden ser intermedios o de comienzo/fin.
• Eventos en carrera: modelan situaciones en que el evento
que suceda primero determina el curso del proceso.
• Excepciones: similar a las de los lenguajes de programación,
determinan el curso del proceso en condiciones fuera de lo
normal; incluyen posibilidad de “rollback”.
71
Modelado avanzado
• Aborto de procesos: evento especial que termina la
instancia del proceso y cualquier sub-proceso.
• Reglas de negocio:
– Ejemplo: los clientes VIP reciben 20% de descuento en
compras que superan $5.000.
– Aparte de su modelado con constructores ya vistos, hay
eventos especiales llamados “condicionales”.
– Cuando la regla se cumple, el evento se dispara.
– Se diferencia de las condiciones básicas en que se verifican
continuamente hasta que se cumplan.
72
Modelado avanzado
• Coreografías de procesos:
– Cuando una colaboración entre dos o más partes es
compleja, o por razones de privacidad, puede no ser posible
modelar todo en un único diagrama de colaboración.
– Los diagramas de coreografía modelan la interacción entre
los procesos que forman parte de la colaboración.
– Actúan como contratos de alto nivel para todas las partes.
73
Conclusiones
• La idea central del BPM es que los procesos se definan
explícitamente, se ejecuten y que se guarde y analice la
información acerca de su ejecución.
• El ciclo de vida es de realimentación para el mejoramiento
continuo de los procesos.
• Las bitácoras de ejecución son vitales para el monitoreo y
control efectivo de los procesos de negocio.
• Las técnicas y herramientas de BPM se pueden aplicar para
lograr transparencia, performance y asegurar que lo que se
ejecuta está de acuerdo con la especificación.
74
Referencias
[Dumas, 2018] M. Dumas, M. La Rosa, J. Mendling, & H.A.
Reijers: “Fundamentals of Business Process Management”,
2nd Edition. Springer-Verlag, 2018.
75
Recommended