Business Intelligence, relación Datawarehouse, Datamart, Cubos OLAP, y ETL

Esto no pretende ser una introducción a “Business Intelligence”, sino solo un resumen practicó de cómo se implementa, y la relación de sus principales componentes, podríamos verlo como una Ficha Resumen (ayuda de memoria).

Business Intelligence, relación Datawarehouse, Datamart, Cubos OLAP, y ETL

Business Intelligence, relación Datawarehouse, Datamart, Cubos OLAP, y ETL

Business Intelligence: conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización.

Datawarehouse: base de datos especial para toma de decisiones de negocio, bases datos solo lectura, que contiene la relación completa de los principales datos de negocio. En el enfoque bottom –up, Datawarehouse es la unión de todos los Datamart.

Datamart: Datawarehouse especifico a un área de la negocio o de la organización orientada a decisiones de dicha área. Los Datamart se analizan mediante herramientas OLAP.

OLAP: procesamiento analítico en línea, para ello utiliza estructuras multidimensionales llamadas “Cubos OLAP”, permite “jugar” con la información de Negocio, obteniendo distintas vistas (reportes) de la información.

Cubos OLAP: contienen datos resumidos de Datamart u otros tipos de Bases de Datos, en un formato especial para Análisis, son bases de datos multidimensionales. Este tipo de base de datos multidimensional esta optimizada para las consultas query, a diferencia de las bases de datos relacionales que están orientadas a la transaccionalidad (OLTP).

Bajo un producto específico de BI como Pentaho (Opensource), tenemos las siguiente herramientas (http://community.pentaho.com/projects/bi_platform/ ):

  • Servidor Reporting y Análisis OLAP: servidor que permite generar vistas y reportes con información de negocio, además de análisis cubos OLAP; “Pentaho Reporting”.
    http://reporting.pentaho.com/

Orquestadores y SOA

Existen tecnologías dentro del ambiente SOA, y BPM, que tienen mucho en común, y por lo tanto muchas veces no se logra visualizar de forma clara sus diferencias, estamos hablando de los “coordinadores de tareas”, u “orquestadores” en general , herramientas que permiten organizar actividades en un flujo. Bajo este concepto podemos tomar:

  • ETL (Extract Transform and Load)
  • WorkFlow tradicional
  • ESB (Enterprise Service Bus)
  • BPM o BPMS (Business Process Management Suite)

Estas herramientas en general permiten a través de asistentes gráficos crear un proceso a partir de la organización de tareas, o subprocesos.

Extract, Transform and Load (ETL)

Nacida para traspasar información desde un repositorio de datos origen a uno destino, esta tecnología esta orientada a los procesos de datos, procesos basados en repositorios como Base de Datos y archivos.

ETL es una de las tecnología mas antiguas de integración, integración a nivel de datos, y tal como las Bases de Datos relacionales su utilidad se ha consolidado en el tiempo. Incluso en la actualidad dentro de la “Arquitectura Orientada a Servicios” (SOA) tiene su puesto en lo que son los “Servicios de Información”, porque a pesar de que su principal uso es en procesos Batch (procesos de actualización masivos), también se puede usar para el desarrollo de funcionalidades especificas pero que involucran la integración de entidades de información dispares (distintas).

Tal como su nombre lo indica permite Extraer (Extract), Transformar (Transform), y Cargar (Load), información desde, y hacia distintas fuentes de datos.

  • Extraer: permite extraer la información de distintas fuentes de datos, principalmente bases de datos, y de la mayoría de los proveedores conocidos: Oracle, Sybase, DB2, MySQL, esto lo hace directamente desde las tablas, o usando “Stored Procedures” existentes. También permite extraer datos de archivos como XML, Excel, CSV, Texto, entre otros. Y han evolucionado hasta incluso obtener información de colas de mensajes, objetos Java, y Webservices, abarcando de cierta forma el terreno de los ESB.
  • Transformar: a través del manejo de Metadata (datos en un formato estándar desacoplado de la fuente) permite unir la brecha existente debido a la diferencia de los tipos de datos, por ejemplo el proceso de información “Actualizar Datos de un Cliente” que involucra actualizar en distintos lugares, puede requerir que un dato que esta en entero deba pasarse a tipo float (real), o que los apellidos que están separados en una base de datos deban guardarse juntos en un solo campo en otra base de datos, o que un código de comercio que esta en cierto estándar (como EAN) se deba traducir a otro estándar (como ISBN) porque así se maneja en el otro repositorio.
  • Cargar: permite guardar la información procesada en la misma diversidad de entidades que maneja dentro de la extracción: Bases de Datos, y archivos de distinto tipo.

En la actualidad las herramientas de ETL permiten componer estos procesos mediante asistentes gráficos, ambientes de desarrollo (IDE) que realizan una introspección de las fuentes de datos, obteniendo todos los objetos y sus campos de datos, permitiendo a través de “arrastrar y soltar” construir el flujo de proceso de datos. Además pueden incorporar reglas de negocio que permiten potenciar la funcionalidad del procesos.

Ejemplo: Proceso de Información Agrega Nuevo Producto

Proceso ETL

A este proceso ejemplo se le entrega un producto, el cual lo transforma en metadata, para poder por un lado obtener la marca asociada (desde una base Sybase), y por otro lado su código EAN (usando un Stored Procedure), si el código EAN no existe se busca en un archivo XML, luego finalmente toda la información se carga en la tablas de Productos (Base DB2), y además se registra en un archivo de Log (archivo txt). Mas que nada este ejemplo sirve para mostrar la relación que se puede establecer entre los distintos objetos ETL, pero la estructura definitiva de un diseño ETL dependerá de la herramienta que se utilice.

Los principales objetos que maneja un ETL son:

  • Tablas de Bases de Datos
  • Procedimiento Almacenados (Stored Procedures)
  • Archivos XML
  • Archivos de Texto, Archivos Excel.
  • Transformaciones de Datos.

Otra característica que ofrecen actualmente los ETL, y que es muy importante para la Arquitectura SOA, es que los procesos ETL se pueden ejecutar como WebServices, para lo cual el motor de ETL publica el proceso en formato SOAP, pudiendo ser ejecutado desde cualquier plataforma (Java, .Net), y ser integrado en tecnologías como ESB (Enterprise Service BUS).

Luego, en el contexto de SOA podríamos indicar que ETL es la herramienta que permite diseñar y construir procesos de información (servicios de información) basados en actividades (automatizadas) a nivel de datos.

Algunas herramientas ETL del mercado son:

WorkFlow Tradicional

Decimos WorkFlow “Tradicional”, porque la forma actual y bajo SOA de implementar un workflow es BPM, pero existen aun tecnologías WorkFlow tradicionales (no BPM), pero la mayoría se esta transformando en soluciones BPM.

La verdad es que actualmente muchas herramientas WorkFlow se acercan a lo que es BPM, viéndolo solo desde el punto de vista del flujo de los procesos de negocio, por eso aquí vamos a ver el concepto de WorkFlow Tradicional que se refiere al WorkFlow como era antes de evolucionar a BPM.

WorkFlow (Tradicional) es la tecnología que permite coordinar actividades humanas (realizadas por personas, Human Task), aquí se definen roles, actividades, reglas de negocio, en buenas cuentas un flujo de trabajo (WorkFlow), pero que a diferencia de BPM no contempla en forma natural los “servicios de negocio”, es decir no contempla las actividades de sistemas (System Task) bajo el estándar SOA.

Ejemplo: WorkFlow Actualizar Stock de Productos

Proceso WorkFlow

Este WorkFlow ejemplo define un procesos donde un ejecutivo ingresa Stock de productos, el supervisor verifica el stock ingresado, y si es un producto nuevo además verifica la ficha del producto, si por alguna razón no se valida el registro vuelve al ejecutivo, quien debe corregir el ingreso. Este es un ejemplo genérico, la estructura del diseño del proceso dependerá de la herramienta utilizada.

Luego en una solución (WorkFlow tradicional) el participante (usuario) debe indicar el cumpliendo de la tarea (cambio de estado), para de esta forma continúe el flujo de trabajo, y cuando debe interactuar con algún sistema, debe levantar dicho sistema y realizar la actividad en él, por ejemplo ejecutar el sistema de stock para agregar un nuevo producto.

Esa es otra gran diferencia con BPM, en BPM se trata de proveer una sola interfaz para un participante del proceso, ocultando la interacción con los sistemas, mientras en un WorkFlow (tradicional) la persona debe interactuar con distintos ambientes o aplicaciones, dicho de otra forma: la persona debe manejar distintas aplicaciones (sistemas), y además registrar su avance en el WorkFlow.

Con WorkFlow (al igual que BPM) se le da seguimiento y control a los procesos de negocio, es decir, podemos saber el estado actual de cada proceso, en que lugar del flujo se encuentra. Otra similitud con BPM , o dicho de otra forma; otra característica que BPM heredo de los WorkFlow, es que a través del proceso generalmente fluye información (documentos, datos), lo que se llama la metadata, u objeto de negocio (BPM).

Enterprise Service Bus (ESB)

Esta tecnología permite integrar sistemas a nivel de servicios, cuando se habla de tecnología para implementar SOA en una empresa la primera herramienta que se debe incorporar es el “Service Bus”.

Esta herramienta permite componer procesos a partir de servicios SOA, los servicios SOA son componentes funcionales encapsulados fuertemente reutilizables, haciendo el “típico” símil: son piezas de lego que permiten construir un sistema uniendo bloques, y en este caso construir un proceso uniendo servicios SOA.

Proceso ESB Actualiza Producto en Sistemas

Proceso ESB

En este proceso ejemplo se entrega el producto a actualizar se comprueba el tipo de producto (Ecommerce o SAP), usando una clase Java (conecto EJB), luego se actualiza en el sistema Ecommerce usando un WebService, o se actualiza en el sistema SAP usando un conector provisto por el ESB.

Al igual como BPM absorbió las funcionalidades de WorkFlow (a través de BPEL4People), también absorbió las funcionalidades del ESB (a través de BPEL), de hecho las BPMS (BPM Suite) suelen traer como parte de sus componentes el ESB.

La diferencia con BPM es que el ESB no maneja las actividades humanas (Human Task) solo maneja actividades automatizadas (System Task).

La diferencia con ETL (tradicional) es que ETL esta orientado a componentes de datos, y ESB esta orientado a componentes de Servicios.

Los objetos que principalmente maneja ESB son:

  • WebServices
  • Conectores a Colas de Mensajes, y JMS
  • Conectores a Aplicaciones de clase Mundial (PeopleSoft, SAP, JDEdwards)
  • Conectores a J2EE (EJB) y .Net
  • Transformaciones de Datos

Los ESB también manejan Metadata para la transformación de datos, y para lograr que los sistemas se entiendan a pesar de la diferencia en los tipos de datos que manejan.

Una característica importante es que los procesos se pueden ejecutar a través de WebServices, es decir un proceso de negocio ESB se puede publicar en protocolo SOAP, permitiendo que una gran variedad de plataformas puedan acceder a estos procesos.

Algunos ESB tienen conectores para Base de Datos, permitiendo integrar consultas a tablas (SQL Query), y procedimientos almacenados (Stored Procedures), con esto el ESB comienza abarcar terreno de los ETL, pero a decir verdad esta característica pone en riesgo la orientación a servicios (SOA), ya que los servicios deben corresponder a la capa de negocio, y no a la de datos.

Algunos ESB importantes:

Resumiendo ESB desde el punto de vista SOA es la herramienta que permite desarrollar procesos basado en servicios SOA.

BPM Suite.

BPM es la solución que permite construir procesos de negocio basado en coordinar tanto actividades interactivas (human task), como servicios (system task). BPM une lo mejor del mundo del WorkFlow Tradicional con el ESB.

En un mismo flujo se integran tareas realizadas por personas, con tareas automatizadas(sistemas), entregándole al participante de un proceso de negocio una sola interfaz, ocultando la interacción con los sistemas legados.

Ejemplo Proceso de Negocio Actualizar Stock de Productos

Proceso BPM

Basado en los ejemplos anteriores, en este proceso se integran 2 servicios al WorkFlow “Actualizar Stock”: una vez ingresado el stock, si el producto existe, entonces se obtiene los datos del producto usando un “WebService” (Obtiene Ficha Producto), y si el supervisor valida el ingreso al final se actualiza el producto usando otro “WebService” (Actualiza Producto), este ultimo servicio se supone es el proceso ESB “Actualiza Producto en Sistemas” publicado como WebService. Este es un ejemplo simplificado, en la realidad puede ser necesario incluir algunos servicios más.

La otras características de valor agregado de BPM son: que ofrece un grupo de herramientas para atender todo el ciclo de visa de un proceso de negocio, dentro de las cuales se destaca, el modelador (diseño procesos), el IDE (desarrollo de servicios), y el monitor (BAM), este ultimo que permite realizar un seguimiento y control mas acabado de los procesos de negocio.

Orquestadores en la Arquitectura de Referencia SOA

Desde el punto de vista de arquitectura marco SOA, los orquestadotes se organizan de la siguiente forma:

ETL, ESB, BPM, SOA

Xtreme BPM (Extreme BPM) o Agile BPM 2.0

Registered at RegisteredCommons.org

Implementar procesos de negocio bajo el enfoque BPM es una tarea compleja que requiere de la Organización bastante disciplina, y un nivel de madurez metodológico y en estándares alto, esto se traduce en:

  • Tener un acabado conocimiento de los Procesos del Negocio.
  • Dominar la orientación a servicios (SOA).
  • Aplicar varias tecnologías nuevas (XML, WebServices, EBUS, BAM, Portlets, J2EE, .NET, BPEL, BPEL4People, etc.)
  • Tener un esquema de control y apoyo adecuado (Governance).

Luego con tanto prerrequisito implementar BPM puede o tomar mucho tiempo, o involucrar una alta inversión inicial. Entonces ¿Como podemos comenzar a implementar BPM ahora, sin tener que hacer una inversión tan riesgosa?.

A continuación se presentará una alternativa utilizando el enfoque “Ágil” (Agile), el mismo en el que se fundamenta “Xtreme Programming” (XP), a este nuevo enfoque le llamaremos XtremeBPM.

Los principios “Ágiles” son:

  • Simplicidad: consiste en desarrollar solo lo que se necesita actualmente, entregar soluciones simples pero escalables. Los proyectos deben ser de corto plazo. Es muy complejo predecir el futuro.
  • Retroalimentación: el proyecto se divide en pequeñas partes que se desarrollan y prueban, obteniendo una retroalimentación del usuario antes y oportuna.
  • Comunicación: propone una comunicación directa y continua entre clientes y desarrolladores, el cliente se integra en el equipo para establecer prioridades y resolver dudas, y de esta forma ve el avance día a día.
  • Decisión (Courage): enfrentar los problemas inmediatamente, mejorar el sistema si la retroalimentación lo sugiere, y enfrentar los cambios de plan apenas se identifican.

Si nos detenemos en estos principios podremos ver que están en total concordancia con los objetivos de BPM:

  • Integración de TI y Negocio: BPM acorta la brecha entre negocio y TI, y refuerza el concepto de que las soluciones estén basadas directamente en los objetivos de negocio, y en los procesos de negocio. Esto esta directamente relacionado con los principios ágiles de comunicación y retroalimentación.
  • Enfoque Evolutivo: BPM descarta totalmente los enfoques BigBang (revolución en los sistemas), propone un enfoque evolutivo, comenzando por la implementación de algunos procesos de negocio, los principales, y al igual que SOA realizando primero los componentes mas reutilizables, y con el tiempo ir sumando soluciones. A lo mismo que apunta el principio de la “simplicidad” (enfoque ágil).
  • Time2Market: otro objetivo de BPM es salir con las soluciones en forma oportuna, y lograr adecuarse lo mas rápido posible a los cambios del mercado, a los cambios de negocio. El principio ágil de la “Decisión” (Courage) para enfrentar los cambios va en la misma dirección.
  • Ciclo de Vida Procesos: BPM se basa en el ciclo de mejoramiento continuo de los procesos de negocio pasando por el modelamiento, simulación, publicación, ejecución, y monitoreo de los procesos, donde el monitoreo retroalimenta al modelo con estadísticas reales del proceso. Los mismos fundamentos que hay detrás de los principios ágiles de simplicidad y retroalimentación; soluciones que van a mejorando en el tiempo.

La idea de XtremeBPM es ir avanzando en forma acorde al desarrollo de las capacidades de la Organización, comenzando por los pasos mas fáciles de BPM, e ir aumentando la complejidad, y mejorando la solución en forma continua.

Antecedentes de BPM.

Un proceso de negocio se puede definir como una secuencia de actividades para lograr un objetivo o meta de negocio, por ejemplo en un Banco el proceso para “Otorgar un Crédito de Consumo”. En esta definición es importante recalcar lo de “objetivo de negocio”, porque permite diferenciarlos de los otros procesos, por ejemplo el proceso de “Impresión Masiva de Contratos” no es un proceso de negocio, porque no logra una meta de negocio sino una meta operativa, es un proceso informático, lo que si; puede ser parte de un proceso de negocio.

Proceso de Negocio Otorgar Credito de ConsumoEl modelo del proceso de negocio es el componente fundamental de BPM, porque este modelo (o flujo) es el que de cierta forma se ejecuta en el motor de BPM (el Process Server).

El proceso de negocio (su modelo BPM), se compone principalmente de:

  • Actividades: son las tareas que debe hacer una persona (tarea interactiva, human task), o debe hacer un sistema (servicio, o system task) dentro del proceso de negocio. Por ejemplo “Revisar Antecedentes Financieros” (actividad interactiva), o “Imprimir Contrato” (servicio de un sistema).
  • Roles y Usuarios: son los responsables de ejecutar las tareas interactivas, por ejemplo un “Ejecutivo” de un Banco.
  • Objeto de Negocio: es la información o documento que fluye a través del proceso de negocio, por ejemplo la “Solicitud de Crédito”, o el “Crédito de Consumo” (en que se transforma la solicitud), o la “Ficha del Cliente”.
  • Flujos (flechas): es la secuencia que se define entre las actividades.
  • Decisiones: criterios para tomar distintas opciones en el procesos, distintas direcciones en el flujo.
  • Subproceso: otro proceso interno.

Componenetes Modelo BPM

Obstáculos que enfrenta BPM.

A continuación presentaremos los principales obstáculos que presenta un proyecto BPM.

Modelar la Realidad una Tarea Compleja

Como se indicó; el modelo del proceso de negocio es el núcleo de la solución BPM, pero plasmar un proceso real en un modelo es una tarea compleja. Lo que sucede es que la realidad tiene excepciones, es variable, y un modelo trata de “fijar” las reglas.

Otro alcance en BPM es que como el modelo del procesos es el motor de la solución, el nivel de detalle requerido es mucho mayor, porque el modelo ya no solo tiene un objetivo “didáctico” o de documentación de los procesos, en BPM tiene que tener el suficiente detalle como para ser ejecutado.

Si nos damos cuenta un modelo “tradicional” de un proceso de negocio se centra en el “camino feliz” (HappyPath), es decir en el caso que todo anda bien, como en el ejemplo del diagrama anterior “Otorgar un Crédito de Consumo” donde el flujo muestra el caso de un Cliente “ideal”, que cumple todos los requisitos para que se le otorgue un crédito: tiene un patrimonio adecuado, no tiene deudas, y no tiene antecedentes penales, este modelo para efectos de “mostrar” el proceso puede ser suficiente, pero el “camino feliz” es solo la punta del iceberg en un proceso real cada excepción determina varios nuevos caminos en el flujo (decisiones), incluso las excepciones en combinación pueden determinar otros caminos:

  • Que sucede si le patrimonio no es suficiente.
  • Que sucede si tiene deudas en el sistema.
  • Que sucede si tiene antecedentes
  • Que sucede si se arrepiente de firmar una vez aprobado el crédito.
  • Que sucede si tiene antecedentes pero en el ultimo tiempo es un Cliente ejemplar, y su patrimonio es importante.

Luego las excepciones hacen bastante mas complejo el modelo, pero son necesarias para su ejecución.

Y hay otro tipos de excepciones que son comunes, y que también “dificultan” la implementación de un proceso, como la “generalización” de los roles, por ejemplo el “Supervisor” (de una sucursal) es quien “Autoriza el Crédito”, pero en la realidad existe una sucursal pequeña donde lo autoriza específicamente “Juan Perez” que es un Ejecutivo Senior, en este caso no podemos asignarle el rol de supervisor a “Juan Perez” porque le entregaríamos otros privilegios, y dependiendo de la solución BPMS la alternativa incluso puede ser crear un rol especial para un solo caso.

También en la realidad se da el caso de que el flujo depende del criterio de un experto el cual decide cual es la próxima tarea, y la próxima tarea puede ser un subconjunto grande de posibilidades, luego difícilmente vamos a modelar todas las flechas de salida hacia todas las actividades posibles.

caso Experto

Incluso puede ser aun mas complejo: un experto no solo determina la próxima actividad sino toda una forma de flujo especial en cada caso.

Luego, el modelo para realmente operar, se comienza a alejar del modelo inicial entregado por el área de negocio, y tratar de lograr obtener una primera versión funcional del proceso se hace realmente difícil de lograr.

Generalmente lo que se hace en estos casos es que se implementa solo el “camino feliz” y las excepciones se manejan como cajas negras, o simplemente se dejan fuera de la implementación inicial del proceso, pero esto deja muchas funcionalidades sin implementar.

Importancia del Manejo de Excepciones.

El “camino feliz” generalmente es la ejecución (flujo) mas común de un proceso de negocio, que puede corresponder el 70% de los casos reales, luego una solución BPM que implemente solo este flujo estaría apoyando el 70% de los procesos que se ejecutan, pero desde el punto de vista de gestión, el 30% que queda fuera, puede ser tanto o mas importante en cuanto a información , seguimiento y control.

Un caso especial o excepción puede transformarse en un”taco” dentro del flujo del proceso, luego es importante conocer las actividades que se realizaron en el manejo de la excepción, y cuanto demoraron. Si las excepciones se manejan como “cajas negra” entonces ¿Como identificaremos los casos especiales, que se hacen tan comunes que ya deberían ser parte del flujo?.

Modelar por Partes.

Otra forma de hacer mas manejable la implementación de un proceso de negocio con BPM, es empezando con una parte del proceso, donde si se manejen la mayoría de sus excepciones, en el ejemplo del proceso de “Otorgar un Crédito de Consumo” podría ser la parte de la evaluación del Cliente que hace el ejecutivo con todas sus excepciones., dejando fuera las actividades del supervisor. Y esta parte del proceso se lleva a producción, luego en etapas siguientes se implementan las otras partes del procesos hasta completarlo.

El problema de este enfoque es que sigue siendo una solución a medias, es como pavimentar una parte del camino solamente, lo que a vista del usuario final no es considerado como una solución.

Catálogo de Servicios en Desarrollo.

Una de las diferencias importantes entre implementar BPM y el enfoque tradicional de los WorkFlows, es que BPM integra en el flujo a los “servicios” (actividad automatizada realizada por un sistema , y bajo el estándar SOA).

Luego si en una empresa los servicios SOA aun están en desarrollo, es decir, se cuenta solo con un conjunto pequeño de servicios implementados bajo SOA, entonces implementar un proceso de negocio funcional implica una fuerte carga de trabajo en el desarrollo de los servicios necesarios, lo que suele demorar la implementación de un proceso bajo BPM.

Este es otro escollo que suele determinar que un proceso de negocio se realice por partes, o que se opte por implementar primero los servicios de un solo sistema legado (uno de todos los sistemas que están involucrados en el proceso de negocio).

Tareas Interactivas Legadas.

BPM supone una interfaz común para las tareas interactivas, es decir se espera que la solución BPM provea las interfaces necesarias para que un participante del proceso de negocio (un usuario) realice sus actividad, por ejemplo una pantalla que le permita al Supervisor “autorizar el Crédito”, donde se le muestren los datos principales del cliente y de la solicitud, quizás se adjunte la solicitud de crédito (el documento), y donde el tenga la opción de aprobar ,o rechazar el crédito.

Pero muchas veces esta interfaz existe en la empresa y esta implementada en un sistema (legado), y migrarla a la plataforma BPM es una tarea compleja.

Evitar Doble Tarea.

En las soluciones WorkFlow tradicionales, generalmente el usuario tenia que por un lado ingresar al sistema legado hacer su tarea interactiva, y después meterse en el ambiente del WorkFlow para registrar el avance, es decir por cada actividad interactiva tenia que hacer 2 tareas. En BPM se propone evitar esto con la integración de los sistemas (a través de los servicios), y mediante la interfaz común. Así en BPM un actividad como “Registrar el Crédito” internamente y automáticamente registra el avance del proceso a la siguiente tarea, y no lo tiene que hacer expresamente el usuario.

Pero si finalmente para efectos de tener una primera implementación del proceso, se implementa por partes, o solo se implementan algunos servicios, entonces lo mas probable es que se den casos en que el usuario deba registrar su avance en BPM porque el servicio se sigue haciendo en el sistema externo.

Practicas y Principios de XtremeBPM

A continuaciones mostraremos las practicas de desarrollo de XtremeBPM, que tratan de minimizar el impacto de los obstáculos antes mencionados.

Este nuevo enfoque muestra una forma de enfrentar el problema, partiendo por los componentes mas simples, pero mejorando la solución en un proceso continuo, logrando finalmente lo mismo que el enfoque tradicional, que es: el proceso de negocio implementado.

La idea de este enfoque es lograr desde un principio los siguientes objetivos (de la administración de un procesos de negocio):

  • Seguimiento y Control del Proceso de Negocio.
  • Entregar Información de Gestión del Proceso (en tiempo real).

Modelo Centrado en las Actividades.

Lo mas complejo de modelar un procesos de negocio no es determinar las actividades que lo componen, sino representar los distintos flujos o secuencias que existen entre las actividades, gráficamente hablando lo mas complejo es colocar las “flechas” en el modelo.

Tomando ejemplos anteriores, el problema en el manejo de excepciones en un proceso de negocio, no es que agregan tantas nuevas actividades, sino que agrega nuevas secuencias a las actividades existentes, mas flechas y en distintas combinaciones, lo cual desordena el modelo, por ejemplo para el “Otorgamiento de un Crédito”, un Cliente que tuvo antecedentes penales, pero que tiene un patrimonio excelente, quizás este caso especial mas que una nueva actividad, determina que el flujo salte directo a la actividad “Autorizar Crédito” (actividad que ya existe).

Esto incluso lo respaldan metodologías como UML, aquí lo primero que se define son los “Casos de Uso”, es decir, se determinan las distintas funcionalidades por tipo de usuario, o en metodologías orientadas a objeto (OO), aquí se indica que lo primero es comenzar a identificar los objetos y los métodos a partir de los requerimientos del usuario. Fácilmente podemos entonces hacer un paralelo, donde lo primordial es determinar las actividades de un BPM (o modelo de procesos de negocio) al igual como los casos de uso UML, o los “métodos” de OO.

XtremeBPM se basa en ese hecho: de que es más fácil e inmediato determinar las actividades de un proceso que identificar sus flujos, luego la primicia es:

Implementar Primero las Actividades sin los Flujos

En vez de simplificar la implementación del proceso tomando solo una parte de él, o dejando fuera las excepciones, XtremeBPM propone tomar todas las actividades del proceso pero dejando fuera (en primera instancia) los flujos (las flechas). Es decir la primera implementación del proceso de negocio será principalmente actividades, sin flechas (o con muy pocas de ellas).

Participante Determina Flujo.

¿Pero entonces quien determina la secuencia de las actividades?

Respuesta: Las determina cada participante del proceso, es decir un usuario determina cual tarea es la próxima, y quien la realiza.

Manejo de los Estados y Restricciones de Entrada

Una parte importante de esta primicia (XtremeBPM), es que se deben determinar los estados principales de los objetos de negocio, y para las actividades se debe definir los estados que son prerrequisito “obligatorios” de entrada, por ejemplo para al actividad “Autorizar Crédito” la solicitud de crédito debe cumplir con los estados “Patrimonio Verificado”, “Deudas Verificadas” y “Antecedentes penales verificados”, es decir un CheckList de estados.

De esta forma no interesa el orden en que se realizaron las actividades previas, lo que si importa es que se cumplan ciertas condiciones, o estados. El ejemplo esta bastante simplificado, porque las condiciones no son solo si se cumple un estado u otro, sino a veces son condiciones un poco mas complejas, como:

§ El Patrimonio supere cierto monto.

§ Las deudas estén por debajo de un monto.

Estas condiciones “obligatorias” o “estado obligatorios” son los que se deben validar como entrada de una actividad.

Validar Estados en la Entrada

Aquí hay otra característica importante de XtremeBPM, que es; que condiciona la simplificación del modelo, porque muchas veces los estados se tratan de evaluar en la salida de una actividad, dependiendo hacia que actividad se va a saltar, lo cual hace que se tenga que manejar repetidas veces las condiciones, por ejemplo supongamos que N actividades desembocan en la actividad “Autorizar Crédito”, pero en vez de validar en la entrada de esta ultima, validamos en las actividades previas como condiciones para saltar a “Autorizar Crédito”, entonces debemos implementar N veces la validación.

Validar Estados en la Salida

Si no se cumple con las Condiciones se Devuelve.

Si un objeto de negocio no cumple con las condiciones o estados de entrada de una actividad se devuelve a la actividad previa, y al usuario previo, de esta forma se evitan las asignaciones erróneas, y el objeto de negocio vuelve a quien trato de asignarlo.

Actividades “EstereoTipo” (StereoType)

Este es otro aspecto fundamental de este enfoque, las actividades “Estereotipo” son una forma de extender el modelo del proceso de negocio, y son una forma manejar las posibles actividades nuevas o que no están aun en el proceso implementado (no están en el modelo).

En el mismo ejemplo del proceso de “Otorgar un Crédito”, supongamos que hay un caso excepcional que implica la actividad especial “Aprobación del Crédito por el Gerente de Área”, ¿Que se hace en este caso, si el modelo no incluye esa tarea?; lo mas probable es que se realice la tarea pero sea “obviada” en el flujo BPM (no se registre que se hizo), luego dicha actividad especial queda fuera del seguimiento, y control del proceso, y la información de control queda inconsistente, por ejemplo pareciera que la tarea previa o posterior demoro mas porque suma el tiempo de esta tarea especial.

En XtremeBPM se propone que cada proceso de negocio tenga una actividad genérica a la cual llamamos “Actividad Estereotipo”, la cual cualquier participante puede asignar en cualquier punto del flujo. Lo mínimo que tiene que tener esta actividad es:

§ Campo Estereotipo: campo que indica el tipo de actividad, en el ejemplo seria “Aprobación del Gerente”.

§ Descripción Actividad: campo que indica a grandes rasgos que se debe hacer para cumplir la actividad. Este lo define quien enviá la tarea.

§ Desarrollo u Observaciones: campo que indica el detalle de lo que se hizo, o las observaciones de su ejecución. Este lo define quien recibe y/o ejecuta la tarea.

Este concepto es parecido a los estereotipos en UML que permiten extender la metodología a componentes nuevos que no existen en los diagramas base.

Una ventaja esta en que como la actividad “estereotipo” esta dentro del proceso, entonces tiene acceso a los objetos de negocio del flujo, luego por ejemplo para la actividad “Aprobación del Gerente”, el Gerente tiene acceso a los datos de la “Solicitud de Crédito”, tal como cualquier otra actividad del flujo.

Además como cualquier otra actividad aparece en el historial, y en las distintas vistas de control, asegurando de esta forma el seguimiento de estas tareas extraordinarias.

Control y Seguimiento desde un Inicio.

La principal ventaja de XtremeBPM es que se cuenta desde un principio con el “Control y Seguimiento” del proceso de negocio, como BPM mantiene el historial del desarrollo de las actividades entonces en todo momento podemos saber por donde paso el flujo: quien hizo que actividad, cuando se demoro, y luego cual fue la siguiente actividad.

Como este enfoque toma todas las actividades del proceso, a diferencia de tomar solo una parte del proceso, no existen espacios vacíos en el seguimiento del proceso.

Los gráficos de monitoreo (BAM) también cumplen su funcionalidad, por ejemplo gráficos (de barra) que indiquen “Cantidad de Procesos por Actividad” o “Actividades que son Cuellos de Botella” son consistentes bajo esta solución “XtremeBPM”.

Flujos van Apareciendo

Lo primero es “aclarar” que este enfoque es un proceso de mejoramiento continuo, es decir, no se pretende que los procesos nunca tengan flujos (flechas), sino que solo como una forma de enfrentar el problema se implemente primero sin flujos, pero a medida que se va ejecutando el proceso se vayan implementando los flujos.

Y aquí hay otra ventaja de este enfoque; es que lo flujos comienzan a aparecer, no es necesario un análisis detallado de requerimientos, basta con ver algunos “historiales” de ejecución de los procesos para determinar los flujos mas comunes del proceso.

Por otro lado no necesariamente las actividades van a necesitar tener definido un flujo, en la realidad hay actividades que no van a necesitar nunca un orden o secuencia predeterminado, en estos casos bajo XtremeBPM no debería implementarse tampoco un flujo (las flechas).

Manejo de Errores de Asignación

El principal problema de que el flujo no este predefinido (no existan flechas) es que “por error o por mala intención” se asigne una tarea incorrectamente, o se salte alguna tarea.

“El Manejo de Estados y Restricciones de Entrada” prevén esta situación en la mayoría de los casos, pero puede haber excepciones donde no haya forma de controlar (todavía) el cumplimiento previo de actividades, o la asignación a la persona adecuada.

Pero esto hay que analizarlo desde el siguiente punto de vista; si actualmente no hay WorkFlow o proceso BPM implementado, tampoco se esta controlando este problema, y es más existe mayor “riesgo” que con XtremeBPM, porque por lo menos:

  • Con XtremeBPM podemos revisar el historial y queda evidenciado cualquier flujo erróneo, y eso los participantes del proceso lo saben.
  • Con XtremeBPM podemos saber si una persona tiene muchos procesos de negocio estancados.
  • En XtremeBPM las posibilidades están mas limitadas que en la realidad (sin WorkFlow); dentro del proceso de negocio solo se puede asignar tareas que corresponden al proceso, y asignar a participantes validos dentro del proceso, es decir, existen ciertas restricciones mínimas. Por ejemplo sin Workflow una persona puede enviar la “Solicitud de Crédito” por email a cualquier otra persona, y de cierta forma perderse este proceso, o lo que es peor aún llegar a la persona inadecuada.

También están los aspectos de seguridad manual como respaldo, por ejemplo, esta bien un ejecutivo se equivoco y asigno a otro ejecutivo para “Autorizar el Crédito”, y no al Supervisor, pero como la solicitud de crédito debe llevar al firma y timbre del supervisor , aquí hay otro resguardo de que el error no va a seguir curso.

En resumen hay que sopesar ventajas versus desventajas, y claramente son mayores las ventajas en tener todas las actividades en el modelo, y darle de forma efectiva seguimiento al proceso, que esperar a tener un flujo totalmente definido, o tener una parte pequeña del proceso implementada.

Seguridad versus Flexibilidad.

Ahora siempre va a haber casos donde la seguridad prime, donde no haya cabida a asignaciones erróneas, y donde este bien definido el rol que ejecuta una actividad. En este caso la actividad se asigna al rol determinado:

Supongamos que la actividad “Autorizar Crédito” solo lo puede hacer un supervisor, no existe otra posibilidad, entonces esta actividad se restringe al rol “Supervisor”, reduciendo así el riesgo de asignación a la persona inadecuada, pero por otro lado se pierde la flexibilidad o se hace mas compleja la solución, por ejemplo que hacemos con el “Ejecutivo Senior” de la pequeña Sucursal que no puede ser Supervisor, pero si “Autoriza Crédito” en su sucursal (hemos perdido flexibilidad en pro de la seguridad).

Modelo XTremeBPM

Según el principio de “Modelo centrado en las Actividades” , la siguiente es la implementación inicial del ejemplo “Proceso para Obtener Crédito de Consumo”:

Proceso de Negocio bajo XtremeBPM

Esta es la implementación sin flujos (con muy pocas flechas), pero donde en cada actividad se permite determinar cual es la próxima tarea, y a la persona que se asigna.

Se agrega una actividad inicial “Recibir Solicitud”, que es la actividad que permite dar el puntapié inicial en el flujo. Cuando llega un Cliente con una “Solicitud de Crédito”, es la actividad que realiza quien lo recibe, y que permite después poder asignar cualquier otra actividad válida del proceso.

Por “Participante Valido del proceso” se entiende que son todos los roles o usuarios validos en el proceso de “Otorgar un Crédito”, por ejemplo pueden ser ejecutivos , supervisor, o gerente de una sucursal.

En este caso la tarea “Autorizar Crédito” se restringe solo al “Supervisor” por prioridades de seguridad del proceso.

Se supone que en este modelo también contempla las principales actividades de los casos de excepción.

En un principio el orden de cómo se ejecutan las actividades “Verificar Patrimonio”, “Verificar Antecedentes”, “Verificar Deudas”, o “Avisar Rechazo” son irrelevantes, con el tiempo, y si es realmente necesario se van a comenzar a definir los distintos flujos (flechas), apoyados en el historial de ejecución.

Levantar la Interfaz Legada.

Si para los procesos interactivos existe una interfaz en los sistemas existentes (legados) XtremeBPM propone usarla directamente, es decir levantar la aplicación legada y saltar a la funcionalidad correspondiente, de forma tal de aprovechar la interfaz de usuario existente.

Esta claro que esto supone la intervención del sistema legado, y existirán casos en que no se puede hacer.

Pero esta solución es bastante manejable en sistemas Web (legados) donde se puede construir un Portlet, sección (IFrame) que acceda directamente a la funcionalidad Web (legada).

Recordar que esta es la solución para implementar de forma mas inmediata un proceso de negocio, pero con el tiempo se debe ir pasando las interfaces legadas a una interfaz propia de BPM (interfaz única), como parte del mejoramiento continuo de un proceso de negocio.

Servicio de Avance BPM.

Para evitar el problema de doble tarea (hacer actividad interactiva y además registrar avance en BPM) en el caso anterior, se propone intervenir el sistema legado para que llame a un “Servicio de Avance BPM” una vez completada la funcionalidad, para que automáticamente el Flujo avance a la siguiente actividad.

Generalmente existen conectores en las soluciones BPMS para realizar esto.

Generadores de Servicios, o Adaptadores de Servicios para Sistemas Legados.

Una forma de tener antes los Servicios SOA necesarios para implementar el proceso de negocio, es utilizar generadores de código, o adaptadores para poder componentizar los sistemas legados.

En algunos BPMS se provee de dichas herramientas, en otras ocasiones puede convenir incluso desarrollarlos.

Por ejemplo si nuestro sistema legado tiene gran parte de su funcionalidad de negocio en “Stored Procedures”, quizás conviene utilizar un generador de código o adaptador que permita darle una cara Java al procedimiento, para que sea más fácil implementar un WebService bajo los estándares SOA. Hay que recalcar que no se recomienda una herramienta que transforme un “Stored Procedure” directamente en un WebService, por que lo mas probable es que ese WebService no cumpla ninguno de los principios SOA de reusabilidad, y de ser un servicio de negocio, porque difícilmente el Stored Procedure cumple dichos principios SOA, luego queda como resultado un servicio orientado a la base de datos, mas que un servicio SOA.

Desafíos Extremos para las Suite BPM (BPMS) Actuales

El futuro de XtremeBPM es que las suites (BPMS)provean las herramientas necesarias para facilitar este enfoque, es decir, que las herramientas BPM en un futuro provean ciertas características que permitan acortar el ciclo para alcanzar el proceso de negocio totalmente implementado.

Generador de Flujos.

Una herramienta bastante útil seria que los BPMS propusieran los flujos, basados en el historial de ejecución de un proceso..

Es decir se implementa con XtremeBPM un proceso basado solamente en las actividades (centrado en actividades), y a medida que se va ejecutando en producción, el BPM determina los flujos (la secuencia de actividades) mas comunes, gráficamente hablando el BPM determina las flechas entre las actividades.

Luego mediante un asistente grafico (Wizard) se fijan los flujos, es decir, se determina cual es el flujo definitivo.

Generador de Roles.

Lo mismo se puede aplicar a los roles, primero se deja la libertad de que cualquier usuario valido del procesos realice la actividad, y después de acuerdo al historial de ejecución se ofrece la lista de personas o roles que ejecutan comúnmente dicha actividad.

Robots para Levantar Sistema Legados.

Las suites BPM (BPMS) podrían incluir robots que permitieran grabar secuencias que permitieran levantar funcionalidades de los sistemas legados, parecidos a los robots para ejecutar test de pruebas. Estos mismos robots deben incluir la capacidad para evaluar el resultado de la funcionalidad (legada), y poder registrar el avance en el flujo BPM.

Manejo de Actividades Estereotipo.

La herramientas BPM deberán contemplar el manejo de las actividades estereotipo, por ejemplo deberían incluirse por defecto en la implementación de cualquier proceso. Y los módulos de seguimiento, control y monitoreo deberían también contemplarlas como actividades tipo, por ejemplo en un grafico de barra (BAM) debería aparecer una barra por cada estereotipo.

Manejo de Asignación de Tareas y Restricciones de Entrada.

Las herramientas BPMS deberán contemplar el manejo por defecto de que en una tarea se pueda asignar la siguiente actividad, y quien la realiza, también se debe manejar las condiciones de entrada, y automáticamente si no se cumplen devolver el flujo al origen (actividad y persona anterior).

Asignación de Roles y Personas Especificas a una Actividad.

Algunas herramientas BPMS de cierta forma lo ofrecen actualmente, que es la posibilidad de asignar roles a una actividad, pero que se puedan ademas incluir y excluir personas especificas, de forma de contemplar los casos excepcionales.

Registered at RegisteredCommons.org

Xtreme BPM
was created by Luis Alberto Espinoza Bustamante
on 2007-11-12.
License: http://creativecommons.org/licenses/by-nc-nd/2.0/cl/ .
Description: Design and Development Principles for BPM and tools definitions

Aqualogic BPM Suite, la solución BPM de BEA

BEA AquaLogic BPMS (ex Fuego) es una suite BPM (BPMS) que permite crear, ejecutar y optimizar procesos de negocio. Esta suite permite la colaboración entre las áreas de negocio, y el área de TI (Tecnologías de la Información), para automatizar y optimizar los procesos del negocio, impulsando eficiencia y agilidad, mientras se reducen los costos, y se mejora la calidad.

Los analistas de negocio pueden diseñar y correr simulaciones de un proceso completo sin necesidad de apoyo de TI, y solo cuando el proceso abarca las especificaciones de negocio, es traspasado a TI para que implemente e integre los componentes necesarios para implementar el proceso.

Las interfaces de usuario para integrar a los participantes en el proceso (WorkFlow) son generadas automáticamente, y además se provee Portlets (componentes de presentación) estándar para el ambiente de ejecución.

Datos en tiempo real, e históricos son recolectados por el servidor, y están disponibles en dashboards (paneles de control), y reportes, que permiten realizar una optimización continua de los procesos de negocio, y hacer seguimiento de las actividades del negocio.

BEA AquaLogic BPMS es un componente critico para las empresas que desean implementar SOA, permite la orquestación de servicios, e integrar a las personas que necesitan interactuar con dichos servicios. Esta solución ofrece beneficios tangibles para SOA en la línea del negocio, a través de la creación, ejecución, y optimización de los procesos de negocio con la participación de los usuarios de negocio.

BEA AquaLogic BPMS también se ajusta a implementaciones que no involucren aun una infraestructura de servicios, por ejemplo se pueden crear solo WorkFlows (solo actividades humanas) que permiten controlar los procesos actuales de una empresa y optimizarlos, esta solución además permite integrarse fácilmente a sistemas existentes a través de un conjunto de asistentes guiados (Wizards), sin necesidad de crear servicios, por ejemplo integración directa con base de datos (querys), o stored procedures.

BEA AquaLogic Designer.

Es el ambiente de diseño para los analistas de negocio, permite la creación de cualquier tipo de proceso haciendo drag&drop (arrastre) de los elementos de procesos en la “áreas de rol” (swimlanes) correspondientes.

BEA AquaLogic BPMS

Este modulo soporta estándares como BPEL, y UML, y permite con un solo clic hacer switch en la forma de visualización del modelo de un estándar a otro. Se puede modelar y simular un procesos sin necesidad de programar, ni del departamento de TI, ni tampoco necesita que el proceso este implementado en producción, ni de estar conectado al servidor de procesos.

BEA AquaLogic BPM Studio.

Es el ambiente de trabajo de los desarrolladores de procesos, incluye todo lo del BPM Designer, sumando las herramientas necesarias para que el desarrollador cree los componentes de negocio, se integre a los sistemas existentes, y ensamble la interfaz de usuario para la interacción de las personas participantes. Esta herramienta soporta interfaces estándares como J2ee, .NET, WebServices, XML, COM, SQL, y más.

BEA AquaLogic BPM Enterprise Server.

Orquesta todos los procesos y sus recursos; personas, organizaciones, sistemas, gestionando la secuencia y reglas de negocio definidas, y auditando cada paso para asegurar la fluidez en la ejecución del proceso. El servidor ejecuta los procesos diseñados en el BPM Studio, así como cualquier procesos escrito en BPEL.

BEA AquaLogic BPM Workspace.

Es parte del BPM Enterprise Server, y es el ambiente de trabajo para los participantes del procesos de negocio. Las actividades de negocio que requieren de interacción de personas son automáticamente publicadas con una interfaz Web, sin necesidad de diseño Web manual, o programación. Los participantes tienen una vista de sus tareas pendientes y se les ofrece un medio para ejecutar dichas tareas. Los componentes de presentación de AquaLogic pueden ser expuestos como Portlets estándar (JSR168) lo que permite integrarlos sin problemas en cualquier solución de Portal como WebSphere , JBoss, y Weblogic Portal.

BEA AquaLogic BPM DashBoard (BAM).

El verdadero valor de SOA, y BPMS, es la visibilidad que se provee de la operaciones de negocio. AquaLogic BPM permite ver información en tiempo real e histórica de las actividades, que sirve para monitorear la performance de los procesos de negocio, y su estado , a través de indicadores de performance y SLA (Service Level Agreements, niveles de servicio a cumplir).

SOA Fundation, el BPMS de IBM

IBM SOA Foundation es un paquete de software integrado, y basado en estándares abiertos que permite implementar una Arquitectura Orientada a Servicios (SOA)

IBM SOA Foundation esta diseñado para apoyar la extensión de valor de las aplicaciones y procesos de negocio de una Empresa, los módulos que componen SOA Foundation han sido seleccionados para soportar cada etapa del ciclo de vida de los Procesos de Negocio.

WebSphere Business Modeler

Es especialmente útil para brindar valor a las organizaciones en el clima actual de fusiones y adquisiciones, tercerización de procesos de negocios, reingeniería de procesos y automatización de los procesos que antes eran manuales o semiautomáticos, debido a que las compañías desean evitar la dificultad y el gasto de reinstrumentar un proceso que no cumple con el desempeño esperado.

WebSphere Business Modeler

 

WebSphere Business Modeler es una herramienta de modelado construida según estándares abiertos y basada en Eclipse, una plataforma universal de herramientas de desarrollo de software de código abierto, lo cual le permite integrarse fácilmente con la arquitectura existente de una organización. El software se basa en BPEL (Business Process Execution Language), un estándar abierto basado en XML utilizado en la automatización de procesos de negocio basado en Web Services, y brinda soporte para exportar los modelos a formatos UML y las herramientas de desarrollo Rational Rose XDE.

WebSphere Integration Developer

WebSphere Integration Developer tiene por objeto proporcionar un entorno de desarrollo integrado para la creación, la realización de pruebas, la integración y la implantación de aplicaciones J2EE y servicios Web. Basado en Eclipse Versión 2.0 y escrito según las especificaciones de la norma J2EE, WebSphere Integration Developer ayuda a optimizar y simplificar el desarrollo de aplicaciones J2EE con métodos recomendados, herramientas visuales, plantillas y generación de código.

WebSphere Process Server.

Websphere Process Server es esencialmente un servidor de aplicaciones J2EE de IBM que incluye el componente para coreografía de procesos. Este es un motor de workflow basado en BPEL con las siguientes características:

 

  • Soporte de integración, instalación y ejecución de procesos de negocios basados en BPEL.
  • Herramientas intuitivas que permiten arrastrar y pegar para definir visualmente la secuencia y el flujo de los procesos de negocios BPEL.
  • Un depurador de procesos de negocios visual para depurar y visualizar paso a paso la ejecución del proceso de negocio del BPEL.
  • Soporte de compensación para proveer soporte de “rollback” a transacciones o procesos de negocios que requieran esta funcionalidad.
  • Manipulador de fallas integrado que provee un manera visual e integrada de realizar el manejo de excepciones en el flujo.
  • Un constructor de condiciones visual para definir la ejecución de lógica condicional en los procesos de negocio.
  • Posibilidad de incluir código Java como parte de los procesos.

 

El soporte para macroflujos extiende el alcance de BPEL para incluir actividades que requieren interacción humana dentro del proceso de negocios, este incluye:

 

  • Nodos específicos para representar un paso en un proceso de negocio que se realiza manualmente.
  • Facilidades para la asignación genérica de personas a una actividad de un proceso.
  • Interfaz grafica basada en Browser para acceder a la lista de ítems de trabajo y ejecutar las tareas asignadas o transferirlas a otros usuarios.
  • Administración de ítem de trabajos para controlar la creación, transferencia y eliminación de ítem de trabajos.

WebSphere Business Monitor.

Permite el análisis continuado de los datos de ejecución de procesos en tiempo real generados por IBM WebSphere MQ Workflow, WebSphere Business Integration Message Broker y WebSphere MQ Integration Broker con el objeto de optimizar los procesos empresariales.

BPMS y Ciclo de Vida de los Procesos

BPMS presta apoyo en todo el ciclo de vida de los procesos de negocio, el cual se compone de las siguientes etapas:

  • Modelamiento de los Procesos de Negocio: en esta etapa se crea o modela un proceso de negocio, también es aquí donde se definen mejoras, o cambios a los procesos para optimizarlos. En esta etapa el principal involucrado es el “Analista de Negocios”.
  • Implementación: en esta etapa se integran los componentes necesarios para implementar el proceso. El principal involucrado en esta etapa es el “Ingeniero de TI” para el caso de que los procesos se implementen como soluciones tecnológicas.
  • Ejecución de Procesos: esta es la etapa en donde se explota el proceso desarrollado previamente, en esta etapa los principales involucrados son los “Participantes” del proceso. Además aquí es cuando se recolecta la información para control, y seguimiento.
  • Control y Gestión: esta es la etapa donde se le da seguimiento a los procesos, y donde se analiza la información de su ejecución, por ejemplo: indicadores de desempeño, cuellos de botella, caminos críticos, carga de trabajo, etc., su principal características es que la información se analiza en tiempo real. En esta etapa los principales involucrados son los “Supervisores, y la Gerencia”.

Luego los módulos principales que componen la plataforma BPMS, y que apoyan las etapas del ciclo son:

  • Modelador Gráfico de Procesos: (Business Modeler) que permite modelar los procesos de negocio, simular su ejecución, definir métricas para el monitoreo, y exportar a BPEL (lenguaje estándar de procesos). Tiene un diseñador gráfico de procesos, que permite fácilmente crear los modelos.

  • Ambiente Integración y Desarrollo: (Integration Developer) es la herramienta que permite implementar los procesos, y servicios. Esta herramienta permite integrar las pantallas (para interacción de un participante), y los servicios (interacción con sistemas legados).

  • Servidor de Procesos de Negocio: (Process Server) es el motor que permite ejecutar los procesos de negocio, aquí se ejecutan las Aplicaciones Compuestas ( flujos BPM), los Workflows tradicionales, y la Orquestación de Servicios (procesos compuestos solo por servicios). Este servidor también es el encargado de generar los datos de las métricas, y de monitoreo. Permite intervenir los procesos en tiempo real: balancear carga, cambiar flujo de negocio, y realizar acciones correctivas (según reglas de negocio).
  • Monitor de Actividades de Negocio: (BAM, Business Activity Monitor) esta es una aplicación de administración que permite gestionar los procesos y servicios, gráficamente se pueden ver indicadores de performance, y SLA (Service Level Agreements, niveles de servicio a cumplir). Se puede además definir alertas y triggers de acuerdo a eventos de negocio que sucedan en el proceso. También puede proveer datos reales a los modelos (Business Modeler) para ajustar las simulaciones (y lograr mejoramiento continuo)

La siguiente imagen muestra como se ve la herramienta BPMS, en este caso se muestran pantallas de BEA Aqualogic, pero visualmente las soluciones BPMS son parecidas:

BPMS y Ciclo de Vida de los Procesos
Algunos ejemplos de BPMS:

Que es BPM, Que es BPMS

BPM (Business Process Management),o BPMS (BPM Suite) es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio. Por administración de procesos entendemos: análisis, definición, ejecución, monitoreo, y control de los procesos.

BPM además contempla soporte para interacción humana, e integración de aplicaciones, y es aquí la diferencia fundamental con la tecnología de WorkFlow existente, que es que BPM integra en los flujos a los sistemas.

Flujo BPM

Las soluciones del tipo WorkFlow solo se limitaban a definir el flujo de actividades humanas, o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos si un participante del proceso requería como parte de sus actividades ingresar datos en una aplicación, entonces debía salir del ambiente del WorkFlow, levantar la aplicación, y luego de terminada su operación volver al WorkFlow y registrar el cambio de estado, o termino de la actividad. En BPM todo esta integrado en el mismo flujo lo que es mas natural para un participante, el completa su actividad dentro del flujo BPM, y tras bambalinas se actualizan los sistemas que se tengan que actualizar.

En la practica un flujo BPM (o modelo de proceso BPM) visualmente es muy parecido a un WorkFlow, la diferencia esta en que en que uno puede notar que ciertas actividades son realizadas por personas, y otras son actividades sistematizadas (realizadas por sistemas), y ambas aparecen en el flujo.

El otro “valor agregado” de BPM es que ofrece una solución completa, que abarca todo el ciclo de vida de un proceso de negocio: análisis, modelamiento, ejecución y monitoreo de los procesos.

En BPM el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (su diseño), que realiza el área de negocios de una empresa, es “en si” lo que se ejecuta sobre el “servidor de procesos” (el motor de BPM). Dicho en otras palabras: la “lógica de negocio” principal que antes bajo las tecnología tradicional se debía programar, y colocar sobre un “servidor de aplicaciones” (tradicional), ahora se reemplaza por un modelo que se sube al “servidor de procesos” con mucho menos intervención del área de TI (menos programación).

En la practica una buena solución BPM debería poder ejecutar un proceso modelado por el área de negocio, sin la necesidad de que TI tenga que programar una sola línea de código, y obtener como solución algo equivalente a un WorkFlow Tradicional (sin integración de sistemas). Luego el área de TI debería tomar este “workflow”, e implementarle los formularios de entrada (de interacción con usuarios), y los “servicios” (las actividades automatizadas) para completarlo en un flujo BPM.

Hacer que un modelo se convierta en un proceso ejecutable requiere de varias tecnologías habilitantes (enabling tools), cuando estas tecnologías se proveen juntas se le llama BPMS, las principales son:

  • Motores de Orquestación: permiten coordinar la secuencia de actividades según los flujos y reglas del modelo de procesos.
  • Herramientas de Análisis y Business Intelligence: permiten analizar la información producto de la ejecución del proceso en tiempo real.
  • Motores de Reglas: (Rule Engines) ejecuta reglas que permiten abstraer las políticas y decisiones de negocio de las aplicaciones subyacentes.
  • Repositorios: mantiene los componentes y recursos de los procesos (definiciones, modelos, reglas, etc. ) disponibles para su reutilización en múltiples procesos
  • Herramientas de Simulación y Optimización: permite a los administradores del negocio, comparar los nuevos diseño de procesos con el desempeño operacional actual.
  • Herramientas de Integración: permiten integrar el modelo con otros sistemas, con los sistemas legados de la empresa.


Algunos ejemplos de BPMS:

BPM también es vista como una disciplina de administración, que requiere que las organizaciones se cambien a un pensamiento centrado en los procesos y que reduzcan su dependencia de estructuras tradicionales de territorio y funcionalidad (los llamados silos). Es un enfoque estructurado que emplea métodos, políticas, métricas, practicas de administración, y herramientas de software para mejorar la agilidad y el desempeño operacional.

La disciplina BPM tiene implicancia en 4 aspectos del negocio:

  • Estrategias
  • Governance (Administración y Control)
  • Estructura Organizacional (Organization)
  • Cultura.