Adaptive Workflow Management

Adaptive Workflow Management
Ing. Gonzalo Fernández

Agenda Por qué las empresas eligen Workflow?
Limitaciones de los Sistemas de Workflow tradicionales Clasificación de Sistemas de Workflow Sistemas de Workflow Adaptables Adaptabilidad en GXflow

Conceptos Básicos Business Process Process Definition
(i.e what is intended to happen ) Is defined in a Is managed by Process Definition Workflow Management System (a representation of what is intended to happen) (controls automated aspects of the business process via) Used to manage and create Sub-Processes Composed of Process Instances (a representation of what is actually happening) Activities Include one or more Which may be TERMINOLOGY All workflow systems are process oriented. A process definition, a representation of what should happen, is created, and it typically comprises some sub-processes. Thus, a business process might be to grant a new loan. This process would be split into sub processes such as reviewing the application for completeness and accuracy, executing a credit check, creating a new loan contract, sending it to the client, checking the form on its return, set-up of payment schedule, and finally issuing the check. Each process and sub-process comprises some activities. An activity is a single logical step in the process. Making a payment, or NOT making a payment is an activity. It is sometimes not practical to automate all activities during a single project. Therefore workflow executes automated activities whilst process definitions will describe all activities whether they are automatic or manual. For example, if the law states that contracts for loans must be signed in front of independent witnesses, then this might be the one manual activity within the whole process of granting a loan. When the process definition has been tested and put into production, instances of that process flow through the system. The process definition describes how a loan is granted by the company; the instance is actually granting a loan to a client. The instance of a process comprises of activity instances that will include workitems that are passed to an individual (or workflow participant, or user) for action, or to another process for action. So, a user might receive all documents relating to a loan, and he may be asked to approve the loan. Alternatively, the activity instance might invoke a query on a public credit checking system, and then take the result, measure it against pre-determined criteria, and pass to the next activity a binary result (APPROVED! or DECLINED!) Workflow terminology Before doing so we first introduce some standard workflow terminology. Workflow management systems are case-driven, i.e., they focus on a single process instance. This means that only business processes describing the handling of one workflow instance in isolation are supported. Many cases can be handled in parallel. However, from the viewpoint of the workflow management system these cases are logically independent. To handle each case, the workflow management system uses the corresponding workflow process definition. The process definition describes the routing of the case by specifying the ordering of activities. Activities are the logical units of work and correspond to atomic pieces of work, i.e., each activity is executed by one worker (or another type of resource) and the result is either ‘‘commit work’’ or ‘‘abort and roll back’’. To specify the ordering of activities typically some graphical language such as Petri nets or workflow graphs is used. These languages allow for sequential, conditional, and parallel routing of cases. Typically, an activity which is enabled for a given case may be executed by many workers, and many workers may execute a given activity. To support the distribution of work, the concept of a role is used. A worker can have multiple roles, but an activity has only one role. If activity A has role R, then only workers with role R are allowed to execute activities of type A. Based on this information, the workflow management system works as follows: The corresponding workflow process definition is instantiated for each new case, i.e., for each case (e.g., request for information, insurance claim, customs declaration, etc.) a new workflow instance is created. Based on the corresponding workflow process definition, the workflow engine calculates which activities are enabled for this case. For each enabled activity, one workitem is put in the in-tray of each worker having the appropriate role. Workers can pick workitems from their in-tray. By selecting a workitem the worker can start executing the corresponding activity, etc. Note that, although a workitem can appear in the in-tray of many workers, only one worker will execute the corresponding activity. When a work-item is selected, the workflow management system launches the corresponding application and monitors the result of executing the corresponding activity. Note that the worker only sees work-items in his/her in-tray, and when selecting a work-item only the information relevant for executing the corresponding activity is shown. Activity Instances During execution are represented by or Which include Manual Activities Automated Activities And/Or (which are not managed as part of the Workflow system) Work Items Invoked Applications (tasks allocated to a workflow participant) (computer tools/applications used to support an activity) SOURCE: WFMC

Por qué las empresas eligen Workflow?
Procesos más fáciles de modificar más eficientes más flexibles Procesos más fáciles de modificar El workflow permite que el flujo de control de las aplicaciones sea definido en forma declarativa (en lugar de tenerlo embebido en el código de la aplicación). Como consecuencia, es más fácil y rápido realizar modificaciones sobre el flujo de control ya que no requiere modificar el código de la aplicación. Procesos más eficientes They make sure that business tasks are executed by the right resource at the right time. Procesos más flexibles Al tener definido el flujo de control en forma declarativa, el workflow tiene la posibilidad de modificar el proceso en tiempo de ejecución para adaptarse a situaciones de la vida real. Why Workflow? Because workflow allows you to explicitly / declaratively model the control flow of an application. Rather than embedding your application logic in code, in a workflow the logic is represented declaritively. As a result you can inspect the application logic, visualize it, track it's execution, and even change the logic at runtime.

Por qué es tan importante la Flexibilidad en los Procesos?
Procesos de larga duración Contratos de leasing (3-5 años) Tratamientos médicos (meses, años) ... Consecuencia Procesos tienen que ser frecuentemente adaptados Nuevas leyes Nuevos tratamientos médicos Nuevas estrategias de negocio

