BI Self Service: SAP Lumira

Aprovecho para compartir una iniciativa para soluciones de Business Intelligence que estamos lanzando desde The White Team Consulting.

En este vídeo se puede ver una breve demostración de como usar SAP Lumira como solución de descubrimiento de información, también como una herramienta “Self Service” de Business Intelligence.

Algunas ventajas de SAP Lumira (en mi opinión) son

Ventaja vs Competencia

  • Permite diseña cuadros de mando en horas mientras se observan los resultados que se generan.
  • Aunque en el vídeo no se observa SAP Lumira permite compartir resultados en tiempo real mediante Cloud y acceso móvil.
  • Mínima inversión en licencias, por causas que desconozco SAP no permite publicitar el precio (¿?) pero es fácil de encontrar la referencia.
  • Los proyectos de implantación inicial se pueden ejecutar en días.

SAP Lumira (en sus diferentes versiones, personal, Server y Cloud) permite complementar las actuales inversiones en soluciones de Business Intelligence, en mi opinión es una solución muy recomendable para analizar.

SAP Lumira

Como se ve en el vídeo SAP Lumira permite acceder a fuentes de datos (mezclando incluso diferentes fuentes), pero es aún más interesante la opción de poder transformar los datos directamente por un usuario, y aplicar técnicas de búsqueda interactiva (en el vídeo se observa como descubrir un problema de quejas de usuarios, localizar donde ocurre y el posible motivo.

SAP líder en business intelligence

Logo SAPGartner sitúa a SAP como líder en business intelligence por cuota de mercado, SAP acapara casi un 24% de este negocio y creció en 2011 un 19,5% con respecto al ejercicio anterior.

Los esfuerzos de SAP en el ámbtio de Busines Intelligence parecen dar frutos, también es posible que se esté aprovechando de un cierto desenfoque de sus principales rivales (IBM, Oracle o Microsoft) que están centrados en muchos más temas y no hacen tanto esfuerzo como los alemanes.

La posición de SAP en el mercado ERP (donde residen gran parte de los datos) les puede ayudar mucho, además de su imponente cuota de mercado le ayuda a generar venta cruzada.

Es sorprendente que Oracle esté perdiendo esta batalla, desde su posición de vendedor dominante en las bases de datos tenía una ventaja importante y creo que este es un mercado fundamental para ellos, pero tal vez la absorción de SUN y competir contra IBM y HP en el mercado HW le está haciendo prestar menos atención.

Esto unido a la llegada de SAP HANA puede hacer que Oracle deba comenzar a preocuparse por su mercado de bases de datos.

Medir el desempeño de la empresa

En otro artículo hablaba sobre el mito de que necesitamos medir para gestionar, pero no pretendía decir que medir fuera siempre inútil, es evidente que hay casos donde la medición de parámetros que nos digan como funciona la compañía es importante.

Mi experiencia me dice que en ocasiones las empresa se lanzan a “medir cosas” sin saber para que o que esperan, con la intención de que al final, buscando entre los datos aparezcan matices importantes para la compañía.

Un mal ejemplo

Hace varios años Luis (un buen cliente, de esos de los que aprendes cosas) me explicó una mala experiencia, en su compañía para justificar un gran proyecto SAP y la inversión de TI se había decidido medir el uso de cada empresa para facturarles el servicio realizado. Tras un proyecto de meses, con un esfuerzo mensual de varios días se obtenia repetidamente que el reparto era practicamente equivalente a la facturación de cada compañía, que era el método de reparto que se usaba un año antes. El esfuerzo de medir no sirvió de nada, el resultado era el que ya se estaba utilizando.

Elegir qué se mide y para qué

Cuando hablamos de implantar sistemas de medición en las compañías debemos seguir los siguientes puntos (la teoría de los cuadros de mando es una buena base):

  • Comenzar por conocer la pregunta que pretendes contestar, y que harás en cada tipo de resultados. Conocer que nuestro ratio de ocupación de un departamento es bajo no sirve de nada si no sabemos que haremos cuando pase.
  • Analizar la fiabilidad de los datos origen y el grado de subjetividad de los mismos. Las mediciones de datos poco fiables son inútiles.
  • Analizar el coste de obtención de la información. Debe ser inferior que el valor de la respuesta.

Lo importante es el proceso de toma de decisiones, no es la medición,. La medición es adecuada y útil enmarcada dentro de un proceso bien definido. En muchas ocasiones después de medir ocurre que tomar una decisión respecto de la información obtenida es muy complejo porque existen innumerables consideraciones que no aparecen.

Por ello el primer punto es crucial, si no tenemos claro que buscamos y que pretendemos, así como las opciones de decisión puede que obtener la medición no sirva de nada o sea un proceso que se demore tanto tiempo que haga inútil la elección.

Medir importa para analizar las mejoras

Después de definir el proceso, y después de tomar una decisión de mejora en un área de negocio entonces medir si tiene valor, para saber si están teniendo resultados los cambios adoptados. Y es cierto que para saber si estamos mejorando necesitas valores históricos previos. Pero, ¿y si no los tienes? lanzar un proyecto de medición de datos para disponer de valores históricos antes de hacer cambios y analizar las mejoras es, en ocasiones, absurdo.

Puede que haya empresas que tengan necesidades en áreas que puedan esperar dos años para tener esa información previa, pero en esos casos realmente los sistemas de información claramente no son capaces de aportar valores competitivos.

Conclusión

Medir es una herramienta útil, muy útil, pero igual que un motor de avión no es una herramienta útil para un granjero debemos aplicar la herramienta en áreas donde la medición sea relevante. El uso de sistemas de información, y su inmensa capacidad de manipular valores ha hecho pensar que dando vueltas a los datos podremos resolverlo todo.

Un verdadero cuadro de mando debe ser interactivo

Hay ideas que valen por si mismas más que la tecnología que tiene por detrás. Y creo que este es uno de los casos. Me había prometido con convertir este blog en una herramienta de venta, así que no voy a especificar el proveedor concreto, pero hace pocos días estábamos preparando una demo para un cliente de una aplicación de Business Intelligence que incluía una variación que al menos yo creo que es novedosa (no soy un experto en BI).

Las soluciones de BI orientadas a generar cuadros de mando suelen presentar información al usuario (o usuarios) que los visualizan, recuerdo que un consultor comentaba que un cuadro de mando debería de ser visualizado en pantallas alrededor de la mesa de reuniones del consejo si era realmente útil. El uso de cuadros de mando, “dashboards” e indicadores es ya muy habitual en las soluciones, con sus ventajas y carencias estas soluciones ya tienen una amplia implantación.

Pero las soluciones carecen de capacidad de actuar sobre ellas, un director de ventas ejecuta el cuadro de mando y visualiza los indicadores, no le gusta lo que ve, ¿qué hace? Comienza a llamar a su equipo, da ordenes, envía correos, averigua que ocurre, intenta solucionarlo, pero la propia herramienta no le permite manipular la acción de la empresa. Con las mejores puede profundizar en los datos con la función “drill-down” pero para actuar debe usar otra herramienta o apoyarse en ordenes directas a alguien.

Un enfoque diferente es añadir al cuadro de mando un “control” interactivo que varía el proceso de negocio que estamos monitorizando.

Por ejemplo, si monitorizamos el número de peticiones de oferta y controlamos el stock podríamos aumentar el stock deseado o reducirlo en función de los parámetros, reducir el límite a partir del que una compra debe ser autorizada por otro nivel si nos quedamos sin presupuesto, o ampliar el personal asignado a un departamento si vemos que el número de peticiones que tiene en cola está creciendo (por ejemplo pedidos a un departamento de ventas).

La intención es dotar a un directivo de los cuatro o cinco indicadores que le dan la información que necesita a su nivel y el control de un parámetro que modifica la actuación de la empresa incidiendo sobre un BPM donde se automatiza el proceso con reglas de negocio.

La idea es brillante, el análisis para hacerla efectiva es complejo y necesita de directivos que entiendan la gestión por procesos pero el potencial es realmente interesante.

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: