Por qué muchos problemas de dashboard no nacen de la Business Intelligence

Cuando un dashboard se vuelve lento, los datos no cuadran o añadir una nueva fuente exige semanas de trabajo, la primera reacción suele ser mirar la herramienta de Business Intelligence.

«Power BI va lento.» «La query es demasiado compleja.» «El dataset se ha hecho demasiado grande.» «El refresh tarda demasiado.»

Pero muy a menudo el problema no está en el dashboard. Está en todo lo que ocurre antes.

En Syncronika lo vemos en el perímetro de data analytics y de la plataforma de datos: la BI es el último eslabón. Si la cadena de arriba es incoherente, ningún dashboard “arregla” el caos. Como mucho lo hace más visible.

Un dashboard es solo el último eslabón de la cadena. Antes hay que saber qué significa ese dato para la empresa.

1. Un dashboard es solo el último eslabón

Imaginemos una empresa que con los años ha acumulado varios sistemas: ERP, CRM, verticales, plataformas SaaS, API, bases de datos, archivos Excel y quizá algún legacy todavía operativo.

Cada uno produce datos según su propia estructura. El mismo concepto puede tener nombres, formatos y, peor aún, significados ligeramente distintos.

En ese punto construir un dashboard no significa simplemente conectarse a las fuentes y crear unos gráficos. Antes hay que responder a una pregunta más importante:

¿Qué significa ese dato para la empresa?

Si diez sistemas representan el mismo concepto de diez maneras distintas, el problema no se resuelve llevando las diez interpretaciones hasta el dashboard. Hay que definir una undécima: la de la empresa.

Es el mismo principio que usamos cuando una métrica no guía una decisión: sin vocabulario compartido, cada informe es una opinión.

2. Del Data Lake al modelo de datos empresarial

En los últimos años muchas organizaciones han invertido en crear un Data Lake. Fue un paso importante: centralizar datos ayuda a superar muchos de los silos creados por los distintos software de la empresa.

Pero centralizar no significa armonizar.

Podemos tener todos los datos en el mismo sitio y seguir teniendo información difícil de usar. Un Data Lake puede contener perfectamente:

datos duplicados
nomenclaturas distintas
información incompleta
formatos incompatibles
reglas de negocio implícitas
errores procedentes de los sistemas fuente
cientos de columnas que ninguna aplicación utiliza

El paso siguiente consiste en transformar el dato recogido en un modelo de datos común para la organización. Y ahí la arquitectura se vuelve fundamental.

3. La BI no debería ser el lugar donde se arregla todo

Herramientas como Power BI permiten hacer mucho: adquirir, transformar, unir, corregir, crear columnas calculadas, aplicar lógicas y construir modelos muy complejos.

Que sea posible no significa que sea el mejor sitio para hacerlo.

Cuando una cantidad creciente de lógica se desplaza al layer de Business Intelligence, el riesgo es construir un sistema difícil de mantener:

una nueva fuente exige nuevas transformaciones
una nueva estructura exige nuevas excepciones
un cambio de regla debe replicarse en varios puntos
los datasets crecen de tamaño
los refresh se alargan
resulta más difícil entender dónde se modificó un dato y por qué

El problema ya no es solo de rendimiento. Se convierte en un problema de arquitectura y gobernanza.

El mismo esquema lo describimos en el Company Brain: sin una capa informativa gobernada, cada herramienta (incluida la BI) hereda ambigüedad.

4. Separar responsabilidades y niveles

Una Data Platform moderna debería tener responsabilidades claras a lo largo del recorrido del dato. Una estructura conceptual útil:

Fuentes · ERP, CRM, PMS, e-commerce, API, bases de datos, archivos y apps externas. No hablan el mismo idioma.
Raw Data · dato adquirido cerca de su forma original. Sirve para histórico, auditoría y reelaboración cuando cambian las reglas.
Transformation & Data Quality · limpieza, normalización, deduplicación, mapping, excepciones y controles automáticos antes de la BI.
Canonical Data Model · el lenguaje de la organización. Cada fuente se mapea hacia una definición empresarial.
Semantic Layer · métricas, KPI, relaciones, agregaciones y dimensiones usables por el negocio.
Business Intelligence · visualización. Power BI, Tableau, Looker u otras: hacer el dato comprensible y usable.

Canonical Data Model y semantic layer son el punto en el que «ingreso» se vuelve igual para todos. No el informe individual.

En Syncronika este recorrido operativo vive en data analytics, reporting ejecutivo y plataforma de datos.

5. Data quality: cuadrar los números no basta

