Hello BW4HANA World

No comments

Desde hace ya unas cuantas semanas, podemos encontrar el nuevo producto estrella de SAP para “Enterprise Data Warehousing” dentro de HANA EDW (link 1, link 2, link 3), algo que llama la atención a alguien como yo, que lleva casi toda su vida profesional con SAP BW, aka BIW o BI.

Es importante saber qué funcionalidades están disponibles en este nuevo producto y cuáles dejan de existir. Esta información puede encontrarse en las FAQ de BW4HANA y en el texto “Complete Functional Scope(CFS) for BW4HANA. Para “ver” la funcionalidad más relevante, recomiendo este documento. A la hora de entender el alcance funcional de BW4HANA se puede tomar de momento como referencia la versión de BW 7.5 SP4 (CFS, p. 7), en la que observamos cambios notables. Por ejemplo, nuestros “queridos” BEX Analyzer, Query Designer, etc., ya no están soportados con BW4HANA o ciertos tipos de sistemas fuentes de toda la vida, entre ellos los tipos “SAP System” y “DB Connect”. También el Data Warehouse Workbench para el modelado y el APD ya no están accesibles.

 

En general, ¿cómo puede seguir uno con su BW(s)? Desde el punto de visto de soporte, SAP dice:

“6. Will SAP BW 7.5 powered by SAP HANA and edition for SAP HANA continue to be supported?

Yes, SAP BW 7.5 powered by and edition for SAP HANA will still be supported release options, however, SAP BW/4HANA will receive the majority of the new innovation being developed moving forward.” (BW4HANA FAQ, p. 5)

Y para los que quieren migrar a BW4HANA, SAP recomienda lo siguiente como un posible camino:

“For customers running SAP BW 7.3 or 7.4 powered by SAP HANA today, who choose to move to SAP BW/4HANA, we recommend upgrading to SAP BW 7.5 and applying the SAP BW/4HANA. Starter add-on as an intermediate step.”

Nos encontramos frente a los posibles procesos de migración/transición a BW4HANA y que sí pueden afectar al roadmap de SAP EDW de una organización. Este tema merece un post específico debido a su amplitud.

En este post presentaré un desarrollo, la aplicación analítica “Hello BW4HANA World”. Este desarrollo incluye la creación de una fuente de datos basada en el nuevo tipo de sistema fuente “HANA Source System”, un open ODS View y una query modelada con el BWMT Eclispe Query Designer. Como fuente de datos me sirve una vista HANA de otro esquema que tengo disponible.


 

 

 

Este desarrollo no utiliza las modalidades nuevas de integración de datos vía SAP HANA SDI, sino que “solo” utiliza el acceso virtual vía SDA.

La fuente de datos resultante está, al igual que una fuente de datos de Netweaver BW, basada en campos y no exige modelado de info objetos para su creación:

 

 

 

 

Para poder tener acceso inicial, este desarrollo incluye una vista ODS de esta fuente de datos:

 

 

 

 

 

Creamos una query para consultar estos datos (ojo: aún no se ha creado ni un solo info objeto…):

 

 

 

 

 

Podría ejecutar la query dentro de los BWMT, lo que resulta muy práctico ya que no hay que cambiar a otro entorno. Compruebo que todo funciona correctamente a través de la conocida transacción RSRT:

 

 

 

 

Y, voilà, aquí la información de la tabla integrada en BW4HANA y accesible a través del  Analytic Manager de BW4HANA, utilizando una query de BW.

En el próximo post se enseñará la segunda parte del desarrollo, que incluye un info objeto “Hello product”, destino de datos, transformación optimizada para HANA, actualización automática y un bonito front end con SAP Design Studio.

ConVistaHello BW4HANA World
Ver más

Thinking about the “Hyper” EDW*

No comments

Estimado lector:

Sí, admito que el título puede hacer que a uno se le levante una ceja, pero déjenme explicar por qué llegué a titular este post así.

En el entorno SAP contamos desde hace ya varios años con SAP HANA y su aplicación dentro del ámbito de data warehousing, bien porque se utiliza SAP BW o en un futuro BW4HANA, o bien porque se utiliza SAP HANA como motor de BBDD para un data warehouse estilo “free-hand SQL”. Ambos mundos no son contradictorios ni se excluyen mutuamente, como ya comentaba Thomas Zurek de SAP en este post de hace ya casi un año. BW4HANA implementará este concepto de forma más integrada en los próximos años, aunque a día de hoy ya se puede trabajar en esta dirección de una forma más desligada.

Lo que sí tienen en común ambos estilos de Data warehousing con SAP HANA es el crecimiento de datos al que se puede enfrentar una plataforma de In-Memory basada en SAP HANA. Esto es quizás algo impredecible hoy en día, por tener que ampliar el horizonte temporal de los datos gestionados o por la amplitud del tipo de datos que se quieren ofrecer a los usuarios finales. Factores limitadores pueden ser el valor de la unidad de memoria (bits/EUR), pero también otro factores como la robustez de la integración, SLA’s, o las normativas y procesos de desarrollo que puedan obstaculizar la integración en un EDW central como lo percibimos hasta ahora.

Desde un punto de vista simplificado, podemos dividir los datos relevantes para una memoria corporativa en dos tipos: Por un lado (tipo 1) están los datos generados por transacciones empresariales y gestionados en sistemas OLTP, como por ejemplo ERP, SCM y CRM. Estos datos suelen ser relativamente de buena calidad, consistentes y completos. De momento quiero llamarlos “(well) managed enterprise data”. Este tipo de dato bien estructurado tiene a menudo un valor decreciente con el tiempo desde el punto de vista informativo y por lo tanto en su importancia y su frecuencia de acceso (“la temperatura del dato baja” – Concepto de Hot/Warm/Cold data, conocido en SAP BW desde 7.0). Es obvio, que nos interesa disponer de opciones para mover los datos de tipo 1, ya más fríos, a un repositorio de datos probablemente más lento, pero considerablemente más económico que nuestra valiosa infraestructura in-Memory de la que disponemos.

