Trabajar con BI corporativo: lo que nadie te cuenta

En 2019 Salesforce pagó 15.700 millones de dólares por Tableau. Google compró Looker por 2.600 millones el mismo año. Microsoft regala Power BI Desktop y cobra por compartir. Nadie invierte esas cantidades ni monta esos modelos de precios por casualidad: el BI corporativo es un negocio gigante, y cuando entras a trabajar en una empresa te chocas con una realidad que ningún tutorial de dashboards menciona. La herramienta que usarás no la eliges tú. El dashboard que montes no puede conectarse a donde tú quieras. Y el mismo panel enseñará números distintos según quién lo abra. Nada de esto es sobre saber hacer gráficos: es sobre trabajar con datos DENTRO de una organización, con sus costes, sus reglas y sus límites. Esta lección es ese lado que solo se aprende cuando ya estás dentro.

Ya sabes cómo funciona una herramienta de BI por dentro: sus capas, cómo conecta con las fuentes, cómo relaciona tablas y refresca datos. Eso es lo que la herramienta hace. Ahora toca lo que la empresa hace CON la herramienta: cuánto le cuesta, cómo la protege, quién puede tocarla y qué pasa cuando doscientas personas la usan a la vez. Son las decisiones que se toman por encima del dashboard, y que condicionan todo lo que puedes construir con él.

### Las licencias: por qué la empresa no elige la mejor herramienta

Empecemos por lo que más sorprende al que llega: la empresa casi nunca elige la herramienta más potente. Elige la que sale a cuenta. Y para entender por qué, hay que entender cómo se cobra el BI, porque no es como comprar un programa una vez. Se paga por usuario y por mes, y ahí es donde la aritmética manda sobre la técnica.

Casi todas las herramientas dividen a los usuarios en dos tipos, con nombres que varían pero con la misma lógica. Está el que CREA — el creator, el editor, el que construye dashboards, conecta fuentes y define métricas — y está el que MIRA — el viewer, el consumer, el que solo abre un panel ya hecho y lo consulta. El primero cuesta bastante más que el segundo, porque hace mucho más. En una empresa típica hay unos pocos creadores (el equipo de datos, tú) y muchísimos espectadores (toda la organización que consume los dashboards).

Hagamos la cuenta que hace un director financiero, porque es la que decide de verdad. Una empresa de 500 personas donde 10 construyen dashboards y 200 solo los miran. Empieza por los que miran, que son los que mandan en la factura: con una herramienta cuya licencia de espectador cuesta 10 euros al mes, esos 200 son 2.000 euros al mes, 24.000 al año. Con otra a 15, son 3.000 al mes, 36.000 al año: 12.000 euros de diferencia anuales, y eso que la licencia solo cuesta cinco euros más. Ahora mira a los 10 que construyen, que pagan la licencia cara, 70 euros al mes cada uno: 8.400 al año entre todos. Los 200 que solo miran cuestan más de cuatro veces lo que los 10 que construyen. Ésa es la aritmética que decide una compra de BI: no cuánto cuesta la licencia buena, sino cuánta gente va a mirar. Y por eso Power BI, incluido en las licencias de Microsoft que la empresa ya paga, arrasa aunque Tableau sea más bonito.

### Rendimiento a escala: por qué nunca se conecta al corazón de la empresa

Imagina la base de datos donde la empresa registra cada venta en el momento en que ocurre: la que usa la web para cobrar, la que el almacén consulta para saber el stock, la que sostiene el negocio minuto a minuto. Se llama base de datos de producción, y es sagrada. Ahora imagina que conectas un dashboard directamente a ella, lo compartes con 200 personas, y cada mañana a las 9:00 todas lo abren a la vez. Doscientas consultas pesadas cayendo sobre la misma base que está intentando cobrar a los clientes. El resultado no es un dashboard lento: es una web que deja de vender porque su base está ahogada respondiendo a informes.

Esta es una regla que no se negocia en ninguna empresa seria: un dashboard NUNCA se conecta directamente a la base de producción. Entre el dashboard y el corazón del negocio siempre hay una capa intermedia que absorbe el golpe. Esa capa tiene varias formas, pero todas cumplen la misma función: que las consultas de análisis no toquen la base que hace funcionar la empresa.

