Complementando BPM con herramientas de BI

Cuando las empresas implementaron las soluciones ERP y les dieron capacidades de análisis con productos de Business Intelligence parecía que por fin el mapa estaba completo, teníamos los datos, las funciones y el análisis integrado. Pero la dicha nunca es duradera, de modo que surgió el paradigma del BPM como complemento de las soluciones ya existentes.

La incorporación del BPM desestructuró la información porque añadió más información al sistema al abarcar más procesos y de un modo más extenso.

Mientras que los ERP almacenan todos los datos en un modelo de base de datos determinado (gracias a verse favorecidos por el uso de información muy estructurada) los BPM tienen metadatos, datos propios, datos externos, información que es variable en función del tiempo, reglas de negocio que se ejecutan de modo paralelo, un diseño del proceso, información sobre las personas que participan… y todo ello se almacena en contenedores separados, no relacionados y que no tienen un modelo de datos estructurado porque el propio flujo no lo es sino que intenta adaptarse a las necesidades.

De nuevo la incorporación de tecnología nos generó un problema cuando nos solucionaba otro (no desesperemos, al mismo tiempo se debería de dar una mejora de la competitividad y capacidad de la empresa o no tendría sentido).

La nueva problemática se puede minimizar con la incorporación de soluciones BI al mundo BPM, estas soluciones tienen muchos nombres en función de su enfoque técnico (CEP – Complex Events Proccesing, BAM Business Activity Monitoring o el clásico BI – Business Intelligence). En este artículo se habla un poco de este tema por ejemplo.

Debilidades en la actualidad

  • La capacidad de integrar los metadatos del BPM, los datos externos y los datos de otras aplicaciones es todavía muy débil, en realidad solo está razonablemente conseguido cuando recurrimos a soluciones BI del mismo fabricante de la suite BPM, por ejemplo el BI de Tibco no sabe acceder a los metadatos del BPM de Oracle y tampoco a la inversa. La falta de información sobre los modelos internos de cada sistema no aporta ayuda.
  • La relación entre las soluciones BI y los BPMS aún no está madura, la experiencia de fabricantes de software e implantadores con la casuística es aún insuficiente y muchas veces las necesidades se deben resolver sobre la marcha con desarrollos, adaptaciones o mejoras a los productos. Esto ralentiza todavía los proyectos notablemente, por lo que los tiempos de un proyecto BI con BPM son muy superiores a un proyecto BI en entornos de ERP por ejemplo.
  • Los modelos de aplicación están por desarrollar, los clientes saben que hay información en sus BPM cuyo análisis integral con el resto de datos de la empresa les interesa, pero no existen “librerías de casos” conocidas, en cada cliente se trabaja en el análisis de las necesidades y el diseño de como obtener estos datos para cada ocasión, de nuevo los proyectos tienen un componente mayor de tiempo porque la fase previa de análisis necesaria es mayor que en entornos de BI más maduros.

¿Hay buenas noticias?

SI, los fabricantes han comenzando a consolidar sus propuestas y las soluciones son cada vez más robustas, del mismo modo el que cada fabricante de BPMS tenga una solución BI hace que se desarrolle un conector entre ambos que una vez desarrollado y documentado es utilizado por otros fabricantes lo que beneficia la integración. Además las experiencias ya están apareciendo, comienzan a darse casos de éxito reales y los integradores ya podemos ayudar al cliente dirigiéndole hacia modelos de aplicación (que en todo caso deben adaptarse de modo continuo a cada caso).

Las carencias de integración de datos se pueden solventar con las herramientas CEP o BAM, gracias a su capacidad de capturar información en vuelo sobre las aplicaciones.

¿Qué puede aportar el BI con BPM?

En el BPM existe mucha más información potencial, no solo que está ocurriendo sino que esperamos que ocurra cuando los procesos avancen en el tiempo gracias a los datos históricos y la simulación, potencialmente podríamos “ver el futuro” de nuestra empresa. Por ello su potencial para anticiparnos a posibles eventos futuros es muy elevado, del mismo modo que podríamos detectar cambios en las tendencias de la empresa a día de hoy.

Es una información muy difícil de procesar, por lo que el foco debería ser en objetivos muy claros del negocio para poder diseñar correctamente las herramientas.

Aspectos a tener en cuenta

Tal como explica al artículo que enlazo, antes de iniciar el proyecto hay que centrarse en:

  • Asegurar la calidad de los datos.
  • Establecer las métricas del sistema.
  • Crear centros de competencia con visión de negocio y no solo de tecnología. Buscamos información, no datos, eso requiere conocimiento del negocio.
  • Definir una arquitectura tecnológica basada en una arquitectura de referencia de un proveedor completada con aquellas soluciones “best of breed” que el cliente pueda integrar.
  • Enfocar el proyecto a una mejora continua del proceso de negocio.

Otros enlaces útiles: