anibal goicochea

Consideraciones al migrar «SAP NW BW» a «SAP NW BW powered by SAP HANA»

Diciéndolo en pocas palabras SAP NetWeaver Business Warehouse powered by SAP HANA consiste en utilizar la base de datos SAP HANA en lugar de la base de datos relacional que utilizan las plataformas SAP NW BW estándar. Realizada esta migración, se seguirá utilizando BW con las mismas funcionalidades, sin la necesidad de realizar muchas tareas de optimización/administración y obteniendo tiempos de procesamiento muy rápidos.

Diciéndolo en pocas palabras SAP NetWeaver Business Warehouse powered by SAP HANA (BW ON HANA) consiste en utilizar la base de datos SAP HANA en lugar de la base de datos relacional que utilizan las plataformas SAP NW BW estándar. Efectuada la migración, se podrá utilizar BW on HANA con las mismas funcionalidades que en un BW tradicional pero con tiempos de respuesta reducidos, realizando algunas tareas adicionales de optimización/administración, obtendremos aún mayores beneficios.

A grandes rasgos, la migración de SAP NW BW a SAP NW BW powered by SAP HANA contempla las siguientes tareas:

Si aún no se cuenta con una plataforma SAP HANA, el primer paso es identificar las necesidades de la organización para estimar la configuración idónea de SAP HANA Appliance que se requiere (estas tareas se denominan Sizing).
Verificar que se cuente con las versiones mínimas exigidas para SAP NW BW (actualmente 7.3 SP5) y si ya se contara con una plataforma SAP HANA, verificar la versión de SAP HANA System.
Migrar la base de datos SAP NW BW a SAP HANA.
Verificar las fuentes de datos y conexiones (Si se utilizarán SLT o SAP Data Services)
Revisar el modelo de datos para retirar características innecesarias es una plataforma SAP HANA, como el cálculo de agregados. Quizás también podría ser necesario revisar las cadenas de procesos para retirar procesos innecesarios.
También podría ser factible revisar los modelos de datos para eliminar redundancias de datos que se implementaron para facilitar el procesamiento de la información en un entorno lento que ya no sería necesario en SAP HANA.
Conversión de objetos BW a objetos optimizados (cubos y ODSs)
Verificación y pruebas

El proceso es mecánico y muy similar entre todas las implementaciones, salvo que se trate de alguna implementación muy especial o particular, un buen punto de partida es utilizar el “despliegue rápido” que SAP ofrece a través de una RDS.

Referencia: (post relacionada)

Conectividad SAP HANA con BI4

Teniendo presente que la conectividad de SAP HANA y SAP BusinessObjects BI (quizás ya deberíamos llamarlo SAP Analytics) está en evolución, compartimos este gráfica en dónde se puede ver las posibilidades de acceder a los datos de la base de datos de SAP HANA desde los componentes de la plataforma de Business Intelligence de SAP.

Teniendo presente que la conectividad de SAP HANA y SAP BusinessObjects BI (quizás ya deberíamos llamarlo SAP Analytics) está en evolución, compartimos este gráfica en dónde se puede ver las posibilidades de acceder a los datos de la base de datos de SAP HANA desde los componentes de la plataforma de Business Intelligence de SAP.

(clic para ampliar imagen)

Referencia: SAP Press

HANABPC, ¿un SAP BPC sin restricciones?

En un proyecto de SAP Business Planning and Consolidation (SAP BPC), luego del análisis de las necesidades, el punto de partida de la implementación técnica, es el diseño del modelo de datos, pero guste o no, esta fase se debe asumir teniendo en consideración algunas “best practices” que sugieren un uso moderado de dimensiones (datos maestros) o casi “prohíben” el uso de fórmulas en los miembros de dimensión.

En un proyecto de SAP Business Planning and Consolidation (SAP BPC), luego del análisis de las necesidades, el punto de partida de la implementación técnica, es el diseño del modelo de datos, pero guste o no, esta fase se debe asumir teniendo en consideración algunas “best practices” que sugieren un uso moderado de dimensiones (datos maestros) o casi “prohíben” el uso de fórmulas en los miembros de dimensión.

En un post anterior, un comentario nos recordó la recomendación de no usar más de 16 dimensiones (mejor 13) en SAP BPC y señaló que esta restricción podría seguir vigente en la versión SAP BPC powered by SAP HANA (componente HANABPC). Ante la inquietante afirmación, preguntamos a un miembro del equipo que está elaborando la guía de Sizing para BPC sobre SAP HANA si esta restricción seguiría vigente en SAP HANA y nos brindó la siguiente respuesta:

This particular suggestion is not applicable for BPC on HANA due to architectural differences.

Teniendo en cuenta la viabilidad de usar más dimensiones, unido a otras posibilidades como la de poder utilizar fórmulas a nivel de miembros de dimensión (actualmente posible, pero nada recomendable) facilitaría el desarrollo de soluciones BPC, evitando complejas arquitecturas de datos. Ya veremos si con HANA, BPC no tiene restricciones.

La encuesta, herramienta indispensable para medir la gestión de las organizaciones

Si estamos considerando la implementación de un Cuadro de Mando Integral (CMI, Balanced Scorecard) seguro que definiremos algunos indicadores denominados subjetivos, imposibles de cuantificar objetivamente con un valor absoluto, característica típica de los indicadores de las perspectivas no-financieras del CMI.

Para valorar estos indicadores no-financieros, por el momento, la alternativa más efectiva es la encuesta a los entes que podrán colaborar a cuantificar el grado de alcance o logro de un objetivo, pudiendo ser estos entes los clientes, empleados, proveedores o cualquier otro stakeholder de la organización.

En el documento de referencia, encontramos un breve caso de una empresa, que en primer lugar, a través de un estudio, detectó lo que esperaban sus clientes:

Amplia gama de productos,
Buena atención por parte de los empleados,
Ser atendidos en su propia lengua,
Cumplimiento de los plazos,
Alta calidad de los productos

De todas las preocupaciones del cliente, sólo el “cumplimiento de los plazos” puede medirse con objetividad, podría pensarse que quizás la “amplia gama de productos” también podría ser medido directamente, pero en este caso lo que se desea medir es la percepción que tiene el cliente, para este tema, así como para los demás inquietudes del cliente, el mejor sistema de valoración son las encuestas, las cuales deben ser breves y fácilmente ponderables.

Referencia: ISBN 978-84-7356-737-4

¿Columnas vs. Filas?

Tener los datos en memoria no es lo único que hace rápido y eficiente a SAP HANA, hay un conjunto de aspectos adicionales que contribuyen a lograr tiempos tan reducidos de acceso a la información (aquí un post al respecto) como la tecnología de procesamiento o almacenamiento basado en columnas, esta tecnología es una alternativa a la clásica y popular almacenamiento basado en filas, utilizada por la gran mayoría de bases de datos relacionales, mayoritariamente en uso en la actualidad.

Tener los datos en memoria no es lo único que hace rápido y eficiente a SAP HANA, hay un conjunto de aspectos adicionales que contribuyen a lograr tiempos tan reducidos de acceso a la información (aquí un post al respecto) como la tecnología de procesamiento o almacenamiento basado en columnas, esta tecnología es una alternativa a la clásica y popular almacenamiento basado en filas, utilizada por la gran mayoría de bases de datos relacionales, mayoritariamente en uso en la actualidad.

Al referirnos al almacenamiento basado en columnas o filas no pretendemos señalar a una como buena y a la otra como obsoleta, ambas tecnologías son buenas y eficientes pero dependiendo qué uso se le da. La base de datos de SAP HANA utiliza ambas tecnologías, pero para tareas diferentes para así obtener su mejor rendimiento.

Resumiendo lo bueno y malo de cada tecnología, lo siguiente sería lo más destacable:

Almacenamiento basado en filas (Row – based Storage)
- Ventajas: Todos los datos se almacenan juntos, facilitando la inserción y actualización
- Desventajas: Durante la selección o recuperación de datos, todos los datos son leídos.
Almacenamiento basado en filas (Column – Based Storage)
- Ventajas: Sólo se accede a la información requerida durante el proceso de selección o lectura. Cualquier columna de datos puede actuar como un índice o clave para la recuperación de datos.
- Desventajas: La actualización de datos en columnas no es eficiente como lo puede ser la tecnología basada en rilas.