Por otro lado (tipo 2) están los datos cuyo origen puede estar en otras fuentes de datos como por ejemplo data streaming en sentido de IoT (sensor data, machine data, fleet data) y que tienen los siguientes aspectos en común:

  1. No se necesitan con una calidad del 100%
  2. No tienen que ser necesariamente consistentes desde un punto de vista transaccional
  3. Para muchas consultas analíticas es suficiente mirar aspectos detallados con poco    horizonte temporal (HOT para un muy corto plazo)
  4. Tienen un gran volumen de detalle
  5. En un primer momento se desconoce si los datos tienen valor desde el punto de vista de  negocio

Raras veces los datos de tipo 2 serían candidatos para ser incorporados en un repositorio de datos estilo EDW, por el consumo de recursos de memoria, esfuerzo de integración, continuidad de operación y aumento de complejidad (especialmente si las fuentes son inestables). Es preferible canalizar estos datos a otro lugar, en el cual se puedan tratar de forma más sencilla, económica y ágil. Aquí entran en juego las posibilidades que ofrecen los componentes de “Big Data”, enfocados a trabajar con grandes volúmenes de datos en entornos de hardware económicos y robustos, y que a día de hoy, permiten ser consultados y analizados de diferentes maneras incluso de forma online.

De este modo resulta lógico pensar en una arquitectura común para acceder y gestionar estos dos tipos de datos debajo de un paraguas unificador. Unificador a nivel de datos o sus agregados (“early join”) pero también a nivel de usuario (“late join”), algo ya muy factible según mi opinión. SAP ha dado los pasos necesarios para poder construir un “hyper” data warehouse con estas características. El HANADW con o sin BW4HANA (incluyendo S4HANA hasta cierto punto, pag.36) ofrece, gracias a la infraestructura de integración de SAP HANA, la posibilidad de construir algo de esta magnitud y que abarca los dos mundos, permitiendo gestionar la temperatura de los datos y la interoperabilidad con “lagos de datos” no gestionados dentro de la instancia central de un sistema basado en SAP HANA.

La arquitectura se presentará así:

El componente de acceso a los datos juega un papel muy importante ya que actúa como “Gate Keeper” principal de los datos, incluyendo la posibilidad de hacer transparente su ubicación técnica y homogenizando su acceso (“data access channeling”). SAP dispone para este componente de una solución con SAP BO BI platform y las herramientas de BO para los usuarios finales. Sin embargo, aun así todavía puede ser necesario la utilización de herramientas especializadas, no integradas, para aprovechar todas las posibilidades de análisis y procesamiento almacenado en nuestro “Hyper” Data Warehouse*. Esta sería uno de los puntos a analizar.

De momento quedan por supuesto retos por solucionar, tales como aspectos de seguridad, la heterogeneidad de la tecnología empleada, la gestión del “conjunto/cluster” integrado y también como integrar los expertos de ambos mundos en un solo equipo.

En los próximos posts iré describiendo nuestros avances en este apasionante área para una arquitectura estratégica y de análisis unificado. También explicaré con más detalle qué son los componentes más importantes en este setup. So, please stay tuned.

ConVistaThinking about the “Hyper” EDW*
Ver más

Business Intelligence para el sector seguros

Business Intelligence para el sector seguros
 
Las aseguradoras se enfrentan actualmente al reto de adaptar continuamente sus procesos de informes y planificación a las presiones que ejercen las exigencias reguladoras y la competencia.
 
Las nuevas directrices normativas, los bajos tipos de interés, el cambio demográfico o las nuevas tendencias, tales como el procesamiento de datos en tiempo real, la movilidad, las soluciones en la nube y el big data, generan tanto riesgos como oportunidades para los modelos de negocio ya existentes.
 
Contar con una base de datos uniforme y consolidada resulta clave para analizar los efectos y las decisiones estratégicas de una empresa. Se trata de una necesidad fundamental para la transparencia y calidad de los datos en los procesos de informes y planificación, y la base para afrontar con éxito los desafíos futuros.
 
En muchas empresas los flujos de datos históricos y desestructurados, las aplicaciones de informes aisladas, así como la falta de transparencia en los procesos de gestión de datos están dando lugar a operaciones muy complejas.
 
Por eso es importante contar con un modelo de procesos para crear conceptos bien estructurados y soluciones de BI integradas. De esta forma, se reduce la complejidad general, los requisitos adquieren transparencia y se alcanza un objetivo claro para los procesos de inteligencia de negocio.
 
¿Qué ventajas ofrece este modelo?:
  • Enterprise Data Warehousing – configuración de soluciones de BI integradas
  • Big Data Analytics – análisis individual del uso de las aplicaciones, desde el diseño hasta la implementación de soluciones de big data (p. ej., In-Memory-Analytics)
  • Informes de gestión efectivos y eficientes – desde la certificación del contenido de los informes, visualizaciones, procesos y organización hasta la selección de herramientas de TI
  • Informes operativos – análisis de requisitos, desarrollo de conceptos e implementación de soluciones y procesos de generación de informes globales y por departamentos
  • Informes financieros – conexión de sistemas financieros operativos con los informes del grupo o el departamento, así como análisis de estructuras y procesos de BI con el sistema de control corporativo
  • Informes de seguros – consultoría y apoyo con la arquitectura de soluciones de BI integradas, así como con proyectos centrales de seguros

 

Puedes ponerte en contacto con nosotros si necesitas más información sobre este tema.
ConVistaBusiness Intelligence para el sector seguros
Ver más