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