Capítulo 2 - Requerimientos funcionales de un Workfow Management System
Capítulo II – Requerimientos Funcionales.
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)
o Funciones para recepcionar asincrónicamente notificaciones de cambios en los documentos, desbloqueando operaciones pendientes en el workflow.
- 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.
o Funciones para recepcionar sincrónicamente notificaciones de cambios en los documentos, autorizando o cancelando las mismas de acuerdo al estado del workflow y a la identidad del usuario que origina el cambio.
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.
o Costos operativos (suponiendo que cargamos costos en las actividades o tareas).
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.
Comments
Anonymous
March 22, 2008
He publicado en este blog un nuevo capítulo sobre tecnología de workflow, pero debido al tamañoAnonymous
April 24, 2008
He publicado un nuevo capítulo sobre tecnología de workflow, "as usual", como un