Dos sistemas muestran números distintos. Empieza una larga cuadratura para entender cuál es el correcto. Es necesaria, pero si se aborda solo caso a caso corre el riesgo de volverse infinita.

La pregunta útil no es solo «¿por qué estos dos números no cuadran?», sino:

¿En qué punto de la cadena empezaron a no cuadrar?

El error puede estar en la fuente, en la adquisición, en la transformación, en una business rule, en el modelo semántico, o simplemente en una definición distinta del mismo KPI.

Por eso preferimos un Data Quality Framework. Los controles más importantes se pueden automatizar:

número de registros
duplicados
valores faltantes
sumas y desviaciones
mappings no reconocidos
completitud de dimensiones
anomalías de dominio

La calidad del dato deja de ser una verificación ocasional y pasa a ser parte de la pipeline.

6. Python, Dataflow, Fabric: la tecnología viene después

Cuando surgen estos problemas es fácil desplazar de inmediato la discusión hacia la tecnología: ¿reescribimos en Python? ¿Usamos Dataflow? ¿Pasamos a Microsoft Fabric? ¿Creamos un Data Warehouse o un Lakehouse?

Todas son preguntas legítimas. Pero vienen después.

Una mala arquitectura no se vuelve buena porque se reescribe en Python. Un sistema poco gobernado no se vuelve gobernado porque se migra a Fabric.

Antes hay que entender:

cuáles son las fuentes
qué transformaciones se realizan
qué reglas de negocio existen
qué datos hacen falta de verdad
qué debe historificarse
qué requisitos de rendimiento existen
quién es responsable del dato
cómo se verifica la calidad
cómo crecerá el sistema

Solo después tiene sentido elegir las herramientas.

Es el mismo orden que usamos en AI Transformation: primero procesos y definiciones, después el multiplicador tecnológico.

7. Escalabilidad no significa solo gestionar más datos

Una arquitectura puede contener otros millones de registros y seguir siendo poco escalable. Para nosotros existe también una escalabilidad organizativa:

¿cuánto cuesta añadir una nueva fuente?
¿cuánto tiempo hace falta para integrar una nueva empresa, filial o sede?
¿cuántas partes del sistema hay que modificar?
¿cuántas reglas hay que replicar a mano?
¿cuánto debe conocer una sola persona del sistema para que todo siga funcionando?

Si añadir una nueva fuente significa copiar queries, modificar a mano decenas de transformaciones y conocer excepciones no documentadas, el problema de escalabilidad existe con independencia de la potencia de la infraestructura.

8. El verdadero objetivo: convertir el dato en infraestructura empresarial

Una buena Data Platform no sirve solo para producir dashboards mejores. Sirve para crear un nivel común sobre el que construir aplicaciones, automatizaciones, análisis y, cada vez más, sistemas de Inteligencia Artificial.

Un agente puede analizar enormes cantidades de información más rápido que una persona. Pero si las definiciones son ambiguas, las fuentes incoherentes y las business rules no están formalizadas, simplemente estamos permitiendo que la AI elabore más rápido datos que no comprendemos lo bastante.

Trabajar en Data Architecture hoy significa también preparar la infraestructura sobre la que funcionarán las aplicaciones de AI de mañana.

El punto no es tener más datos. Ni dashboards más bonitos. Es llegar a una situación en la que la empresa sabe:

qué datos posee
qué significan
de dónde vienen
qué transformaciones han sufrido
cuánto puede fiarse del resultado

Es en ese momento cuando un Data Lake deja de ser un sitio donde acumular información. Y empieza a convertirse en una verdadera infraestructura de datos empresarial.

Checklist operativa

Listar las fuentes críticas y los conceptos compartidos (cliente, pedido, ingreso, stock…)
Definir el vocabulario empresarial antes de otro informe Power BI
Separar raw, transformaciones y modelo canónico de la BI
Poner los controles de data quality en la pipeline, no solo en la reunión de cuadratura
Medir el coste de añadir una nueva fuente (tiempo, personas, excepciones)
Solo después elegir el stack (warehouse, dbt, Fabric, lakehouse…)

Qué preguntar al próximo proveedor (o al equipo interno)

¿Qué decisiones deben mejorar, y con qué cadencia?
¿Quién posee las métricas críticas y quién aprueba su definición?
¿Dónde vive hoy la lógica de transformación: en Power BI, en el script o en un modelo versionado?
¿Cómo se intercepta una desviación antes de que llegue al board?
¿Cuánto cuesta añadir la próxima fuente o filial?

Dónde empezar

Si los números no cuadran, los refresh no bastan o cada nueva fuente se convierte en un proyecto aparte, cuéntanos el perímetro: partimos de las fuentes y las definiciones, no del próximo dashboard.