¿Mayores causas de pérdida de rendimiento en BPC 10.0 que en BPC 7.5?

Comparando las guías de Sizing o dimensionamiento de las necesidades de hardware de SAP Business Planning and Consolidation NW (SAPBPC NW) de las versiones 7.5 y 10.0, vemos un aumento considerable de las posibles causas de pérdida de rendimiento en la última versión.


Comparando las guías de Sizing o dimensionamiento de las necesidades de hardware de SAP Business Planning and Consolidation NW (SAPBPC NW) de las versiones 7.5 y 10.0, vemos un aumento considerable de las posibles causas de pérdida de rendimiento en la última versión.

Factores que influyen en la pérdida de rendimiento en SAP BPC 7.5 NW

No creemos que se deba a un aumento de complejidad de BPC, más pensamos que SAP ha aprendido de la experiencia y señala casi absolutamente todo como posible causante de pérdida de rendimiento.

Factores que influyen en la pérdida de rendimiento en SAP BPC 10.0 NW

Nuestra sugerencia es que se debe tener en cuenta, desde el punto de partida, que BPC es una herramienta transaccional ´para las tareas relacionadas a la planificación y consolidación financiera.  Si se desea analizar grandes volúmenes de información,  SAP BPC no es la herramienta analítica que cubrirá tus expectativas, quizás, además de BPC, deberías pensar en SAP BusinessObjects BI.

Anuncio publicitario

Vías para estimar las necesidades de hardware (Sizing)

Hemos escrito un par entradas sobre Sizing basada en SAP Quick Sizer (aquí y aquí), pero esta no es la única vía para trasladar las necesidades del negocio en necesidades de hardware, hay otros procedimientos para dimensionar las necesidades de CPU, memoria, espacio en disco y en algunos casos, capacidad de la red de datos.


Hemos escrito un par entradas sobre Sizing basada en SAP Quick Sizer (aquí y aquí), pero esta no es la única vía para trasladar las necesidades del negocio en necesidades de hardware, hay otros procedimientos para dimensionar las necesidades de CPU, memoria, espacio en disco y en algunos casos, capacidad de la red de datos.

En todos los casos, se parte de más o menos supuestos, el resultado final son unas estimaciones de características iniciales que luego se deberán ajustar según la auditoria y seguimiento que se le dará a la implantación. A continuación, la descripción de los cinco procedimientos que considera SAP para el Sizing:

Plantilla de Quick Sizer para SAP BusinessObjects BI 4.0

Determinar las necesidades de CPU, memoria y disco (Sizing) para un nuevo proyecto de TI puede resultar un tanto al azar. Indicar números absolutos sobre la cantidad de registros a procesar o usuarios concurrentes, es como tirar los dados, cualquier número que resulte será válido, ¿cómo estimar sobre algo que nunca se ha utilizado en una empresa, algo tan singular y variable como el uso de una plataforma de Business Intelligence?


Determinar las necesidades de CPU, memoria y disco (Sizing) para un nuevo proyecto de TI puede resultar un tanto al azar.  Indicar números absolutos sobre la cantidad de registros a procesar o usuarios concurrentes, es como tirar los dados, cualquier número que resulte será válido, ¿cómo estimar sobre algo que nunca se ha utilizado en una empresa, algo tan singular y variable como el uso de una plataforma de Business Intelligence?

Para el caso de SAP BusinessObjects BI 4.0 (BI4), la vía más rápida para obtener un Sizing es utilizando la utilidad Quick Sizer, la cual ofrece un plantilla (BO_BI_V26 F.), basada en el siguiente supuesto: El 10% del total de usuarios de la organización serán usuarios de BI4, el 10% de estos serán usuarios concurrentes, los cuales serán distribuidos en partes iguales en cada uno de los componentes de BI4 que se desplieguen.

Utilizar el QuickSizer puede ser un buen punto de partida para el Sizing de BI4,  luego vendrán las pruebas con datos reales, el seguimiento de los ficheros logs y los resultados de utilidades como el Monitoring incluido en el CMC (Consola de Administración Central) de SAP BO BI 4.0, para ajustar las necesidades de memoria de los servicios. 

Referencia: NT 1702470

Sizing para SAP HANA (CPU y memoria)

Ante todo es importante señalar que para realizar un “Sizing” sobre cualquier herramienta SAP, más para una plataforma como SAP HANA, debe ser realizada de manera personalizada para cada organización por un equipo de expertos.


Ante todo, es importante señalar que un “Sizing” (estimación de necesidades hardware) sobre cualquier herramienta SAP, más para una plataforma como SAP HANA, debe ser realizada de manera personalizada para cada organización por un equipo de expertos.

Para SAP HANA, hay una serie de propuestas de hardware estándar que ofrecen los socios de SAP en esta tecnología (Fujitsu, IBM, entre otros), pero para cada realidad hay que considerar el número de usuarios que pueden estar trabajando en un período de tiempo (una hora), el tipo de trabajo que están realizando (SAP señala tres categorías: «easy», «medium», «heavy») y la frecuencia con lo que la realizan (SAP identifica tres categorías: «sporadic», «normal», «expert») esta información determinará las necesidades de CPU.

Para determinar las necesidades de memoria se toma en consideración el tamaño de las tablas de datos que se desean incluir en la plataforma HANA, aplicando un factor de compresión.  Para este fin SAP tiene una serie de scripts (programas SQL) que son aplicados según el tipo de base de datos.

Una reciente novedad para estimar el dimensionamiento de una plataforma SAP HANA es la posibilidad de utilizar SAP Quick Sizer, una aplicación Web utilizada para dimensionar las necesidades de hardware de las herramientas más utilizadas en SAP.

Recomendado la lectura de la Nota 1514966, además de la documentación de instalación y configuración de SAP HANA que se actualizada con regular frecuencia.