Archivo mensual: mayo 2013

No diseñes “mastodontes” en SAP BPC


Ante todo, cuando diseñes un modelo o aplicación en SAP Business Planning and Consolidation (SAP BPC), ten presente que es una herramienta para automatizar los procesos de negocio de las áreas financieras – contables, tales como la elaboración de los presupuestos o la consolidación financiera. 

SAP BPC no es una herramienta de Business Intelligence (BI) o analítica, ofrece características de reporting pero esta dirigida a explotar la información introducida es esta herramienta transaccional, una funcionalidad para que los usuarios validen la información introducida o realicen tareas básicas de análisis.

Si se desea analizar la información de presupuesto, planificación, previsiones o cualquier otro proceso que se automatice utilizando SAP BPC con información generada en otras aplicaciones o sistemas, no lleves toda la información a SAP BPC, terminarás construyendo un “mastodonte” que tarde o temprano tendrás que “sacrificar”.

Nuestra recomendación es que diseñes el modelo analítico que requiere tu organización en una plataforma externa a SAP BPC, tal como SAP NW BW, en la que se integre toda la información necesaria para el análisis de información, proveniente de diversas fuentes, entre ellas de SAP BPC.  Esta información luego podrá ser explotada con herramientas de BI y análisis que ofrecen mayores recursos y posibilidades, tales como las que se incluyen en la plataforma SAP BusinessObjects BI 4.0 (nuestra recomendación indiscutible si todas tus fuentes de datos son SAP e inapelable si tienes o tendrás SAP HANA)

SAP BPC es una herramienta transaccional para usos específicos, no es una plataforma de BI y mucho menos un data warehouse, para estos fines tiene limitaciones técnicas, que si ignoras el uso especifico que tiene, terminarás construyendo una “jungla” de cubos con una infinidad de “tuberías” entre ellos, de difícil mantenimiento y con riesgos potenciales de inconsistencia e inseguridad.

En SAP BPC 10.0 ten cuidado con el “contexto por defecto”


En SAP Business Planning and Consolidation 10.0 (SAP BPC) se denomina “contexto por defecto” a lo que en versiones previas denominábamos “current view”, el cual señala el conjunto de miembros de dimensión (datos maestros) sobre los que se ejecutará cualquier operación, a menos que explicitamente se señale que miembros de dimensión se deberán utilizar.

Este aspecto los debemos tener presente especialmente en el diseño de informes y formularios de entrada de datos utilizando el cliente de SAP BPC, denominado, SAP EPM Add-in.  Debido a que el contexto por defecto se guarda en un fichero local (EPMXLClientPreference.XML) y las interacciones con la interfaz del EPM Add-in permiten cambiarlo, en el diseño de informes y formularios deberían utilizarse todas las dimensiones, indicando los miembros de dimensión a las que deben apuntar cada una.

Referencia: Nota 1848621

Usuarios concurrentes en SAP BPC


Denominados  concurrencia cuando los usuarios están realizando operaciones de lectura y grabación simultáneamente.  Se estima que el número de usuarios concurrentes que puede tener una plataforma de SAP Business Planning and Consolidation (SAP BPC) es aproximadamente igual al 5% de los usuarios nominales.  

Entre las buenas prácticas y sugerencias que nos brinda SAP para configurar nuestras plataformas de SAP BPC, señala que se debería contar con un servidor por cada 50 usuarios concurrentes, con el fin de que el sistema pueda realizar balanceo de carga.

Referencia: Nota 1783080

Factores que influyen en el rendimiento de SAP BPC


Hay diversos factores que pueden influir en el rendimiento de SAP Business Planning and Consolidation (SAP BPC), sobre todas las posibles causas esta la configuración del hardware (CPUs, memoria, red, uso de SAP HANA o SAP BWA) el cual debería responder, especialmente en cuanto al número de CPU y memoria, a los siguientes otros factores que también influyen en el rendimiento:

  • Número de usuarios concurrentes.
  • Volumen de datos maestros (dimensiones).
  • Volumen de datos transaccionales (cubos).
  • Complejidad de jerarquías (número de jerarquías y niveles o profundidad).
  • Complejidad de lógicas (scripts y fórmulas).
  • Complejidad en la definición de business rules para los procesos de consolidación y conversión monetaria.  