Las formas que toma esa capa intermedia ya te suenan de cómo funciona una herramienta por dentro. Puede ser un almacén de datos (data warehouse) separado, una copia pensada para análisis que se refresca de noche. Pueden ser tablas resumen o tablas de agregación: en vez de guardar cada venta individual, se guarda ya el total por día y por región, mucho más ligero de consultar. Pueden ser vistas SQL que preparan el dato. Y recuerda el modo importación de la lección anterior: cuando la herramienta copia los datos dentro de sí misma, esa copia ES una forma de capa intermedia, porque las consultas ya no van a la fuente.

### Seguridad de los datos: el mismo dashboard, filas distintas

Aquí hay un concepto que cambia la forma de pensar los dashboards y que casi nadie explica al empezar. Imagina un único dashboard de ventas por comercial, y dos personas que lo abren: el comercial de la región Norte y el director general. Quieres que el comercial vea SOLO sus ventas, y que el director las vea TODAS. La solución ingenua sería hacer dos dashboards. La solución profesional es hacer UNO que muestre filas distintas según quién lo mira. Eso se llama seguridad a nivel de fila — row-level security, o RLS.

La seguridad a nivel de fila conecta la identidad de quien abre el dashboard con los datos que tiene permitido ver. La herramienta sabe quién ha iniciado sesión, y aplica un filtro invisible y obligatorio: "este usuario pertenece a la región Norte, así que de la tabla de ventas solo le devuelvo las filas de Norte". El comercial no ve las demás filas, no puede verlas, y no sabe cuántas hay. El director, con permiso total, ve todo. Un solo dashboard, una sola definición, tantos alcances como perfiles de usuario.

Y aquí llega la distinción crítica que separa un dato seguro de uno expuesto: un filtro NO es seguridad. Es tentador pensar que si el dashboard tiene un filtro de región puesto en "Norte", el comercial solo ve lo suyo. Falso, y peligroso. Un filtro es una comodidad visual que el usuario puede cambiar: quita el filtro, o edita la dirección web, y ve todas las regiones. La seguridad a nivel de fila es distinta: es un filtro OBLIGATORIO que la herramienta impone por debajo, que el usuario no ve, no puede quitar y no puede saltarse. Confundir un filtro con seguridad es cómo se filtran datos que no deberían salir.

### Self-service contra BI gobernado: la libertad contra la verdad única

Hay una tensión que atraviesa toda organización que trabaja con datos, y que no tiene solución perfecta, solo equilibrios. Por un lado está el deseo de que cualquiera explore los datos por su cuenta, sin depender del equipo de datos para cada pregunta. Eso es el BI de autoservicio — self-service BI. Por otro lado está la necesidad de que haya UNA sola verdad: que cuando alguien dice "ingresos", todos entiendan exactamente lo mismo. Eso es el BI gobernado — governed BI.

El autoservicio suena maravilloso: das las herramientas a toda la empresa, cada uno responde sus preguntas, el equipo de datos deja de ser un cuello de botella. Y funciona... hasta que empieza el caos. Porque cuando cien personas pueden calcular "ingresos" a su manera, aparecen cien definiciones sutilmente distintas. Uno incluye el IVA, otro no. Uno cuenta los pedidos cancelados, otro los quita. Uno usa la fecha del pedido, otro la del cobro. Y llega el día en que dos personas presentan al mismo director dos cifras de ingresos que no cuadran, y nadie sabe cuál es la buena. La confianza en los datos se derrumba.

La mayoría de las empresas maduras no eligen un extremo, sino una mezcla: dejan explorar libremente sobre un conjunto de métricas ya definidas y certificadas. Es decir, tú puedes cruzar, filtrar y combinar como quieras, pero cuando usas "ingresos", usas LA definición oficial de ingresos, no la tuya. Eso se consigue con la pieza que une las dos secciones: la capa semántica gobernada.

### La métrica única de verdad: una definición para gobernarlas a todas

La capa semántica gobernada es un sitio central donde la empresa define, una sola vez y de forma oficial, qué significa cada métrica. Ahí está escrito que "ingresos" es la suma del importe de los pedidos completados, sin IVA, por fecha de cobro. Punto. Cuando cualquiera en la empresa arrastra "ingresos" a un gráfico, usa esa definición, venga de donde venga y la mire quien la mire. Ya viste una forma de esto en cómo funciona una herramienta por dentro: definir el margen en una vista SQL en vez de dejar que cada uno lo recalcule. La capa semántica lleva esa idea a toda la empresa y a todas las métricas.

Distintas herramientas materializan esta idea de formas distintas. Looker fue famoso precisamente por esto: su lenguaje LookML es una capa semántica donde se declaran las métricas de forma centralizada, y nadie las redefine por su cuenta. Power BI tiene sus modelos semánticos compartidos y sus métricas certificadas. Están surgiendo capas semánticas independientes que se sitúan entre la fuente y varias herramientas a la vez. El nombre y la tecnología cambian; el objetivo es siempre el mismo: que "ingresos" signifique una sola cosa en toda la organización.

### Compliance y sectores regulados: cuando los datos tienen abogados

En muchos sectores, cómo tratas los datos no es una decisión técnica ni de negocio: es una obligación legal con inspecciones y multas detrás. A este conjunto de normas y controles se le llama cumplimiento normativo — compliance. Y en sectores como la banca, la sanidad, los seguros o las telecomunicaciones, condiciona qué herramienta de BI se puede usar y cómo.

Tres cosas cambian cuando trabajas con datos en un sector regulado. La primera es la certificación: la herramienta debe cumplir normas específicas (protección de datos personales, seguridad de datos de pago, historiales clínicos) y estar certificada para ello. No vale cualquier herramienta: por eso las opciones muy establecidas como Power BI o Qlik, con años de certificaciones acumuladas, ganan a las alternativas más nuevas o de código abierto en estos entornos. La segunda es la auditoría: hay que poder demostrar quién vio qué dato y cuándo. Cada acceso queda registrado, porque un inspector puede preguntar "¿quién consultó los datos de este paciente el mes pasado?" y la respuesta tiene que existir.

La tercera es dónde viven los datos, lo que se llama residencia del dato — data residency. Aquí conviene deshacer un malentendido muy común: el RGPD no obliga a que los datos personales se queden dentro de la Unión Europea. Lo que hace es regular su salida: se pueden transferir a un país que la Comisión Europea haya declarado con protección adecuada, o con garantías específicas —las cláusulas contractuales tipo son las más habituales—, y fuera de eso solo con excepciones muy tasadas. Ahora bien, en la práctica muchas empresas, y casi todos los bancos y hospitales, exigen residencia europea igualmente, porque es la vía más simple de cumplir y porque su regulador o su cliente se lo pide por contrato. Así que un banco español no va a poder montar un dashboard que copie datos de clientes a un servidor en otro continente, por muy buena que sea la herramienta — no porque el RGPD lo prohíba en seco, sino porque su contrato y su supervisor no se lo permiten. La ley y el contrato deciden antes que la técnica.

### Todo esto apunta a lo mismo: alguien tiene que gobernar

Mira atrás a lo que hemos recorrido. Las licencias hay que administrarlas: decidir quién es creador y quién espectador, y revisarlo. El rendimiento hay que protegerlo: vigilar que nadie conecte un dashboard al corazón del negocio. La seguridad hay que configurarla y mantenerla: los permisos de quién ve qué cambian cuando la gente cambia de puesto. La verdad única hay que defenderla: alguien tiene que ser el guardián de la definición de "ingresos". Y el compliance hay que demostrarlo, con registros y controles. Ninguna de estas cosas se sostiene sola.

Todo esto es trabajo continuo, no una configuración que se hace una vez y se olvida. Los dashboards se multiplican, la gente entra y sale, las métricas cambian, las herramientas se actualizan. Sin alguien que ponga orden, una empresa acaba con cientos de dashboards que nadie sabe si están vivos, permisos que no se revisan desde hace años, y tres definiciones de cada métrica. A esa disciplina de mantener el orden a lo largo del tiempo se la llama gobierno, y es la diferencia entre un BI que la empresa controla y uno que se le ha ido de las manos. Cómo se mantiene, se versiona y se retira un dashboard —quién es su dueño, cuándo se archiva, cómo se evita el caos— tiene lección propia más adelante.