Automatización de procesos

Presentación del tema: "Automatización de procesos"— Transcripción de la presentación:

1 Automatización de procesos
Gestión de Procesos y Servicios

2 Estas transparencias son una versión traducida al español de las creadas por Marcello La Rosa y Marlon Dumas para el Tutorial “Process Automation” en BPM Disponibles en

3 Introducción

4 ¿Dónde estamos?

5 La automatización de procesos abarca:
Automatizar actividades del proceso Automatizar la coordinación del proceso Proceso de negocio automatizado

6 Sistemas de información conscientes del proceso
Explotan la definición explícita del proceso de negocio Sistemas de gestión de procesos de negocio (BPMSs) Gestión de clientes (CRM) Sistemas empresariales (ERP) Sistemas de gestión de casos (ACM)

7 Sistemas de gestión de procesos de negocio
Introducción Sistemas de gestión de procesos de negocio

8 Business Process Management System (BPMS)
Sistema software genérico que está dirigido por la representación explícita de representaciones de procesos para coordinar la realización de procesos de negocio

9 BPMS debe dar soporte a:
Modelado de procesos de negocio Incluye visualización, simulación, definición de reglas de negocio Ejecución de procesos de negocio Es habitual usar sistemas de workflow Medición de procesos de negocio Análisis, monitorización y auditoría de procesos de negocio Optimización de procesos de negocio

10 La arquitectura de un BPMS

11 Process modeling tool Crear y modificar procesos de negocio ejecutable (permitiendo especificar propiedades de ejecución) Almacenar y cargar procesos de un repositorio Puede importar de herramientas de modelado de proceso conceptuales

12 Ejemplos de process modeling tools
Focus on the interface to specify extra properties Bonita Soft Bonita Open Solution IBM Business Process Manager

13 Execution Engine Instancia modelos de procesos ejecutables (también llamados “casos”) Orquesta la distribución de trabajo entre los participantes de proceso y los sistemas software para ejecutar el proceso de principio a fin Guarda datos de ejecución en un log

14 Worklist Handler Se puede ver como una “bandeja de entrada” Ofrece work items a los participantes del proceso y les permite aceptarlos y empezar a trabajar en ellos Maneja las listas de tarea de los participantes Pueden proporcionar capacidades de redes sociales

15 Ejemplos de worklist handlers
TODO: add example with social network capabilities from Appian. Comment on social network capabilities of commercial worklist handlers Bonita Soft Bonita Open Solution

16 Administration & Monitoring Tools
Gestionar el BPMS Configurar el acceso a los componentes del sistema Monitorizar la disponibilidad de los participantes y el rendimiento de la ejecución del proceso

17 Ejemplos de monitoring & administration tools
Perspective BPMOne IBM BPM Process Admin Console IBM BPM Process Portal

18 External Services Exponen una interfaz de servicio con la que interactúa el motor de procesos. El motor proporciona al servicio los datos para que ejecute la actividad Ejemplos: motores de reglas, notificación por o Twitter notification, conectores con DBs, CRMs…

19 Ejemplo de external services
Bosch Visual Rules editor

20 Evolución del panorama de BPMS
© BPTrends

21 Commercial open-source Community open-source
BPMS Landscape Big vendors IBM BPM Oracle BPMS Microsoft BizTalk, Wf SAP NetWeaver BPM Software AG webMethods Pegaystems PegaRULES Other closed-source Appian BPMS BizAgi BPM Suite Bosch inubit Suite OpenTex tBPM Perceptive BPMONe Progress Savvion TIBCO ActiveMatrix BPM Commercial open-source Bonita Open Solution Camunda Intalio|BPM JBoss jBPM ProcessMaker Community open-source Shark YAWL Activiti A lot of choice. In large commercial projects, the engines on the left column are an option, since upfront licensing costs can be absorbed either by a project, or more frequently, by multiple projects (BPM program). It is worth noting that Microsoft offers two options: BizTalk which has a large number of integration features (all sort of adapters and integration tools), and Windows Workflow Foundation, which is more geared towards smaller projects. In smaller projects/companies, the other closed-source engines are an option. These compete with open-source solutions, among which we can clearly distinguish between commercial open-source (companies making revenue out of consultancy, training and branding), and community open-source. In this course we well use YAWL for 3 reasons: Very easy and relatively lightweight installation (both on Windows and Mac), and small footprint – Cf. YAWL4Study Quite advanced resource management features, good for illustrating various ways of assigning tasks to actors Freely available, no restriction

22 Clasificación de BPMS de acuerdo a su soporte a BPMN
BPMN puro: (re)diseñado desde el principio para seguir la especificación IBM BPM, Appian BPMS, Camunda, Activiti BPMN adaptado: puede importar de BPMN pero lo transforma a su representación interna propia Bonita Open Solution, BizAgi BPM Suite No BPMN: lenguaje y semántica propietaria Bosch inubit Suite, BPMOne, YAWL Adapted BPMN: can import from BPMN

