Fallas, Excepciones y Compensacion II

Actualmente existen tres tipos de mecanismos para gestionar errores en un proceso de negocio: Transacciones, Excepciones, y Compensaciones. Estos tres mecanismos, trabajan juntos para evitar que los procesos fallen.

Este esquema se basa en el principio transaccional basado en el modelo “todo o nada”, ofreciendo flujos o rutas (paths) alternativos cuando se producen excepciones, las cuales pueden desencadenar acciones compensatorias para deshacer las operaciones fallidas.

Transacciones: Una transacción, es una secuencia de operaciones agrupadas en una unidad indivisible, en la cual se ejecutan todas las tareas o ninguna. Si una tarea, se encuentra dentro de una transacción y esta no puede ser ejecutada, todas las tareas anteriores que ya han sido ejecutadas deben ser devueltas a su estado original. En un diagrama del proceso (notación BPMN), se utiliza el sub-proceso para agrupar las actividades dentro de una transacción.

Manejo de Excepciones: Una excepciones de negocio reorienta el flujo o ruta del proceso cuando se detecta una excepción. Por ejemplo, una tarea que debe realizar una operación de debito, pero la cuenta carece de fondos suficientes. Como resultado de ello, una excepción puede ser lanzada, y el flujo del proceso es afectado. En un diagrama del proceso, el manejo de excepciones se realiza adjuntado una excepción a un sub-proceso, conectándola con una actividad que la manejara, para luego retornar a su ruta normal, sino finaliza el proceso antes esta condición.

Compensaciones: Las compensaciones establecen reglas para deshacer tareas si una tarea falla. Por ejemplo, una tarea recibe una transacción y es completada. Posteriormente, sin embargo, una tarea relacionada no se ejecuta. La tarea de compensación asociada a la primera actividad se ejecuta, restituyendo la transacción. La compensación no se ejecuta si la tarea no tiene asignada una excepción.

Este es un ejemplo donde podemos ver la secuencia o ruta del proceso ante diversos escenarios:

Descripción de Secuencia

Sin Excepcion

1. La Tarea A se ejecuta y completa.
2. La Tarea B Falla, debido a una excepcion de negocio.
3. El proceso de negocio falla porque no hay un manejo de excepciones configurado para el subproceso AB.
   

Con Excepcion

1. La Tarea A se ejecuta y completa.
2. La Tarea B se ejecuta y completa.
3. La Tarea C se ejecuta y completa.
4. La Tarea D Falla, debido a una excepcion de negocio.
5. Se ejecuta la Excepcion 1, y luego el proceso de negocio, sigue su ruta (no falla el proceso, porque se considero una excepcion).
   

Con Compensacion

1. La Tarea A se ejecuta y completa.
2. La Tarea B se ejecuta y completa.
3. La Tarea C se ejecuta y completa.
4. La Tarea D se ejecuta y completa.
5. La Tarea E se ejecuta y completa.
6. La Tarea F se ejecuta y completa.
7. La Tarea G Falla, debido a una excepcion de negocio.
8. Se ejecuta la actividad de Compensacion 1.
9. A pesar que la tarea de compensacion 1 se ejecuta, el proceso de negocio falla. Para evitar este comportamiento, podemos incluir todas estas actividades dentro de un subproceso.
   

Saludos;

Fallas, Excepciones y Compensacion I

Uno de los elementos más importantes, dentro de la notación BPMN es el manejo de excepciones de negocio, fallas, y operaciones de compensación. Actualmente existen diversos tipos de excepciones que pueden ser modeladas con la notación BPMN.

Existen tres tipos de excepciones:

Fallas Técnicas: Estos son eventos que se generan fuera del contexto de ejecución de un proceso de negocio; el cual puede causar que el proceso no este disponible. Ejemplo de este tipo de fallas: mal funcionamiento del disco, errores de CPU, etc. Por su naturaleza, este tipo de fallas técnicas generan la interrupción del proceso de negocio.

Excepciones Temporales: Estos son eventos temporales que pueden ser resueltos con el tiempo. Por Ejemplo: la red no esta disponible, servicio web no disponible, o base de datos no disponible. En estos casos, el proceso será suspendido después de una serie de intentos fallidos y, a continuación, el proceso puede reanudarse manualmente una vez que el problema ha sido resuelto. En este tipo de eventos, el proceso puede realizar el rollback de cualquier actividad, o intentar una acción para un número especifico de veces. Si los reintentos no tienen éxito, el proceso puede ser suspendido (pero no finaliza).

Excepciones de Negocio: Este tipo de excepciones suelen estar relacionados con datos, por ejemplo: código ciudad no valido, número de cuenta no valido, fondos insuficientes para esta transacción, etc.

En el próximo post, hablaremos de las herramientas que tenemos en la notación para representar este tipo de excepciones.

Intalio Eventos Multiples

Como hemos descrito en notas anteriores, un evento es algo que afecta el flujo de ejecución de un proceso de negocio. Según la notación BPMN tenemos tres tipos de eventos inicio, intermedios, y fin. En este ejemplo podemos ver diversos tipos de eventos.

Primero, podemos ver la utilización de un evento denominado “múltiple intermediate event”, que opera como un gateway exclusivo basado en eventos. En este tipo de gateway, solo un evento podrá ejecutarse. En nuestro diagrama utilizamos un evento intermedio o timer. Cuando el mensaje es recibido antes de una fecha determinada, el proceso continua su ejecución normal (Tarea G), de lo contrario se ejecuta la tarea F y se lanza un error.

Por ultimo, podemos ver un ejemplo de la utilización de un “messages end event”, para enviar un mensaje al participante que ejecuta la tarea C.

Manejo de Eventos Intermedios Timer en Intalio

En el post anterior, un amigo realizo algunas preguntas relacionadas con el control de tiempos. La notación BPMN, introduce un símbolo para el manejo de eventos timers, también conocidos como temporizadores. En la notación, se les conoce como “Timer Intermediate Event”.

Los timer intermediate Event, o eventos intermedios de tiempo, se utilizan para controlar el tiempo de una actividad ejecutada por un participante humano o por un servicio (Web Services). Con frecuencia se utilizan, para tareas de escalamiento, notificaciones y cancelación de procesos.

Un ejemplo de este tipo de operaciones: si una actividad no se ejecuta en un periodo de tiempo, podemos romper el flujo o ruta de proceso normal, para cancelar una orden de servicio, o notificar a un cliente. Se pueden utilizar expresiones timers como : PT20S que establece 20 seg, PT50S establece 50 seg y PT2M establece 2 min.

En el ejemplo, tenemos un subproceso que ejecutar dos actividades, adiciono un timers para controlar el tiempo y así permitir que se dispare un evento: “si el tiempo de ejecución del subproceso sobrepasa un valor, ejecuto la actividad Timeout”.

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.
   

Capitulo II El Diagnostico

El Diagnostico

Una estrategia para crear la necesidad, es impulsar actividades del diagnostico de la documentacion existente de los procesos, actividades, etc.

Sobre la Calidad del Diagnostico

No importa que los datos no sean levantados y recopilados de forma exhaustiva durante las sesiones iniciales, el objetivo es hacer un diagnostico preliminar de la documentación o existencia de procesos, para potenciar la necesidad de implantar soluciones que estandaricen y automaticen toda la definición de los procesos en la organización. Recuerde que el objetivo inicial es identificar la presencia de toda la documentación relacionada con los procesos de cada unidad organizacional, sin hacer análisis de la calidad de los documentos.

Recomendaciones para Diagnostico

La clave para comenzar con un buen diagnostico, es detectar la existencia y utilización de herramientas que son utilizadas regularmente en la organización para documentar los procesos, por ejemplo, word, visio, etc; este análisis potenciara la necesidad de uniformizar o estandarizar las herramientas para documentar los procesos, la necesidad de tener un repositorio único, basado en una norma de modelado como BPMN, que permita simular y proporcionar algunos elementos dinámicos a esa documentación. Este trabajo abrirá un abanico muy amplio de las mejoras que pueden sustentar un cambio organizacional.

Nota: Recuerde, que el objetivo preliminar del diagnostico no es analizar los macro procesos, ni realizar un análisis cualitativo de los mismo.

Areas claves:

1. Numero de procesos existente por cada unidad organizativa.
2. Proporción de macro procesos existentes en las unidades.
3. Evaluar el número de procesos documentados.
4. Evaluar la existencia de indicadores de gestión para procesos.
5. Procesos con Indicadores vs. Procesos sin Indicadores.
6. Proporción de herramientas utilizadas para diagramas (PowerPoint, Visio, docs, pdf, etc.).
   

Los Resultados del Diagnostico

El diagnostico se convertirá en una herramienta para establecer conclusiones sobre la situación actual de los procesos de la organización, por ejemplo el numero de procesos documentados, la existencia de herramientas para su documentación. Este diagnostico, será el insumo preliminar para detectar procesos repetidos y serán una referencias que luego utilizaremos para asociar los procesos con un modelo referencial, hablaremos mas adelante sobre este marco referencial.

Detectar Áreas de Apoyo

En muchas organizaciones, podrían existir iniciativas orientadas en la mejora continua de procesos, por ende; es importante detectar todas estas iniciativas existentes y utilizarlas como mecanismo de participación para acelerar y potenciar todas las iniciativas. Recuerde: Unificar iniciativas, evitar redundancia, lo mejor no es imponer, sino acordar y avanzar.

La importancia de un Marco de Referencia

Una recomendación importante es utilizar un marco referencial de procesos que pueda ser extendida y adoptada, y responda a todas las necesidades presentes y futuras de la organización, articulando diversos enfoques.

Algunas organizaciones cuentan con marcos de referencia, en el cual se describen las áreas generales o macro procesos, el Comité extendido de procesos, debe acordar un marco de referencia, en el cual puedan ser mapeados todos los procesos actuales de la organización.

El marco de referencia responde a preguntas como cual es el modelo que queremos? se equilibra con la realidad existente en la corporación?, estamos todos referenciados ahí?

Los marcos de referencia contribuyen con la formalización de los procesos de la organización, y es el punto de partida para soluciones como cuadro de mandos par medir las áreas claves de procesos y los acuerdos de servicios.

El Marco Referencial y el ajuste.

Los marcos de referencia, deben especificar todos los macro procesos actuales de la organización y futuros, e incluir características y necesidades particulares, para ajustarla. Esto es responsabilidad del Comité Extendido de Procesos.

Se pueden presentar escenarios, donde algunas unidades organizaciones ya cuenten con un marco referencial propio, el cual puede ser extendido o actualizados según las necesidades de toda la organización, la clave: todos deben verse reflejados.

Un ejemplo particular es NGOSS, que es un marco referencia para empresas de telecomunicaciones, el cual puede ser extendido o modificado acorde con las características y necesidades de la organización.