MÓDELO WORKFLOW Y SGBD

Origen del BPM: Workflow 

A principios de los años 90 muchas empresas empiezan a dar cierta importancia a los procesos de negocio. Como consecuencia surgen herramientas de flujo de trabajo o workflow, cuyo objetivo era la automatización de los procesos de negocio, involucrando tanto actividades manuales como automáticas. La coalición WfMC (Workflow Management Coalition) define Workflow como: la automatización, total o parcial, de los procesos de negocio, que involucra el transporte de documentos, información o tareas de un participante a otro, de acuerdo a un conjunto de reglas establecidas para conseguir el objetivo global del negocio. En esta definición se utiliza el concepto de proceso de negocio considerándolo como el "Conjunto de actividades ejecutadas por usuarios humanos o por aplicaciones software que constituyen los pasos a ser completados para conseguir un objetivo de negocio concreto" (Leading Edge Forum Report 2003). Los sistemas de workflow son el primer ejemplo de un cambio claro en la orientación de la construcción de sistemas informáticos, pasando de los datos a los procesos. El objetivo inicial del workflow era conseguir una oficina sin papeles, automatizando los procesos administrativos habitualmente basados en documentos en papel. Sin embargo, pronto se extendió a todo tipo de procesos desarrollados dentro de las organizaciones. Ello provocó la necesidad de rediseñar los procesos de negocio para optimizar el funcionamiento de la organización. Uno de los problemas que surge ya por entonces, y que continúa sin resolverse, es la definición de estándares para el desarrollo de estas herramientas, lo que convierte a la interoperabilidad entre sistemas de workflow como uno de los objetivos más difícil de conseguir. Por ello surgió el modelo de referencia de Workflow (Hollingsworth 1995), que pretende identificar las características comunes de los sistemas de gestión de Workflow, proporcionando un marco general para la construcción de los mismos y permitir la interoperabilidad entre ellos, así como con otras aplicaciones involucradas.

Modelo de Referencia Workflow

Todos los sistemas de Workflow contienen componentes genéricos que interactúan de forma definida. Para mantener la interoperabilidad entre los diversos productos de workflow se definen un conjunto de interfaces y formatos para el intercambio de datos entre dichos componentes. Los componentes que considera el modelo de referencia

(ver Figura 2) son los siguientes: 

Motor de Workflow: Es el software que se encarga del seguimiento de los casos o instancias de los procesos. Servicio de ejecución de Workflow: Consta de uno o más motores de workflow. Interpreta la descripción de procesos y controla las diferentes instancias de los procesos, secuencia las actividades, añade elementos a la lista de trabajo de los usuarios e invoca las aplicaciones

necesarias. Interfaz de Programación de Aplicaciones de Workflow: (WAPI) Conjunto de interfaces de programación de aplicaciones (APIs) y funciones de intercambio soportadas por el servicio de ejecución de workflow. Permiten la interacción del servicio de ejecución de workflow con otros recursos y aplicaciones.

Figura 2. Modelo de referencia de Workflow (Hollingsworth 1995)

Los interfaces que considera el modelo de referencia son:

- Interfaz 1: Herramientas de definición de procesos. Los analistas de procesos serán los encargados de realizar una definición de los procesos de la organización, es decir, definir el conjunto de actividades, tareas, condiciones, personal, etc., que conlleva un determinado proceso y la secuencia de ejecución del mismo. Para ello utilizarán herramientas

de modelado y simulación de procesos, lo que les permitirá obtener una "definición del proceso" que debe poder ser interpretada en tiempo de ejecución por el o los motores de workflow. Este interfaz se encargará del intercambio de información entre el componente que permite la definición del proceso y el propio servicio de ejecución del flujo de trabajo. Será necesaria la definición de un metamodelo básico, en el que se identifique el conjunto mínimo de entidades para la definición de un proceso, permitiendo el intercambio de información entre ambos componentes. Un ejemplo de este metamodelo es la especificación XPDL (Workflow Management Coalition Members 2005) de la WfMC, aunque existen múltiples lenguajes de modelado de procesos tales como BPMN (Business Process Modeling Language), BPEL (Business Process Management Initiative), YAWL (Van Der Aalst y Ter Hofstede 2005), etc. – 

Interfaz 2: Aplicaciones clientes. Definición de APIs que permiten que aplicaciones clientes puedan solicitar servicios al motor de workflow y así poder controlar la progresión de procesos y actividades (incluso para iniciar la ejecución de una instancia de workflow). También define y maneja el concepto de lista de trabajos (o worklist) como una cola de trabajo asignado a un usuario o a un grupo de usuarios por el propio motor de ejecución del flujo de trabajo.

 - Interfaz 3: Aplicaciones Invocadas. Definición de APIs para permitir al motor de workflow invocar distintas aplicaciones. La aplicación invocada es manejada localmente por un motor de Workflow, usando la información suministrada en la definición del proceso para identificar la naturaleza de la actividad. La aplicación invocada puede ser local al motor de workflow, es decir, residente en la misma plataforma, o estar en otra plataforma dentro de una red. En este caso la definición del proceso debe contener información necesaria para poder encontrar la aplicación que se va a invocar. 

- Interfaz 4: Funciones de interoperabilidad entre distintos sistemas de workflow. Utilizado en el caso de estar en un entorno de ejecución de flujo de trabajo distribuido, en el que podrían existir diferentes motores de flujo de trabajo que controlen distintas partes de la ejecución del proceso. - Interfaz 5: Herramientas de administración y monitoreo. Permitir una visión completa del estado del flujo de trabajo, así como poder realizar auditorías sobre los datos del sistema.  

Funcionamiento de los sistemas de workflow Las instancias de workflow son ejecutadas por un motor de workflow. Este motor es básicamente un planificador que organiza el trabajo a realizar y lo asigna al actor que se encargará de realizarlo, que en la terminología de workflow se denomina recurso 

(Ver Figura 3). Figura 3. 

Funcionamiento de los sistemas de Workflow Cuando un nuevo proceso de workflow se instancia, el motor recupera la definición del mismo en el repositorio y determina el nodo a ser ejecutado (el siguiente nodo al nodo de comienzo). Si este nodo es un nodo de enrutamiento entonces el motor evalúa la condición y determina la salida que debería ser activada y por tanto el nodo que se ejecutará a continuación. Si el nodo es un nodo de trabajo entonces el motor determina los recursos a los que debería ser asignado para su ejecución. Para esto puede necesitar contactar con un intermediario de recursos que ejecute alguna política de selección de recursos definida por el usuario. A continuación, el motor de workflow coloca el trabajo en la cola del recurso seleccionado. Cuando el recurso esté preparado para ejecutar un nuevo trabajo, saca uno de su cola, lo ejecuta y devuelve el resultado al motor de workflow, que lo colocará en una cola de trabajo completado del motor de workflow. El motor continuamente monitorea esta cola para procesar mensajes de trabajo completado.

 Concretamente, por cada mensaje de esta cola, el motor determina el siguiente nodo a ejecutarse basado en el grafo de flujo del proceso workflow que se está ejecutando (Alonso et al. 2004). Los sistemas de workflow han evolucionado y quizá sea la propia organización WfMC la que define mejor su estado actual: ...El desarrollo y uso de la tecnología de workflow se ha movido desde simplemente soportar el en rutado de trabajo entre la gente a en rutar el trabajo horizontalmente entre recursos. Aquí el recurso puede verse como una persona, pero también un sistema o incluso una máquina. 

El en rutado también es vertical (controlando los pasos que serán llevados a cabo en cada punto del viaje) como por ejemplo cuando se llama a programas. Y como los datos se mueven entre procesos, hay típicamente una integración con los sistemas de procesamiento, lo cual coloca al workflow dentro del área de la integración de aplicaciones de empresa. 

3. GESTIÓN DE PROCESOS DE NEGOCIO

La intensificación en la orientación hacia los procesos de las organizaciones ha provocado una visión más global de los sistemas de información basados en gestión de procesos y ha hecho aflorar algunas carencias de los sistemas de Workflow. Es por eso que en los últimos años han surgido múltiples trabajos en el campo denominado Gestión de Procesos de Negocio, que muchos consideran sustancialmente más amplio que los sistemas tradicionales de Workflow. Por ello el BPM puede verse como la evolución natural de los sistemas de workflow y del tratamiento automatizado de los procesos de negocio de las empresas. Esto es debido a que la evolución del término proceso ha cambiado en el interior de las organizaciones; muchos de los procesos de las empresas actuales no se apoyan solo sobre una aplicación o un conjunto de aplicaciones internas, como sucede con los sistemas de workflow tradicionales. No obstante, es interesante resaltar que los investigadores en el campo del Workflow ya se habían planteado y se plantean actualmente muchos de los problemas que en estos momentos se atribuyen habitualmente al BPM (Van Der Aalst y Van Hee 2002). BPM ve a los procesos como algo más complejo que la visión tradicional del workflow, en palabras de los autores del libro (Smith y Fingar 2003) la definición de proceso es más genérica y centrada en la coordinación de procesos: "Un proceso de negocio es el conjunto completo y coordinado de actividades colaborativas y transaccionales que proporcionan valor a los clientes". BPM es un intento sistemático para mejorar los procesos de negocio de una organización. Las actividades de BPM buscan hacer los procesos de negocio más efectivos, eficientes y adaptables a un ambiente dinámico; las empresas afrontan con más frecuencia procesos más complejos, que engloban diferentes departamentos, filiales o socios, y que pueden estar geográficamente distribuidos. BPM surge como un nuevo, Eva Cuervo Fernández 141 paradigma para dar solución a la integración de ambientes heterogéneos haciendo convivir las aplicaciones existentes con nuevos desarrollos. BPM engloba todas las actividades que forman parte del ciclo de vida de un proceso de negocio, tales como el descubrimiento, diseño, simulación, despliegue, ejecución, interacción, monitorización, control, análisis y optimización del proceso de negocio. Además, BPM implica el desarrollo de nuevos sistemas de información que se conocen como Business Process Management Systems (BPMS). Los BPMS son capaces de suplir las carencias de los sistemas de workflow en el campo de los procesos de negocio: control de las conversaciones de larga duración entre las entidades que forman parte del proceso, control y gestión de diferentes hilos de ejecución, ejecución paralela, control de errores, compensación de transacciones, soporte de datos XML complejos, etc. Los BPMS están compuestos por cinco bloques de construcción: 

1.- Diseñador gráfico de procesos, que permite realizar el modelado de los mismos. 

2.- Motor de ejecución. 

3.- Monitor de procesos y gestor de capacidades. 

4.- Herramientas de análisis. 

5.- Interfaz para modificar el proceso en tiempo de ejecución.

Es útil comparar los BPMS con los sistemas de gestión de base de datos (SGBD). Un SGBD gestiona los modelos de datos en una base de datos que es externa a las aplicaciones individuales y que depende de modelos formales de datos. La separación de la gestión de datos de las aplicaciones fue el principal paso en la racionalización del desarrollo de aplicaciones. La separación de la gestión de procesos de negocio de las aplicaciones es un movimiento de magnitud similar. Se pretende separar la gestión de los procesos de las aplicaciones para que cualquier cambio en la lógica de los procesos no suponga ninguna modificación en el código de las aplicaciones (Smith y Fingar 2003). También es importante considerar, que BPM no se refiere a priori al desarrollo de aplicaciones software. Su interés principal es la gestión de los procesos de negocio, aunque para ello requiere asistencia computacional. Los modelos formales de procesos de negocio son legibles por las máquinas, pero es útil que las herramientas presenten los modelos a la gente de negocio para que puedan crearlos, leerlos o modificarlos. Los objetivos básicos que se plantean a la hora de realizar BPM pueden agruparse en los siguientes: Agilidad o capacidad de respuesta ante cambios: debido a la llegada del e-business, continuamente se están produciendo cambios: aparecen nuevos clientes, nuevos modelos de negocio, nuevas plataformas de tecnología, nuevos estándares, etc. BPM pretende permitir a las organizaciones aportar nuevos productos y servicios al mercado más rápidamente y adaptar sus procesos de forma más efectiva a los cambios de las demandas del mercado. Gestión de los procesos de principio a fin: lo que proporciona una mayor capacidad de control de la gestión y monitorización de las actividades del negocio. Los directivos quieren información en tiempo real de las claves en la ejecución de sus procesos. Estas métricas normalmente necesitan correlaciones de datos de sistemas heterogéneos situados dentro y fuera de la organización. Conseguir la implementación de los procesos a partir de modelos orientados a negocio: Anteriormente los modelos de procesos han sido utilizados como herramientas para la captura de requisitos proporcionando guías para que los desarrolladores construyesen modelos de implementación utilizando herramientas diferentes. BPM promete poder generar modelos de implementación y código directamente de los modelos orientados al negocio. BPM utiliza los modelos formales para automatizar la gestión de procesos de negocio, esforzándose por conseguir la máxima independencia de la plataforma de computación. Monitorización de las actividades del proceso en tiempo real y optimización dinámica vía las reglas del negocio.