Definiciones básicas de SAP HANA

A menudo usamos una serie de términos al hablar sobre SAP HANA, tales como appliance, base de datos o sistema, por la novedad que engloba HANA, puede haber ciertas dudas a lo que nos estamos refiriendo, una aclaración al respecto la encontramos en la nota 1661202:


A menudo usamos una serie de términos al hablar sobre SAP HANA, tales como appliance, base de datos o sistema, por la novedad que engloba HANA, puede haber ciertas dudas a lo que nos estamos refiriendo, una aclaración al respecto la encontramos en la nota 1661202:

SAP HANA Appliance hace referencia a toda la instalación en su conjunto que puede estar compuesta por un servidor (node server) o un cluster (conjunto) de servidores, es decir se trata del hardware y del software que lo gestiona.

SAP HANA System es el software que funciona sobre un SAP HANA Appliance está identificado por un SID  (System IDentifier), lo componen una serie de aplicaciones y componentes, de los cuales el más popular y relevente sea SAP HANA Database.

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.


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