23 Criterios de selección para el BPMS
Criterios de integración ¿Qué facilidades da para integrar otros sistemas? Criterios de interacción con el usuario ¿Qué posibilidades ofrece para diseñar interfaces de usuario? Criterios de diseño del proceso ¿Qué lenguaje de ejecución de procesos soporta? Criterios de pruebas y simulaciones ¿Soporta realizar pruebas/simulaciones sobre los procesos? Criterios en tiempo de ejecución ¿Soporta monitorización? ¿Escala el sistema? ¿Adapta dinámicamente los workflows? Criterios generales ¿Se integra bien en el entorno? ¿Qué soporte tiene? ¿Qué precio tiene?

24 Ventajas de los BPMS Introducción
Sistemas de gestión de procesos de negocio Ventajas de los BPMS

25 Reducción de la carga de trabajo
Distribución del trabajo Coordinación entre participantes del proceso Recopilación de la información relevante

26 Integración de sistemas flexible
Separación de aspectos Punto de integración

27 Ejecución transparente
Información del estado Balanceo de carga Análisis del rendimiento

28 Aplicación explícita de reglas
Acuerdos de nivel de servicio Normativas / regulaciones Segregación de tareas

29 Problemas al introducir un BPMS
Introducción Sistemas de gestión de procesos de negocio Ventajas de los BPMS Problemas al introducir un BPMS

30 Problemas técnicos: Integración
Integración con sistemas legacy: Screen scrapping Orientado a casos vs orientado a lotes Mitigado con el uso de tecnologías web y la orientación a servicios

31 Problemas organizacionales
Cambios contínuos en los procesos Efecto de ser vigilado Convertirse en “autómatas” Problemas al tratar casos excepcionales

32 Haciendo ejecutable un modelo de procesos
Introducción Sistemas de gestión de procesos de negocio Ventajas de los BPMS Problemas al introducir un BPMS Haciendo ejecutable un modelo de procesos

33 El salto entre TI y negocio
Stress that this is achieved via a BPMS and that it’s not necessarely a refinement, it’s rather an incremental transformation

34 El resultado: dos caras de la historia
Modelos conceptuales “to be” Hechos por expertos del dominio Proporcionan una base para la comunicación entre las partes interesadas Deben ser entendibles Deben ser intuitivos y dejar espacio a la interpretación Contienen únicamente un conjunto relevante de la información del proceso Modelos ejecutables Hechos por expertos de TI Proporcionan la entrada a los BPMS Deben ser entendibles por la máquina Deben ser no ambiguos y no contener nada abierto Contienen detalles que son sólo relevantes para la implementación Conceptual vs to-be-executed and executable Add “to-be-executed model” as a bridge between the conceptual and executable process model “to-be executed” process model

35 Pasos para convertir procesos en ejecutables
Identificar las fronteras de la automatización Revisar tareas manuales Completar el modelo de proceso Ajustar la granularidad de las tareas Especificar las propiedades de ejecución Let’s see how we can achieve that. We propose a five-step method whereby we incrementally transform the conceptual process model in order to obtain an executable counterpart of this. First, we [read steps]. At the end of step 4 we obtain the “to-be-executed” model, which in final step gets finally transformed into the fully executable process model, by specifying execution properties. This method is inspired from teaching material of Remco Dijkman. Outline: we will cover the first four steps, until we obtain the to-be-executed pm in Part I of this tutorial. After the break, in Part II, we will cover the “last mile”. Adapted from teaching material of Remco Dijkman, TU/e.

36 Nuestro ejemplo Customer Seller Supplier 1 Supplier 2

37 Nuestro ejemplo

38 1. Identificar las fronteras de automatización
Principio: no todos los procesos pueden ser automatizados. -> Empieza identificando cada tipo de tarea: 1 2 3 We have to be honest about that. Not all processes can be automated. So we need to start by… We can distinguish between automated tasks, i.e. those tasks that can executed by an external application or internally to the BPMS, for example checking the stock availability through an ERP system or retrieving a document from a DMS, user tasks, those tasks where process participants need to provide input to the process, typically via the use of web forms, and finally manual tasks, those which are entirely manual, such as retrieving a product from the warehouse Tareas automáticas Tareas de usuario Tareas manuales

