Que podemos ver hoy ??? Vamos a ver uno de los problemas que podemos tener, y es el mismo de siempre, cuanto tardan en mostrarse los datos y lo que nos interesa es saber, por qué nuestra inversión en BI o Planning depende de la velocidad, es un punto muy importante y debemos tener en cuenta como podemos llegar a optimizarla. Continuamos ??
Por qué tu inversión en BI depende de la velocidad (y cómo optimizarla)
En el mundo del Business Intelligence (BI), solemos obsesionarnos con la arquitectura del dato o la sofisticación de los modelos predictivos. Sin embargo, hay un factor crítico que a menudo se queda en el plano técnico y que, en realidad, es el que decide el éxito o el fracaso de cualquier proyecto: el rendimiento.
El rendimiento no es solo una métrica de IT; es el catalizador del Retorno de Inversión (ROI). Si una herramienta diseñada para aportar agilidad falla en la entrega inmediata de la información, el usuario pierde la confianza. ¿La consecuencia directa? La aparición del «Shadow BI». Cuando un dashboard tarda una eternidad, el usuario vuelve al Excel de toda la vida y a los silos de datos no gestionados, invalidando cualquier estrategia de Gobierno de Datos. Si la herramienta no se usa porque es un «dolor de muelas» esperar a que cargue, la inversión se convierte automáticamente en un activo varado.
El umbral de la paciencia: El impacto real en el usuario
Como ya sabemos existe un límite psicológico y técnico muy claro: los 20 segundos. Superar este umbral de tiempo para visualizar un indicador, cuadro de mandos o informe (depende también de que tipo de informe, no hablo de aquellos que algunas vecemos sacamos con mas de 50000 líneas o más, nos pasa y nos seguirá pasando), clave no es solo una molestia, es una señal de obsolescencia tecnológica para el negocio. Según los datos de adopción, pasamos de una «Analítica Ágil» con un 90% de uso a una zona de abandono casi total una vez cruzamos esa frontera.
Cuando nos ocurre esto solemos escuchar lo siguiente, «No ejecutamos los informes y hemos vuelto a la extracción de datos ad-hoc porque los tiempos de respuesta eran demasiado largos… «. Esta realidad demuestra que el rendimiento es la base sobre la que se asienta el Gobierno de Datos. Sin agilidad, el BI pasa de ser una ventaja competitiva a un centro de costes infrautilizado.
El mito de la nube y el papel del Hardware
Lo que nos pasa normalmente y es un error de bulto es pensar que, al ser una solución Cloud, el PC del usuario no importa. Nada más lejos de la realidad. En SAP Analytics Cloud (SAC), gran parte del trabajo «sucio» —el renderizado de los widgets y la ejecución de la lógica de JavaScript— ocurre directamente en la CPU local del navegador. A esto es lo que llamamos una arquitectura de aplicación de página única (SPA).
Para diagnosticar si «el hierro» es el culpable, contamos con la Performance Measurement Tool (dentro del menú de Sistema). El indicador clave es el Client Score, que mide la capacidad del dispositivo para procesar historias complejas y estos son los valores:
| Client Score | Evaluación | Impacto |
| >= 75 | Excelente | Procesamiento fluido de scripts y visuales pesados. |
| 50 – 75 | Bueno | Rendimiento estable para la mayoría de casos. |
| < 50 | Pobre | Riesgo crítico de latencia; incapacidad de manejar dashboards densos. |
Ojo al dato: El Client Score no es estático. Factores como tener veinte pestañas abiertas en Chrome, el uso de la batería en modo «ahorro de energía» en Windows o una CPU saturada por otros procesos pueden hundir el rendimiento. La diferencia es multiplicativa: un mismo dashboard que carga en 10 segundos con un score de 200, se va fácilmente a los 30 segundos en un equipo con un score de 30. Si no puedes renovar los portátiles de toda la empresa, tu diseño debe ser «consciente del hardware».
Si el hardware no da para más, nos toca ser más listos con el diseño y sacar petróleo de la configuración. ¿Seguimos?
Diseño de historias: El equilibrio de la «economía técnica»
Tengamos en cuenta que optimizar no significa quitarle funciones al usuario, sino aplicar un diseño inteligente basado en la «economía técnica». Cada elemento en pantalla tiene un coste computacional en la CPU. Aquí tienes algunos «Quick Wins» fundamentales:
- Viewport Loading: Es una cuestión de percepción. Esta función prioriza la carga de lo que el usuario ve en pantalla. Aunque haya una pequeña latencia al hacer scroll, el arranque inicial es inmediato, algo que el usuario agradece mucho más que una espera infinita al principio.
- Pause Refresh: Evita que SAC sature el backend lanzando peticiones innecesarias nada más abrir la historia. Configura los widgets para que solo soliciten datos cuando sean necesarios.
- Desactivación de Planning: Si tienes tablas que son solo de lectura, desactiva las funciones de planificación. Esto evita que SAC cargue librerías de software pesadas que no vas a usar.
- Estructura plana (DOM): El exceso de anidación (los famosos nested panels) hincha el código HTML y obliga al navegador a realizar recálculos complejos. Menos contenedores significan un renderizado más ágil.
- Optimización de medios: Olvida los PNG o JPG para iconos. El formato SVG es infinitamente más ligero (pasamos de 500 KB a 2 KB), no se pixela nunca y reduce las llamadas HTTP externas si usas las formas nativas de SAC.
Scripting eficiente: Reduciendo los viajes al servidor
En las actuales Optimized Stories, el scripting nos da una flexibilidad enorme, pero también es donde más tiempo podemos perder. El gran enemigo aquí son los «roundtrips» (viajes de ida y vuelta innecesarios entre el navegador y el servidor). Cada vez que tu script pide algo al servidor, sumamos latencia.
Para ganar la batalla de la agilidad, tendremos que aplicar estas tácticas:
- Batching de variables: Si vamos a definir varias variables para una fuente de datos, hagámoslo en líneas consecutivas. SAC detecta esta secuencia y las agrupa en una única petición al backend.
- setDimensionFilter() frente a setVariableValue(): En entornos BW Live, los filtros de dimensión directos son mucho más eficientes que los valores de variable, ya que reducen el «ruido» con el motor analítico de BW.
- El truco del «Käsekuchen» (Metadatos dummy): Al aplicar filtros, el sistema necesita el ID y la Descripción. Si no le pasas la descripción, SAC hace un viaje extra al servidor solo para buscarla. Pasar una descripción ficticia (como el famoso ejemplo del «Käsekuchen») es, curiosamente, mucho más rápido que dejar que el sistema la busque.
- Gestión de Loops: Nunca invoquemos un
getDataSource()dentro de un bucleFOR. Almacena los datos en una variable local antes de iterar para evitar peticiones redundantes. - Navegación entre historias: Al vincular dashboards, usaremos parámetros de URL específicos (Story ID + Model ID). Es más tedioso de configurar que los parámetros genéricos, pero la ganancia de velocidad al abrir la historia de destino es sustancial.
La optimización técnica es potente, pero sin orden no es nada. ¿Seguimos?
No es un ajuste puntual, es una metodología
A ver!!!!!! Que optimizar SAP Analytics Cloud no consiste en tocar un botón mágico. Podríamos resolverlo como un proceso estructurado que requiere rigor para que las mejoras sean superables por el usuario y no solo una «métrica verde» en un informe. Seguimos estas fases:
- Assess (~1,5 días): Registro de tiempos actuales y gestión de expectativas. Hay que ser honestos: el «tiempo real» absoluto a veces choca con las limitaciones de la infraestructura física.
- Analyze (~3 días): Identificación de cuellos de botella con el Runtime Analyzer. ¿El problema es el Frontend (scripts/diseño) o el Backend (consultas pesadas en BW/HANA / S/4 HANA / Datasphere)?
- Plan (~1 día): Priorización de medidas de alto impacto y bajo esfuerzo.
- Implement (>1 semana): Ejecución sistemática. Fundamental: trabajar siempre sobre una copia 1:1 del dashboard original. Solo así podemos comparar el «Antes vs. Después» de forma objetiva y asegurar que no rompemos ninguna funcionalidad.
Conclusión estratégica
La agilidad es lo que transforma el BI de un simple informe a una verdadera ventaja competitiva. El valor de SAP Analytics Cloud no reside en lo que cuesta la licencia, sino en el valor realizado a través de la adopción activa.
Un sistema lento es un sistema que no se usa y que fomenta el Shadow BI y la pérdida de gobierno sobre el dato. El rendimiento debe ser el pilar central de tu estrategia. No te conformes con que «funcione», asegúrate de que sea rápido. Solo así SAC será el motor de decisión que tu negocio necesita.
Espero que os sirva
Óscar Gómez Huertas - Consultor SAP 