FLUJOS DE TRABAJO O WORK FLOW

Sebastiano Milesi Sebstian Ingeniero Comercial - Economista Profesor de Administracin IPLA

Introduccin
Al interior de las organizaciones se genera la informacin necesaria para el funcionamiento de sus diferentes procesos; sta parte de un puesto de trabajo en particular y puede ser utilizada en el mismo o en otro diferente. Cuando la informacin generada es usada en un lugar distinto al que la produce, se debe tener en cuenta que los documentos hacen un recorrido dentro de la empresa, antes de llegar a su destino final; esto es conocido como flujo de trabajo o workflow.

De acuerdo con lo anterior se puede decir que el proceso workflow o flujo de trabajo ha existido desde hace bastante tiempo atrs, debido a que el manejo de informacin es importante para todas las organizaciones y siempre la han utilizado en sus procesos.

Tradicionalmente, el principal inconveniente del manejo de documentos ha sido la dificultad para distribuirlos con un mismo formato, segn la informacin que contengan, a las dependencias de la empresa que requieran dichos artculos. Las redes de rea local Intranet han creado un medio donde se puede superar este obstculo, haciendo que casi cualquier informacin sobre la red este disponible en cualquier punto de la empresa. Debido que las Intranet por medio de una infraestructura para administradores de consideraciones sobre documentos. permiten una buena gestin de documentos sede Web, se puede aprovechar esta crear nuevas herramientas para los redes, que ahora deben enfrentar el acceso, control y la auditora de los

Muchas organizaciones se ven en la necesidad de crear rutas para el flujo de informacin va electrnica con el fin de despapelar y agilizar el recorrido de documentos, flujo ste, en el que sea posible dar trmite por medio de contraseas que pueden ser representadas como claves personales. Este sistema de claves puede ser implementado dentro de un software para workflow con el fin de permitir el servicio del envo de documentos bajo una red de rea local como Intranet.

Concepto y elementos
El workflow es una herramienta de software que puede ser implementada sobre una Intranet para automatizar procesos que requieren del envo de documentos, con el fin de agilizar los trmites propios existentes en el funcionamiento de una organizacin; cabe anotar que la persona encargada del proceso puede definir el recorrido que debe tener un documento al que haya que dar trmite, definir niveles de seguridad y definir prioridades en documentos.

A continuacin se hace mencin a los elementos ms importantes que componen un sistema Workflow, as como algunas de las arquitecturas conocidas, con el fin de dar claridad a la herramienta. Las caractersticas claves de un sistema workflow son las tareas, personas, herramientas y datos que dependen de varios elementos modulares crticos para poder llegar a su expresin final. Estos elementos se conocen como las tres "Rs" (Rutas, Reglas y Roles) y las tres "Ps" (Procesos, Polticas y Prcticas) de la arquitectura workflow. Cuando se cambian las rutas, reglas y roles adecuados con los procesos, polticas y prcticas adecuadas, la tecnologa

workflow se convierte en un potente medio para el desarrollo de aplicaciones. Esta tecnologa se expresa por lo general en tres mdulos de aplicacin workflow que tienen por base el proceso cliente/servidor, basado en correo electrnico; base de datos compartida y base de datos cliente servidor. En el modelo base proceso cliente/servidor, toda la funcionalidad workflow reside en el cliente y es ejecutada por ste, y solo las funciones de mensajera propiamente dichas tienen lugar en el servidor. Aunque este modelo soporta usuarios remotos, mltiples sistemas operativos de red y mltiples plataformas clientes, las reglas que lo gobiernan son difciles de controlar.

El modelo de base de datos compartida es similar al modelo basado en correo electrnico en que todo el proceso se realiza en el cliente. Sin embargo, los documentos se almacenan en una base de datos compartida en la red, en lugar de ser trasladados de un lado para otro a travs del sistema de correo electrnico. Sus puntos fuertes son su acceso continuo a documentos y sus fciles capacidades de gestin, mientras que su principal limitacin es la necesidad de que est conectado a la base de datos. El modelo de base cliente/servidor es una extensin al modelo de base de datos compartida al almacenar y ejecutar reglas en el servidor. El servidor ejecuta procesos o agentes que determinan el paso siguiente a realizar en el proceso workflow, y adems se puede monitorizar el status workflow y alertar a alguien si una tarea se retrasa. El punto fuerte y principal del modelo cliente/servidor es su capacidad de controlar el workflow desde el servidor, mientras que el punto dbil ms notable es su necesidad de acceder a la red, lo cual puede ser una carga para los usuarios remotos.

Aspectos tecnolgicos
El proceso workflow es simplemente la automatizacin de los procesos que se realizan a diario dentro de la actividad comercial de una empresa. Una aplicacin workflow automatiza la secuencia de acciones, actividades o tareas utilizadas para la ejecucin del proceso, incluyendo el seguimiento del status de cada instancia del mismo y la aportacin de las herramientas necesarias para gestionarlo.

Cuando se discute de workflow, se est hablando bsicamente de mover informacin a las personas apropiadas siguiendo un orden adecuado, y de suministrar las herramientas idneas que permitan procesar esa informacin. La tecnologa workflow aunque evoluciona rpidamente, se encuentra an en sus etapas formativas, lo que significa que el mercado es dinmico y est abierto a una amplia variedad de productos y servicios. Sus caractersticas ms relevantes son:

Tareas. Una aplicacin workflow automatizada est formada por diferentes tareas o actividades que deben ser realizadas para alcanzar un determinado objetivo comercial. Personas. Las tareas son realizadas siguiendo un orden especfico, por personas especficas o por agentes automatizados que asumen el papel de personas en base a condiciones o reglas comerciales. Herramientas. El proceso de la informacin propiamente dicho dentro de cada tarea como una comprobacin de crdito o la redaccin de una carta no lo realiza la aplicacin workflow, sino que generalmente estas tareas las realizan herramientas tales como aplicaciones de productividad personal y aplicaciones de lnea-de-negocio, por ejemplo un sistema de contabilidad llamado por la aplicacin workflow o invocado explcitamente por el usuario cuando se necesita.

Las Rs y las Ps del workflow

Aunque hay gran cantidad de funciones y caractersticas que forman parte del workflow, los atributos que identifican a una aplicacin workflow pueden simplificarse en forma de tres "Rs" y tres "Ps", como se seal anteriormente

Rutas. Los primeros productos workflow eran en realidad routers inteligentes. En el mundo del tratamiento de imgenes, compaas como FileNet o Recogniton International permitan a vendedores o revendedores (y ms adelante a los clientes) definir el orden en el que deberan fluir las imgenes. Hoy, es necesario especificar el flujo de cualquier tipo de objeto como documentos, formularios, datos, aplicaciones, entre otros. Estos objetos deben ser capaces de moverse a travs de cualquier cantidad de rutas secuenciales, diferentes y despus reconciliarse formando una nica ruta en un punto especificado. Adems, los objetos debern poder ser enviados en modalidad de transmisin o en cualquier orden descrito por el usuario o en el momento del proceso. Un ejemplo de esto es el correo electrnico, en el que todo el mundo recibe inmediatamente el objeto en cuestin.

Reglas. Una caracterstica ms avanzada de la automatizacin workflow, y que hace que sea tan valiosa, es su capacidad de definir las reglas que determinan que informacin debe dirigirse a travs de la ruta y a quin. Esto se conoce a veces como routing condicional o tratamiento de situaciones de excepcin. El routing condicional permite al sistema manejar una mayor proporcin de la transmisin automtica de objetos, para enviarla al receptor apropiado. Recoger las normas y supuestos que describen como funciona verdaderamente una empresa es incluso ms valioso que definir reglas workflow, sin embargo, definir las reglas de un proceso comercial puede resultar difcil, ya que pueden ser complejas y elaboradas, con mltiples opciones, variaciones y excepciones.

Roles. Es importante definir roles o funciones independientemente de las personas o de los procesos especficos que desempeen ese rol.

Procesos. Los procesos establecidos, que controlan y dirigen la actividad de una empresa, son tan variados y tan personales como las personas que participan en ellos. Con frecuencia, los procesos no son diseados, sino que se identifican despus del hecho en cuestin y se extraen del uso o la actividad comn.

Polticas. Las normas o polticas son expresiones redactadas formalmente, que indican la forma en que deben manejarse ciertos procesos. As, cuando los empleados inician un nuevo trabajo, se les comunican las normas de la compaa sobre vacaciones, beneficios asistenciales y pagos en caso de enfermedad. Aunque las compaas deben mantener una poltica formal sobre cmo manejar cada proceso comercial automatizado, muchas no la tienen.

Prcticas. Las prcticas son aquellas cosas que verdaderamente suceden en las empresas, y que pueden considerarse como actos que "infringen las reglas" y que hacen que el proceso funcione realmente.

Modelos de arquitectura
Pueden crearse aplicaciones workflow en base a uno de tres modelos de arquitectura cliente/servidor:

Basada en correo electrnico. Base de datos compartida. Base de datos cliente/servidor.

A.- Modelo basado en correo electrnico

Puede crearse aplicaciones workflow basadas nicamente en la infraestructura de correo electrnico que existe en las empresas. Esta arquitectura es muy apropiada para aplicaciones de envo de documentos a travs de rutas, como la requisicin de gastos o la aprobacin de rdenes de compra. En el modelo basado en el correo electrnico, prcticamente toda la funcionalidad workflow reside en el cliente y es ejecutada por ste y slo las funciones de mensajera propiamente dichas tienen lugar en el servidor. La recepcin de asignaciones de tareas y la realizacin de stas tienen lugar en el cliente en los tres modelos.

Los elementos clave del entorno de ejecucin, rutas, roles y reglas son ejecutados todos por uno o ms procesos de cliente. Los datos, las reglas para procesar los documentos y el documento propiamente dicho, reside en el depsito de entrada del usuario, mientras que las reglas de proceso pueden viajar con el documento o ser mantenidas en la aplicacin de correo electrnico del cliente.

* Evaluacin del modelo basado en correo electrnico Los puntos fuertes principales del modelo de correo electrnico son el soporte para tres entidades: Usuarios remotos, Mltiples sistemas operativos de red y Mltiples plataformas cliente. Como la informacin viaja hacia el usuario, no importa donde resida ste y, como la mayora de los usuarios estn conectados a una red de correo electrnico, esta arquitectura es muy prometedora para situaciones workflow entre mltiples organizaciones. El inconveniente del enfoque basado en correo electrnico es la complejidad de gestionar las reglas de workflow. Como estas reglas tienden a residir en mltiples localizaciones (muy frecuentemente, en mltiples aplicaciones de correo electrnico de los usuarios), cualquier cantidad de cambios realizados en el proceso pueden tener que realizarse tambin en muchas aplicaciones que pueden existir en estaciones de trabajo en todo el mundo. Adems, en el modelo de correo electrnico, puede ser difcil determinar el status o situacin exacta de una determinada porcin de trabajo ; finalmente en una aplicacin basada en correo electrnico destinada a dirigir documentos a travs de rutas, el documento no est disponible para nadie que no sea el receptor actual del correo.

B.- Modelo de base de datos compartida

En este modelo todo el proceso es realizado en el cliente. Sin embargo, en el modelo de base de datos compartida, los documentos no se envan de un lado a otro a travs del sistema de correo electrnico, aunque puede notificarse a los usuarios - mediante ese correo - que tienen una tarea workflow a realizar. Por el contrario, los documentos se almacenan en una base de datos compartida en la red, de forma que el documento est siempre disponible para ser visto, al menos en una versin de slo lectura. En este modelo, las reglas y los roles pueden ser almacenados separadamente de los documentos en la misma base de datos o en una base de datos diferente, o bien pueden estar contenidos dentro del software cliente, o conectados a los documentos propiamente dichos.

* Evaluacin del modelo de base de datos compartida

Aparte de la ventaja de disponer de un acceso continuo a los documentos, el modelo de base de datos compartida ofrece mejores capacidades de gestin que el modelo de correo electrnico, incluyendo una mejor gestin de las reglas y el seguimiento del

status. La base de datos compartida puede utilizarse tambin para almacenar informacin histrica sobre los workflow. La principal limitacin de este modelo es la necesidad de estar conectado a la base de datos.

C.- Modelo cliente/servidor

El modelo cliente/servidor amplia el modelo de la base de datos compartida almacenando y ejecutando las reglas en el servidor. El servidor ejecuta procesos o agentes que determinan el proceso siguiente a realizar en el proceso workflow, y adems puede monitorizar el status del workflow y notificar a los participantes sobre cualquier tarea prxima o retrasada, o alertar a alguien que este gestionando workflow que ha vencido el plazo para la ejecucin de un determinada tarea.

* Evaluacin del modelo cliente/servidor El modelo cliente/servidor ofrece todos los beneficios de la arquitectura de bases de datos compartidas, y puede ser integrado fcilmente con el sistema de correo electrnico. Su punto fuerte principal es su capacidad de controlar la aplicacin workflow desde el servidor, lo cual incluye la capacidad de monitorizar y gestionar cada aplicacin workflow.

Este modelo almacena y ejecuta las reglas workflow en el servidor permitiendo una gran facilidad de mantenimiento de la aplicacin. La arquitectura workflow cliente/servidor sufre de limitaciones similares a las del modelo de base de datos compartida. Se requiere el acceso a la red, pero la replicacin puede resolver algunos de los problemas remotos. Sin embargo, este modelo puede ser capaz de manejar mejor clientes remotos, ya que si un usuario no acta sobre una determinada tarea dentro de un periodo especfico, el agente servidor puede reasignar la tarea a otro. Las aplicaciones cliente/servidor requieren una aplicacin corriendo en el servidor y otra corriendo en el cliente. Esta aplicacin de servidor necesita generalmente trabajar en un sistema operativo multitarea que probablemente ser distinto al sistema del cliente.

Santiago, mayo del 2007