Archivo mensual: octubre 2012

Una gráfica de miedo


De acuerdo con la fecha de este post compartimos este enlace a una gráfica o visualización diseñada con SAP BusinessObjects Dashboard (Xcelsius), una muestra más de las posibilidades que brinda esta herramienta.  En el enlace de referencia podrás ver la muestra en ejecución (en formato Flash) y el fichero original (.XLF) por si deseas conocer como se ha diseñado.

Referencia: SAP SDN

Anuncios

SAP NW BW powered by SAP HANA, obliga a rediseñar el modelo de datos


Al utilizar cualquier tecnología, en su implementación, podemos vernos obligados a realizar ciertas “soluciones” que si estuvieras utilizando otro producto no serían necesarias.  Esta situación también se produce con SAP NetWeaver Business Warehouse (SAP NW BW), que para agilizar los tiempos de respuesta se diseña un modelo de datos, algunas veces muy complejo.  Pero si pensamos en SAP NW BW sobre SAP HANA (SAP NW BW powered by SAP HANA) debemos considerar las siguientes situaciones:

  • Se requiere que la presentación de informes sea más rápida. Como ya muchas veces se ha comentado, SAP HANA brinda tiempos muy reducidos con relación a una plataforma estándar de SAP NW BW.  Tener SAP NW BW sobre SAP HANA  requiere la versión 7.3 de SAP NW BW, lo que puede incrementar los costos si se tiene una versión anterior.
  • Se desea simplificar el modelo de datos de su plataforma SAP NW BW. Con SAP NW BW powered by SAP HANA ya no es necesario la redundancia de datos o agregados para agilizar los procesos y flujos de datos, esto puede conllevar a un trabajo inicial de rediseño de la arquitectura de datos, pero que en el futuro facilitará la administración de los datos, la escalabilidad o adaptabilidad a nuevas necesidades y desarrollos.
  • Se necesita cargas de datos más rápidasSAP HANA brindará cargas de datos más rápidas porque tendrá menos tablas e índices por actualizar, pero un impacto significativo se logrará si se diseña un modelo más eficiente, con menos capas y eliminando redundancias de datos, innecesarias en SAP NW BW powered by SAP HANA.

Considerando estos aspectos, podríamos señalar que llevar SAP NW BW a SAP HANA no pasa sólo por una migración de un producto, para obtener una mejora considerable estaríamos hablando de dos fases:

  • Migración técnica (según el RDS correspondiente demandaría alrededor de 3 meses).
  • Rediseño del modelo de datos para eliminar capas y estructuras innecesarias, que dependiendo de su complejidad, podría ser necesario dividir esta fase en proyectos o etapas.

La consultoría informática necesita su libro de historia


Dicen que “la historia se repite” o que “es necesario conocer el pasado para comprender el presente”, frases de uso frecuente que bien se podrían aplicar a la consultoría informática, que  si se recopilara anécdotas e historias bien podrían tomar forma de más de un libro.  Algunas anécdotas o historias no tan agradables como pueden ser las demandas de un cliente porque no está muy contento con el resultado de un proyecto de implementación, por causas como los que señala el artículo de referencia:

  • Problemas o diferencias políticas.
  • Incremento desproporcionado de los costes de los proyectos.
  • No se logran cubrir los objetivos esperados, insatisfacción de los usuarios.
  • Considerable incumplimiento de los plazos de entrega (“dijeron que podían hacerlo en siete semanas. Les dimos siete meses, y tenemos cero…”).
  • Presentación de un “demo” amañado en la preventa
  • Asignar consultores sin experiencia al proyecto.
  • Errores informáticos que generan incorrectamente pagos millonarios (Diagnóstico de auditoría: “el sistema se puso en marcha antes de superar ciertos hitos de prueba”).

Conocer un poco más sobre estos casos serían verdaderas lecciones para clientes y consultores.  Por ejemplo, interesante resulta el argumento de defensa de Oracle ante una demanda: “… Cuando los problemas surgieron durante el transcurso del proyecto, se hizo evidente que el cliente no comprendió adecuadamente la tecnología, como tampoco sabía los pasos que debía seguir para completar el proyecto…”

Referencias: aquí y aquí

En eventos, no preguntes, dialoga


Si tienes la suerte de asistir a un evento como SAPPHIRE NOW o SAP TechEd que se celebrarán en los próximos días en Madrid, deberías “sacarle” el máximo beneficio (sobre todo si por asistir has pagado y no te han invitado), según el libro del CEO de Linkedin, El mejor negocio eres tú, la clave está en formular buenas preguntas y si es posible dialoga será mejor que preguntar.  De las sugerencias plasmadas en este libro, destacamos lo siguiente:

  • Conversar y no interrogar. Un repertorio de preguntas puntuales nos brindará respuestas que quizás podremos obtener en manuales o en la web.  En cambio induciendo un dialogo o conversación, probablemente obtendremos valiosas experiencias en forma de ideas o sugerencias, difíciles de encontrar sólo cuando te encuentras sólo con “y ahora qué hago” y tienes la serenidad y tiempo para descubrir la respuesta.
  • Céntrate en tu interés. Más vale una sola pregunta que nos ayude a descubrir un camino o solución a varias que no nos lleve a ninguna parte.  Buscar las respuestas que despejen nuestras dudas.
  • Preguntar lo mismo de otro modo. Si hay la oportunidad de ampliar la conversación o formular una pregunta adicional, repetir una pregunta desde otra perspectiva puede brindar información adicional de mucho valor.
  • Escarbar en las respuestas. Si no nos queda clara la respuesta, o si una expresión nos crea duda,  no dejemos de formular la repregunta ¿qué significa…?

Referencia: (aquí)

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:

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 (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.

(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 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.

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.

Referencia: (aquí)