Un adecuado dimensionamiento de las necesidades de hardware (sizing) desde el inicio, teniendo una visión clara de lo que se diseñará, podrá evitar contratiempos posteriores.  Adicionalmente, tenga presente las tareas de administración que requiere esta plataforma (tales como optimización de cubos y eliminación de ficheros temporales).

Cinco preguntas para definir una estrategia


La definición de una estrategia es una acto de elección/renuncia, elegir lo que se debe hacer y renunciar a una serie de acciones que no se harán para lograr ganar a la competencia.  Pero alrededor de la definición de la estrategia se ha formado cierta complejidad que muchos desisten en platearse oficialmente un plan estratégico.

Cinco preguntas esenciales para definir una estrategia

Una técnica creada en Procter & Gamble basada cinco preguntas, definida inicialmente para plasmar la estrategia de lanzamiento de nuevos productos podría ayudarnos a definir los pilares de una estrategia para una organización. Más información en el documento de referencia.

Referencia: Revista Harvard Deusto (mayo 2013, número 223)

Consideraciones básicas para el despliegue de “BW on HANA” (II)


Continuando con el post anterior relacionado sobre la preparación y configuración de un sistema SAP NetWeaver BW powered by SAP HANA (BW on HANA),  agregamos los siguientes apuntes:

  • Los cálculos de necesidades de memoria o sizing varían en cada instalación, depende principalmente de cada arquitectura, por ejemplo, índices, agregados y otras tablas que podrían ser eliminadas. Para más información sobre sizing seguir las novedades de las notas 1736976 y 1637145.
  • No existe tamaño máximo soportado de un sistema SAP NW BW para ser llevado sobre SAP HANA, esta restricción sólo existió en la fase ramp-up.
  • Para evitar la migración innecesaria de datos que no tienen ningún uso, es recomendable realizar “tareas de limpieza” antes se estimar y efectuar la migración de un sistema SAP NW BW a SAP HANA.
  • Un sistema BW “limpio” oscila los 60 GB pero este puede crecer según el contenido de las tablas de los usuarios. La nota 1637145 contiene un script e información necesarios para el cálculo de necesidades de hardware (sizing).
  •  Es recomendable que las tablas “row-store” no superen los 200 GB. La nota 1659383 contiene  la relación de tablas con almacenamiento en filas.
  • SAP HANA soporta tanto almacenamiento basado en columnas como en filas, BW on HANA determina automáticamente el tipo de almacenamiento que debe tener cada tabla.
  • Todas las transacciones y funciones de BW on HANA son las mismas que en la versión tradicional.
  • Las posibilidades de configuración que puede tener un sistema SAP HANA y BW on HANA, tales como el número de nodos soportados o memoria por nodo recomendable puede variar, recomendable consultar la documentación disponible en el sitio SAP Product Availability Matrix (SAP PAM).

Novedades que tendrá SAP BusinessObjects BI Mobile 5.0


En el enlace de referencia se hace un recuento de una presentación sobre la próxima actualización de la aplicación para dispositivos móviles SAP BusinessObjects BI Mobile 5.0 (o SAP BI Mobile).  De las diapositivas compartidas, destacamos la siguiente:

Principales novedades de SAP BI Mobile 5.0

 

  • Contaríamos con una única aplicación mobile. Se podría prescindir de la aplicación SAP BusinessObjects Explorer Mobile al incluirse compatibilidad con este tipo de contenidos.
  • Se podrá visualizar contenido procedente de SAP Lumira (SAP Visual Intelligence)
  • Las visualizaciones de SAP Dashboards (Xcelsius) reconocería el uso de variables Flash y Query as a Web Service (QaaWS).

Nota: La numeración de las versiones de la plataforma SAP BusinessObjects BI y la aplicación mobile no van alineadas, son independientes, al menos por el momento.

Referencia: SAP SDN y post relacionado

Filosofía “Powered by SAP HANA”


En anteriores entradas hemos señalado diversas características sobre SAP HANA, pero ante todo se debe tener presente que SAP HANA es una plataforma sobre la cual funcionarán todos los nuevos y actuales sistemas de SAP, esta visión o filosofía se trata de comunicar a través de la expresión “Powered by SAP HANA”, expresión que acompaña a las versiones in-memory computing de SAP NetWeaver BW y SAP Business Suite.

Tratando de simplificar el concepto “Powered by SAP HANA” este se podría reducir a lo siguiente: remover y remplazar la capa de datos que utilizan las soluciones o aplicaciones actuales para utilizar SAP HANA Database, de este modo, SAP HANA se convierte en la principal y única base de datos que utilizarían las soluciones SAP “Powered by SAP HANA”.

SAP NW BW Powered by SAP HANA, liberada en noviembre de 2011, fue la primera gran aplicación SAP llevada a la plataforma SAP HANA, brindando los siguientes beneficios:

  • Incremento en la rapidez de la actualización de informes
  • Mejoras en la cargas datos
  • Simplificación de los modelos de datos al prescindir de objetos técnicos o estructuras de datos diseñadas debido a las limitaciones técnicas de bases de datos tradicionales.
  • Simplificación de los modelos de datos por la incorporación de nuevos objetos más eficientes para almacenar y procesar la información.
  • Reducción de las tareas de administración.

SAP Business Suite Powered by SAP HANA fue liberada el 10 de enero de 2013 el cual comprende, por el momento, SAP ERP, SAP CRM, SAP PLM y SAP SCM. Destacamos los siguientes beneficios:

  • Agilizar las tareas básicas de los procesos de negocio.
  • Posibilita la integración de funcionalidades de búsqueda, análisis, planificación y predicción en los sistemas transaccionales.
  • Permite la integración con otras fuentes de datos.
  • Tratamiento masivo de datos.
  • Simplificación de los sistemas.  Al posibilitar la combinación de la información de los datos transaccionales con fuentes de datos no estructuradas o al incluir otras capacidades tales como la planificación, tradicionalmente configuradas en sistemas distintos.

Proyectos tradicionales de TI vs. Proyectos de análisis de datos


Un proyecto de Análisis de datos o Big Data difiere de lo que puede ser un proyecto tradicional de informática (o TI – Tecnologías de la Información), tener en cuenta los siguientes factores contribuirá en lograr mejores resultados:

Proyectos TI vs Proyectos de Análisis (Parte I)

Proyectos TI vs Proyectos de Análisis (Parte II)

Referencia: Revista Harvard Business Review (número 91)

¿SAP HANA Accelerators?


Las aplicaciones SAP HANA denominadas “aceleradoras” son soluciones predefinidas que cubren las necesidades de un proceso de negocio concreto en un sistema SAP ERP, en algunos casos funcionan del mismo modo cómo lo hace el procedimiento tradicional, por lo requieren mínima configuración y se tiene mínimo riesgo en su implementación.

Esquema general de una aplicación del tipo aceleradora SAP HANA

El principal objetivo de las denominadas Accelerators de SAP HANA es superar los cuellos de botella que puede significar el acceso a los datos, para ello se utiliza la base de datos de SAP HANA como una base de datos auxiliar o secundaria, replicándose parte de la información que utiliza el proceso en SAP HANA database, de este modo, todas las operaciones de lectura son dirigidas a HANA y las operaciones de escritura y cálculos serían mantenidas en la base de datos tradicional.

Entre los aceleradores más conocidos tenemos:

  • CO-PA Accelerator
  • Financial Accounting Accelerator
  • Controlling Accelerator
  • Material Ledger Accelerator
  • Production Cost Analysis Accelerator
  • Customer Segmetation Accelerator