Manejo de Eventos en Intalio BPM

Uno de los elementos gráficos de la notación BPMN son los eventos. En este ejemplo, podemos ver el comportamiento del motor BPEL, para el manejo de eventos intermedios y timers, elementos fundamentales en la comprensión de BPMN para el modelado de procesos de negocio.

Primero un poco de teoría. Un evento es algo que pasa durante la ejecución de un proceso. Estos eventos afectan el flujo del proceso, y usualmente tienen una causa (disparador o trigger), o un impacto (resultado - result). Los eventos son representados con círculos, sobre diversas marcas que representan diferentes disparadores y resultados. Existen tres tipos de eventos basado en como afectan el flujo del proceso: inicio, intermedio, finalización (start, intermediate, end).

Por ejemplo tenemos un evento timer, donde podemos establecer un período de tiempo (fecha), o un ciclo (por ejemplo, todos los miércoles a las 6am), con el cual podemos condicionar el inicio o disparo de un evento.

Otro tipo de eventos son los intermedios, los cuales son utilizados para condicionar la entrada de un mensaje dentro del flujo. Un evento intermedio, según definición, ocurre entre un evento de inicio (Start Event) y uno de fin (End Event), y afecta el flujo de el proceso, pero no inicia o finaliza el proceso directamente.

Por lo general, los eventos timers, son utilizados en tareas, y generalmente pueden representar una condición de timeout para un Web services, que puede disparar un evento para enviar la solicitud a una cola de mensajeria de excepciones.

En este ejemplo, estamos utilizando un timer, que permite observar el comportamiento de un evento intermedio; en resumen, el proceso de negocio no ejecutara la tarea B, hasta que pasen 2 min. (timer), y se ejecute la tarea C.

Proceso y actividades en BPM, una vision pragmatica

Hace unos días, me invitaron a una reunión, en la cual un proveedor muy importante en el área de BPM, realizaba demostraciones sobre un producto para el modelado de procesos de negocio. Quiero compartir con la comunidad algunas apreciaciones y diferencias de opiniones, que considero muy importantes.

La mayoría de las presentaciones sobre BPM disponibles en la red, y los mensajes de proveedores importantes en esta área, se centran en: “el primer paso es el modelado de los procesos”. En primer lugar considero vital, que en los primeros pasos no hablemos de procesos, hablemos de actividades que son ejecutadas por personas.

En la mayoría de las organizaciones, desde un punto de vista pragmático, no existe en el vocabulario de los trabajadores la palabra proceso; la cual inicialmente es percibida como algo complejo; la realidad; las organizaciones están formadas por personas que ejecutan actividades; y en la mayoría de los casos, no se conoce el objetivo estratégico que esta relacionado a su trabajo. La clave es como llevar el trabajo del día a día (actividades) a un proceso, promocionándole una esencia organizacional más formal.

El objetivo de un consultor BPM, es identificar las actividades, responsables, relaciones con otras actividades, participantes, identificar que variables pueden ser medidas, y si están enmarcadas dentro de un objetivo estratégico de la organización, y como estas pueden ser mapeadas en un marco de procesos referencial. Este trabajo, define, forma, y establece el concepto de un proceso, pero no es de el; donde se inicia el trabajo. Este modelo es una aproximación más humana, y pragmática para introducir el concepto de proceso en la organización.

Otro aspecto, es que asumimos que el diseño de los procesos esta basado en un lenguaje natural, por ende; para la organización es muy fácil modelar sus procesos. Esta premisa no es cierta; en realidad no es un lenguaje natural, ya que requiere de un análisis, practicas de modelado, reglas; inclusive si se cuenta con un marco referencial.

Por ultimo, algunos proveedores aseveran que el modelamiento de los procesos de negocio los llevara al camino de SOA; en realidad este camino se inicia con el entendimiento de este estilo de arquitectura en las gerencias responsables de las infraestructuras de hardware y software que sustentas las operaciones de negocio de la organización.

Algunas Recomendaciones

1. No introducir el término de proceso, en la organización en las primeras fases, si el de actividades.
2. Cuando el rompecabezas este armado, identificamos un proceso (actividades, participantes, reglas, etc.), y le damos un firma mas formal.
3. Es imprescindible establecer una buena estrategia para capacitar a las personas en el modelamiento de procesos; recuerde que en realidad no es un lenguaje natural, y requiere del conocimiento de prácticas y reglas.