Las Partes Fundamentales de un Motor de Flujo – I Parte

La verdad es que en el blog llevamos ya acumulados unos cuantos artí­culos que tienen que ver con motores de flujo, pero repasando hoy un poco los temas que se han ido tocando, me he dado cuenta que no hay ningíºn artí­culo que ofrezca un resumen introductorio para las personas que permanezcan ajenas a este mundo y quieran empezar a “tocar pie” y sentirse seguros tratando con estos temas. De ahí­ que el objetivo de este artí­culo es el de aterrizar ciertos conceptos comunes que manejan los motores de flujo que podemos encontrar hoy en dí­a en el mercado.
Para empezar a tratar este tema, creo que primeramente nos debe quedar claro la capacidad y potencia de que sean los propios conocedores de un negocio los que sean capaces de diseñas sus flujos de trabajo. De este tema si que ya hemos hablado anteriormente en un artí­culo anterior. Emplearemos el gráfico de flujo incluido en dicho artí­culo como ejemplo para alguna de las definiciones de las que se van a ir hablando.
Una vez conocido lo que es un flujo de trabajo y cual es su función principal (la capacidad de los propios conocedores del negocio de definir cómo funciona su propio negocio), vamos a desglosar otras de las piezas que forman parte del puzle.
Actividades
Una actividad es cada uno de los pasos que hemos definido en el flujo y que corresponden a acciones determinadas a realizar dentro de nuestro negocio. Por ejemplo, en el artí­culo “Definiendo el Negocio a Base de Flujos”, disponí­amos de actividades como “Disminuir Stock”, “Hacer Pedido”, “Introducir Datos Personales Comprador”, etc.
Estas actividades pueden llevarse a cabo de forma manual (por personas) o automáticas (procesos automáticos), y pueden conllevar el que al realizarse sea necesario incorporar cierta información que quede registrada en algíºn lugar, o simplemente sea necesario marcar que han sido realizadas, a modo de punto de control (por ejemplo, entregar una documentación, marcar que una caja ha sido embalada, etc). Siguiendo el ejemplo de flujo inicial del que disponemos, una actividad manual que incluye la introducción de datos de negocio serí­a la de “Introducir Datos Personales Comprador”, mientras que una automática serí­a la de “Imprimir Factura”, ya que una vez realizada la actividad “Realizar Cobra Manual”, la factura se imprime de forma automática a través de la caja registradora pertinente.
Una actividad también puede contar con una caracterí­stica temporal, ya que podrí­a darse el que tenga que ser cumplida en un plazo de tiempo máximo determinado. Por ejemplo, algíºn tipo de notificación podrí­a requerir respuesta en un plazo de menos de un mes. Si este plazo se superara tal vez necesitáramos realizar alguna otra actividad relacionada con el reenví­o, o cancelar la notificación (como véis, de aquí­ se extrae que los condicionantes temporales pueden afectar al flujo de trabajo, y que estos son piezas que el conocedor del negocio puede utilizar para modelar también el comportamiento del flujo a partir de las excepciones temporales que pueden darse). En una tí­pica aplicación de videoclub, ante una hipotética actividad de “Devolver Pelí­cula”, serí­a totalmente adecuado establecer un lí­mite temporal en nuestra definición de flujo. En caso de que dicho lí­mite temporal se supere, dispondrí­amos de una alarma al respecto, y podrí­amos actuar en consecuencia.
Para acabar con las caracterí­stica de las actividades, lo haremos con una de las más importantes, la “Responsabilidad”, es decir, ¿quién o quiénes van a llevar o pueden llevar a cabo potencialmente una actividad? ¿Todos los trabajadores de nuestro videoclup pueden marcar como devuelta una determinada pelí­cula, o íºnicamente lo podrán realizar las personas que están cara al píºblico? Lo mismo ocurre con nuestro ejemplo de aplicación de compra, ¿todos los trabajadores van a poder realizar un nuevo pedido a un proveedor? Lo más natural es que a la hora de poder modelar una actividad se defina qué persona en concreto va a realizarla, o qué grupo de personas va a poder hacerlo (por ejemplo: contables, administrativos, técnicos, jefes de obra, etc). En conclusión, a la hora de definir un flujo de trabajo podremos definir para las actividades que forman parte del mismo, qué persona o personas la van a realizar. Una vez se inicie el flujo (instancie) y se empiecen a instanciar algunas de las actividades (tareas), se comprobará a qué persona o grupo de personas pertenece, y esta persona o grupo serán notificadas de que algo se espera de ellos.
Finalmente, exponer el caso de que tal vez no se pueda definir inicialmente cuál o cuáles van a ser los responsables de ciertas actividades, ya que dicha casuí­stica dependerá de información proporcionada una vez el flujo haya comenzado. Por ejemplo, en un flujo de una empresa que se encargue de vender pizzas a domicilio, tendrí­a una actividad que serí­a algo así­ como “Llevar Pizzas a Casa del Cliente”, y otra anterior llamada “Seleccionar Persona que Realizará el Reparto” (ya que el reparto dependerá de la disponibilidad de los repartidores en un momento dado). En esta segunda actividad se contarí­a con el listado de todos los repartidores disponibles, la actividad finalizarí­a al marcar el repartidor. Una vez el repartidor se haya marcado, al ejecutarse la actividad “Llevar Pizzas a Casa del Cliente” se asignarí­a de forma automática al repartirdor seleccionado. Estamos hablando ahora de una asignación dinámica de la responsabilidad, y no de una pre-asignación en el tiempo de definición del flujo.
Resumiendo este punto, hemos hablado de las siguientes caracterí­sticas de una actividad: manual, automática, punto de control, temporalidad, responsabilidad (estática y dinámica).
Subrutinas
Una subrutina no es más que un flujo de trabajo pero que está orientado a la reutilización en otros flujos. Por ejemplo, la actividad “Realizar Pedido Proveedor”, seguramente podrí­a tener en su “interior” un conjunto de actividades a realizar (en el ejemplo se simplificó por mayor claridad). Serí­a bastante normal que en otros flujos de trabajo que realizáramos, fuera necesario también en un momento dado (segíºn lo dictamine el flujo), realizar un pedido a un proveedor, entonces en lugar de indicarlo como una actividad estándar, lo estarí­amos indicando como una actividad de subrutina. Al terminarse de ejecutar las actividades de la subrutina, el control volverí­a a la siguiente actividad del flujo principal. Otros ejemplos de subrutinas tí­picas son las de notificación. Podemos tener determinados cuáles son los pasos a realizar en el caso de que queramos realizar una notificación, o una entrega de material. En nuestros flujos de trabajo podrí­amos enlazar directamente como actividad de subrutina dicha acción, en el caso de que fuera necesario realizar una notificación. Para los programadores o personas con conocimientos de programación, estarí­amos hablando de la misma acción que realizan los subprocedimientos en la programación estructurada, agrupaciones de código reutilizable desde llamadas de otros procedimientos principales.
Procesos (instancias de flujos)
Una vez definido nuestro flujo de trabajo, llega la hora de ponerlo en funcionamiento. En el caso de que estuvieramos hablando de nuestra aplicación de compra, si la instaláramos en unos grandes almacenes donde existen multitud de puntos de venta en cada una de las plantas, se estarí­an lanzando procesos de venta de forma continua y simultánea a lo largo de toda la jornada.
A cada una de las instancias realizadas de un diagrama de flujo, se les llama proceso. Un flujo (o plantilla) es a lo que una clase serí­a si estuviéramos hablando en términos de programación en objetos. Es un modelo. Un proceso (o instancia de flujo o plantilla) es a lo que un objeto serí­a si estuviéramos hablando en términos de programación en objetos. Tenemos entonces ahora un sí­mil estupendo, que nos ayuda a comprender mejor esta casuí­stica. De nuestra plantilla podemos hacer cientos de instancias en forma de procesos, de manera que a nuestras clases, podecemos hacer cientos de instancias, en forma de objetos.
Una de las caracterí­sticas principales de un motor de flujo es que es capaz de almacenar todos los estados de transición de un proceso. Es decir, cada vez que se crea una instancia, se almacena la fecha, el usuario que la ha creado, y toda la información que se requiera guardar y que esté relacionada con el flujo. ¿Qué sentido tiene esto? Pues que nuestro flujo no tendrí­a por qué ser completado en un tiempo corto de varios minutos, si no que podrí­a durar dí­as, meses, semanas, incluso años (imaginad por ejemplo un flujo que represente los pasos a realizar en un expediente administrativo).
Gracias a disponer de esta información de forma almacenada podremos saber qué usuarios han lanzado las peticiones de compra y en qué fechas, además de saber si dichas compras han sido ya finalizadas o están en proceso de.
Tareas (instancias de actividades)
Así­ como hemos hecho ya la relación flujo-proceso, ahora nos queda hablar de la relación actividad-tarea. Cada vez que instanciamos un flujo creamos un nuevo proceso íºnico. Cada vez que se alcanza una de las actividades de dicho proceso, creamos, una o varí­as instancias de la misma, a dichas instancias se les llama tareas. Realmente la tarea es lo que hay que llevar a cabo o se ha llevado a cabo en la vida del proceso. Una vez finalizadas las diferentes tareas, las actividades se dan por finalizadas, el motor de flujo calcula el camino a seguir, y se siguen creando nuevas instancias de actividades, que como acabamos de averiguar, se les denomina tareas.
Como habí­amos visto ya cuando hemos hablado de las actividades, estas tienen un responsable. Cuando la actividad se instancia, convirtiéndose en tarea (o tareas), éstas también pasan a tener un responsable (que como hemos visto también se puede asignar de forma manual o automática). La información de las tareas vivas en el flujo se almacena también de forma permanente en el flujo. Una consulta tí­pica y básica es preguntarle al motor de flujo que retorne todas las tareas de un usuario que están en estado “pendiente”. Con esto sabrí­amos todas las tareas que tiene el usuario pendientes de realizar. Su trabajo.
¿Qué más estados puede tener una tarea? Pues depende un moto del motor de flujo que estemos utilizando, pero de forma genérica podrí­amos diferenciar los siguientes:

1. Pendiente: La tarea está creada, no está finalizada y está pendiente que se le asigne un usuario en concreto. Normalmente pertenecerá a un grupo de usuarios, y está pendiente de que alguno de ellos se la asigne o le sea asignada.
2. Asignada: La tarea está pendiente de cerrarse y permanece asignada a un usuario en concreto.
3. Finalizada: La tarea ha sido cerrada por un usuario en concreto, el trabajo relacionado ya ha sido finalizado.
4. En Ejecución: La tarea está asignada a un usuario, está pendiente de finalizarse, y en estos mismos momentos está siendo ejecutada por el usuario responsable.
5. Cancelada: La tarea se ha cancelado.
6. Enviada: La tarea se ha finalizado al haberse enviado a otro usuario, generándose una nueva tarea relacionada a la inicial.

Aqui damos fin a la primera parte del artí­culo, en la segunda, trataremos otros temas relacionados como son: Bandeja de Tareas, Delegaciones, BAM y otras piezas.
Saludos a todos y feliz año!