Limitaciones de los Sistemas de Workflow tradicionales
Asumen que los procesos son bien estructurados Utilizan el ruteo tanto para distribución del trabajo como para su autorización Demasiado foco en el flujo de control Enfocar el ruteo en lo que se debería hacer y no en lo que se puede hacer Sin embargo, los Sistemas de Workflow actuales tienen problemas para manejar los cambios que pueden ocurrir durante la ejecución del workflow. La incapacidad de manejar adecuadamente este tipo de cambios limita la utilización de este tipo de sistemas. La mayor deficiencia de gran parte de los productos de workflow actuales es que asumen que los procesos de workflow son bien estructurados y completamente definibles en tiempo de diseño. In this paper, we argue that the lack of flexibility and––as a result––the lack of usability of contemporary workflow management systems to a large extent stems from the fact that routing is the only mechanism driving the case, i.e., work is moved from one in-tray to another based on pre-specialized causal relationships between activities. This fundamental property of the workflow approach causes the following problems: • Work needs to be straight-jacketed into activities. Although activities are considered to be atomic by the workflow system, they are not atomic for the user. Clustering atomic activities into workflow activities is required to distribute work. However, the actual work is done at a much more fine-grained level. This would mean that workers would only execute the actions that are specified for the activity, i.e., additional actions would not be allowed, and it would also not be possible to skip actions. • Routing is used for both work distribution and authorization. As a result, workers can see all the work they are authorized to do. Moreover, a worker is not authorized to do anything beyond the work-items in her in-tray. Clearly, work distribution and authorization should not coincide. For example, a group leader may be authorized to do the work offered to any of the group members, but this should not imply that all this work is put in his worklist. Since distribution and authorization typically coincide in contemporary workflow management systems, only crude mechanisms can be used to align workflow and organization. • By focusing on control flow, the context (i.e. data related to the entire case and not just the activity) is moved to be background. Typically, such context tunneling results in errors and inefficiencies. • Routing focuses on what should be done instead of what can be done. This push-oriented perspective results in rigid inflexible workflows. However, there appears to be a severe gap between the promise of workflow technology and what systems really offer. As indicated by many authors, workflow management systems are too restrictive and have problems dealing with change. In particular, many workshops and special issues of journals have been devoted to techniques to make workflow management more flexible. Some authors stress the fact that models should be as simple as possible to allow for maximum flexibility [11]. Other authors propose advanced techniques to support workflow evolution and the migration of cases of one workflow model to another. If the process model is kept simple, only a more or less idealized version of the preferred process is supported. As a result, the real run-time process is often much more variable than the process specified at design-time. In contemporary workflow technology, the only way to handle changes is to go behind the systems back. If users are forced to bypass the workflow system quite frequently, the system is more aliability than an asset. If the process model attempts to capture all possible exceptions, the resulting model be comes too complex to manage and maintain. These and many other problems show that it is difficult to offer flexibility without losing control. To illustrate the deficiencies of contemporary workflow management and to motivate the case handling paradigm, we use the metaphor of a blind surgeon. Before doing so we first introduce some standard workflow terminology. Workflow management systems are case-driven, i.e., they 1 focus on a single process instance. This means that only business processes describing the handling of one workflow instance in isolation are supported. Many cases can be handled in parallel. However, from the viewpoint of the workflow management system these cases are logically independent. To handle each case, the workflow management system uses the corresponding workflow process definition. The process definition describes the routing of the case by specifying the ordering of activities. Activities are the logical units of work and correspond to atomic pieces of work, i.e., each activity is executed by one worker (or another type of resource) and the result is either ‘‘commit work’’ or ‘‘abort and roll back’’.

Clasificación de Sistemas de Workflow
Estructurado Workflow de Producción Workflow Adaptativo Workflow Colaborativo No estructurado TYPES OF WORKFLOW What type of workflow should you use? It does depend on what you want to achieve. Many large organizations use more than one workflow product supplied by different companies. It is not unusual for organizations to use the same workflow product in a number of different ways. To help people to understand the market better, a number of segmentations have been proposed. The following segmentation is most useful. PRODUCTION The key goal of Production Workflow is to manage large numbers of similar tasks, and to optimize productivity. This is achieved by automating as many activities as practical, and to relentlessly pursue more and more automation until Straight-Through-Processing has been achieved and human input is required only to manage exceptions—those work items that fall outside pre-determined process tolerances. The events that require human contribution are minimized, as are the duration and complexity of that intervention. Production workflow is optimized to attain high levels of quality and accuracy by executing highly repetitious tasks, usually in a non-stop manner. Production Workflow can manage hugely complex processes, and can be tightly integrated with existing (legacy) systems. In fact the trend is to embed the workflow component into large applications where its role is to act as a Rules Engine. ADMINISTRATIVE The most important feature of an administrative workflow system is the ease to define the process. Typically, there are many definitions running concurrently and they tend to involve a large number of employees. Process Definitions are usually created using forms—and if the definition is too complex for the form then you just have to use another product. Flexibility is more important than productivity, and these systems handle one or two orders of magnitude lower numbers of instances per hour than Production Workflow Systems. COLLABORATIVE Collaborative workflow focuses on teams working together towards common goals. Groups can vary from small, project-oriented teams, to widely dispersed people with interests in common. Effective use of collaborative workflow to support team working is now considered a vital element in the success of enterprises of all kinds. The use of Internet and the World Wide Web to support team communications across enterprises is also a critical success factor to most organizations. Throughput is not an important consideration, and Process Definitions are not rigid and can be amended frequently. Collaborative Workflow is sometimes called Groupware. On the other hand, there are certain types of groupware that are NOT workflow; for example, bulletin boards or videoconferencing. AD-HOC Ad-Hoc Workflow systems allow users to create and amend Process Definitions very quickly and easily to meet circumstances as they arise. So it is possible to have almost as many Process Definitions as there are instances of the definitions. Ad-Hoc Workflow maximizes flexibility in areas where throughput and security are not major concerns. Whereas in Production Workflow, clearly the organization owns the process, Ad-Hoc Workflow users own their own processes. Conclusion As with most classifications, there are exceptions, and gray areas. For example, some production systems are now supporting some dynamic change in an individual process instance by specifying dynamic “–abilities” associated with an activity which can be varied during enactment—skip-ability, delegate-ability, etc, providing a sort of half-way house between production and ad-hoc workflow. Existing tools are typically in one of the two extremes of the spectra: groupware products such as Lotus Notes and Exchange are typical CSC W tools, not providing much process support, whereas commercially available (production) WFMSs such as Staffware and Flowmark are not able to cope with unstructuredness. Adaptive workflow aims at providing process support like normal workflow systems do, but in such a way that the system is able to deal with certain changes. These changes may range from ad-hoc changes such as changing the order of two tasks for an individual case (often called exceptions) to the redesign of a workflow process as the result of a Business Process Redesign (BPR) project. Flexibility & Control If users are forced to bypass the workflow system quite frequently, the system is more aliability than an asset. If the process model attempts to capture all possible exceptions, the resulting model be comes too complex to manage and maintain. These and many other problems show that it is difficult to offer flexibility without losing control. Orientado a Datos Orientado a Procesos control L libertad limitada, no flexibilidad J libertad, flexibilidad L no control

Sistemas de Workflow Adaptables
Clasificación de Adaptaciones Estrategias Criterios de Consistencia y Conformidad Control de Acceso Problemas pendientes por resolver Consideraciones Finales

Clasificación de Adaptaciones
Mayor nivel de abstracción Adaptación del sistema de workflow a un contexto de negocio diferente Dominio Proceso - Modelo - Tareas Evolución del Modelo Cambios Ad-hoc Recursos - Componentes de Software - Modelo Organizacional - Modelo de Datos Ajuste de recursos: - Componentes & Interfaces - Recursos humanos - Adaptación de datos relacionados Adaptación en un Contexto de Negocio Los sistemas de workflow no existen por su propio propósito. Ellos son un componente constituyente de un sistema de negocios. Los sistemas de negocios son usualmente específicos de un dominio determinado. Al nivel de dominio, un sistema de workflow puede ser considerado como un componente simple. Integrar un WFMS de propósito general en el contexto de una organización abocada a un negocio específico necesita adaptación y reconciliación desde ambas partes. Por lo tanto, los sistemas de workflow deben estar preparados para adaptarse a un amplio rango de organizaciones y tipos de negocios y también a un contexto cambiante. Adaptación a nivel de Proceso Adaptaciones a nivel de proceso se refiere a los cambios en los modelos de workflow y las tareas que lo constituyen. Las adaptaciones a nivel de proceso pueden clasificarse en Evolución de los modelos de workflow y Modificaciones Ad-hoc de las Instancias de Workflow. Adaptación a nivel de Recursos Adaptaciones relacionadas con el modelo organizacional Los cambios en el personal pueden tener un impacto directo en la ejecución de los procesos de workflow. La forma en que los cambios puedan ser reflejados en forma eficiente depende de los mecanismos para manejar la adaptación de recursos organizacionales. Adaptaciones relacionadas con los Datos Los datos y estructuras de datos pueden cambiar durante la ejecución de los proceso de workflow. Usualmente, los datos que no son utilizados por el WFMS pueden ser modificados independientemente y accedidos por las aplicaciones en el mismo momento. Pero si los procesos de workflow dependen de la existencia de cierto dato o propiedad, entonces el proceso de workflow necesita ser adaptado a los cambios en los datos. Esto requiere que los cambios en datos relacionados sean notificados al WFMS de manera que este pueda reaccionar a los cambios. Adaptaciones a nivel de Infraestructura En respuesta a a la evolución de los requerimientos y a los avances tecnológicos, los sistemas de workflow puede que necesiten adaptarse rápidamente a nuevas configuraciones. Infraestructura Reconfiguraciones