39 En BPMN: especifica los marcadores de tareas
Identify automated, manual and user tasks: Manual tasks are marked with a hand icon User tasks are marked with a user icon (scheduled in worklist) Automated tasks are subtyped in BPMN: script (script marker), if the task executes some code (the script) internally to the BPMS. This task can be used when the functionality is simple and does not require access to an external application service (wheels marker), if the task is executed by an external application, which exposes its functionality via a service interface send (filled envelope marker), if the task sends a message to an external service receive (empty envelope marker), if the task waits for a message from an external service Tareas automáticas Tareas de usuario Tareas manuales

40 automática usuario manual En nuestro ejemplo…

41 2. Revisar las tareas manuales
Principio: si no se ve en el BPMS, entonces no existe. -> Busca formas de soportar tareas manuales vía TI: via tareas de usuario via tareas automáticas -> Aíslalas y automatiza el resto Once we have identified each task’s type, and so the automation boundaries, we can review each manual task to see whether we can automate them or we have to isolate them. Here the principle is: … Where the nice looking woman gets a notification on her mobile device to go and pick up the box from the shelf, and once she is done she scans the barcode of the product so that an automatic notification is sent back to the BPMS, which now knows it can move on

42 Alternativa: aísla tareas manuales
Isolate manual tasks (use Example 9.1 – student admission process)

43 Alternativa: aísla tareas manuales
Segmento 1 Segmento 2 Segmento 3 Isolate manual tasks (use Example 9.1 – student admission process)

44 Consideremos este fragmento de proceso
Proceso preparación de recetas: Cuando la receta pasa la comprobación del seguro, se asigna a un técnico que recoge las medicinas de las estanterías y las pone en una bolsa con la receta grapada en ella. Después, la bolsa se pasa al farmacéutico que vuelve a comprobar que la receta se ha procesado correctamente. Después del control de calidad, el farmacéutico sella la bolsa y la pone en la zona de recogida. Cuando un cliente llega a recoger su receta, un técnico se la da y le solicita el pago. Asume que el sistema de la farmacia automatiza este proceso. Identifica el tipo de cada tarea y enlaza las tareas manuales al sistema. Exercise 9.8 If therea are any manual tasks, find a way to hook them to the pharmacy system. One way of modeling this fragment is by defining the following tasks: “Check insurance”, “Collect drugs from shelves”, “Check quality”, “Collect payment” (triggered by the arrival of the customer), and finally “Retrieve prescription bag”. Assume the pharmacy system automates the prescription fulfillment process. Identify the type of each task and if there are any manual tasks, specify how these can be linked to the pharmacy system. Task “Check insurance” can be automated through a service that determines the amount of the co-payment based on the details of the prescription and on the customer’s insurance policy. Tasks “Collect drugs from shelves” and “Check quality” are manual tasks. These tasks can be implemented as user tasks in the automated process. To do so, the pharmacy technician who collects the drugs, and the pharmacist who quality-checks the prescription and seals the bag, should have a convenient mechanism to signal the completion of these activities to the BPMS. This could be achieved by putting in place a system based on barcode scans to track prescriptions. For example, the technician would see a list of prescriptions to be filled from their worklist. They would then pick up one of the prescriptions and the system would associate the prescription to a new barcode which is printed on an adhesive label. The technician would then attach the label to a bag, collect the drugs and put them in a bag, and when done, they would scan the barcode from the label to record that the prescription has been fulfilled. This signals the completion of task “Collect drugs from shelves” to the pharmacy system. In turn, it generates a new work item of task “Check quality” in the pharmacist’s worklist. The pharmacist can then quality-check the prescription and scan the barcode again. Task “Collect payment” is also a manual task. This task could be implemented as a service task whereby the pharmacy system would push the task of collecting the payment for a prescription to a Point-of-Sale (POS) system and expect the POS system to indicate that the payment has been collected. The pharmacy technician would interact with the POS system once the customer arrives, but this interaction is outside the scope of the pharmacy system. The pharmacy system merely pushes work to the POS system and waits for completion. The description of the process implicitly refers to a manual task whereby the pharmacist seals the bag and puts it into the pick-up area. However, this “Seal bag” task is not included in the executable process model. Instead, this task is integrated into the “Check quality” task. In other words, at the end of the quality check, the pharmacist is expected to seal the bag if the prescription is ready and drop the bag in the pick-up area. Task “Retrieve prescription bag” is also manual but there is no value in automating it in any way. So this task is left out of the executable process model, which completes once the payment has been made.

45 Posible solución TODO: Exercise 9.8 (prescription fulflliment process)

46 Elementos de BPMN irrelevantes para la ejecución
Objetos de datos físicos (en la práctica todos los objetos de datos porque los BPMS los gestionan de forma simplificada) Mensajes llevando objetos de datos físicos Data stores (en cualquier caso) Pools y lanes Anotaciones de texto Eliminar o ignorar, según el BPMS There are a few further elements besides manual tasks that are irrelevant for execution and that as such could potentially be removed or are actually not tolerated by the BPMS. These are: Data stores are not interpreted since the BPMS assumes the existence of an external service that can communicate with the data store, e.g. an Inventory information service that can access the warehouse DB in our example. In general, databases are accessed via DB adapters, e.g. a MySQL Adapter. So the BPMS will interface with these services rather than with the data store directly. Still, at the conceptual level, it may be relevant to explicitly represent the data store. Pools and lanes, you would be surprised, but are discarded by BPMSs. This is because they capture coarse-grained resource assignments, e.g. activity “Confirm order” is done within the sales department. When it comes to execution, we need to define resource assignments for each task and capturing this information via dedicated lanes (potentially one for each task) will just make the diagram too cluttered. Some BPMSs tolerate the presence of these non-executable elements too. If this is the case, we suggest to leave these elements in. Especially pools, lanes, message flows bearing electronic objects, electronic data stores and annotations will guide us in the specification of some execution properties. For example, the Sales lane in the order fulfillment model tells us that the participant to be assigned task “Confirm order” has to be from the sales department. Other BPMS modeling tools do not support these elements, so it is not even possible to represent them in the diagram.

47 3. Completa el modelo de proceso
Principio: las excepciones son la regla -> Añade manejadores de excepciones Principio: sin datos = no hay decisiones. -> Especifica todos los objetos de datos electrónicos (en función de la forma en que los soporte el BPMS) Huelga de controladores Process exceptions happen all the time and for as intelligent as a modern system can be, it can never foresee exceptions, which we need to implement, though it doesn’t need to be done all at once, it can be done in stages. Tech-related exceptions: system crash, network outage, service unavailability, data mismatch Bus-related: product discontinuation, order cancelation, out-of-stock items BAs legitimately think it’s not relevant for communication purposes, they assume it’s common knowledge or they are not (fully) aware of it. So first we need to Check for coverage of exceptions. Then we need to Specify all electronic data objects and split conditions

48 En nuestro ejemplo… So first we need to Check for coverage of exceptions. Then we need to Specify all electronic data objects and split conditions

49 En nuestro ejemplo… And there is virtually no limit to the number of exceptions we can capture in a model – it depends on how sophisticated is our system to be able to handle such exceptions. In other words, the more exceptions we add, the more robust the solution will be.

50 4. Ajusta la granularidad de las tareas
Principio: Los BPMSs añaden valor si coordinan el paso de trabajo de un recurso a otro. -> Fusiona tareas consecutivas asignadas al mismo recurso -> Refina las tareas que tengan un grano muy grueso There is not necessarily a 1-1 mapping between tasks in a conceptual process model and those in the executable counterpart. Principle: a BPMS is intended to coordinate and manage handovers of work between multiple resources (human or non-human). Accordingly, two or more consecutive tasks are candidate for aggregation. If this was the case, the BPMS would not add any value as it would not manage any handover of work Similarly, if an activity requires more than one resource to be executed, it is too coarse-grained and thus needs to be refined. Aggregation: Enter customer name, enter customer policy number and enter damage details into Enter claim, if performed by the same claims handler Refinement: Enter and approve money transfer, typically performed by two different participants with the same role, financial officer, in order to enforce a separation of duties

51 Cuidado: Busca por todos lados
Tareas candidatas para la fusión pueden no ser consecutivas debido a que el proceso no esté correctamente modelado. Let’s consider this example in the context of a loan assessment process. A loan officer has to first… Then an automatic check of the home insurance requirements is performed by the BPMS,

52 Una excepción a la regla
Remember the student admission process? Let’s take a look at this subprocess “Verify degrees validity”… While these may be performed by the same admin clerk, we do want to report the completion of each task to the BPMS for the sake of monitoring the progress of the application, for example for auditability, also because there is typically some idle time between each task (e.g. after the documents have been posted and before receiving the results). It is also useful in this case to manage potential exceptions. For example, if the results aren’t received within a given timeframe, we can handle this delay with an exception handler attached to this task.

53 Nuestro ejemplo… Después del paso 4 Before Step 1

54 5. Especificar propiedades de ejecución
-> Variables de proceso, mensajes, señales, errores -> Variables de tareas y eventos y su mapeado a variables de proceso -> Detalles de servicio -> Código de las tareas de script -> Reglas de asignación de recursos y estructura de la interfaz de usuario -> Expresiones en tareas, eventos y flujos de secuencia -> Otras específicas del BPMS: listas de tareas, formularios, conectores… So far we have obtained a “to-be-executed” process model. Up until this point, business analysts can be involved, so these first four steps are not a prerogative of technical staff. However, the last step is something that requires knowledge of the system and related technologies. In fact, in this step we need to specify:

55 Fundamentals of Business Process Management
Capítulo 9 Accesible en: Más información en: