1 Profesor: Dr. Rogelio S. Silverio Castro Departamento de Ciencias de la Computación Facultad de Matemática Física y Computación. UCLV Universidad Central Martha Abreu de las Villas “Significado y papel de Business Process Modeling, Service Oriented Architectures, Model Driven Architectures y Business Process Intelligence para la comprensión, desarrollo, implementación, explotación y perfeccionamiento de los Business Process Management Systems.”
2 Algunos conceptos
3 PROCESO DE NEGOCIO
4 Proceso de Negocio Un proceso de negocio consiste de una colección de actividades que son realizadas coordinadamente en un ambiente técnico y organizacional. La conjunción de estas actividades logra un objetivo del negocio. Los procesos de negocio toman una o mas tipos de entradas (precondiciones) y crea una salida (poscondición) que posee un determinado valor para el cliente. Ejemplo de proceso de negocio: Procesamiento de una orden “Una orden es recibida, una factura es enviada, el pago es recibido, los productos ordenados son remitidos y la orden es archivada” Envía la Factura + + Recibe el Pago Remite los Productos Recibe la OrdenArchiva la Orden
5 Procesos de Negocio: orquestación y coreografía Cada proceso de negocio es realizado por una organización simple, que puede interactuar con procesos de negocios realizados por otras organizaciones.
6 SISTEMAS DE INFORMACION EMPRESARIALES
7 Sistemas de Información Empresariales (objetivos)
8 Objetivos de los Sistemas de Información Empresariales Ser un instrumento para el control de los recursos y finanzas de la empresa y fundamento para la aplicación de herramientas de apoyo a la toma de decisiones, Garantizar el enrutamiento y coordinación de los tareas de los procesos de negocio, Ser un instrumento para el control de la información sobre la ejecución las instancias de los procesos de negocio para poder realizar análisis de: desempeño, de desviaciones del flujo planificado Asegurar cambios dinámicos de los procesos de negocios; todo esto con vistas a hacer a la empresa eficiente, competitiva y adaptable a los requerimientos del entorno.
9 Evolución de los EIS
10 De la orientación a datos a la orientación a procesos OS DBMS appl. DBMS W FMS appl. UIMS 1965-19751975-19851985-19951995-2005 UIMS
11 Inconvenientes de la orientación a datos En los sistemas orientados a datos la lógica de los procesos de negocio se define dentro de las aplicaciones y procedimientos manuales, lo cual tiene como desventajas: los procesos de las organizaciones deben ajustarse al sistema de información. se introducen ineficiencias tales como: pobre separación de responsabilidades, incapacidad de detectar cuellos de botella, operaciones secuenciales, innecesarias, pasos redundantes, etc. falta de control sobre las actividades de la organización como un todo dificultades para optimizar y adaptar los procesos de negocio a los cambios.
12 Los modelos de procesos sirven como medio de comunicación entre analistas de negocio e ingenieros en sistemas Los modelos de procesos permiten cambiar procesos de negocio sin modificar el código de los sistemas que soportan las tareas de los procesos La representación explícita de los procesos permite que los mismos puedan ser ejecutados y automatizados a través de un sistema de computación permite el control y monitoreo de los procesos. Beneficios de la orientación a procesos
13 Gestión de Procesos de Negocios Vs Gestión de Flujos de Trabajo
14 Aquel que no conoce la historia se ve obligado a repetirla In 1979, a small company called Ashton-Tate introduced a microcomputer product, dBase II, and called it a relational DBMS. In an exceedingly successful promotional tactic, Ashton-Tate distributed -nearly free of charge- more than 100,000 copies of its product to purchasers of the then -new Osborne microcomputers. Many of the people who bought these computers were pioneers in the microcomputer industry. They began to invent microcomputer applications using dBase, and the number of dBase applications grew quickly. As a result, Ashton-Tate became one of the first major corporations in the microcomputer industry. Later, Ashton-Tate was purchased by Borland, which now sells the dBase line of products. The success of this product, however, confused and confounded the subject of datábase processing. The problem was this: According to the definition prevalent in the late 1970s, dBase II was neither a DBMS nor relational (though it was marketed as both). In fact, it was a programming language with generalized file- processing (not database-processing) capabilities. The systems that were developed with dBase II appeared much more like those in Figure 1-9 than the ones in Figure 1-8. The million or so users of dBase II thought they were using a relational DBMS, when in fact, they were not. Thus the terms datábase management system and relational datábase were used loosely at the start of the microcomputer boom. Most of the people who were processing a microcomputer datábase were really managing files, and so they were not receiving the benefits of datábase processing, although they did not realize it.
15 Gestión de Procesos de Negocios Vs. Gestión de Flujos de Trabajo Jon Pyke Chief Technology Officer Staffware Plc
16 Gestión de Procesos de Negocios Los orígenes de BPM se remontan a la mitad de la década de 1970 cuando la automatización de procesos fue incluida como parte del prototipo de automatización de oficinas de at Xerox Parc (Officetalk, desarrollado por by Skip Ellis y Gary Nutt) y Wharton (SCOOP, desarrollado por Michael Zisman). La primera vez que se utiliza en un documento el termino “Business Process Management” es en un articulo de Frank Leymann y Wolfgang Altenhuber de IBM, en 1993, pero este término no entro en el lenguaje de los analistas de sistemas y vendedores de software hasta el año 2000, momento en que se volvió un “hit”, cuando fue utilizado por BPMI.
17 Campos emergentes en el área de BPM Debido a la popularidad del término Business Process Management los vendedores de los tres importantes campos que competían en esta área: los vendedores de Sistemas de Gestión de Procesos de Negocio.(BPMI) los productores tradicionales de Workflow. (WfMC) los vendedores de orquestación de servicios e integración dieron su propia definición de BPM, en función a las características de sus productos.
18 Enfoque de los productores tradicionales de Workflow (WfMC) La gestión de flujos de trabajo es: “la automatización de los procesos de negocio, completamente o en parte, durante la cual documentos, información o tareas son pasadas de un participante a otro para alguna acción, de acuerdo de un conjunto de reglas de procedimientos” Un Sistema de Gestión de Flujos de Trabajo es: “un sistema que define, crea y gestiona la ejecución de flujos de trabajo (workflow) mediante el uso de software, siendo capaz de interpretar la definición del proceso, interactuar con los participantes y, siempre que se requiera, invocar el uso de herramientas y aplicaciones”
19 Enfoque de los productores tradicionales de Workflow La tecnología de workflow es capaz de soportar los procesos de negocio dentro de un sistema de aplicaciones o entre varios sistemas de aplicaciones integrando los mismos
20 Enfoque de los vendedores de Sistemas de Gestión de Procesos de Negocio Definición: La Gestión de los Procesos de Negocio incluye conceptos, métodos y técnicas para soportar el diseño, la administración, la configuración, el lanzamiento y análisis de los procesos de negocio. La Gestión de los Procesos de Negocio se basa (fundamenta, utiliza) en la representación explicita de los procesos de negocio con sus actividades, encadenamiento y restricciones. La Gestión de los Procesos de Negocio incluye el lanzamiento, ejecución y control de las instancias de los modelos de Procesos.
21 Enfoque de los vendedores de orquestación de servicios e integración Para los vendedores de orquestación de servicios e integración para el desarrollo de los sistemas de software los términos BPM y WorkFlow significan: BPM es todo lo que tiene que ver con procesamiento “systems-to-systems” y Workflow es todo sobre el aspecto Humano. Nota: Un proceso de negocio necesita tener en cuenta todos los recursos que se requieren para hacer un trabajo – el aspecto humano no puede ser ignorado ya que la mayoría de procesos negocio implica interacción humana.
22 Gestión de Procesos de Negocios Vs Gestión de Flujos de Trabajo “ True Business Process Management is an amalgam of traditional workflow and the 'new' BPM technology. It then follows that as BPM is a natural extension of – and not a separate technology to – Workflow, BPM is in fact the merging of process technology covering 3 process categories: interactions between (i) people-to-people; (ii) systems-to-systems and (iii) systems-to-people all from a process-centric perspective. This is what true BPM is all about.” Jon Pyke Chief Technology Officer Staffware Plc
23 Algunas aspectos a resaltar Los procesos de negocio poseen diferente grados de complejidad**, la cual debe ser evaluada para seleccionar el producto o herramienta mas idónea para la automatización del mismo. ** La evaluación de cual producto o sistema utilizar es un proceso no trivial, para el cual se debe tener en cuenta como sus herramientas soportan el ciclo de vida de los Sistemas de Gestión de Procesos de Negocios A.Según los tipos de participantes: personas y/o aplicaciones. (Aplicaciones vs Orientación a Personas) B.Según el grado de estructuración del proceso para su automatización. (Estructurados vs Desestructurados) C.Según el alcance o dominio de los mismos. (Organizacionales vs Inter-Organizacionles)
24 CICLO DE VIDA DE LOS SISTEMAS DE GESTIÓN DE PROCESOS DE NEGOCIOS
25 Ciclo de vida de los Sistemas de Gestión de Procesos de Negocios El ciclo de vida de los Sistemas de Gestión de Procesos de Negocios tiene cuatro fases: diseño del proceso implementación (configuración o ensamblaje) lanzamiento o promulgación de procesos( ejecución) y diagnostico de procesos
26 Aéreas de conocimiento que soportan las fases del ciclo de vida de los Sistemas de Gestión de Procesos de Negocios Service Oriented Architectures Model Driven Architectures Business Administration Principles Business Process Modeling Business Process Intelligence Data Warehouse Data mining Business Process Mining Business Process Query Language (BPQL) Modelación del proceso de Negocio Modelación del Sistema de Información
27 Diseño de procesos
28
29
30
31 Grupos de investigación y desarrollo de estándares para la modelación de los procesos de negocio Grupos de investigación OMG. Object Management Group. WfMC. Workflow Management Coalition. BPMI. Business Process Management Initiative. BPMG. Business Process Management Group. ebXML. UN/CEFACT and OASIS. Eindhoven University of Technology. WARIA. Workflow and Reengineering International Association Lenguajes y estándares Diagrama de Actividad de UML. SPEM. Software Process Engineering Metamodel. BPMN. Businees Process Moedeling Notation. XPDL. XML Workflow Definition Language. jBPM-jPDL. jBOSS Process Definition Language. IDEF. ICAM Definition Language. ARIS-EPC Event-Driven Process Chain.
32 Algunos criterios para la selección del lenguaje de modelación de procesos de negocio (I) La capacidad de modelar la complejidad de los procesos de negocio, es decir la expresividad. Para esto se debe comprobar el soporte que dan las distintas notaciones a los patrones de workflow. La capacidad de representar roles y su asignación a diferentes tareas. Capacidad para especificar las características de calidad de los procesos de negocio. Capacidad para especificar repositorios de procesos que nos permitan la reutilización de procesos mediante la utilización de conceptos como la variabilidad y la extensibilidad. Capacidad para especificar atributos que nos permitan gestionar los procesos (monitorizar, controlar o planificar los mismos).
33 Algunos criterios para la selección del lenguaje de modelación de procesos de negocio (II) Permitir una vista multinivel de los procesos para partiendo de descripciones mas comprensibles de alto nivel tener la posibilidad de alcanzar niveles con gran cantidad de detalles. Ser comprensible para aquellos que no son especialistas en modelado. Permitir la integración y soporte para otro tipo de notaciones que nos facilitaría una mejor interacción entre las herramientas que den soporte a estas notaciones. Posibilidad de enlazar de manera directa una actividad con un fragmente de código en un lenguaje de programación. La existencia de herramientas para trabajar con ella.
34 Patrones de Workflow Los patrones de workflow surgen de la investigación de “Wil van der Alst” de la Eindhoven University of Technology y se han convertido en el criterio estándar para el análisis de la expresividad de los lenguajes o notaciones de procesos de negocio. Los patrones de workflow: Están ampliamente difundidos. Han sido aceptados por la comunidad investigadora. Son comprensibles por los profesionales de la informática. Presentan el nivel de abstracción adecuado para comparar las características de los lenguajes y notaciones de modelado de procesos de negocio.
35 Patrones de WorkFlow
36 Ejemplo de diagrama de actividad en UML 2
37 BPMN (Business Process Modelling Notation)
38 Comparación de lenguajes de modelación de Procesos de negocio en base a los patrones de Workflow
39 Aéreas de conocimiento que soportan las fases del ciclo de vida de los Sistemas de Gestión de Procesos de Negocios Service Oriented Architectures Model Driven Architectures Business Administration Principles Business Process Modeling Business Process Intelligence Business Process Mining Data Mining Data Warehouse Business Process Query Language (BPQL) Modelación del proceso de Negocio Modelación del Sistema de Información
40 Modelado de Sistemas de Información Enfoques para el Modelado estructurado, el bloque para construcción de todo el software es el procedimiento o función orientado a objetos, el bloque de construcción de todo el software es el objeto o clase (Booch et al., 1999). orientado a servicios, el bloque principal para la construcción del software son los servicios. Un servicio se define como “un recurso abstracto que representa una capacidad de realización de tareas que forman una funcionalidad coherente desde el punto de vista de las entidades proveedoras y de las entidades solicitantes”
41 Computación Orientada a Servicios
42 Servicios asociados a Procesos de Negocio en un desarrollo SOA
43 Arquitectura dirigida por modelos
44 La modelación de procesos de negocios y la ingeniería dirigida a modelo (MDE) Los modelos de procesos de negocio se utilizan para integrar la definición, el modelado y el análisis de procesos dentro de las metodologías de desarrollo que tienen un enfoque MDD/MDA (Model Driven Development/Model Driven Architecture) con el objetivo de ir automatizando, el desarrollo de productos software dentro de un dominio determinado. La ingeniería dirigida por modelos (MDE) ayuda a transferir los cambios en los procesos de negocio a los sistemas que implementan dichos procesos.
45 BUSINESS PROCESS INTELLIGENCE
46 Business Process Intelligence Business Process Intelligence consiste en la aplicación de las técnicas Business Intelligence a la información sobre la ejecución de los procesos de negocio almacenada en los denominados Log de procesos con vista a realizar: Análisis de desempeño, con vistas a mejorar el mismo. Análisis Delta, o sea cuanto nos separamos del proceso especificado Descubrimiento de procesos
47 Business Process Intelligence
48
49
50 Los Sistemas de Gestión de Procesos de Negocio (BPM) almacenan información en los denominados “log de ejecución” (Workflow Log) sobre la ejecución de las diferentes instancias de los procesos de negocio a los que ellos dan soporte Ejemplos de tal tipo de información son: las actividades que componen a los procesos para los procesos y actividades: instante en que se ha iniciado o ha finalizado la Las entrada y salidas de datos para cada actividad y cada proceso el recurso que ejecuta cada actividad y cada proceso estado final alcanzado (terminación con éxito o sin éxito) instante en que un cierto recurso es utilizado cualquier fallo ocurrido durante la ejecución Recursos Actores, etc
51 Esquema de un almacén de datos para el análisis del desempeño en general de un proceso de negocio
52 Ejemplo de aplicación del Procesamiento Analítico en Línea para el análisis de desempeño en general de un proceso de negocio A continuación se muestra un cubo de datos con tres dimensiones Procesos, Estado y Tiempo y la medida cantidad.
53 Ejemplo de aplicación del Procesamiento Analítico en Línea para el análisis de desempeño en general de un proceso de negocio Para la vista (Task) se visualiza la medida Duración. Si elegimos como nivel de la jerarquía las actividades, tenemos el resultado que de forma gráfica visualiza la figura izquierda. Si elegimos por procesos, es decir, subimos el nivel de granularidad, el resultado obtenido es el que muestra la figura de la derecha.
54 Ejemplo de reglas de asociación que pueden ser minadas en un almacén de datos para el análisis del desempeño en general de un proceso de negocio Asociaciones entre elementos de un flujo de trabajo. (Asociación inter-atributos). “el 75 % de las veces que se ejecuta la actividad A 1, el usuario que la lleva a cabo es U 1 ”. Asociaciones entre valores de un mismo elemento del flujo de trabajo. (Asociación intra-atributos). “el 80% de las veces que se ejecuta la actividad A 1, también se ejecuta la actividad A 4 ”. Asociaciones entre elementos de un flujo de trabajo y sus valores. (Asociación híbrida). “el 80% de las veces que se ejecuta la actividad A 1 por el usuario U 1, también se ejecuta la actividad A 8 por el U 1 ”; “ el 70% de las veces que se ejecuta la actividad A 1 y se envía el dato D 1, la ejecución de la actividad A 5 acaba en fallo”.
55 Esquema de un almacén de datos para el análisis del desempeño en particular del proceso de negocio “cirugía”
56 Business Process Intelligence
57 Descubrimiento de Procesos
58 Relaciones entre tareas inducidas a partir del Workflow Log. case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B case 5 : task F case 4 : task D
59 Relaciones entre tareas inducidas a partir del Workflow Log. case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B case 5 : task F case 4 : task D A>B A>C B>C B>D C>B C>D E>F ABACBDCDEFABACBDCDEF B||C C||B
60 Transformaciones de sucesiones de relaciones entre tareas en diagramas expresados como redes de Petri x y x y, x z, and y||z x y, x z, and y#z x z, y z, and x||y x z, y z, and x#y XY X Z Y X Y Z X Z Y X Z Y
61 (W):Resultado de la aplicación del algoritmo Alpha a un workflow low case 1 : task A case 2 : task A case 3 : task A case 3 : task B case 1 : task B case 1 : task C case 2 : task C case 4 : task A case 2 : task B case 2 : task D case 5 : task E case 4 : task C case 1 : task D case 3 : task C case 3 : task D case 4 : task B case 5 : task F case 4 : task D (W) W
62 Algunos aspectos a resaltar Los procesos de negocio pasan a ser elementos de primera categoría dentro de los Sistemas de Información Empresariales por la importancia de los siguientes aspectos en el logro de la competitividad de las empresas: Garantizar el enrutamiento y coordinación de los tareas de los procesos de negocio, Ser un instrumento para el control de la información sobre la ejecución las instancias de los procesos de negocio para poder realizar análisis de: desempeño, de desviaciones del flujo planificado Asegurar cambios dinámicos de los procesos de negocios
63 Algunos aspectos a resaltar En el proceso de diseño se debe conjugar: la visión del negocio centrada en especificar y mejorar sus procesos mediante análisis del negocio, la visión de las tecnologías de la Información centrada en informatizar dichos procesos utilizando las tecnologías y metodologías de desarrollo de software
64 Algunos aspectos a resaltar Los patrones de workflow son básicos en la modelación de los Procesos de negocio para el enrutamiento de los tareas, además de ser un criterio para evaluar la expresividad los lenguajes de modelación. Las redes de Petri son un instrumento para comprobar las propiedades estructurales y dinámicas de los flujos de trabajo modelados con ellas.
65 Algunos aspectos a resaltar Las tendencias y desarrollos en los últimos años en la producción de Software han conducido a que: El modelado arquitectónico va reemplazando al diseño y especificación clásica La programación se va transformando en configuración y orquestación Los componentes son reemplazado en un sistema que esta funcionando de forma que la reconstrucción es un proceso continuo de perfeccionamiento Por lo que: Las empresas productoras de software clásicas se están convirtiendo en integradoras de sistemas Los programadores son reemplazados cada vez mas por asesores que ayudan a los clientes en la selección, configuración e integración de componentes. El mercado crece fundamentalmente para las fabricas de software que construyen componentes genéricos para un área funcional especifica ( el mercado horizontal) o para un tipo particular de negocio (el mercado vertical)
66 MUCHAS GRACIAS