Estrategias para la Adaptabilidad
Evolución Cambios Ad-hoc

Escenario 1 (Evolución)
El tratamiento de un paciente puede seguir uno de varios planes posibles. El médico responsable elige el plan adecuado Los planes de tratamiento evolucionan constantemente en respuesta a cambios en la política del hospital, nuevos tratamientos, avances médicos, nuevas drogas, etc. El médico puede tener que adaptar el plan de tratamiento a una “versión mejorada” Blind surgeon metaphor We use the ‘‘blind surgeon metaphor’’ to illustrate the four problems identified by placing them in a hospital environment. In a hospital both operational flexibility and well-defined procedures are needed. Therefore, workflow processes in a hospital serve as benchmark examples for flexible workflow management, cf. [39]. Note that the ‘‘blind surgeon metaphor’’ is not restricted to hospital environments, similar issues can be observed in a wide range of other knowledge-intensive application scenarios. Consider the flow of patients in a hospital as a workflow process. One can consider the admission of a patient to the hospital as the creation of a new case. The basic workflow process of any hospital is to handle these cases. The activities in such a workflow include all kinds of treatments, operations, diagnostic tests, etc. The workers are, among others, surgeons, specialists, physicians, laboratory personnel, nurses. Each of these workers has one or more roles, and each task requires a worker having a specific role. For example, in case of appendicitis the activity ‘‘remove appendix’’ requires the role ‘‘surgeon’’. Clearly, we can define hospital workflows in terms of process definitions, activities, roles, and workers. In the setting of ‘‘hospital workflows’’, we again consider the four problems identified before. Suppose that work in hospitals would be straight-jacketed into activities. This would mean that workers would only execute the actions that are specified for the activity, i.e., additional actions would not be allowed, and it would also not be possible to skip actions. Such a rigorous execution of the work specified could lead to life-threatening situations. In hospital environments it is crucial that knowledgeable persons can decide on activities to perform based on the current case and their personal experiences. In general, workflow process models cannot represent the complete knowledge of the experts and all situations that might occur. Suppose that the routing in hospital processes would be used for both work distribution and authorization. This would mean that activities can only be executed if they are in the in-tray of a worker. Since distribution and authorization then coincide, it would not be possible to allow for initiatives of workers, e.g., a physician cannot request a blood test if the medical protocol does not specify such a test. Context tunneling is also intolerable. This would mean that the information for surgeons, specialists, physicians, laboratory personnel, and nurses is restricted to the information that is needed for executing a speci.c task. In contrast, given a speci.c medical situation, doctors and nurses may take advantage from consulting the complete medical record of the patient, based on the current state of the patient and their personal knowledge and experiences. Finally, it is clearly undesirable that the medical sta. of a hospital would limit their activities to what should be done according to the procedure rather than what can be done. The medical protocol typically speci.es what should be done instead of what can be done. Such descriptions are useful to guide workers. However, it is clear that restricting the workers to the work.ow speci.ed in the medical protocol would lead to absurd situations. It is clear that such a ‘‘tunnel vision’’, i.e., a straight-ahead vision without attention for contextual information, is not acceptable in any hospital process. Consider for example a surgeon who would ignore all information which is not directly related to the surgical procedure. A straightforward implementation of such a process using contemporary work.ow management systems would result in surgeons who are blind for this information, just doing the actions speci.ed for the activities in their in-trays. This ‘‘blind surgeon metaphor’’ illustrates some of the key problems of present-day work.ow management technology.

Escenario 2 (Cambios Ad-hoc)
El médico puede ordenar exámenes de laboratorio para un paciente pero no puede esperar por los resultados en el caso de una emergencia. El médico puede comenzar un plan de tratamiento para el paciente en emergencia. Tan pronto como llegan los resultados de los exámenes se notifica al médico. Después de que el médico analiza el resultado de los exámenes, éste puede necesitar modificar el plan de tratamiento inmediatamente para adecuarlo a los resultados.

Evolución vs Cambios Ad-hoc
Tiempo de Diseño Tiempo de Ejecución Modelos de Workflow Instancias de Workflow Evolución del Workflow Cambios Ad-hoc Notar que puede existir una relación fuerte entre los cambios ad-hoc y la evolución. Si los cambios ad-hoc pasan a ser permanentes entonces estamos a un problema de evolución del workflow. In contrast to ad hoc changes of individual WF instances, these approaches deal with changes of the WF schema and their propagation to running WF instances whose execution started with the old schema. Although the support for both types of changes is a complex and yet unsolved problem and many related issues can be identified, in some respects ad hoc modifications are much more intricate and problematic, as they may have to be performed by end users. Cambios permanentes

Evolución del Workflow
Motivación Facetas Requerimientos

Motivación Ambiente cambiante Nuevas estrategias de negocios
Alteración de condiciones externas (leyes, etc) Avances en nuevas tecnologías Optimizaciones Corrección de errores Ambiente cambiante (Changing Environment) Las actividades de negocio, como en cualquier campo de ingeniería, son altamente dinámicos y sujetos a una evolución constante. Como el clima de negocios es incrementalmente dinámico y competitivo, el rediseño y la optimización de los procesos de negocios existentes se convierte en una tarea indispensable en muchas organizaciones, las cuales necesitan ganar en eficiencia y efectividad en este ambiente de cambios constantes. En este ambiente, los procesos de negocio deben ser ajustados una y otra vez. En los hechos, en lugar de cambios radicales frecuentes, los procesos se encuentran en una evolución constante. Avances en nuevas tecnologías Aun cuando el ambiente de negocios permanezca estable, los sistemas de software necesitan evolucionar para adaptare a los avances en nuevas tecnologías. Estos avances tecnológicos pueden requerir de la reconfiguración de los sistemas para eventualmente incorporar nuevos componentes de software, etc.

