Los capítulos anteriores son:

Capítulo II - Requerimientos Funcionales de un WMS.

Capítulo 1 - Conceptos de workflow

El diseño del mismo no es un problema siquiera medianamente complejo, pero habrá que tener en cuenta algunos elementos importantes a la hora de que el mismo potencie el diseño de los procesos.

En primera instancia, definiremos al organigrama como una estructura de nodos (estructura de árbol), donde cada nodo tendrá un conjunto de atributos básicos. Para cada nodo definiremos un nombre y una lista de supervisores del nodo.

Las imagenes que se muestran a continuación, corresponden al organigrama que he publicado como código abierto en CodePlex, en el proyecto https://www.codeplex.com/orgchart (colaboración para completar el código es bienvenida...)

Figura 1 - Arbol del organigrama

Adicionalmente, podemos definir otros atributos avanzados en la estructura de nodos o árbol del organigrama, pero en este caso solo nos referiremos a un atributo adicional.

En caso de grandes organizaciones (u organizaciones que han crecido en forma desordenada con sus servicios de directorio) será necesario integrar diversas fuentes de validación y extracción de usuarios con el organigrama. La tecnología disponible hoy en día hace que sea muy fácil integrar usuarios de diversas fuentes explotando las interfases de active directory. Opcionalmente, definiremos para cada nodo un directorio u unidad organizacional con las que deberá sincronizarse.

Figura 2 - Propiedades del Nodo

Los otros cursos, clases o charlas dictados en otras universidades se encuentran publicados aquí

Capítulo 1 - Conceptos de workflow

El desarrollo de un sistema de Workflow implica diseñar un sistema capaz de modelar y ejecutar los procesos de la organización, y por sobre todo, capaz de acompañar en el tiempo a la organización en su evolución natural, lo cual implica una tarea nada sencilla.

Comenzamos dividiendo el diseño en las siguientes áreas o perspectivas, analizando los requerimientos funcionales en cada una de ellas para luego desarrollar cada una de estas áreas en su propio capítulo. Las áreas son:

-       Elementos de la organización.

-       Modelado de procesos.

-       Interfases de usuario.

-       Integración.

-       Manejo de documentos.

-       Enfoque global del sistema.

-       Administración de los workflows.

-       Seguridad de acceso a la información.

-       Análisis de la información.

-       El Motor de workflow (las interfases y el diseño a bajo nivel)

-       Extensibilidad.

Área: Elementos de la organización.

La implementación de procesos organizacionales, hace que sea indispensable disponer de un organigrama que represente las diversas relaciones funcionales existentes en la organización. Normalmente, los servicios de directorio de usuarios (Active Directory, Servicios LDAP como los de Netscape, Novell Directory Services) no presentan las relaciones funcionales adecuadas para implementar un sistema de workflow, ya que la distribución de los usuarios en unidades organizacionales o grupos está basada en criterios de políticas de seguridad, ubicación geográfica y hasta en criterios históricos, pero rara vez en verdaderas relaciones jerárquico-funcionales.

Ningún proceso de workflow es sustentable si no es flexible y práctico para adaptarse a los cambios de la organización. Si el sistema debe nominar a los usuarios en forma directa, está destinado claramente al fracaso (a que las tareas queden esperando por usuarios inexistentes, a que la salida de un trabajador o el reemplazo o suplencia del mismo sea una tarea de alto riesgo). En el organigrama, representaremos la estructura jerárquica de la organización y en el distribuiremos los usuarios y los diferentes tipos de roles que debamos definir.

Para cada elemento de la organización deberemos establecer un conjunto de propiedades básicas del sistema (necesarias para la implementación) y un conjunto de propiedades extendidas, orientadas a facilitar la tarea de diseño de los procesos y la administración del sistema. El análisis de las propiedades y los detalles particulares de la implementación del organigrama se ven en detalle en el capítulo 4.

La definición de los usuarios, incluirá también la forma en que los usuarios serán autenticados o reconocidos por el sistema (tema que se verá en detalle también en el capítulo 4).

Para hacer eficiente el manejo de la asignación de responsabilidades de ejecución o supervisión de las distintas tareas que compongan los procesos necesitamos implementar diversas formas de referenciar o nominar a los usuarios en forma indirecta (ya sea por una nominación indirecta o por alguna regla que determine en tiempo de ejecución del proceso, quién desempeñará un determinado rol).

Las distintas formas de nominar a un usuario para realizar una tarea son:

1)          Asignación Directa: El usuario es nominado directamente por el proceso (hard-coded). Esta es la forma mas pobre y menos flexible de asignación de trabajo, ya que la asignación está definida en el propio proceso en forma nominativa y nos obliga a alterar el proceso para cambiar la asignación (no deja de ser válida para organizaciones pequeñas, con menos de 30 usuarios). A esta forma la denominaremos como Usuario Nominado

2)          Asignación Indirecta por Rol o Cargo; Es una de las formas mas comunes de asignación de tareas o responsabilidades, en la cual un elemento del organigrama (Cargo o Rol) está asignado a uno o mas usuarios y en el diseño del proceso se referencia al cargo (ejemplo: gerente de compras)

3)          Grupos: Los grupos son la forma más básica de manejar asignaciones de tareas a un conjunto de personas. Generalmente son utilizados para enviar notificaciones o para realizar una consulta de tipo votación. El control de la membresía de los grupos podrá ser estática (se nominan los usuarios que serán miembros del grupo) o dinámica (se determina por medio de una fórmula quienes son miembros de ese grupo en el momento de utilizarlo o expandirlo).

4)          Colas de Trabajo: Son la base de la asignación de trabajo en forma indirecta, con un modelo de reparto de las tareas ya sea por parte de los propios participantes, por parte de un moderador o por un mecanismo de balance de carga. Las colas de trabajo son básicamente un grupo, donde se comparte una lista de tareas o bandeja de entrada. El trabajo se asigna a las colas de trabajo y luego este es tomado de la cola por los miembros de la misma, haciendo una asignación indirecta del mismo. Las colas de trabajo pueden tener diversos mecanismos de asignación del trabajo. Estos pueden ser:

a.     Auto-Asignado: Los usuarios toman en forma preactiva las tareas de la cola de trabajo y un supervisor controla solo las desviaciones. Los usuarios reciben una lista unificada y priorizada de tareas unificando todas las colas de trabajo de las que son miembros y simplemente se auto-asignan las tareas en base a su propio criterio.

b.    Moderado: Un moderador de la cola distribuye el trabajo entre los participantes.

c.     Balanceadores de carga: El motor de workflow, en el momento de generar la tarea, decide que miembro de la cola de trabajo realizará la misma. Las opciones son:

                                          i.    Secuencial: Se entrega una tarea a cada uno de los miembros de la cola de trabajo, en forma secuencial (Round Robin).

                                         ii.    Menor carga: Se entrega una tarea al usuario con menor carga de trabajo pendiente o con cero carga de trabajo.

                                        iii.    En línea: Donde se detectan lo usuarios conectados al sistema y se reparten las tareas a medida que vacían su lista de tareas.

5)          En el diseño del proceso pueden existir roles propios del proceso, los cuales podrán ser roles de sistema (que existen siempre en todos los procesos y son relativos al mismo) o roles definidos para realizar manejos avanzados en el proceso. Distinguiremos las dos clases:

a.     Roles de Sistema; Son roles que existen asociados a todos los procesos y son asignados a diversos usuarios de acuerdo a su relación con el proceso o workflow en ejecución. Estos pueden ser:

                                          i.    Usuario que inició el workflow.

                                         ii.    Usuario que Administra el Proceso.

                                        iii.    Usuarios que está asignado a una determinada tarea del workflow.

                                        iv.    Relaciones jerárquicas o funcionales sobre los roles anteriores (p/ejemplo: Supervisor del usuario que inició el workflow)

b.    Roles definidos en el proceso: En algunos procesos, se necesitará realizar una asignación dinámica de las tareas, calculando el destinatario de una tarea mediante programación o permitiendo que al inicio, o dentro de una  determinada tarea se seleccione que usuarios desempeñarán uno o más roles a ser utilizados en tareas posteriores.

Analizaremos en detalle el diseño del Organigrama en el capítulo 4.

Área: Modelado de los procesos.

El confeccionar un modelo para que los usuarios puedan reflejar las reglas de negocio en forma sencilla (no solo en forma sencilla en cuanto al diseño de las mismas, sino en cuanto a la interpretación y conocimiento de las mismas por parte de los usuarios finales del sistema) es la tarea más importante de la fase de diseño.

Sin duda, el diseño de la interfase que utilizarán los analistas de organización y métodos para diseñar cada uno de los procesos de la organización determina en gran parte el éxito o fracaso del sistema de Workflow.

A la inversa de la gran mayoría de sistemas de workflow existentes, un sistema ágil, que acompañe los tiempos de negocio, debe estar orientado a que el diseño final de la lógica de negocios lo realice una persona con conocimientos organizacionales pero sin conocimientos informáticos y una vez terminado el trabajo de esta persona, el proceso debe etar listo para ser utilizado por los usuarios finales. Esta fue, en gran medida, la decisión con que diseñé, en el año 2000, Q-flow 1.0 y que marcó en su tiempo una tendencia que actualmente no es tan extraña.

En base a esa premisa, se propone aquí un modelo en el cual el analista de organización define los requerimientos de información necesarios (lo que llamamos datos relevantes del proceso) y luego diseña el proceso especificando la secuencia de tareas a realizarse en un grafo, mediante el cual establece los criterios de secuencia, precedencia y paralelismo de proceso. El diseñador de procesos, simplemente organizará la secuencia lógica de las tareas, encapsulando cada interacción con personas o sistemas en un conjunto de “clases” de tareas. De la capacidad de estas clases de tareas para proveer una funcionalidad amplia que satisfaga las necesidades operativas de los procesos depende en gran medida el éxito de cualquier sistema de Workflow.

En cualquier herramienta de Workflow encontraremos los átomos con los cuales compondremos los procesos, a los cuales llamaremos actividades. En general, el diseño de un proceso de negocios es un proceso en el cual se deberán identificar las tareas que deben completarse para alcanzar el objetivo del proceso y luego encontrar la actividad o el conjunto de actividades que implementarán dicha tarea. A  nivel de actividades, podremos tener diferentes abstracciones representadas por las mismas (tarea, pregunta, votación, creación de documento, notificación, etc.) y gran parte de la potencia del sistema de Workflow se medirá por las abstracciones que maneje y por las actividades que implemente en forma nativa, así como por su capacidad para implementar en forma sencilla nuevas actividades.

Las actividades serán conectadas entre si por conectores que permitirán al proceso pasar de una actividad a otra, realizando la transición entre actividades. A estos conectores los llamaremos “transiciones”.

En cuanto a la orquestación de las actividades dentro de un flujograma, representando por medio del mismo las reglas de negocio (dando la secuencia de ejecución de actividades), existen dos modelos básicos sobre los cuales trabajar. Por un lado, el modelo secuencial tradicional, donde cada actividad define en forma fija los conectores de salida que posee (es decir, las transiciones que puede disparar, por ejemplo, una actividad de evaluación tendrá los conectores de entrada, salida por verdadero y salida por falso mientras que una actividad de notificación tendrá los conectores de entrada y de salida). Por otro lado, existe el modelo de la máquina de estados, donde se tienen un conjunto de actividades que representarán los estados en los cuales puede tomar la máquina (aunque esta siempre estará en uno y solo uno de los estados) y en cada una de ellas, se define en tiempo de diseño, las transiciones entre los diversos estados.

En el diseño de los procesos intervendrán 7 elementos principales, todos los cuales darán forma al proceso de negocios completo. Estos son:

-       Los datos relevantes del proceso. Es decir, los elementos de información que son necesarios para la toma de decisión dentro del proceso y que en muchos casos van a estar conectados con los sistemas de información de la organización.

-       La secuencia de actividades, con el contenido de información necesaria en cada una de ellas para realizar la misma, unidas en un grafo que brinde las relaciones de precedencia del proceso y las transiciones posibles entre actividades.

-       Los roles propios del proceso. Aquellos roles que deben ser nominados en tiempo de inicio o de ejecución del workflow y que no pueden asignarse de ante mano a un miembro o grupo de la organización.

-       El manejo de información no estructurada (documentos adjuntos).

-       Reglas: Existirán un conjunto de reglas de negocio, asociadas a los procesos, que no podrán representarse en el grafo debido a su naturaleza o a que tienen un alcance global y no particular de cada actividad. Por lo tanto deberemos incluir el concepto de validaciones y validaciones avanzadas.

o    Las validaciones declarativas, incluyen las validaciones globales del proceso (o de parte del proceso) que pueden ser introducidas al diseño como una secuencia de instrucciones IF-THEN-ELSE y que mediante la interpretación del motor de workflow garantizan la consistencia de la información provista por el usuario o por sistemas externos al completar una actividad.

o    Una premisa de diseño presente en cualquier sistema debería ser el “Construir soluciones abiertas y extensibles” y es una de las claves de cualquier sistema informático para permitir una evolución de segundo nivel del mismo, sin necesidad de volver a la mesa de diseño. Debemos dejar puntos de entrada para que usuarios con dominio de la informática sobrescriban o extiendan funcionalidades y comportamientos del producto e implementar el ser básico de funcionalidades usando estos mecanismos de extensibilidad, de forma de estabilizar su interfase y la imlementación. Por lo tanto, será posible anexar a las actividades o al proceso validaciones especiales que cambien o complementen el comportamiento por defecto que presenta el sistema de workflow.

-       Procesamiento de eventos del proceso. El concepto de la programación orientada a eventos es un concepto muy arraigado en el ambiente Windows y es una de las mejores formas de “Extender” o cambiar el comportamiento de un sistema, conectando rutinas o código a “eventos” que el sistema publica y que pueden ser consumidos por uno o más “Manejadores” que se suscriban a los mismos. Es una realidad de la interacción con usuarios que cualquier proceso de negocios recibirá y deberá “procesar” de manera sencilla un conjunto de eventos desde el medio ambiente donde se desempeña. El diseñar un proceso que en cada actividad en que se encuentre pueda aceptar y procesar todos los tipos de eventos que puede llegar a recibir hace que el proceso tenga un diseño complejo, por lo tanto, deberemos proveer una forma genérica de que nuestro diseño reciba eventos externos y les de la adecuada atención a los mismos sin tener que recurrir a intrincados elementos de diseño.

-       Como una forma particular de eventos (si se quiere, puede tratarse a los errores como eventos de tipo error) debemos manejar las excepciones que ocurran en el proceso. Las excepciones implican situaciones que ocurren en condiciones excepcionales (si la excepción es común, deberíamos mejorar el diseño del proceso para que la trate como una opción mas a manejar dentro del flujo de proceso) y debemos dar en el diseño del proceso una forma de atender esas situaciones excepcionales sin incurrir en generar un proceso ininteligible, completamente lleno de manejadores de excepciones y excepciones de excepciones. Debido a ello, se deberá generar el proceso de atención de excepciones con cierta independencia del diseño general del proceso (al menos con una interfase de diseño que separa el proceso principal del proceso de manejo de excepciones).

Otra arista importante del diseño de procesos es el manejo de múltiples versiones. Normalmente, los procesos evolucionan constantemente dentro de una organización. Aquellos procesos de corta duración (tal como puede ser una solicitud de licencia, una orden de compra, una rendición de gastos) no presentan mayores problemas para ser impactados por una nueva versión, pero existen dentro de las organizaciones procesos de muy larga duración (siempre recuerdo el caso del primer Corredor de Marcas donde implementamos una solución de workflow, en esos casos, un registro de marcas con oposición en el cual se llega a un juicio puede durar ¡hasta 5 años!) y para esos procesos, el sistema debe ofrecer las siguientes prestaciones:

-       Debe tener la capacidad de manejar múltiples versiones de un mismo proceso a nivel de diseños incorporados en la base de producción.

-       Debe ser capaz de señalar una de las versiones como la versión a ser utilizada por los nuevos workflows que se inicien.

-       Debe ser capaz de manejar múltiples versiones de un mismo proceso en ejecución en forma concurrente (a partir de tal fecha o de una operación administrativa se inician los workflows con determinada versión y los workflows iniciados con una versión anterior continúan como estaban).

-       Debe ser capaz de realizar un cambio sobre una determinada versión de un proceso siempre y cuando este sea un cambio que no genere “inestabilidad” en el proceso (como cambiar propiedades o contenido de algunas tareas, etcétera) y en el caso de que genere inestabilidad, debe ser capaz de diagnosticarlo y dar alternativas a los diseñadores.

-       Debe ser capaz de independizar un workflow del diseño general (esto se verá en detalle en el capítulo de operaciones, pero en algunos casos es necesario alterar el diseño de un único workflow y en algunos ambientes es una prestación muy apreciada).

-       Debe ser capaz de realizar un análisis del impacto que causaría cambiar una versión en producción por otra (y realizar el cambio por supuesto).

-       Por último, pero no menos importante que los anteriores, todo sistema de workflow tiene que tener capacidad de simulación. Un simulador permite a los analistas organizacionales probar fácilmente el proceso y evaluar el funcionamiento del mismo en un entorno virtual.

Analizaremos en detalle el diseño de los procesos en el capítulo 7.

Área: Interfases de usuario.

Para que el sistema sea utilizable por los usuarios, debe presentar a estos una interfase que les brinde las prestaciones adecuadas a sus necesidades. En el mundo actual, la interfase adecuada a un sistema que por sus características debe ser ubicuo, son el correo electrónico y los Sitios Web. El correo electrónico es ideal para transportar tareas, recordatorios, alertas y listas de consolidación de tareas. Un sitio Web es la herramienta necesaria para presentar a los usuarios la funcionalidad completa de interacción con el sistema de workflow. Pero, tal como veíamos en el capítulo anterior, un sistema de workflow tiene que ser un puente entre los diversos sistemas y tecnologías que posea la organización y esta premisa tiene especial trascendencia en lo que respecta a las interfases de usuario, donde habrá que pensar en una integración a nivel de portal para “fundir” el workflow con el portal de la organización y, en especial, habrá que trabajar en la integración con las herramientas que el usuario conoce y utiliza habitualmente (herramientas de productividad de oficina, sistema de gestión, etc.). Será un requerimiento también del sistema de workflow el ser una puerta de entrada a las tecnologías emergentes, ya que el workflow implica conectividad, pro-actividad, ubicuidad y hoy en día, esos son los disparadores naturales para soluciones móviles, basadas en diversas tecnologías. Continuemos ahora con el análisis más “funcional” del sistema, para retomar en el capítulo 7 un análisis detallado de las opciones tecnológicas que se deberán utilizar para interactuar con los usuarios ya sea en modalidad de trabajo en línea como desconectado.

Básicamente, tendremos que manejar información referente a 3 entidades y a agrupaciones de las mismas:

-       Procesos.

-       Tareas.

-       Workflows

-       Conjuntos de workflows

-       Conjuntos de tareas.

Los procesos, son el diseño de los workflows en si y debe brindarse una interfase amigable para el inicio o puesta en funcionamiento de nuevas instancias del proceso o workflows (por ejemplo, ingresar mi rendición de gastos de un viaje). Los usuarios deberán ser capaces de encontrar fácilmente una lista de los procesos que pueden iniciar y deberán poder iniciar los procesos en forma simple y amigable. Si generalizamos un poco el diseño y simplemente tratamos al inicio de un workflow como a la ejecución de la tarea de inicio del workflow, podemos simplificar el trabajo de diseño y presentar a los usuarios un comportamiento más consistente. Por lo tanto el inicio de un workflow pasará a desarrollarse como la ejecución de una tarea de inicio, con sus correspondientes propiedades, contenido de información e interfase de usuario.

Las tareas, son la unidad básica de los procesos y workflows, son los átomos de los procesos y para que puedan ser desempeñadas los usuarios deben tener acceso a sus listas de tareas (work list), las cuales deben presentarse ordenadas de acuerdo al criterio de prioridades de la organización. Estas tareas deberán tener una interfase amigable mediante la cual el usuario pueda completar la misma (ya sea una interfase generada por el sistema de workflow en forma automática, diseñada por el usuario con las herramientas que provea el sistema de workflow o diseñada totalmente fuera del sistema e interactuando con el mismo por medio de las interfases que este provea).

El acceso de un usuario a una tarea puede darse pro-activamente, en una modalidad por la cual el usuario accede a una pantalla de consulta donde visualiza su lista de tareas pendientes y las novedades o tareas nuevas. O puede darse en forma reactiva, donde la tarea se entrega directamente al usuario por medio de un correo electrónico o un mensaje instantáneo, reaccionando el usuario a la tarea que le llega directamente a su bandeja de entrada de correo y muchas veces, realizando la misma desde dentro del propio correo electrónico.

Cuando un usuario accede a la información de un workflow, dependiendo de los criterios de seguridad establecidos y al perfil de seguridad con que accede al mismo, el usuario accederá a diversos niveles de detalle o contenidos de información del workflow (dados dos usuarios con idénticos permisos en el sistema y un workflow que ha sido iniciado por uno de ellos o en el que uno de ellos ha participado del mismo en alguna tarea, se espera que este usuario tenga mayores posibilidades de visualización de la información o toma de acciones sobre el proceso que el otro).

Las formas de visualizar un workflow son:

-       Grafo de ejecución: Es el grafo del proceso, con clara indicación de cómo se han ejecutado las tareas, cuales tareas están en ejecución, etcétera. Esta es la vista generalmente mas utilizada, porque de un vistazo permite ver el estado del proceso (además de ser la única vista que permite visualizar que tareas faltan para completar el mismo) y generalmente, haciendo clic sobre las tareas permite visualizar el contenido o resultado de las mismas (En casos tales como una tarea que implica la ejecución de un proceso subordinado, generalmente permite navegar al subproceso).

-       Seguimiento: Es una lista de tareas ejecutadas o en ejecución, con detalles de tiempo de asignación, ejecución, interacciones con el sistema, etc.

-       Vistas personalizadas: Básicamente son vistas o formularios diseñadas por los diseñadores del proceso en el cual se visualiza la información del proceso en forma totalmente personalizada (En aquellos procesos que están centrados en el ciclo de vida de un formulario, es utilizado el mismo formulario como vista personalizada).

-       Documentos Adjuntos: Es una vista de todos los documentos anexados al workflow (generalmente acompañados por la historia de versiones y de modificaciones de los mismos)

-       Roles: Es una vista de los roles propios del proceso y de quienes los están desempeñando en esta instancia o workflow (generalmente se permite visualizar la historia de modificaciones de los roles desde esta vista).

-       Datos: Esta es una vista avanzada, generalmente utilizada para diagnóstico o análisis del proceso y en la misma se presenta todo el contenido de los datos relevantes del workflow y la historia de modificaciones.

-       Generalidades: Una vista resumen, con información general del inicio, versión del proceso, vencimientos globales, etc.

Las listas de tareas deben ser presentadas a los usuarios teniendo en cuenta dos aspectos diferentes:

-       En primer lugar, la asignación de la misma, para lo cual presentaremos al menos:

o    Una lista de tareas asignadas al usuario.

o    Una lista de las tareas que están en colas de trabajo en las cuales el usuario participa y las cuales están disponibles para que el usuario se las auto-asigne.

-       En segundo lugar, las tareas por las cuales el usuario es responsable en forma indirecta (ya sea porque tiene un rol de responsabilidad sobre el proceso o sobre el usuario que está desempeñando dicha tarea). En este caso debemos presentar al usuario:

o    Listas de tareas ordenadas por prioridad.

o    Listas de tareas ordenadas o filtradas por estado (una tarea podrá tener muchos estados, analizaremos el tema en el capítulo de diseño, pero básicamente las tareas estarán en distinto estado de avance (no iniciada, en progreso o finalizada) y en distinto estado de escalamiento con respecto al diseño del proceso (en espera, el sistema ha disparado un recordatorio al usuario, el sistema ha disparado una alerta a un supervisor, el sistema ha realizado un delegación automática de la tarea por vencimiento o la tarea está fuera de tiempo y atrasando la finalización del proceso).

o    Gráficos de torta distribuyendo las tareas por prioridad o por usuario asignado a la misma, que permitan rápidamente ver el estado general de las tareas por las cuales el usuario es responsable.

Las listas de workflows, deben ser presentadas a los usuarios, respetando criterios de seguridad, de acuerdo a los siguientes criterios de selección y agrupamiento:

-       Los estados básicos de un workflow son cuatro: Ejecutando, suspendido (administrativamente), en error o finalizado. Para cada estado de los workflows de un mismo proceso, debe existir una forma sencilla de acceder a la lista completa de workflows (Por Ejemplo, las órdenes de compra en proceso).

-       Aplicando los criterios de estado de las tareas, se deben presentar  listas de workflows por estado.

-       Para que la interfase de acceso a las listas de workflows sea totalmente amigable al usuario se deben agregar los siguientes criterios:

o    Criterios de búsqueda o de filtro tipo “pattern matching”

o    Listas armadas de acuerdo a los criterios de necesidad de información, donde se define los criterios de filtrado, el alcance de la selección y las columnas que se incluirán en la lista. (este punto merecerá especial atención en el capítulo 8 ya que es un lugar donde se puede explotar toda la potencia de un sistema informático brindando a los usuarios una solución muy flexible y con una cobertura muy amplia de sus necesidades de información).

Área: Integración con los sistemas de la organización.

Un sistema de workflow es, en sí, el integrador final de los procesos de la organización. Continuando con un tema que ya abordamos superficialmente en el comienzo de este capítulo, los sistemas de gestión tienen generalmente mucho workflow escondido dentro de ellos y es impensable implementar procesos de negocio en la organización que sean una isla sin contacto con los sistemas de información de la organización.

Hoy en día, la gran estrategia de integración se basa en los Web Services y si bien una herramienta de workflow no tiene que tener obligatoriamente una estrategia de EAI (integración de aplicaciones de la empresa), es necesario que al menos tenga algunas capacidades de integración con las tecnologías de base más comunes y en particular con los Web Services, quienes se presentan como el mecanismo estándar de interoperabilidad entre Sistemas de diverso tipo, implementados sobre diversas plataformas.

Las necesidades de integración con los sistemas de la organización que se identifica claramente, son las siguientes (*descartamos aquí la integración de seguridad, porque ya fue tratada en un apartado específico*):

-       Integración de datos:

o    Necesidad de integrarse con las fuentes de datos de la organización, de forma que al realizar un ingreso de datos en una pantalla (o formulario de una actividad) sea posible extraer, consultar y validar los datos contra las diversas fuentes de datos o sistemas de la organización.

o    Necesidad de publicar la información estructurada contenida en los workflows, así como la información relativa a la ejecución de los procesos en las fuentes de datos de la organización o en las herramientas de análisis de la misma (por ejemplo, aportar información a la datawarehouse corporativa o  a un business scorecard).

-       Integración Funcional

o    Necesidad de integrarse a nivel de transacciones implementando:

§  La conexión de workflows con transacciones del sistema externo, de modo que los procesos puedan conectarse con transacciones de los sistemas de información de la organización y que sea disparado un workflow automáticamente al producirse determinadas transacciones monitoreadas (por ejemplo, cuando en el ERP se de de alta un nuevo funcionario, iniciar un proceso para gestionar la creación de cuentas de correo y acceso a los sistemas, entrega de los materiales de oficina, creación de tarjeta de acceso, y entrega de copia de los manuales de procedimiento de la organización al nuevo funcionario).

§  La inclusión dentro del diseño de los procesos de transacciones que serán ejecutadas por los sistemas de información de la organización (cuando se termina de gestionar un reclamo, ingresar automáticamente una nota de crédito en el sistema de gestión).

§  La liberación de tareas al ejecutarse una transacción en un sistema de gestión de la organización (esperar una confirmación de pago de una factura para liberar un proceso de entrega). Si bien esta tarea se puede considerar como la recepción y el procesamiento de eventos de un sistema externo, existe cierta capacidad "transaccional" que hay que darle a este intercambio, al menos, en la forma de mensajería confiable (entrega segura, no duplicación ,etc). Analizaremos mas adelante las posibilidades tecnológicas de esta implementación.

o    Disponibilizar las funciones de inicio y cancelación de workflow y completado de actividades a través hacia los sistemas de la organización, sobre diversas tecnologías, en especial, sobre web services como mecanismo predilecto de comunicación entre procesos.

-       Integración de portal

o    Integrar la administración de workflows y el manejo de worklists con la estrategia de portal de la organización, do forma de que el workflow se integre con la visión estandarizada que tienen los usuarios de los sistemas de su organización.

-       Adicionalmente puede definirse una integración para utilizar el sistema externo como repositorio de documentos, de forma de integrar los documentos del workflow a la estrategia de gestión del conocimiento de la organización, catalogando y controlando el ciclo de vida de esos documentos dentro del workflow pero compartiendo el acceso a los mismos.

A partir de estas necesidades, se define un conjunto de interfases sobre las cuales implementar conectores con sistemas o tecnologías específicas. Analizaremos en detalle estas opciones en el capítulo 9.

Un especial análisis requiere la integración del sistema de workflow consigo mismo, es decir, el diálogo entre “workflows”. A nivel de sistemas de workflow, se pueden encontrar diversos niveles de integración entre workflows, los cuales vamos a dividir en 3 niveles.

-       Nivel 1: básico

o    Capacidad de iniciar workflows por medio de una actividad, pasando datos y documentos al workflow hijo.

o    Capacidad de esperar en la actividad de inicio a que el workflow hijo termine y devuelva información (documentos y datos) al workflow padre antes de pasar a la siguiente actividad.

-       Nivel 2: avanzado

o    Capacidad de ejecutar en paralelo con sincronización, donde un workflow es disparado en una actividad y en una actividad posterior, del workflow padre, se espera por la finalización o por un punto de sincronización del workflow hijo.

o    Capacidad de ejecutar en paralelo con sincronización, donde un workflow es disparado en una actividad y en una actividad posterior, del workflow hijo, se espera por un punto de sincronización del workflow padre.

-       Nivel 3: integrado

o    Existe el concepto de paquete, definido tal como lo hace la WFMC, considerando al paquete como un contenedor de diseños de procesos, que a su vez puede contener otros paquetes y además se ha dado al sistema la capacidad de definir datos relevantes para la toma de decisiones del proceso, roles, validaciones y eventos a nivel del paquete, aplicando a todos los procesos que se encuentran por debajo de este paquete en la jerarquía. De esta forma, contabilizar un valor común a varios procesos, definir un parámetro, etc., se reduce a definir un dato de aplicación en un paquete que contenga a ambos procesos.

Área: Manejo de documentos.

El manejo de documentos es un área típica de integración, donde, de acuerdo al porte del sistema a implementar se debe seleccionar una solución externa de manejo de documentos o implementar una solución con las prestaciones básicas, como puede serlo una solución implementada sobre el propio sistema de archivos del sistema operativo.  Durante el año 2004 se dio la estabilización y el crecimiento de Windows 2003 Sharepoint Services y en el año 2007, llegó la versión 2007 de los Sharepoint services, los cuales son el principio del fin para la necesidad de utilizar el sistema de archivos del sistema operativo como una alternativa económica a una solución de almacenamiento documental, ya que proveen como una funcionalidad estándar del sistema operativo todo lo que una empresa pequeña puede necesitar en materia de manejo de documentos.

Indudablemente, los sistemas de workflows deberán manejar información no estructurada (documentos) en casi cualquier proceso a sistematizar. Los usuarios, interactuando con el sistema, deberán ser capaces de leer, editar y/o crear nuevos documentos.

En esta etapa del diseño, debe aplicarse la regla de reutilizar las tecnologías existentes y proveer diversos niveles de integración con las diversas tecnologías. Para esto debe definirse el concepto de almacenamiento y clase de almacenamiento. Cada clase de almacenamiento definirá los elementos que implementan dicha funcionalidad (por ejemplo las clases .net que implementan la funcionalidad del tipo de almacenamiento) y los niveles de funcionalidad soportados por el mismo (o la sinterfases que implementa).

Definiremos 4 niveles básicos de funcionalidad:

-       Nivel 0:

o    Funciones para agregar, recuperar, chequear existencia y borrar documentos.

-       Nivel 1

o    Nivel 0 +

o    Funciones para manejo de carpetas

o    Funciones para manejo de documentos (renombrar, copiar, mover, contar)

-       Nivel 2

o    Nivel 1 +

o    Funciones para manejo de versiones (proteger, desproteger, deshacer desprotección, publicar, volver a versión anterior, listar historia de cambios, recuperar versión anterior)

-       Nivel 3

o    Nivel 2 +

o    Manejar Referencias a los documentos.

o    Funciones para mapeo de propiedades de los documentos con datos relevantes del proceso.

Los requerimientos básicos de manejo de información no estructurada, de cualquier sistema de workflow medianamente adecuado están entre el nivel 2 y 3, ya que es muy importante poder realizar tareas de edición de documentos como parte del proceso y en cualquier organización donde se tenga una verdadera estrategia de manejo del conocimiento se debe poder acceder a los documentos producidos en los procesos por fuera de los procesos en si, esto implica que el sistema de workflow no solo debe poner a disposición de la organización los documentos que en el se han generado, editado o anexado, sino que además debe poder colocarlos en el lugar adecuado (generar una estructura de carpetas o seleccionar una biblioteca de documentos en base a la información propia del proceso) y catalogarlos adecuadamente (conectando datos relevantes del proceso con propiedades de los documentos, manejadas por el repositorio de documentos (o solución documental).

Analizaremos en detalle el manejo de documentos en un capítulo específico.

Área: Enfoque global del sistema.

El aspecto global del sistema es uno de los más interesantes en la etapa de crecimiento de un sistema de workflow. En la actualidad, las herramientas de desarrollo de la tecnología .net de Microsoft ofrecen una buena estrategia para la creación de aplicaciones globales, pero lo más importante es saber cuales son estos aspectos globales a tener en cuenta.

En primer lugar, un sistema de workflow pensado para personas que trabajan en diversos países, implica un sistema de workflow para personas que se encuentran en diversos husos horarios y el tiempo es un factor clave en este tipo de sistema.  Por lo tanto, cuando definimos a un usuario del sistema, le asociaremos a un calendario que va mucho más allá de especificar los horarios de trabajo y descanso, los días laborables o no laborables. Este calendario deberá especificar el huso horario donde se aplica dicho calendario. Así, para una tarea despachada a las 9:15 de la mañana, con un recordatorio automático a las 2 horas, asignada a un usuario que está en un uso horario atrasado 3 horas con respecto al huso horario del lugar donde se dispara la tarea, y que cumple funciones en horario continuo de 9 a 17hs, deberá recibir el recordatorio a las 14:00hs del primer sitio (que es también a las 11hs del lugar donde se encuentra el usuario).

El razonamiento puede parecer extraño, pero introduje los 15 minutos iniciales para explicar el concepto de horas laborales y horas no laborales. Pasemos los horarios a tiempos del lugar donde el usuario desempeña sus tareas.

-       La tarea es despachada a las 6:15 de la mañana (9:15 del sitio de inicio)

-       El usuario ingresa a trabajar a las 9:00 de la mañana. (12:00 del sitio de inicio)

-       A las 11:00 de la mañana se ha cumplido el plazo de 2 horas laborables y se dispara el recordatorio. (14:00 del sitio de inicio).

En general, los sistemas mas avanzados implementan horarios de trabajo y descanso, calendarios, husos horarios y vencimientos que se aplican o que escapan al control de los calendarios. Especificada la regla, trabajemos sobre las excepciones; Como secuencia de escape a la flexibilidad de los calendarios, dejaremos que los vencimientos expresados en minutos escapen al control de los mismos, de forma de poder soportar aquellas tareas que aunque entren 1 minuto antes de cerrar o de salir a almorzar, una vez que entra, tenemos que realizarla en tiempo, extendiendo o modificando la jornada laboral (el cliente entra a la tienda antes de que cierre y hay que atenderlo antes de completar el cierre).

En segundo lugar, es el manejo de interfases en múltiples idiomas. Para esto, en un nivel básico, el sistema deberá tener ejecutables únicos y archivos que contengan los contenidos en los diversos idiomas. Sobre todo en un sistema global no es posible manejar ejecutables distintos para los diversos idiomas que se implementen, ya que es extremadamente difícil mantener la coherencia del mismo con distintos ejecutables operando sobre el sistema. Esta parte del sistema es en general algo que no merece mucha detención ni análisis, pero nos abre una puerta de discusión a la parte más interesante del manejo de múltiples idiomas. Un sistema de workflow es básicamente una herramienta para construir sistemas para las organizaciones y en ese contexto, el sistema de workflow debe dar prestaciones de manejo de múltiples lenguajes, para que las interfases visuales que construyan los usuarios soporten el uso o la explotación de las mismas en diferentes idiomas. Si bien las organizaciones multinacionales manejan generalmente un lenguaje corporativo, es extremadamente importante brindar esta facilidad, ya que los sistemas de workflow llegan generalmente a todos los miembros de la organización (y muchas veces cruzan la frontera de esta hacia proveedores o clientes finales) y no puede ser una exigencia para estos el manejar el lenguaje corporativo, así como tampoco es una opción el tener islas de procesos en cada país. Por lo tanto, el sistema deberá asociar a los usuarios los elementos de información necesarios para determinar en que idioma se le presentan las interfases visuales y en la etapa de diseño o de puesta en producción deberá posibilitar la carga de los elementos de información necesarios (traducciones) para dar soporte al manejo de contenido con múltiples lenguajes (por ejemplo, el asunto de un mensaje o de una tarea debe estar descrito en todos los idiomas en que sea necesario de acuerdo a los idiomas de los potenciales usuarios de dicha tarea).

El otro elemento importante en una aplicación global es un elemento más viejo y conocido, pero que no deja de ser relevante a esta hora. El concepto de almacenar los elementos en su forma canónica (guardar un número en una representación numérica y no como una cadena de caracteres numéricos) y de tener la capacidad en momentos de presentar la información o de editar la misma, de respetar los formatos que tiene definidos el usuario en el sistema que está utilizando o, en el caso de reportes y otros elementos visuales (por ejemplo la generación de un documento Word enviado por mail), respetar los formatos que tiene seleccionados el usuario para el manejo de números, fechas, etc.

Analizaremos en detalle el enfoque global del sistema en el capítulo 12

Área: Análisis de la información.

Como analizáramos en el capítulo 1, hay diversos público-objetivo para la información que debe devolver el sistema de workflow y debe existir una estrategia precisa, destinada a cada uno de los consumidores de dicha información.

Para los usuarios, se les debe dar una forma sencilla de consultar la información, de encontrar los procesos, de visualizar sus listas de tareas y de interactuar con las tareas.

Para los mandos medios se debe dar información general por estado de las tareas y proceso y detalles de acumulación y desenvolvimiento de las personas que ellos supervisan directamente.

Por último, quizás la parte mas rica del proceso de análisis de la información es la de alimentar los tableros de control de la organización y la de brindar rica información de análisis, que pueda ser manipulada con una herramienta especializada que permita partir de niveles de alta abstracción y llegar a las tareas particulares que conformaron esos datos. Esto es, claramente, el utilizar una herramienta OLAP para analizar el desempeño de los procesos.  Para realizar esto, debemos pedir al sistema de workflow que nos genere las estructuras de análisis de la información y que provea los elementos que un sistema externo no puede calcular (tales como tiempos netos laborables insumidos en el desempeño de cada tarea y otros).

Un proceso automatizado con tecnologías de workflow, podrá fácilmente generar una estructura de análisis multidimensional llamada esquema estrella, en el cual una tabla central o tabla de hechos (Fact-table) contiene la información de las tareas realizadas en el proceso y en la cual se definen un conjunto de dimensiones y medidas a saber:

-       Las dimensiones de tiempo, donde se marca cuando se hizo cada tarea y cuando se inició y terminó el proceso.

-       Las dimensiones basadas en las estructuras de datos propias del sistema de workflow.

o    Los usuarios y la jerarquía funcional.

o    Los distintos tipos de tarea del sistema.

o    Dimensiones basadas en los hitos del proceso.

o    Dimensión de niveles de alertas y escalamiento.

-       Las dimensiones basadas en datos relevantes del workflow.

o    Dimensiones sobre datos de toma de decisión (ej. moneda, País/región/sucursal, etcétera)

-       Medidas

o    Tiempos netos en horas de trabajo de cada tarea.

o    Tiempos netos en horas de trabajo con solapamiento y encolado.

o    Tiempos brutos en horas de trabajo de cada tarea.

o    Cantidades de tareas realizadas

o    Cantidades de tareas abiertas.

o    Medidas basadas en datos relevantes del workflow de tipo numérico. (ejemplo: Importe Total, Sobregiro).

o    Desviaciones sobre los tiempos previstos en el diseño.

o    Cantidades de alertas disparadas.

Analizaremos en detalle el análisis de la información en el capítulo 13

Área: El Motor de Workflow  (las interfases y el diseño a bajo nivel)

El corazón del sistema de workflow se puede dividir en dos grandes partes. Una parte encargada de realizar las operaciones o transacciones propias del sistema de workflow y otra (a la cual podríamos llamar la maquina de estados y transiciones) que es la que se encarga de interpretar la definición del proceso de negocio y ejecutar las actividades y transiciones definidas en el.

Los grandes elementos que tenemos como entrada, para trabajar en el diseño, son las interfases definidas por la Workflow Management Coalition (WFMC) y el XMLPDL y WF'XML (definidos por la WFMC), el BPEL4WS 2.0 (estándar de orquestación de procasos basados en Web Services), el XAML definido por Microsoft y los patrones de workflow definidos en YAWL (Yet Another Workflow Language). Estos son los elementos públicos que pueden reconocerse como los estándares existentes y relevantes en lo que respecta a la materia Workflow. (Al momento de publicar este capítulo, esoty trabajando mi tesis de maestría alrededor de estos estándares). Si bien estos son una base de diseño importante, en pos de alcanzar un nivel de prestaciones adecuadas, cada sistema de workflow debe implementar una importante evolución de esas interfases y patrones para poder competir con el universo de productos que existen hoy en día en el mercado. Los detalles “técnicos” (la arquitectura) del sistema, tanto como el análisis detallado de estos estándares, merecen un capítulo entero para su adecuado análisis. Así que este será el tema del próximo capítulo.

Muchas de las presentaciones se encuentran en formato PPTX, por lo cual si Ud dispone de una versión anterior de Office, puede agregarle a la misma la capacidad de abrir y guardar en este nuevo formato de documentos bajando el siguiente agregado: https://www.microsoft.com/downloads/details.aspx?FamilyId=941B3470-3AE9-4AEE-8F43-C6BB74CD1466&displaylang=en

Todas las presentaciones están disponibles en esta carpeta de acceso público en mi SkyDrive: https://cid-ab9876f1cda024c9.skydrive.live.com/browse.aspx/PPTs%20de%20Presentaciones

Comencemos por identificar el concepto de Workflow como algo no nuevo, sino como algo implícito en mayor o en menor medida en muchos sistemas informáticos. Habitualmente, los sistemas de gestión de las organizaciones dan el soporte administrativo a las tareas que se desarrollan dentro de las mismas, escondiendo los procesos dentro del código de los sistemas informáticos. El nivel de dinamismo de una empresa moderna hace que los sistemas basados en la tecnología tradicional tengan un muy alto costo de mantenimiento (y de desarrollo), ya que el tener que recurrir a la codificación para ajustar los mismos a sus cambios operativos, hace que esta tarea sea no solo costosa, sino también lenta y difícil.

Por otro lado, este ocultamiento de los procesos en los sistemas de gestión hace que los usuarios tengan poco conocimiento de que la tarea que están realizando es parte de un proceso definido de la organización; que esta tiene un contexto mas amplio del que pueden percibir del sistema y que existe un objetivo final del proceso, con estándares de calidad o cumplimiento globales, mas allá de la tarea particular.

La solución a este problema, pasa por atomizar las diversas tareas procesadas en la organización y conectarlas en un proceso que sea claro para los usuarios y fácil de modelar (y gestionar) para la organización. La tecnología que hace esto posible, es la tecnología de Workflow.

Definiciones

En primer lugar, cabe definir el concepto de Workflow, para lo cual recurriremos a las referencias obligadas en la materia.

Según la WFMC (Workflow Management Coalition), se define proceso como: "Un conjunto de uno o más procedimientos o actividades directamente ligadas, que colectivamente realizan un objetivo del negocio, normalmente dentro del contexto de una estructura organizacional que define roles funcionales y relaciones entre los mismos."

Y se define Workflow como: "Workflow implica la automatización de procedimientos organizacionales donde tareas, documentos e información son pasados de un participante a otro de acuerdo a un conjunto definido de reglas para alcanzar o contribuir a alcanzar un objetivo de la organización".

Una síntesis habitual de las definiciones anteriores es la que define Workflow como: "Un conjunto de tareas realizadas por dos o más miembros de una organización para alcanzar un objetivo común".

En resumen, podemos definir Workflow como: El área de la informática que trata de la automatización de los procesos empresariales que involucran secuencias de tareas bien definidas, ejecutadas por personas o sistemas.

En esencia, Workflow implica procesos de la organización bien definidos, un sistema informático para modelar esas reglas de negocio y un agente "invisible" que hace que esos procesos se desarrollen de acuerdo a lo especificado.

Ventajas competitivas.

En la actualidad, las organizaciones están inmersas no solo en un mundo globalizado, sino en un mundo extremadamente competitivo, en el cual las ventajas que provienen de la excelencia operacional se obtienen y sostienen en 3 grandes frentes:

Sea cual sea el período de tiempo que usemos para medir la “cantidad” de decisiones tomadas, la primer diferencia la establece la toma de decisiones estratégicas de la alta dirección. Esta debe mantenerse centrada en tomar muy pocas decisiones, pero de alto contenido estratégico. Aquí es donde un sistema de Workflow debe establecer la fundación para que el diseño de los procesos y la ejecución de los mismos genere, a partir de la ejecución de los procesos centrales de negocio y sin un esfuerzo adicional importante, las Data Marts (pequeñas Data Warehouses) que posibiliten una toma de decisión efectiva, basada en información de la operativa de negocios de la organización, obtenida de los propios procesos de negocios. El sistema de workflow debe contribuir al tablero de control de los directores con un reducido conjunto de indicadores de gestión de los procesos de la organización (cantidades, tiempos, desviaciones y tendencias).

La segunda diferencia, la establece la pro-actividad de los mandos medios, su capacidad para planificar y ejecutar, para aprender y retro-alimentar al proceso y a las personas que trabajan en el. Un sistema de Workflow debe interactuar constantemente con los mandos medios (gerentes y supervisores) escalando a ellos las excepciones y desviaciones y brindándoles información de supervisión concerniente a distribución y carga del trabajo, desempeño de sus subordinados y de los procesos que les atañen. Aún más, los sistemas de Workflow posibilitan la aparición de responsables o administradores del proceso y no de los funcionarios en particular, ocupándose estas personas de la excelencia operativa del proceso y de los participantes del mismo (solo como participantes del Workflow y no con una relación de dependencia funcional-jerárquica). La información a estos usuarios no solo debe llegarle como excepciones y alertas, sino que deben tener un lugar donde visualizar las cargas, desempeños y estadísticas de los elementos que les conciernen (llámese tablero de control o similar)  donde un simple vistazo les permita identificar los problemas potenciales (sobrecarga de un usuario, etc.) y tomar las acciones correctivas correspondientes en el momento (re-asignar trabajo, cambiar prioridades, interactuar con los actores, etc.). Los procesos implementados con sistemas de Workflow están diseñados para actuar automáticamente sobre las desviaciones, minimizando el impacto de estas, pero la adecuada información y facilidad de gestión al alcance de un mando medio, puede hacer que las correcciones sean realizadas antes de que se produzcan las desviaciones y es en esos casos donde la organización se aproxima a la excelencia operativa.

Por último, la automatización del gran volumen de tareas. A los usuarios que realmente participan en la parte productiva del proceso (ya sea al funcionario de la organización, de otra organización o el cliente mismo) un sistema de Workflow les da una lista de tareas, ordenadas por prioridad (ordenadas de acuerdo al criterio de importancia de la organización y no del propio funcionario), conteniendo cada una de ellas el contexto de información necesario para realizar la misma, o sea el conocimiento organizacional que se necesite para realizarla (ya sean procedimientos del sistema de calidad de la organización, documentos que deben ser evaluados en esa tarea o simplemente datos extraídos de sistemas informáticos o de tareas anteriores).

En los conceptos que estamos manejando, salta a la vista un concepto muy importante y el cual sea, quizás, el factor más importante de la implementación de una solución de Workflow. En los ítems anteriores analizábamos las necesidades de información de los diferentes actores de la organización, pero; ¿Como es posible cubrir estas necesidades sin un proceso que orqueste, coordine y unifique todas las tareas relacionadas con el objetivo de negocios sobre el cual queremos obtener información? ¿Es posible obtener nuestros requerimientos de información de un proceso donde el soporte de información del mismo se encuentra distribuido en diversos sistemas informáticos, planillas electrónicas y hasta planillas en papel? Es ese aspecto unificador del Workflow, en una visión de proceso único, el que permite a la organización obtener la información que necesita para lograr una excelencia operacional.

El Factor Tiempo

La implementación de un sistema de Workflow, como la de cualquier sistema informático que se implementa en una organización, busca básicamente, reducir costos operativos y generar valor para la organización (mejor información, más adaptabilidad a los cambios, mejor servicio, etcétera). El efecto más notable en una automatización de procesos con tecnologías de Workflow es el producido en los tiempos de ejecución de los procesos de la organización.

Es comúnmente aceptado que del tiempo total que demora para completarse un típico proceso de proceso no automatizado, un 90% del mismo, es lo que llamamos tiempo de transferencia. Este tiempo de transferencia está compuesto por dos factores fundamentales.

Tiempo de Transferencia = Tiempo de entrega del trabajo + tiempo en cola hasta que es iniciado por el siguiente funcionario.

El primer factor, es prácticamente reducido a cero por un sistema de Workflow, ya que al confirmarse una tarea, el motor de Workflow demorará un tiempo insignificante en hacer la entrega o asignación de la próxima tarea.

El segundo componente, que es el tiempo que las tareas listas para ser realizadas y ya entregadas a los usuarios, demoran en ser iniciadas (normalmente por interferencia, o sea porque el usuario está realizando otras tareas) es abordado de diferentes maneras:

-       Al tener una lista de tareas, ordenadas por prioridad, se produce el efecto de que la decisión general (o sugerencia) de que tarea realizar primero la hace la organización en base a las necesidad globales o compromisos asumidos y no el funcionario.

-       Los supervisores pueden controlar la carga de trabajo de los funcionarios y trabajar sobre esta, realizando delegaciones o re-asignaciones. El aporte de los supervisores es realmente trascendente en la reducción del tiempo de ejecución del proceso.

-       El sistema normalmente provee mecanismos de balance de carga, los cuales mitigan el efecto de interferencia, haciendo una selección basada en determinado criterio, aplicado por el balanceador de carga. Algunos ejemplos de estos son:

o    Colas de trabajo sin moderador (las personas se auto-signan el trabajo en forma pro-activa).

o    Colas de trabajo moderadas (un moderador asigna el trabajo, es una asignación indirecta).

o    Round Robin. Se asigna una tarea a cada uno de los miembros de un grupo, implementando una cola circular (una a cada uno y luego iniciamos de nuevo el ciclo).

o    Menor Carga. El sistema asigna la tarea al miembro de grupo que tiene menos tareas pendientes.

-       Todo sistema de Workflow debe proveer al  menos 3 niveles de escalamiento de las tareas:

o    Recordatorio: Un aviso al usuario recordándole que tiene una tarea pendiente.

o    Alerta: Un aviso al responsable del proceso o del usuario, avisando que una tarea se está retrazando.

o    Vencimiento: Una acción preparada en el diseño propio del proceso para activarse cuando la tarea no se realiza dentro de los plazos planeados (consultar con un responsable, delegar la tarea a otro usuario, etc.).

-       Por último, aunque se esté haciendo una simple automatización del proceso, normalmente hay un rediseño del mismo, ya que la realidad electrónica hace que la información sea ubicua y que se puedan realizar tareas en paralelo o en simultáneo (es decir, enviar la tarea a dos o mas personas y darla por concluida cuando cierto número de personas la finalicen, realizar diversos trabajos al mismo tiempo, etc.). Esto tiene normalmente un efecto muy importante en el tiempo de ejecución de los procesos.

El efecto que causa un sistema de Workflow en los tiempos de ejecución de un  proceso lo podríamos graficar de la siguiente manera.

Después de implementada la automatización de un proceso, tenemos un verdadero tiempo medio de ejecución del proceso con una desviación normalmente consistente entre el promedio menos 3 desviaciones estándar y el promedio mas 3 desviaciones estándar.

Las Desviaciones.

Estos tiempos normalizados son una muy rica fuente de análisis de los problemas en el proceso y de predicción de futuros problemas. Aplicando a estos tiempos las reglas del análisis estadístico, controlaremos en detalle la ejecución de los procesos cuando:

-       El tiempo de una de los procesos caiga fuera del intervalo ( promedio de tiempos – 3 desviaciones estándar y promedio de los tiempos + 3 desviaciones estándar)

-       Cuando 3 puntos consecutivos (tiempos de los procesos), se sitúen en el intervalo comprendido entre promedio de tiempos + 2 desviaciones estándar y promedio de tiempos + 3 desviaciones estándar o en el intervalo promedio de tiempos - 2 desviaciones estándar y promedio de tiempos - 3 desviaciones estándar.

-       Cuando 5 puntos consecutivos se sitúen en el intervalo comprendido entre promedio de tiempos + 1 desviación estándar y promedio de tiempos + 3 desviaciones estándar o en el intervalo promedio de tiempos - 1 desviación estándar y promedio de tiempos - 3 desviaciones estándar.

-       Cuando 7 puntos consecutivos caigan del mismo lado de la gráfica dividida por línea del promedio de los tiempos.

El análisis de estas desviaciones no solo nos permite detectar tareas que se están realizando mal (tareas que por realizarse mal provocan demoras, rechazos, equipos que necesitan ajustes o mantenimiento, funcionarios que necesitan capacitación), sino que hasta las desviaciones “positivas”, o sea aquellas que a priori muestran un desempeño mejor que el habitual, pueden ser indicativos de controles de calidad que se han dejado de aplicar o procedimientos que se están salteando o que no se realizan debidamente.

El Proceso de “mejora continua”.

A partir de cierto momento, el impacto de la reducción de tiempos por la implementación de un sistema de Workflow cae en una meseta (producto de que ya la organización ha madurado en el uso de la tecnología y se ha adaptado a los cambios operativos, obteniendo los funcionarios y los mandos medios la experiencia necesaria en el aprovechamiento de las bondades de la tecnología). Este es el momento apropiado para empezar un proceso de mejora continua, generando nuevas versiones de los procesos automatizados, ingresando la organización en una dinámica de excelencia operacional.

Podemos definir un proceso genérico de mejora continua como un ciclo compuesto de las siguientes etapas:

-       Definición de Alcance y Objetivos (Establecer y priorizar los objetivos que se quieren alcanzar en el ciclo de mejora).

-       Definición de  Métricas (Establecer las métricas que se necesitarán para medir la evolución del proceso en relación con los objetivos especificados).

-       Establecimiento de una línea base (Realizar las mediciones iniciales de las métricas establecidas, para usarlas como base de comparación y referencia de la evolución del proceso).

-       Aproximación Táctica.

o    Trabajar sobre el proceso (Esta es la etapa de laboratorio, donde debe aplicarse la experiencia, la imaginación y el conocimiento de los actores directamente involucrados en el proceso).

o    Medir y Comparar con la línea base (El efecto de todo cambio en el proceso debe ser medido y comparado con la medición inicial o línea de base. Esta comparación es la única medida válida del suceso o fracaso en el alcance de los objetivos).

Volver a Definir Alcance y Objetivos (No dejar nunca de trabajar sobre los procesos. Nunca debemos dejar que se vuelvan “viejos”, o que se conviertan en un freno a los cambios en la organización).

Esta pregunta me la he hecho muchas veces durante los últimos años, ya que mi pasado está muy ligado a construir soluciones y herramientas de Workflow y en este artículo intento transmitirles alguna de las formas en que con el tiempo, la implementación de WF, me ha llegado a convencer de que sus limitaciones no son tales.

Abordemos el que parece ser el problema mayor de la implementación, tomando como base los patrones de Workflow concebidos por las universidades de Eindhoven  (Eindhoven University of Technology) y de Queensland (Queensland University of Technology), las cuales han creado un repositorio de 43 patrones de Workflow (ver: https://www.workflowpatterns.com/), los cuales sirven para evaluar las capacidades de los diversos sistemas de Workflow.  (para los que deseen introducirse en el concepto de workflow, en esta página he publicado algunos conceptos básicos de workflow: https://blogs.msdn.com/pcgarcia/pages/capitulo-1-conceptos-de-workflow.aspx)

De estos patrones, voy a tomar dos que a primera vista aparecen como insalvables, los cuales son:   "Ciclos arbitrarios" y "Discriminador estructurado". La implementación de Workflow Foundation tiene dos restricciones que hacen imposible implementar estos patrones. La primera de ellas es que una actividad siempre está contenida en otra, por lo tanto, solo puede conectarse con su actividad madre, con sus hermanas y/o con sus hijas. La segunda restricción tiene que ver con que no existe el concepto de thread de ejecución en Workflow Foundation y si bien el concepto de "Execution Context" se le aproxima mucho, está sujeto a una limitación impuesta en el runtime y es que al finalizar una actividad, el runtime fuerza la finalización de todas sus actividades hijas, con lo cual, si queremos despachar la actividad que sigue a la actual, se cancelarán todas las actividades hijas de la actual que estén en estado de ejecución (el despachador no le dará ni oportunidad de ejecutar porque una actividad en estado de cancelación tiene prioridad en la cola de despacho sobre las que están esperando para ejecutar).

Bien, formalicemos un poco estos patrones y analicemos si existen equivalentes funcionales que nos permitan obtener las mismas prestaciones del motor de workflow a pesar de las restricciones descriptas.

Structured Discriminator (ver: https://www.workflowpatterns.com/patterns/control/advanced_branching/wcp9.php )

Este patrón se utiliza cuando tenemos una separación en hilos de ejecución paralelos (Split y Join) donde queremos que al llegar uno de los hilos de ejecución al join se active la tarea que prosigue al join y que las actividades que se encontraban pendientes de ejecución o activas en los demás hilos de ejecución continúen siendo ejecutadas en forma normal.

Podemos graficar esta operación de la siguiente manera:

Consideremos las Actividades en verde como actividades activadas (ejecutando) y las azules como ya terminadas. En esta secuencia se ilustra como ejecuta este patrón, donde luego de completarse la actividad A, se pasa por el join y se activa la actividad C, quedando activa la actividad B. Cuando la actividad B se termina, no se vuelve a activar la actividad C.

¿Cómo compatibilizamos este hecho con la aseveración anterior de que al terminar una actividad madre (por ejemplo, el Split-join) el motor de workflow foundation se asegura de que no quede ninguna actividad hija ejecutando?

Planteemos el caso inicial en un Workflow Secuencial de Workflow Foundation y veamos como lo podemos "Refactorizar" para obtener un funcionamiento equivalente al patrón presentado.

Aplicando una refactorización obtenemos el siguiente workflow:

Técnicamente, podemos implementar esta solución con un par de actividades custom, una de envío de la señal de sincronización y otra de espera por la señal, la cual puede estar basada en el uso del mecanismo de colas internas que posee Workflow Foundation y en  el uso de una propiedad con la cual hacer metadata binding de forma de asociar el destino de la señal enviada por las actividades SendSync con la actividad WaitforSync. El mecanismo de comunicación usado puede limitarse simplemente a crear una cola con el nombre de la actividad (el cual es clave dentro del workflow) en el método Initialize de la actividad WaitForSync y en cada una de las actividades SendSync simplemente introducir una novedad en la cola (no importa el contenido).

Si queremos llevar este patrón a una resolución gráfica que presente el mismo nivel de transparencia en el orden de ejecución de las actividades que presentan los mini-diagramas presentados anteriormente, tendremos que construir nuestra propia actividad "StructuredDiscriminatorActivity", la cual debe ser funcionalmente igual al proceso que acabamos de presentar, pero presentando un diseño gráfico compuesto de una actividad de ejecución en paralelo, donde colocar las actividades que se ejecutarán en paralelo con la capacidad de continuar ejecutando cuando uno de los hilos de  ejecución alcance el join, continuada por una actividad de secuencia, donde colocar la parte correspondiente al resto del workflow que continúa a posteriori del join. De esta forma, la actividad contenedora será una sola y al estar las actividades hijas contenidas en el mismo nivel, podremos mantener estas activas cuanto tiempo sea necesario.

Analicemos ahora un segundo patrón de workflow (quizás el más complicado de resolver con WF).

Arbitrary Cycles (ver: https://www.workflowpatterns.com/patterns/control/structural/wcp10.php )

Este patrón nos dice que dentro del flujo del proceso deben de poderse implementar conexiones que formen ciclos o bucles sin un constructor específico. Un ejemplo sencillo se ve de la siguiente forma:

En este ejemplo, se forman dos ciclos (B - C - D.Else) y (C - D - E - F.Else) los cuales están cruzados entre sí y la importancia de este patrón radica en lo simple que es construir un workflow sin tener que utilizar un constructor específico (si quieren una notación específica) para formar los ciclos.

Implementemos lo  mismo ahora con un workflow secuencial de Workflow Foundation.

Lograr la representación equivalente con el diseñador de workflow foundation sin caer en la tentación de repetir las actividades B y C es todo un desafío y con una simple mirada al workflow (que ya pierde mucho sentido de si) podemos imaginar lo que pasaría si apareciera otro bucle mezclado con los dos bucles identificados o si el workflow fuera un poco más complejo, bueno, mejor no imaginarlo siquiera.

Analicemos ahora si existe una forma alternativa de construir este workflow sin caer en la trampa de agregar tantos bucles. Hagamos de cuenta que el visual studio tiene un Refactoring llamado "Arbitrary Loop" que permite inyectar en una secuencia cualquiera de actividades un bucle arbitrario, respetando todos los cruzamientos que  se den entre los bucles definidos en el workflow. Sigamos el proceso de diseño:

1) Diseñemos el workflow inicial ignorando los loops y simplemente ingresando las actividades del tipo If-Then-Else y dejando indicado que en el Else debemos hacer un loop con determinada actividad.

2) Ahora, seleccionando el primer IF, apliquemos un "Refactoring" al que llamaremos "Arbitrary Loop", indicando que queremos hacer un loop con B. Si bien estamos haciendo algo que no es estrictamente un refactoring sino una transformación del workflow que conserva la lógica que hemos implementado en el workflow y que usando la salida por "Else" del condicional que tomamos como punto de partida del refactoring forma un loop con la acción seleccionada.
En este caso estamos aplicando un "Arbitrary Loop" de Eval.Else a B.

3) Y ahora nuevamente aplicamos el mismo refactoring, uniendo El Else de Eval1 con la actividad C, para lo cual deberemos fraccionar la secuencia B-C, ya que cuando la condición F sea falsa, vamos a necesitar hacer un bucle en el proceso a la actividad C, por lo cual deberemos saltear en la secuencia a B. El proceso refactorizado nos quedaría formado de la siguiente manera:

En este proceso tenemos un loop central que oficia de bucle maestro y en cada hilo o bifurcación de ejecución dentro del bucle se termina con una actividad Setxxxx que establece, a partir de ese punto del proceso, por donde se debe continuar al volverse atrás en el bucle, usándose bifurcaciones condicionales en cada punto de entrada para soportar los saltos representados en el proceso.

Nuevamente voy a abusar de la imaginación de Uds, pero el ejemplo presentado es claramente funcionalmente equivalente al problema planteado y nuevamente la solución para implementar bucles arbitrarios en workflow foundation pasa por construir un tipo de actividad bucles arbitrarios, que ejecute la secuencia de actividades de acuerdo al esquema presentado pero que presente al usuario una interfase gráfica similar a una secuencia pero con un menú contextual que permita conectar una rama de un condicional con una actividad de dicha secuencia. Gráficamente, creo que la solución mas simple es presentarlo así:

En este último Workflow, contenido dentro de una actividad del tipo arbitraryloop, se utilizan actividades del tipo LoopTo para indicar la formación de un loop arbitrario, es decir, cuando se alcancen las actividades LoopToC o LoopToB se pasará a ejecutar directamente la actividad C o B según corresponda.

Puede que este análisis les parezca rebuscado, puede que Uds piensen que estos patrones se utilizan muy poco en la realidad o puede que simplemente piensen que hay que eliminarle algunas restricciones al motor de workflow de WF para seguir un camino más simple, pero como conclusión, quisiera transmitirles mi convicción de que el camino para extender workflow foundation y para hacer y construir Sistemas de Workflow sobre Workflow Foundation (sistemas que implementen patrones avanzados de workflow y que permitan que un analista de procesos  cree directamente los procesos de negocios, trabajando en el nivel de abstracción adecuado) es solo cuestión de usar a fondo el propio sistema de extensibilidad del runtime de workflow foundation, es decir, crear actividades y servicios, claro está, algunas actividades serán "estructurales" y otras de dominio específico.