Las Partes Fundamentales de un Motor de Flujo – II Parte

Tras publicar unos meses atrás la primera parte del artí­culo, comenzamos con la segunda.
Reenví­os
Las tareas pueden ser asignadas en un momento dado a un usuario en concreto, y, a posteriori, por necesidades del negocio asignarse a usuarios diferentes del inicial. Normalmente a funcionalidades de este tipo no suelen tener acceso los usuarios con nivel básico, sino que se encuentran delegadas a usuarios con nivel de administración o a gestores de grupos de usuarios (gestores normalmente asociados al negocio de la aplicación).
Normalmente cuando una tarea es reenviada a otro usuario, el BPM no se limita a cambiar la asignación de propiedad a la tarea (a quien le está asignada un momento dado), sino que se realiza una copia de la tarea inicial y posteriormente crea una nueva tarea la cual pasara a la propiedad del usuario al que se ha reasignado. Finalmente, la tarea inicial pasa a un estado especial (“Reenviado” por ejemplo) y si cuenta con algíºn tipo de campo de observaciones, se indica de forma automática cuál es el identificador de la tarea asociada al reenvió y que se acaba de generar.
El sentido de todo esto es contar con la trazabilidad completa de lo que ha ocurrido. Si el BPM se limitara a cambiar el usuario propietario, nunca sabrí­amos cuales han sido los sucesivos cambios que ha sufrido una tarea.
Delegaciones
Las delegaciones son una serie de reglas que automatizan los reenví­os de tareas a partir de un conjunto de requerimientos establecidos.
Por ejemplo, si tenemos una actividad en nuestro flujo que la realiza un usuario en concreto, podrí­a darse el caso de que de forma temporal queramos que en lugar de realizarla dicho usuario lo hago otro (por ejemplo porque el usuario inicial estarí­a de vacaciones en ese periodo de tiempo y queremos que las tareas que se le asignen no queden esperando a que vuelva).
En el caso de que se cumpliera la condición, automáticamente la tarea se reenviarí­a al usuario de destino, sin necesidad de que la operación deba hacerse de forma manual.
BAM
El BAM (Business Activity Monitoring) es el panel de control a partir del cual un usuario administrador es capaz de obtener información de explotación a partir de los resultados generados a partir de la instanciacion de las plantillas y actividades existentes en el motor, a modo de report. Los indicadores tí­picos muestra el níºmero de instancias por plantillas, los cuellos de botella en diversas actividades, o la eficiencia (relativa) de los usuarios a la hora de completar las tareas. Lo de relativo viene al hilo de que para poder conocer la eficiencia real de un usuario no nos va a bastar la información contenida en el motor, ya que para un resultado real vamos a necesitar conocer (por ejemplo) cuántos dí­as ha trabajado ese año, y mucho me temo que dicha información va a partir de otro modelo de datos referenciado a nuestro propio negocio y no al del motor.
De ahí­ que bajo mi punto de vista, en la mayorí­a de ocasiones el BAM que ofrecen los BPM es insuficiente, ya que nos dan una visión muy superficial de la realidad, y responden a preguntas demasiado concretas. Cuando normalmente para responder a las preguntas del conocedores del negocio vamos a tener que mezclar la propia información de negocio con el resultado contenido en el modelo de datos del motor, y esto, no suele ser precisamente sencillo.
Hasta aquí­ la segunda parte, en la tercera, intentaremos abordar de forma directa el concepto de Bandeja de Tareas, que no es algo que conceptualmente ofrezca el BPM, pero que es muy comíºn su uso a partir de la información que el propio BPM alberga. Hablaremos entre otras cosas de funcionalidades asociadas a la bandeja, así­ como de algunos problemas o decisiones de arquitectura tí­picos a la hora de querer mostrar en la bandeja de tareas información que no es propia del BPM y que forma parte de nuestro negocio.
Saludos.
Miguel.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.