Ciclo de Diseño de Procesos
Proceso de negocio visionado Modelo de Workflow En la vida real hay discrepancias entre lo previsto y lo necesario Ejecución Primeramente, los modelos de workflow son desarrollados completamente de acuerdo a la visión que se tiene de los mismos. Luego, la representación (que puede ser formal, gráfica, textual, etc) sirve como entrada para el sistema de gerenciamiento de workflow (WFMS). Finalmente, su ejecución lleva a los procesos de workflow en el mundo real. Notar que la mayoría de las veces habrán diferencias entre la versión que se tuvo en determinado momento y las necesidades actuales durante la ejecución del proceso de workflow. La retroalimentación desde el proceso de workflow del mundo real debe ser capturada en tiempo y forma de manera de que los próximas ejecuciones de procesos de workflow se ajusten adecuadamente a la realidad. Para manejar estos problemas, los productos de workflow contemporáneos deben evolucionar de soportar procesos predefinidos a soportar modificaciones dinámicas y reconfiguración en base a la retroalimentación del mundo real. Retroalimentación Proceso de Workflow (proceso actual)

Facetas de la Evolución de Workflow
Evolución estática Modificación de los procesos Evolución dinámica Manejo de las instancias de proceso en ejecución cuya definición ha sido modificada La faceta de evolución dinámica requiere de mecanismos para soportar la migración de las instancias existentes a nuevas definiciones de proceso, sin afectar su correctitud. Una instancia de proceso es correcta si cumple con su definición, esto es, que haya ejecutado de acuerdo a la nueva versión al momento de la migración. Un método simple pero ineficiente para determinar si una instancia de proceso puede ser migrada es verificar su historia y verificar su compatibilidad con la nueva definición de proceso. Un método mas eficiente, define una condición de migración para cada una de las operaciones de cambio en el proceso y determina si la migración es posible considerando las condiciones de migración de las operaciones realizadas a la definición de proceso modificada. Para manejar las definiciones de proceso que no pueden ser migradas a la nueva definición de proceso y que por lo tanto debe permanecer asociado a la anterior, algunos WFMS soportan diferentes versiones de una definición de procesos. Notar que los cambios ad-hoc son soportados generalmente por las WFMS como casos particulares de los cambios evolucionarios.

Requerimientos para la Evolución de Procesos
Manejo de Versiones Propagación de Versiones Estrategias de Propagación Perezosa (Lazy) Impaciente (Eager) Selectiva Manejo de Versiones Deben soportarse el manejo de versiones de los procesos de workflow. Estrategias de Propagación Además el sistema de workflow debe proveer de diferentes estrategias de propagación de los cambios en los procesos a sus respectivas instancias de proceso (activas) para flexibilizar la migración de un proceso de negoció a una versión mejorada del mismo. Propagación perezosa: el esquema de los procesos puede modificarse sin impactar en las instancias de proceso (activas) asociadas. La nueva versión del esquema del proceso es solamente relevante para todas las nuevas instancias que se creen basadas en el nuevo esquema. Esta política es útil para la introducción de nuevos (mejorados) procesos de negocio de corta duración. Propagación impaciente (eager): los cambios en el esquema del proceso son propagados inmediatamente a todas las instancias (activas) basadas en el esquema modificado. Esta política es útil para corrección de errores o mejoras en el proceso, generalmente para procesos de larga duración. Propagación selectiva: los cambios en el esqumea son propagados inmediatamente a un conjunto seleccionado de instancias de proceso. La selección de las instancias puede ser realizada manualmente por el diseñador del proceso o puede ser realizada automáticamente por el sistema de workflow de acuerdo al estado de ejecución de las instancias. Estrategias de migración para la propagación selectiva Además de la migración inmediata, la migración de un nuevo esquema puede que tenga que ser atrasada hasta que la instancia haya alcanzado un determinado estado. Además, pueden tener que soportarse diferentes variantes para diferentes instancias asi como también ajustes locales para algunas instancias. Un caso especial de la propagación selectiva es la modificación de la definición del proceso para una única instancia a fin de adaptar el workflow para una situación particular (excepción, etc). Esta estrategia es útil también para el caso de procesos que no pueden ser definidos completamente en la etapa de diseño. Cuando aquellos workflows que sufrieron modificaciones locales pasan a ser de interés general, los cambios tienen que ser propagados para la definición de proceso general, algo llamado upward propagation. Propagación entre diferentes versiones de un proceso Cuando los cambios tienen que ser aplicados a diferentes versiones de un proceso (este es el caso cuando una definición de proceso o una instancia de proceso es modificada localmente) necesitamos mecanismos que soporten la combinación de las diferentes variantes. Consistencia de las modificaciones de las instancias La propagación de versiones o modificaciones locales a una instancia llevan al problema de controlar y manejar el impacto de los cambios en las instancias que estan en ejecución, a fin de evitar estados de ejecución inconsistentes. En general, se deben restringir los cambios a realizar y pueden ser necesarias compensaciones para reestablecer la consistencia del estado de ejecución. La consistencia de una instancia depende de la correctitud dinámica entre la definición del proceso y el estado de ejecución de la instancia. La correctitud dinámica de una definición de proceso asegura que cada estado de ejecución que es alcanzado por el estado inicial es seguro. Usualmente se utilizan de herramientas de análisis y simulación por el modelador para chequear esta propiedad. Una instancia de proceso esta en un estado de ejecución consistente si su estado de ejecución actual es seguro con respecto a la nueva definición de proceso. Además del criterio de correctitud también es importante la propiedad de conformidad. Esta se enfoca no solo en la ejecución futura sino que también toma en cuenta la ejecución pasada. Requiere que toda la traza de ejecución de la instancia sea legal bajo la nueva definición de proceso. Cuando se cumple esta propiedad, la instancia puede ser migrada a una nueva definición sin ninguna regulación. De otra forma, algunas actividades tienen que deshacerse (rollback) para hacer que la instancia cumpla o en su defecto se debe introducir una nueva variante del proceso con la cual la instancia conforma y que evita el problema de deshacer tareas.

Cambios Ad-hoc Motivación Tipos de Cambios Operaciones
Duración de los Cambios

Motivación Refinamiento dinámico Participación de los Usuarios
Eventos impredecibles Errores Refinamiento dinámico En determinadas circunstancias, es imposible o no es práctico definir un proceso de negocios en su totalidad. Esto puede deberse a que no se tiene una especificación completa de los requerimientos y por lo tanto puede ser necesario un refinamiento en tiempo de ejecución. Es decir, hay determinadas tareas que solo pueden ser especificadas en tiempo de ejecución. Esto es válido tanto para cuestiones de ruteo como para asignación de los recursos requeridos para la ejecución de la tarea. Participación de los Usuarios Los usuarios a menudo necesitan ajustar sus tareas de acuerdo a circunstancias especiales que puede ser causadas tanto por eventos externos o por su forma personal de trabajar. Eventos impredecibles Los eventos impredecibles deben ser manejados apropiadamente para resolver problemas de la vida real. Los usuarios deben ser capaces de modificar el proceso dinámicamente para acomodarse a situaciones especiales. Errores Fallas del sistema, conflicto de recursos, operaciones fallidas, etc. Todas estas cuestiones pueden causar errores y dificultades en la ejecución de los procesos de workflow. Se necesitan de mecanismos de manejo de errores para asegurar que los procesos puedan seguir ejecutando apropiadamente. For most business processes, in addition to the recognized steps or activities that make up the process, there are number of recognized exceptions that may occur along the way. For example in a loan application process a recognized exception will be that the applicant fails the credit check. The point at which these types of exceptions may occur can be anticipated and can be built into the automated business process. On the other hand there are other types of exception that could occur at any point within the process. Examples of these types of exception are: a person moves house, a person gets married and changes their name, a person dies, notification is received that a loan application is being investigated for fraud. In some processes the number of identified exceptions may be numerous. Any attempt to build handling for such exceptions at every point with the process would result in a very large spaghetti-like process that would be almost impossible to enhance or maintain. The way in which these types of exceptions need to be handled may also vary; some may need separate processes to be initiated, some may need the main process to be suspended while some other activity takes place, some may require that process data is modified to take account of changed circumstances while others may mean that the current state of the process may need to change.

Tipos de Cambios Ad-hoc
Pre-Planificados El modelador de los procesos conoce la posición exacta en la cual puede ser necesaria una modificación del proceso de workflow No planificados La posición en la cual puede ser necesaria una modificación del proceso de workflow es impredecible Users must be able to flexibly deviate from the standard process (e.g., by skipping activities or by working on a WF activity ahead of the normal schedule). Concerning pre-planned deviations, their context as well as the actions necessary to handle them are known beforehand. They, therefore, can be already considered at buildtime in order to achieve a flexible execution behavior. As opposed to this, deviations that cannot be pre-planned may become necessary to deal with unforeseen events and must be dynamically handled during WF execution. In practice, both kinds of deviations frequently occur and must therefore be adequately supported by WfMS. In this paper we develop advanced concepts for both, the increase of flexibility at buildtime and its enhancement during runtime. Thereby, we focus on the support of forward and backward jumps, which are indispensable to flexibly deal with exceptions in WfMS. While the former enable deviations in forward direction (e.g., to skip unnecessary activities or to work on a particular activity ahead of the normal schedule), backward jumps make it possible to partially rollback the flow to a previous execution state and to re-continue work in this state (e.g., when activity execution fails). Other examples include the ad-hoc insertion or deletion of WF activities, the late modeling of sub-workflows, and the dynamic change of WF attributes (e.g., activity work assignments).

Operaciones Ad-hoc Estructurales Organizacionales Agenda

Estructurales Suspender / Continuar Abortar
Agregar / Eliminar / Mover Tareas Cambios de ruteo Salto (Adelante / Atrás) Saltear (Skip) / Avance Rápido Deshacer (Undo) / Backtracking Nivel de Proceso Suspend Suspending workflow executions is an important feature to allow dynamic changes and to adapt running workflow instances to newly generated or modified workflow schemas. While suspending atomic workflows is straightforward, there are different options to deal with suspending complex workflows, namely (i) suspending all running sub-workflows or (ii) after the termination of the currently running sub-workflows, no further sub-workflows of that complex workflow are created. Abort Abort a workflow is useful if a workflow is no longer needed during a particular workflow instance. The Abort operation can be invoked on both suspended workflow instances – aborted workflow instances are treated as terminated not successfully. Hence, aborted workflows are in the not successful state. Skip A workflow management system should allow workflow users to skip certain workflow activities which are not required during the execution of a particular workflow instance. SKIP The Skip operation can be invoked for tasks which are not started yet, i.e., for workflows in state init. Skipping a workflow results in a state transition from init to skipped, which is a closed state. Due to the internal structure of complex workflows, performing user intervention operations on complex workflows is more complicated than performing them on atomic workflows. Since skipping can only be done when the workflow has not yet started, skipping complex workflows is straightforward. UNDO (COMPENSATE) The ability to undo or to compensate workflows is another important feature of a flexible workflow management system. To undo a workflow, a compensating workflow has to be executed. We assume that a workflow is undoable, if an appropriate undo-workflow is defined. The responsibility that the defined undo-workflow effectively undoes the workflow is in the side of the developer. The Undo operation can be used in various ways for higher level constructs, for instance repetition and backtracking. It allows to play backwards workflow executions, i.e., when the success of a certain workflow instance cannot be guaranteed then workflows can be undone until a state is reached in which an alternative decision can be taken to resume the workflow instance successfully. This functionality is called backtracking - it effectively means playing back the workflow to a point where the workflow instance satisfies defined requirements. Tasks can be undone if they have successfully terminated, i.e., the Undo operation can be invoked when the task instance is in state successful, and it triggers a state transition to undone, which is a closed state. Correctness properties must be satisfied. The most important one ensures that all data elements read by an activity X must have been written by preceding activities before X can be started, independently from the execution path leading to activation of X. Note that this property is crucial for the proper invocation of external activity programs during WFexecution. In particular, it must be ensured in conjunction with forward jumps as well. Nivel de Tarea

Agregar Tareas Dinámicamente
Proceso de Exámen de sangre análisis estándar sacar sangre escribir reporte When a task is inserted into a WF graph, new nodes and edges (including data links) must be added while maintaining the correctness and consistency of the WF. Current state-of-the-art systems do not provide a sufficient level of flexibility and consistency with respect to this operation. Typically, they allow the addition of an activity only upon completion of a task and before the activation of its successors. Issues concerning data integrity are mostly ignored. For the flexible support of BPs a more generic approach is required. Generally, it should be possible: • to add new tasks or even premodeled task blocks to a WF at any point of time during its execution • to synchronize the execution of an inserted task with the execution of other tasks from the WF graph • to insert tasks into WF regions which have not yet been entered • to dynamically map the parameters of the added task to existing or to newly generated data elements There is no problem to provide an operation for inserting a new task as a direct predecessor (or successor) of a given node, for adding a task as a new branch between a split node and its corresponding join node, and so on. Note, that the insertion of a new task does not necessarily mean that it will be activated for sure. If the task is inserted into a region of the WF graph that has not yet been entered, its execution may depend on future routing decisions. It has turned out to be important to allow process participants to fix a date or a deadline for the execution of the inserted task. The necessary extensions for this are described in (Grimm, 1997). Allows WF designers (as well as selected process participants) to restrict the use of the insert operation to specific WF types or WF categories, to selected users respectively user roles, to specific regions of a WF graph (e.g., a task block), to selected WF states, to specific activity types or categories, or to any combination of them. Generally, we do also not require that the user who adds atask to a WF must subsequently work on it. This provides additional flexibility to process participants, as they are allowed to add tasks to a WF of which the execution is explicitly or implicitly delegated to other process participants. The insert operation also serves as the basis for composing higher-level operations. For example, several instantiations of the same task type (dynamic task) can be realized by the repetitive use of this change operation. Its generality also provides the basis for the ad hoc definition of WFs: a WF starts with a single stop node between the start and the end node of the WF graph, and it may be dynamically extended by the repetitive application of the insert operation presented. In some systems the tasks which shall be dynamically added to a task net must be predefined in a process schema. This significantly limits the dynamics of this approach. ánalisis especial

Eliminar Tareas Dinámicamente
Proceso de Exámen de sangre análisis estándar sacar sangre escribir reporte Individual tasks or task sequences may have to be skipped or removed when the conditions for their execution become unnecessary. Of course, the deletion of tasks should not always be allowed. Firstly, nodes which are an integral part of the WF structure (e.g., the start node of the WF) must not be deleted at all. Secondly, WF designers may customize a WF schema in order to disallow the deletion of individual tasks or tasks from specific WF regions. The deletion of a task X of a running WF instance is only possible, if X is either in the state ACTIVATED or NOT_ACTIVATED. In the former case, the work items associated with X are removed from the corresponding worklists. Tasks in the state RUNNING, COMPLETED, FAILED, or SKIPPED may not be deleted. análisis especial

Salto / Atajo Proceso de Intervención Quirúrgica Skip Jump Skip Skip
Ordenar intervención Agendar intervención Preparar Paciente Realizar Intervención Generar Reporte Validar Reporte Skip Jump Skip Skip Example 1 (Forward jumps in a flow). The processing of a medical examination for an inpatient normally comprises several steps: The examination must be ordered, an appointment with the examination unit be made, the patient be pre- pared and notified about potential risks, the intervention be performed, and medical reports be generated, obtained and validated. Even for this simple process chain, it must be possible for physicians and nurses to flexibly deviate from the standard procedure, in particular to handle exceptional situations (e.g., if the patient’s state of health gets worse during the process or the physician finds out that some preparatory steps are unnecessary for the respective patient). In such cases it must be possible to skip steps or to immediately perform the examination; i.e., without making an appointment or waiting until all preparatory steps (required in the normal case) have been finished. Note that corresponding situations may occur at any time during process execution. The diagram shortcut reflects a forward jump as it is modeled by the designer. It has the following semantics: After successful completion of source activity both, direct successors over normal control edges (activity Agendar) and the target activity of the shortcut (F: Realizar intervención) are activated. While is treated as a normal step (with priority REGULAR), the “untimely” execution of activity F is considered as an exceptional case. This exceptional status is preserved as long as F is no scheduled along the “normal” control flow. In our example, is offered as exceptional step (with priority EXCEPTIONAL in worklists until it will either be finished or its direct predecessor E will be completed. Assume that a user wants to follow shortcut i.e., he wants to jump forward to activity n and work on it though not all steps normally preceding n have been finished yet. When deviating from the preferred execution order, it must be clear how to deal with by passed activities from the jump region; i.e., with activities located between the source and the target node of the shortcut (nodes B, C or D, E in our example). We present two alternative approaches which either allow to skip by passed activities or to finish them concurrently to activity n . One possibility to deal with bypassed activities is to undo, abort, or abandon their execution depending on their current state; i.e. if a user deviates from the preferred execution path by following a shortcut ns ? nd , all activities located between the source and the target activity of the shortcut will be compensated, aborted or abandoned. When a user wants to apply a jump in order to bring forward the execution of a certain activity, it is not always required to skip activities of the jump region. Instead, it may be desired to continue and finish them concurrently to the pre-scheduled activities. With respect to activities from the jump region, this means that the effects of already completed activities are to be preserved, the execution of already started activities be continued, and activities not yet activated be scheduled as planned. Performing forward jumps during runtime Our experience with clinical workflows has shown that the WF designer is generally not capable to predict all possible deviations in advance and to capture the min the WF schema. To adequately cope with such unforeseen exceptions, in addition to the described concepts, ADEPT supports ad-hoc deviations from the pre-modeled WF schema at the instance level as well (e.g. to insert, to delete, or to shift activities). In the following, we restrict our considerations to dynamic forward jumps (e.g., skipping of a set of activities or immediate execution of an activity though not all predecessors have been completed yet). In this context, it is very important that change definition is not complicated for users; i.e., all complexity associated with missing activity input data (e.g., due to skipping of activities), data losses (e.g., due to lost updates), deadlocks (e.g., due to cyclic waits of activities), or state adaptations must be hidden to a large degree from users. Instead, they must be able to define a dynamic forward jump at a high semantic level without requiring that they are familiar with the used WF description formalism. It is important to mention that, in general, the applicability of a dynamic change depends on the current state of the WF instance graph as well. Concerning a dynamic forward jump, we require that its target activity has not yet been activated; otherwise the application of this operation would not make sense. With respect to other change operations, the required state constraints may be more or less complex, depending on the kind of change. For example, a new activity must not be inserted as a predecessor of an already running or completed step and a completed step must not be deleted.

Salto hacia Atrás Proceso de Intervención Quirúrgica Undo Undo Jump
Ordenar intervención Agendar intervención Preparar Paciente Realizar Intervención Generar Reporte Validar Reporte Undo Jump Undo In practice, it is very important to allow authorized users to perform backward jumps to former execution states if need be. In ADEPT, WF designers can model normal loop backs as well as failure backward jumps (called backward jumps for short). While loop backs specify iterative executions, backward jumps can be used to partially roll back the flow as response to semantic failures. More precisely, a rollback operation (partially) resets the effects of previous activity executions. Among other things this includes the resetting of markings, the undoing of write operations on data elements, and the compensation of external effects if possible and reasonable (e.g., by invoking compensating activities). ADEPT allows the modeling of different kinds of backward jumps. Additionally, to deal with unforeseen situations that cannot be pre-planned at build time, it enables users to perform ad-hoc backward jumps. Example (Semantic Failure) Regarding the described workflow, a medical examination may fail due to several reasons. For instance, it may not be possible to examine the patient if preparatory measures have been omitted or the patient does not agree with the intervention. Depending on the concrete reason of a semantic failure, the actions necessary for exception handling may vary. For example, the workflow may have to be aborted or it may be sufficient to suspend its execution, to rollback the flow to a former state, and then to resume work in this state. Example (User initiated Backward Jumps) Assume that the patient’s state of health gets worse or the physician wants to revise previous decisions concerning patient treatment. In such cases it must be possible for him or her to regain control and to jump back to previously executed steps. (This should at least be possible as long as the medical examination has not taken place.) This, in turn, may require that running activities (e.g. “preparation of the patient”) may have to be aborted or completed ones (e.g., “making an appointment”) may have to be undone. In many cases, the context for the application of such user initiated backward jumps is known in advance such that they can be considered at build time. Basic to such an ad-hoc deviation (in backward direction) are the WF instance graph, the execution history, and the data element history of the respective WF instance. The execution history, for example, logs data about start and completion of activity executions, which can be used when a rollback has to be performed (cf. Fig. 20). To initiate an ad-hoc backward jump the user may dynamically select a target activity from the list of already completed or running activities. Afterwards the flow can be rolled back to the state that had been valid before this activity instance was started. It is also possible to rollback the WF instance to earlier iterations of a loop, i.e., the scope of the rollback may comprise activity executions from different loop iterations. Concerning transactional guarantees in combination with backward jumps, usually, for long-running workflows we cannot ensure full ACID properties (and we also do not need this in most cases in practice). We, therefore, have adopted concepts from the field of extended transaction models [21,42] by allowing the WF designer to (optionally) associate activities with compensation programs, which are then invoked in case these activities have to be undone due to a rollback. Currently, we are working on several other issues arising in this context. They include the handling of backward jumps in modified WF instance graphs (e.g., backward jump to a previously inserted activity), the undoing of temporary changes (e.g. modifications caused by a dynamic forward jump) in connection with rollback operations, and the definition of compensation scopes in order to flexibly adapt the compensation behavior of WF instances depending on their state.

Deshacer (Undo) Situación: Estado de ejecución inconsistente o indeseable Necesidad de deshacer tareas hasta alcanzar un estado de ejecución satisfactorio Como deshacer las tareas? Transacciones de Compensación Responsabilidad del programador The ability to undo or to compensate workflows is another important feature of a flexible workflow management system. To undo a workflow, a compensating workflow has to be executed. We assume that a workflow is undoable, if an appropriate undo-workflow is defined. The responsibility that the defined undo-workflow effectively undoes the workflow is in the side of the developer. The UndoActivity operation can be used in various ways for higher level constructs, for instance repetition and backtracking. It allows to play backwards workflow executions, i.e., when the success of a certain workflow instance cannot be guaranteed then workflows can be undone until a state is reached in which an alternative decision can be taken to resume the workflow instance successfully. This functionality is called backtracking - it effectively means playing back the workflow to a point where the workflow instance satisfies defined requirements. Workflows can be undone if they have successfully terminated, i.e., the UndoActivity operation can be invoked when the workflow instance is in state successful, and it triggers a state transition to undone, which is a closed state.

Operaciones Ad-hoc Estructurales Organizacionales Agenda

Operaciones de Adaptación
Organizacionales Asignar Reasignar Delegar

Operaciones de Adaptación
Agenda Modificación de Plazos (Deadlines)

Cambios Ad-hoc Motivación Tipos de Cambios Operaciones
Duración de los Cambios

Duración de los Cambios
Cambios Temporales Aplican durante cierto “tiempo” Cambios Permanentes Se mantienen mientras la instancia de proceso permanece activa For the management of structural WF changes, it makes a big difference whether an applied change must be preserved until the completion of the WF (permanent change), or whether it is only of temporary nature (temporary change). This division is particularly important for the support of long-running BPs, where changes may affect WF regions that are entered several times, e.g., due to loop iterations or due to the partial rollback of a WF. If a task is inserted into the body of a loop, for instance, it must be specified whether this insertion should only be valid for the current iteration of the loop or for following iterations as well. In the first case, the added task is executed at most once, and the (structural) change must be undone before the next iteration of the loop is entered (i.e., the inserted task must be removed together with its associated data links and services). For the remainder of this section, we simplistically assume that the durability of a change – temporary vs. permanent – can be specified at the time it is applied to the WF instance.

Control Flow Processes Event Driven Processes
Modelos de Workflow Secuencial A1 A3 A2 A4 S1 S2 S3 S4 Máquina de Estados A Sequential workflow is characterized by the fact that the workflow is in control. Fred, Joe and I get to do what we’re told, when we’re told to do it. We do our stuff, let workflow central know that we did it, and then the workflow decides what happens next. Of course, the Sequential style doesn’t mean that things always happen in a simple linear sequence like this. We can have conditional branching, loops, and so on. What it means is that the workflow controls the sequence. The Sequential style is the classic style of workflow, as implemented by dozens of products over the years. In my opinion, it is also significantly responsible for giving Workflow a bad name. Not that there’s anything wrong with telling people what to do (I’m known to indulge in the practice myself, occasionally) – but sometimes it just doesn’t work. Control Flow Processes Well understood sequence of events Sequential in nature Process is the driver Suitable for process automation Event Driven Processes Driven by external events Unpredictable sequence of events Many alternative business paths May jump to any step

Por qué los modelos secuenciales no son suficientes?
El Workflow no siempre tiene el control El Workflow puede tener que esperar por demasiados eventos externos Modelar en un Workflow secuencial todos los caminos posibles puede ser engorroso

Cuando usar modelos basados en Máquina de Estados
Demasiada dependencia de eventos externos Demasiada intervención de los usuarios Dificil de modelar todos los caminos posibles

Sistemas de Workflow Adaptables
Clasificación de Adaptaciones Estrategias Criterios de Consistencia y Conformidad Control de Acceso Problemas pendientes por resolver Consideraciones Finales

Criterios de Consistencia y Conformidad
Garantizar ejecución futura Evitar estados de ejecución inconsistentes Conformidad Más exigente Garantizar ejecución pasada y futura Toma en cuenta la traza (historia) del proceso Puede ser necesario deshacer actividades Consistencia de las modificaciones de las instancias La propagación de versiones o modificaciones locales a una instancia llevan al problema de controlar y manejar el impacto de los cambios en las instancias que estan en ejecución, a fin de evitar estados de ejecución inconsistentes. En general, se deben restringir los cambios a realizar y pueden ser necesarias compensaciones para reestablecer la consistencia del estado de ejecución. La consistencia de una instancia depende de la correctitud dinámica entre la definición del proceso y el estado de ejecución de la instancia. La correctitud dinámica de una definición de proceso asegura que cada estado de ejecución que es alcanzado por el estado inicial es seguro. Usualmente se utilizan de herramientas de análisis y simulación por el modelador para chequear esta propiedad. Una instancia de proceso esta en un estado de ejecución consistente si su estado de ejecución actual es seguro con respecto a la nueva definición de proceso. Además del criterio de correctitud también es importante la propiedad de conformidad. Esta se enfoca no solo en la ejecución futura sino que también toma en cuenta la ejecución pasada. Requiere que toda la traza de ejecución de la instancia sea legal bajo la nueva definición de proceso. Cuando se cumple esta propiedad, la instancia puede ser migrada a una nueva definición sin ninguna regulación. De otra forma, algunas actividades tienen que deshacerse (rollback) para hacer que la instancia cumpla o en su defecto se debe introducir una nueva variante del proceso con la cual la instancia conforma y que evita el problema de deshacer tareas.

Control de Acceso en Workflow Adaptables
Quien tiene accesos a los cambios? Qué tipo de cambios? Donde? Alcance Process Definition Process Instance Bajo que condiciones Los cambios Ad-hoc y evoluciones de los procesos imponen nuevos requerimientos de control de acceso que no son contemplados por los mecanismos (de control de acceso) tradicionales. La participación de los usuarios es siempre pasiva, se asume que los usuarios solo necesitan saber acerca de la actividad en la que estan involucrados. Los participantes de workflow toman un workitem de su worklist, lo procesan y lo marcan como completo cuando terminan. Por lo tanto, no necesitan tener una visión general del proceso de workflow. Hay administradores de procesos que se encargan de las definiciones de procesos. Como consecuencia, requerimientos de control de acceso de los WFMS tradicionales están enfocados principalmente en la asignación de tareas. Debería ser posible de controlar a un nivel muy fino de granularidad quien tiene permito realizar que tipo de cambios y bajo que circunstancias.

Usuarios y Privilegios
Usuarios normales Dueños de Procesos Gestionadores de Procesos Excepciones locales Cambios que afectan a otros usuarios Mayores privilegios Mientras que algunos cambios pueden ser realizados por usuarios de workflow normales para manejar excepiones locales, otros pueden afectar a otros usuarios y por lo tanto deben ser realizados por administradores de procesos o por los dueños de los procesos. A los usuarios normales generalmente no se les permite hacer cambios estructurales al modelo de workflow en el cual ellos son solamente participantes. Pero el dueño del proceso comprende la lógica del proceso de workflow como un todo, sabe las implicancias que pueden tener los cambios en contraste con un participante quien desconoce las consecuencias de los cambios. Como participante de un proceso, el usuario delega la responsabilidad de realizar cambios estructurales al dueño del proceso en lugar de hacer cambios en la estructura por mano propia. Recíprocamente, el dueño del proceso podría, eventualmente, delegar la responsabilidad de hacer cambios estructurales a un participante del workflow determinado.

Control de Acceso de las operaciones de Adaptación
Roles Execute Redo Skip For each process and each activity three roles need to be specified: the execute role, the redo role, and the skip role. - The execute role is the role that is necessary to carry out the activity or to start a process. - The redo role is necessary to undo activities, i.e., the case returns to the state before executing the activity. Note that it is only possible to undo an activity if all following activities are undone as well. - The skip role is necessary to pass over activities. In order to skip over two consecutive activities, the worker needs to have the skip role for both activities. An activity with the ‘no-one’ redo role can never be undone again and it would then also not be possible to go back to an earlier activity. This is a very effective way to model ‘points of no return’. An execute everyone role means that the activity can be carried out by anyone who at least has a role in that process (because that person is then, after all, at least equal to the everyone role). The associations redo, skip, and execute link roles to activities. Traditional WFM systems only support the execute role.The redo and skip roles allow for more flexibility.

Problemas pendientes por resolver
Como analizar las adaptaciones antes de su ejecución? Como monitorear procesos adaptados?

Consideraciones Finales
Cambios estructurales pueden producir comportamientos impredecibles Utilizar criterios de consistencia y conformidad No trasladar toda la responsabilidad al usuario Cambios permanentes deben ser preservados Los cambios no deben provocar problemas de performance ni perturbar a los participantes Los cambios deben ser manejados y usados de manera apropiada y segura Unrestricted changes to the structure of a long-running program – possibly in the midst of its execution – make it difficult to have the system behave in a predictable and correct manner. For this reason, supporting dynamic WF changes must not mean that the responsibility for the avoidance of consistency problems or run-time errors is now completely shifted to the naive end user or to the application programmer. Instead, correctness and consistency criteria are required in order to enable the run-time system to adequately assist users in applying structural changes. That is, the system should guarantee that all consistency constraints that have been ensured prior to a dynamic change are also ensured after the the WF instance has been modified. Changes must consider the state of the WF instance, too. For example, it should not be possible to delete a task or to change its attributes if it was already completed. Convenient rules, which should not appear as too restrictive to users, must be defined in order to avoid an improper and uncontrolled use of change operations. Finally, for security reasons it must be possible to restrict the use of change operations to selected users respectively user roles, to specific WF types or regions of a WF graph (e.g., a single task), to certain states of a WF, or to any combination of them. Normally, several instances of a specific WF type are active at the same time. As changes of different kinds may be applied to these instances during their execution, several issues must be addressed. First of all, WF instances of the same type (i.e., the same starting schema) may have to be represented by different execution graphs. Secondly, the run-time system must manage changes of different nature concerning their durability. This is especially important for long-running processes where applied changes may be permanent or temporary. Permanent changes must be preserved until completion of the process. By contrast, temporary changes may have to be undone if the control of the WF is passed back to a previous point of control (e.g., when a new iteration of loop is entered). Consequently, a technical challenge is how to represent and to manage these different types of changes, and how to undo temporary changes in a correct manner. This requires sophisticated mechanisms for change management and a close integration of change operations with other core services of the WFMS. Finally, changes should be made "on the fly" without loss of run-time performance and without disturbing process participants not actively involved in the change. In summary, dynamic structural changes represent serious interventions into the control of a WF, which cannot be handled without extensive system support. In providing support for dynamic WF changes, whether for the process administrator or, in some form, for the process participants, it is crucial that these facilities will be manageable and usable in a proper and secure manner. Correctness properties must be satisfied. The most important one ensures that all data elements read by an activity X must have been written by preceding activities before X can be started, independently from the execution path leading to activation of X. Note that this property is crucial for the proper invocation of external activity programs during WF execution. In particular, it must be ensured in conjunction with forward jumps as well. The Skip operation can be invoked for tasks which are not started yet, i.e., for workflows in state init. Skipping a workflow results in a state transition from init to skipped, which is a closed state. The Abort operation can be invoked on both suspended workflow instances – aborted workflow instances are treated as terminated not successfully. Hence, aborted workflows are in the not successful state. Tasks can be undone if they have successfully terminated, i.e., the Undo operation can be invoked when the task instance is in state successful, and it triggers a state transition to undone, which is a closed state. Due to the internal structure of complex workflows, performing user intervention operations on complex workflows is more complicated than performing them on atomic workflows. Since skipping can only be done when the workflow has not yet started, skipping complex workflows is straightforward. While suspending atomic workflows is straightforward, there are different options to deal with suspending complex workflows, namely (i) suspending all running sub-workflows or (ii) after the termination of the currently running sub-workflows, no further sub-workflows of that complex workflow are created.

Limitaciones de los Sistemas de Workflow actuales Sistemas de Workflow Adaptables Adaptabilidad en GXflow

Adaptabilidad en GXflow
GeneXus Rocha Restricciones Delegación Manejo de Versiones Trns. de Compensación Procesos Ad-hoc … Skip, Undo, …

Adaptabilidad en GXflow
Demo

Preguntas

Adaptive Workflow Management
Ing. Gonzalo Fernández

Más Información Conferencias relacionadas:
Nombre de Conferencia A - Sala X, día, hora: hh:mm Laboratorio B - Sala Y, día, hora: hh:mm Café Tecnológico C - Sala Z, día, hora: hh:mm Más conferencias de <Nombre Orador> Nombre de Conferencia D - Sala Z, día, hora: hh:mm Nombre Orador, Cargo o Equipo al que pertenece

Adaptive Workflow Management

Presentaciones similares

Presentación del tema: "Adaptive Workflow Management"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Adaptive Workflow Management

Presentaciones similares

Presentación del tema: "Adaptive Workflow Management"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback