Herramientas BI modernas: Power BI, Tableau, Looker y alternativas open source para cada caso de uso

Capítulo 31 · Parte IV: Business Intelligence y consumo · Guía práctica para diseñar y operar la arquitectura de datos de tu empresa

El capítulo anterior dejó escrito el criterio con el que se ordena esta comparativa: antes de mirar visualizaciones hay que saber qué herramienta puede consumir la capa semántica elegida y cuál pretende convertirse en ella. Con esa pregunta en la mano, este capítulo recorre las herramientas de Business Intelligence que protagonizan buena parte de las conversaciones de compra en 2026 —Power BI, Tableau, Looker, Qlik y las alternativas open source— y propone una forma de elegir que no depende de la demo del comercial.

Tres promesas en todas las páginas de precios

Quien recorra en octubre de 2026 las páginas de precios de las principales herramientas de BI encontrará un vocabulario casi intercambiable. Tableau organiza toda su oferta en torno al análisis con agentes. Qlik presenta su analítica como agéntica e incluye agentes de respuesta y un servidor MCP desde su plan más pequeño. Microsoft ofrece Copilot en cualquier capacidad de Fabric de pago, desde la F2. Looker mide en tokens de datos el uso de su analítica conversacional. Metabase pone su asistente en todos los planes, incluido el gratuito si el cliente aporta las credenciales de su propio proveedor de modelos, y Lightdash se presenta como una plataforma de BI nativa de IA sin precio por usuario. Debajo de las etiquetas se repiten tres promesas: autoservicio para que cualquiera responda sus propias preguntas, inteligencia artificial que lo haga más rápido y gobierno de nivel empresarial para que nada se descontrole por el camino.

Las tres promesas son razonables, y precisamente por eso no ayudan a elegir. Cuando todos los fabricantes dicen hacer lo mismo, la comparación útil empieza donde termina el folleto, en cuatro preguntas que ninguna demostración responde por iniciativa propia: quién va a consumir el análisis y con qué frecuencia, dónde vive la definición de cada métrica, cómo crece la factura cuando crece el uso y quién opera la plataforma cuando algo falla el día del cierre mensual.

Ahí está la tesis del capítulo. La mejor herramienta de BI es la que mejor sirve al tipo de consumidor dominante en cada organización y encaja con su modelo operativo, y la decisión se toma con dos instrumentos: un mapa de quién consume qué, que aquí se llama la matriz de los tres consumidores, y una métrica económica que no se deja engañar por las licencias compradas, el coste por usuario activo. El ranking sirve como punto de partida y la demo como comprobación final; ninguno de los dos sustituye ese trabajo previo.

El orden de la Parte IV tiene intención. El capítulo 29 situó el BI como un producto de datos con dueño y usuarios definidos; el 30 llevó las métricas a una capa semántica que no depende de ninguna herramienta concreta. Con esas dos decisiones tomadas, elegir herramienta se convierte en una decisión de interfaz, mucho más acotada que una apuesta de plataforma: qué superficie de consumo sirve mejor a cada usuario sobre unas métricas que ya están definidas en otro sitio. Si las dos decisiones siguen pendientes, la herramienta las tomará por la organización, y casi siempre a su favor: el modelo semántico quedará dentro de ella y cada informe nuevo hará más cara la salida.

Seis definiciones para comparar sin hablar idiomas distintos

Buena parte de las comparativas de herramientas fracasan porque cada participante usa las mismas palabras con significados distintos. Conviene fijar seis términos antes de entrar en productos y precios.

El BI de exploración es la actividad de quien interroga los datos sin conocer de antemano la pregunta definitiva: cruza dimensiones, crea cálculos, compara hipótesis y descarta la mayoría. Exige una herramienta expresiva, acceso amplio al modelo y tiempos de respuesta aceptables con consultas que nadie había previsto. La practican pocos usuarios, muchas horas a la semana, y en las herramientas comerciales suele requerir las licencias más caras, las de creador.

El BI de consumo es la actividad de quien abre contenido ya construido para responder una pregunta recurrente o seguir un indicador: cómo van las ventas de la semana, cuántos pedidos están retrasados, si el margen está dentro del objetivo. Exige rapidez, claridad, acceso desde el móvil, alertas y ninguna fricción. Lo practican muchos usuarios, pocos minutos cada vez, y su coste depende sobre todo de cómo cobre la herramienta la lectura: por usuario, por capacidad compartida o por volumen de datos.

El coste por usuario activo es el coste total anual de una herramienta de BI —licencias, capacidad, infraestructura, operación, formación, gobierno y la parte atribuible del cómputo del almacén de datos— dividido entre los usuarios que la han utilizado de forma significativa en el periodo, según un umbral de actividad definido de antemano. Es la métrica económica de este capítulo, y la que convierte una conversación sobre precios de lista en una conversación sobre valor.

La gobernanza de contenido es el conjunto de funciones y prácticas con que una herramienta distingue el contenido certificado del exploratorio, controla quién publica y dónde, versiona los cambios, retira lo que nadie usa y deja traza de quién consultó qué. Es la traducción operativa del ciclo de vida de producto que proponía el capítulo 29, y la base sobre la que el capítulo 33 construirá los carriles del autoservicio.

Open source en BI significa que el código de la herramienta se distribuye con una licencia que permite usarlo, estudiarlo y modificarlo sin pagar al autor. No significa gratis de operar, y tampoco significa lo mismo en todos los casos: una licencia permisiva como Apache 2.0 o MIT y una licencia copyleft de red como la AGPL tienen consecuencias muy distintas cuando la analítica se ofrece a terceros.

Y el BI embebido (embedded analytics) es la analítica servida dentro de otra aplicación —un portal de clientes, un producto SaaS, una aplicación interna— con la identidad, los permisos y la imagen de esa aplicación. Tiene su propio capítulo, el 35, pero aparece aquí porque condiciona la elección de herramienta más que ningún otro requisito.

La distinción entre exploración y consumo tiene una consecuencia económica inmediata. En casi todas las herramientas comerciales, el precio por persona que explora es varias veces el precio por persona que solo consume, y la mayoría de usuarios de una organización consume. Por eso la cifra que más pesa en la factura de BI rara vez es la licencia del analista: es la suma de cientos de lectores, multiplicada por el precio que la herramienta asigna a la lectura. Una herramienta excelente para explorar puede resultar ruinosa como superficie de consumo masivo, y al revés.

La matriz de los tres consumidores

El marco de este capítulo parte de una observación sencilla: en casi cualquier organización, la analítica tiene tres tipos de destinatario con necesidades tan distintas que ninguna herramienta los sirve igual de bien a los tres. Evaluar herramientas en abstracto, con una única nota global, esconde exactamente lo que importa. La matriz de los tres consumidores obliga a hacer la pregunta correcta: cómo sirve cada herramienta a cada consumidor, y cuántos consumidores de cada tipo tiene de verdad la organización.

El primero es el analista explorador. Es el controller que descompone el margen, la responsable de revenue management que compara tarifas y ocupación, el analista de operaciones que busca el origen de un retraso o el científico de datos que hace análisis descriptivo antes de modelar. Necesita expresividad, libertad para crear cálculos propios sobre métricas gobernadas, conexión a muchas fuentes y un rendimiento aceptable con consultas no previstas; si trabaja con modelos como código, también necesita control de versiones. Es una minoría de los usuarios, pero la que más horas pasa dentro de la herramienta y la que más influye en la elección, porque es quien asiste a las demos.

El segundo es el consumidor ejecutivo, y el adjetivo se queda corto: incluye a la dirección, pero también a mandos intermedios, comerciales, jefes de turno o responsables de tienda. Necesita que la respuesta esté a un toque, en el móvil o en la herramienta de colaboración que ya usa, con contexto —frente al objetivo, frente al periodo anterior— y con alertas que le avisen cuando algo se sale del rango. No quiere aprender una herramienta y no debería tener que hacerlo. Es la mayoría de los usuarios, el que determina la factura en cualquier modelo por usuario y el que decide si el BI se usa o se archiva.

El tercero es el cliente embebido: alguien de fuera de la organización —un cliente, un proveedor, un socio, un ciudadano— que recibe analítica dentro de otro producto. Necesita aislamiento total respecto a los datos de otros clientes, la imagen de marca del producto que usa, un inicio de sesión transparente y un rendimiento estable cuando miles de usuarios externos consultan a la vez. Y necesita, sobre todo, un modelo de precio que encaje con la unidad de ingresos del negocio que lo sirve, sea el cliente, la sesión o la carga de un panel, porque la licencia por usuario interno no tiene sentido cuando los usuarios son los clientes de un SaaS. Su desarrollo completo llegará en el capítulo 35.

La regla del marco es doble. Cada herramienta se evalúa por consumidor, nunca en abstracto, y la ponderación la decide el reparto real de usuarios de la organización, medido y no supuesto. Una empresa con veinte analistas y dos mil lectores no debería elegir con los criterios de los veinte analistas, aunque sean ellos quienes vean las demos. El recuento se obtiene de los registros de actividad de las herramientas actuales, de las listas de distribución de informes por correo y de las hojas de cálculo que circulan como sustituto del BI, que también son consumo.

Un cuarto consumidor ha empezado a llamar a la puerta: el agente de IA que formula consultas en nombre de una persona. Se comporta como un explorador incansable, pero no puede preguntar a nadie qué significa «margen», y por eso necesita leer las métricas gobernadas de la capa semántica en lugar de escribir SQL contra las tablas, como explicaba el capítulo 30. Varias herramientas ya exponen un servidor MCP (Model Context Protocol) para que agentes externos consulten su contenido: Tableau lo incluye en todas sus ediciones de Tableau Cloud, Qlik desde su plan Starter, Metabase en todos sus planes y Apache Superset como servicio opcional desde su versión 6.1. No justifica todavía una columna propia en la matriz, pero sí una pregunta obligatoria en cualquier evaluación: qué ve un agente cuando consulta la herramienta, y con qué permisos.

La tabla siguiente aplica la matriz a las siete herramientas que recorre este capítulo. Es una valoración editorial orientativa, a octubre de 2026, que conviene contrastar con las necesidades y los datos de cada organización; su utilidad está en el método más que en las notas.

Panorama 2026: qué ofrece cada plataforma y a quién sirve mejor

El mercado de BI encadena adquisiciones, renombrados y cambios de licencia con una frecuencia que deja obsoleta cualquier comparativa en pocos trimestres. Lo que sigue separa lo que envejece despacio —el modelo de consumo para el que está pensada cada herramienta y dónde guarda la semántica— de lo que cambia a menudo: precios, ediciones y nombres comerciales, que se recogen fechados en la sección siguiente.

Microsoft Power BI y Fabric: la economía del ecosistema

Power BI encabeza el ranking de software de Business Intelligence 2026 de Dataprix, y su argumento principal es económico antes que funcional. Power BI Desktop, la herramienta de creación, es gratuita; publicar y compartir exige una licencia Pro; las funciones avanzadas para un grupo reducido se cubren con Premium por usuario; y el consumo masivo se resuelve con capacidad de Microsoft Fabric. La antigua capacidad Premium (los SKU «P») ya no se vende a clientes nuevos, y su sucesora son los SKU «F» de Fabric, de la F2 a la F2048. El umbral que más conviene recordar es la F64: según la documentación de Microsoft, solo a partir de esa capacidad pueden los usuarios con licencia gratuita ver contenido de Power BI con el rol de visor; en capacidades menores, cada lector sigue necesitando su licencia Pro o Premium por usuario. Desde el 30 de abril de 2025, Copilot y el resto de funciones de IA de Fabric están disponibles en cualquier capacidad de pago desde la F2, y consumen de esa misma capacidad.

La semántica vive en el modelo semántico de Power BI, heredero del motor tabular de Analysis Services, con DAX como lenguaje y el modo Direct Lake para leer tablas de OneLake sin importarlas; el capítulo 30 lo describía como una de las capas integradas con más recorrido en producción. Para analítica dirigida a clientes, Power BI Embedded permite servir informes dentro de una aplicación sin licencias por usuario final, en el escenario que Microsoft denomina App Owns Data. En nuestra valoración, es la opción con mejor relación coste-alcance para el consumidor ejecutivo en organizaciones que ya viven en Microsoft 365, con una red de partners en España muy amplia, y sus puntos débiles están en la curva de aprendizaje de DAX y en el dimensionado de la capacidad, que exige medir antes de reservar. El caso de Vandelar del capítulo 28 mostraba la plataforma desde el lado de la integración; aquí interesa su lado de consumo.

Tableau: la exploración visual bajo el paraguas de Salesforce

Tableau sigue siendo la referencia en exploración visual: la libertad con que un analista pasa de una pregunta a un gráfico y de ahí a la siguiente pregunta es su seña de identidad desde hace dos décadas, y la versión gratuita de Tableau Desktop, que permite analizar archivos y bases de datos en local sin publicar, facilita que los analistas lleguen formados. Su licenciamiento es por rol —Creator, Explorer y Viewer—, con contrato anual y al menos un Creator por despliegue, en dos ediciones principales (Standard y Enterprise) y una premium, Tableau Cloud+, que añade los agentes de Tableau. Para reducir el coste del consumo masivo, Tableau Cloud ofrece precio por capacidad para los lectores, y Tableau Server una modalidad por núcleos de cómputo.

La gran novedad del último año es Tableau Next, una plataforma distinta de Tableau Cloud y de Tableau Server, construida sobre la plataforma de Salesforce, con Tableau Semantics como capa semántica y agentes integrados con Agentforce. Se vende por separado o dentro del paquete Tableau+, junto con Tableau Cloud. Para un cliente de Salesforce, la integración tiene sentido; para el resto, conviene entender que la hoja de ruta de la herramienta se decide cada vez más en función de ese ecosistema. A juicio de la redacción de Dataprix, Tableau es la mejor opción para el analista explorador y una opción cara para el consumidor ejecutivo masivo si no se negocia el precio por capacidad.

Looker: el modelo como código de Google Cloud

Looker fue durante años la excepción del BI de autoservicio: en lugar de dejar que cada informe definiera sus fórmulas, obliga a describir el negocio en LookML, un lenguaje de modelado que se versiona como cualquier otro código. Desde 2024, ese modelo puede consultarse desde otras herramientas, como detallaba el capítulo 30. Se comercializa en tres ediciones de plataforma —Standard, para equipos de menos de cincuenta usuarios; Enterprise, con más seguridad y cuotas de API; y Embed, pensada para analítica dirigida a clientes— a las que se suman licencias por tipo de usuario (Developer, Standard y Viewer). No conviene confundirlo con Looker Studio, el antiguo Data Studio, que es otro producto, gratuito en su versión básica y pensado para informes sencillos.

Dos rasgos condicionan su coste. Las consultas se ejecutan en la base de datos, de modo que la factura del almacén crece con el uso de Looker y forma parte de su coste real. Y su analítica conversacional se mide en tokens de datos, con una cuota mensual incluida en cada edición. En nuestra valoración, Looker es la opción más sólida cuando la gobernanza de métricas y la analítica embebida pesan más que la libertad de exploración, a condición de contar con un equipo que mantenga LookML; sin ese equipo, el modelo se degrada y la herramienta pierde su principal ventaja.

Qlik Cloud Analytics: motor asociativo y precio por volumen de datos

Qlik se diferencia por su motor asociativo, que carga los datos en memoria y permite seleccionar en cualquier dimensión para ver al instante qué valores quedan asociados y cuáles excluidos. Para la exploración comercial o de operaciones, donde la pregunta interesante suele ser qué no se ha vendido o qué cliente ha dejado de comprar, sigue siendo una experiencia difícil de igualar. Su modelo de precio en la nube es uno de los más singulares del mercado: a partir del plan Standard, Qlik Cloud Analytics cobra por el volumen de datos cargados para el análisis, sin coste por usuario adicional. El plan Starter, para equipos pequeños, sí limita usuarios.

Esa estructura invierte la lógica habitual: el coste por usuario activo baja a medida que crece la adopción, y el riesgo se desplaza al crecimiento de los datos. Qlik mantiene además la opción de desplegar su plataforma en la infraestructura del cliente, la integración con Qlik Talend para la ingesta y agentes de respuesta incluidos en sus planes. La valoración editorial es que encaja especialmente bien en organizaciones con muchos lectores, volúmenes de datos contenidos y analistas que valoran la exploración libre.

Las alternativas open source: Superset, Metabase y Lightdash

Tres proyectos concentran las evaluaciones de BI de código abierto. Apache Superset, gobernado por la Apache Software Foundation y con licencia Apache 2.0, es probablemente el más completo en variedad de visualizaciones y en trabajo con SQL; su versión 6.0 rediseñó por completo la interfaz y la 6.1, publicada en mayo de 2026, añadió un marco de extensiones y un servicio MCP opcional. Metabase es el más accesible para usuarios de negocio, con un editor visual de preguntas que no exige SQL; su edición abierta tiene licencia AGPL y sus planes de pago añaden funciones de gobierno. Lightdash es el más reciente y el más especializado: convierte un proyecto de dbt en una herramienta de BI, de modo que las métricas se definen en el repositorio y no en la interfaz; su núcleo tiene licencia MIT y su versión en la nube se cobra con tarifa plana y usuarios ilimitados. La sección dedicada al open source detalla qué implica cada licencia y qué cuesta operarlos.

El resto del ranking y los especialistas

El ranking de Dataprix completa su clasificación con SAP Analytics Cloud y Oracle Analytics Cloud, que tienen su mejor argumento en organizaciones cuyo ERP y cuya planificación financiera ya viven en esos ecosistemas; Domo, plataforma nativa en la nube con integración de datos incluida; ThoughtSpot, que hizo de la búsqueda en lenguaje natural su seña de identidad mucho antes de que la IA generativa la popularizara; Strategy One, heredera de MicroStrategy, y Pyramid Analytics, que une preparación de datos, análisis y ciencia de datos en un solo entorno. Fuera del ranking, Sigma merece una mención por su enfoque de hoja de cálculo sobre el almacén en la nube, pensado para equipos, a menudo financieros, que no quieren abandonar la cuadrícula.

Cómo se paga el BI: cuatro modelos de licencia y su letra pequeña

Detrás de las tarifas de lista hay solo cuatro maneras de cobrar el BI, y cada una crece de forma distinta cuando crece el uso. Entenderlas importa más que memorizar precios, porque decide qué ocurre con la factura el día en que la herramienta tiene éxito.

El modelo por usuario o por rol cobra una cuota por persona con acceso, normalmente distinta según lo que esa persona puede hacer: crear, explorar o solo leer. Es el modelo de Power BI Pro y Premium por usuario, de los roles Creator, Explorer y Viewer de Tableau, de los tipos de usuario de Looker y de los planes de pago de Metabase. Es predecible y fácil de presupuestar, pero crece en línea recta con la adopción y castiga justamente lo que se busca: que más gente consulte los datos.

El modelo por capacidad cobra por una cantidad de cómputo reservada que comparten todos los usuarios. Es el de las capacidades F de Fabric, el de Power BI Embedded y el precio por capacidad que Tableau ofrece para sus lectores. Su coste es escalonado: plano mientras la capacidad aguanta y con un salto cuando hay que subir de tamaño. Recompensa la adopción amplia, pero exige medir el consumo real antes de comprometerse y vigilar que las cargas de actualización no compitan con las consultas de los usuarios a primera hora.

El modelo por volumen de datos cobra por la cantidad de datos que se cargan para analizar, con independencia de cuántas personas los consulten. Es la apuesta de Qlik Cloud Analytics desde su plan Standard. Desacopla el precio de la adopción y lo acopla al crecimiento de los datos, de modo que el riesgo cambia de sitio: lo que hay que vigilar ya no es cuánta gente entra, sino qué se carga y durante cuánto tiempo se conserva.

El modelo por consumo cobra por unidades de uso: tokens de IA, cargas de un panel embebido, ejecuciones de transformaciones o consultas. Aparece en la analítica conversacional de Looker, en el servicio de IA gestionado de Metabase o en el complemento de analítica embebida de Lightdash, y conviene recordar que existe siempre, aunque la herramienta no lo facture, en el almacén de datos que responde a las consultas en vivo. Es el modelo más justo en teoría y el más difícil de presupuestar en la práctica.

La tabla recoge los precios de lista que cada fabricante publica en su web, consultados el 19 de octubre de 2026, sin impuestos y en la moneda en que los publica cada uno. Son la parte más volátil del capítulo: conviene comprobarlos antes de cualquier presupuesto y recordar que los contratos empresariales se negocian.

Fuentes: páginas de precios de Power BI, Tableau Cloud, Tableau, Looker, Qlik Cloud Analytics, Metabase y Lightdash, consultadas el 19 de octubre de 2026. Microsoft advierte de que los importes de su web son orientativos y el precio real se muestra al comprar.

Dos matices de la tabla merecen especial atención. El primero es el umbral de la F64. Con la tarifa de referencia de Fabric en regiones de Estados Unidos, de unos 0,18 dólares por unidad de capacidad y hora, una F64 reservada un año cuesta del orden de 5.000 dólares mensuales, lo mismo que unas 350 licencias Pro. Por debajo de esa cifra de lectores, las licencias por usuario suelen salir más baratas; por encima, la capacidad empieza a compensar, siempre que los creadores conserven su licencia Pro, que sigue siendo obligatoria para publicar. El cálculo debe hacerse con los precios de la región contratada y con el consumo real medido en pago por uso durante al menos un ciclo de negocio completo, que es lo que la propia Microsoft recomienda antes de reservar.

El segundo matiz es la IA medida. Google ha extendido el periodo promocional de la analítica conversacional de Looker y se compromete a avisar con al menos noventa días antes de empezar a facturar el exceso sobre la cuota, que costará 3 dólares por millón de tokens de entrada y 20 por millón de tokens de salida. Metabase cobra su servicio de IA gestionado por tokens, salvo que el cliente aporte las credenciales de su propio proveedor de modelos. Y en Fabric, Copilot consume de la misma capacidad que los informes. En los tres casos, el coste de la IA depende de cuánto se use, y lo prudente es presupuestarlo con un piloto medido, no con la tarifa base.

Coste por usuario activo: la métrica que desarma la demo

La pregunta «cuánto cuesta la herramienta» tiene una respuesta engañosa, el precio de lista, y otra útil: cuánto cuesta cada persona que de verdad la usa. El coste por usuario activo responde a la segunda, y suele revelar que la herramienta más barata en la tabla de precios no es la más barata en la cuenta de resultados.

Su cálculo tiene dos partes. El numerador es el coste total anual: licencias o capacidad, infraestructura si la plataforma es autogestionada, horas de administración y soporte, formación inicial y continua, el tiempo del equipo que gobierna el contenido, la parte del cómputo del almacén de datos que generan las consultas de la herramienta y el consumo de IA. El denominador son los usuarios activos, y aquí está la trampa: hay que definir el umbral antes de medir. Un criterio razonable es contar a quien ha abierto al menos un contenido con interacción en los últimos 28 días, descontando las aperturas automáticas de suscripciones por correo, y complementarlo con una segunda cifra más exigente, la de quienes consultan cada semana, que se acerca a la de usuarios cuyas decisiones dependen de la herramienta.

Los datos para el denominador existen en todas las plataformas comerciales: el registro de actividad de Power BI, Admin Insights en Tableau Cloud, System Activity en Looker o las aplicaciones de supervisión de Qlik Cloud. En Metabase, la analítica de uso forma parte de los planes de pago, y en las instalaciones open source hay que extraerla de los registros del servidor. Si una organización no sabe cuántos usuarios activos tiene su herramienta actual, ese es el primer hallazgo de la evaluación, y conviene resolverlo antes de comparar nada.

Un cálculo ilustrativo, con cifras redondas que no corresponden a ninguna organización concreta, muestra la diferencia. Una empresa mantiene 600 licencias Pro a 14 dólares, unos 100.800 dólares al año. Suma media jornada de administración, la formación de nuevos usuarios y el tiempo de gobierno del contenido, otros 45.000 dólares anuales. Cuando mide la actividad descubre que 190 personas usan la herramienta al menos una vez cada 28 días. El coste por usuario activo resulta de unos 767 dólares al año, 64 al mes: más de cuatro veces y media el precio de lista que figuraba en la propuesta original. Ninguna cifra de la tabla de precios habría anticipado ese resultado, y ninguna demo lo habría mostrado.

La métrica tiene tres usos prácticos. En la evaluación, obliga a comparar herramientas con su coste total y con una previsión realista de adopción, no con la que promete el plan de proyecto. En la operación, señala dónde se pierde el dinero: licencias asignadas a quien no entra, capacidad dimensionada para picos que no se producen, contenido que nadie consulta pero que se sigue actualizando cada noche. Y en la renovación, es el argumento más sólido para negociar, porque convierte una conversación sobre descuentos en una conversación sobre uso real. Enlaza de forma natural con los modelos de valor del capítulo 2: el coste por usuario activo mide el lado del coste; las decisiones que esos usuarios toman con mejor información miden el lado del valor.

Hay un detalle que conviene no perder de vista. Un coste por usuario activo bajo puede esconder un problema si los usuarios activos no son los que deberían. Una herramienta que usan cuatrocientos lectores ocasionales mientras los tres analistas que preparan el cierre trabajan en hojas de cálculo tiene una métrica económica brillante y un problema serio de adopción en la columna que más valor produce. Por eso la métrica se lee siempre junto a la matriz de los tres consumidores, columna por columna.

BI open source: gratis de licencia, con coste de operación

El software libre ha madurado en BI hasta el punto de competir en funcionalidad con herramientas comerciales en muchos casos de uso, y su atractivo es evidente: ninguna cuota por usuario, ningún contrato anual, control total del despliegue y de dónde residen los datos. La parte que el entusiasmo inicial tiende a omitir es que la licencia gratuita traslada el coste a la operación, y que las licencias abiertas no son todas iguales.

Apache Superset se distribuye con licencia Apache 2.0, permisiva: se puede usar, modificar e integrar en un producto propio sin obligación de publicar los cambios. Su contrapartida es la complejidad de operación. Un despliegue en producción con usuarios concurrentes necesita, además de la aplicación, una base de datos de metadatos, una caché compartida y trabajadores asíncronos para las consultas largas, y cada versión mayor trae cambios que hay que probar; la 6.0, publicada en diciembre de 2025, rehízo el sistema de diseño de la interfaz. Metabase publica su edición abierta con licencia AGPL v3, una licencia copyleft con cláusula de red: quien modifique el código y lo ofrezca a usuarios a través de una red debe poner esas modificaciones a su disposición. Para uso interno sin modificaciones apenas cambia nada, pero para un producto que embebe Metabase la recomendación del propio fabricante es prototipar con la edición abierta y pasar a un plan comercial en producción. Además, la seguridad por fila y columna, el inicio de sesión SAML y la analítica de uso solo están en los planes Pro y Enterprise. Lightdash publica su núcleo con licencia MIT, la más permisiva de las tres, pero el código de su edición empresarial reside en un directorio con una licencia propia que exige suscripción para usarlo en producción.

La operación es la otra mitad de la cuenta. Alguien tiene que desplegar la plataforma, mantenerla actualizada, aplicar parches de seguridad con la urgencia que exija cada vulnerabilidad, hacer copias de la base de metadatos, monitorizar la disponibilidad, integrar el inicio de sesión corporativo y atender a los usuarios cuando algo deja de funcionar. Es exactamente el análisis entre plataforma gestionada y autogestionada que proponía el capítulo 12 para las bases de datos, aplicado a la capa de consumo. Por eso las tres herramientas tienen una versión gestionada de pago, propia en el caso de Metabase y Lightdash, y de un tercero, Preset, en el de Superset. Comparar el open source con una herramienta comercial exige comparar el coste total, no el precio de la licencia.

En nuestra valoración, el BI de código abierto es una opción excelente en tres situaciones: cuando la organización ya tiene un equipo de plataforma que opera servicios similares y puede absorber uno más; cuando la analítica se embebe en un producto y el coste por usuario de una herramienta comercial destruiría el margen; y cuando el modelado ya vive en dbt y se busca una capa de visualización ligera sobre él, que es el terreno de Lightdash. Es una mala opción cuando se elige solo para ahorrar licencias en una organización sin equipo técnico que la sostenga, porque el ahorro de la licencia se consume en el primer incidente serio.

La matriz aplicada: cuatro escenarios sectoriales

Los cuatro escenarios siguientes son ilustrativos, compuestos a partir de patrones habituales de cada sector. No describen organizaciones concretas, y las cifras que contienen son órdenes de magnitud calculados con los precios de lista de la sección anterior, no resultados medidos.

Industria: el umbral de la capacidad se cruza con usuarios activos

Un fabricante de componentes con varias plantas en la península trabaja con Microsoft 365 y un ERP sobre SQL Server. Veinticinco analistas de control de gestión, calidad y planificación construyen informes, y unos cuatrocientos veinte mandos —jefes de turno, responsables de línea, encargados de mantenimiento— deberían consultar cada mañana el rendimiento de las máquinas y el rechazo del turno anterior desde una tableta en planta. La propuesta inicial del integrador era una capacidad F64, con el argumento de que 445 licencias Pro costarían más que la capacidad reservada.

Antes de firmar, el equipo de datos midió un piloto de dos meses con licencias Pro y descubrió que los mandos activos en una ventana de 28 días rondaban los 230. Con 255 licencias Pro, la factura mensual quedaba en torno a 3.600 dólares, muy por debajo de la capacidad. La decisión fue mantener licencias por usuario para quien de verdad entra, revisar la cifra cada trimestre y fijar por escrito el disparador del cambio: pasar a capacidad cuando los lectores activos superen de forma sostenida el umbral en el que la F64 compensa. El modelo semántico compartido, que el capítulo 30 recomendaba incluso en organizaciones con una sola herramienta, hizo que el cambio futuro no exija tocar ningún informe. Lección: el umbral de la capacidad se cruza con usuarios activos, no con los usuarios del organigrama.

Turismo: tres herramientas toleradas, una sola definición

Una cadena hotelera vacacional con establecimientos en la costa y en las islas tenía tres superficies de consumo nacidas en momentos distintos. El equipo de revenue management exploraba tarifas y ocupación en Tableau; la dirección recibía cuadros de mando en Power BI, porque sus licencias Microsoft 365 E5 ya incluyen Power BI Pro; y marketing seguía la web con informes de Looker Studio. El problema apareció en un comité: el precio medio por habitación ocupada (ADR) y el ingreso por habitación disponible (RevPAR) daban cifras distintas en cada herramienta, porque cada una trataba de forma diferente las habitaciones de cortesía y la parte del paquete correspondiente a la pensión.

La primera propuesta fue consolidarlo todo en una herramienta. Se descartó tras aplicar la matriz: el equipo de revenue era el analista explorador más intensivo de la empresa y su productividad dependía de Tableau, mientras que el consumo ejecutivo ya estaba pagado dentro de Power BI. La solución fue definir ocupación, ADR y RevPAR una sola vez en la capa semántica, obligar a las tres superficies a leerlas de allí y concentrar el consumo ejecutivo en Power BI. Tableau se quedó con sus Creators y pasó varias licencias a Explorer al comprobar que esos usuarios no creaban fuentes de datos nuevas. Lección: varias herramientas pueden convivir sin conflicto; lo que no puede convivir son varias definiciones de la misma métrica.

Software para despachos: el precio debe parecerse a los ingresos

Un fabricante de software de gestión para asesorías y despachos profesionales quería ofrecer cuadros de mando a sus clientes, unos tres mil despachos con varios usuarios cada uno. El cliente embebido dominaba la matriz por completo, y la licencia por usuario interno quedaba descartada desde el primer cálculo. El equipo evaluó cuatro caminos. Power BI Embedded, con capacidad dimensionada por concurrencia y sin licencias por usuario final, encajaba con un producto ya desplegado en Azure. Looker ofrecía su edición Embed, con precio bajo consulta. Metabase permitía empezar con paneles embebidos de solo lectura, que no cuentan como usuarios, pero su embebido interactivo factura a cada lector como usuario, y modificar la edición AGPL para integrarla en el producto activaba obligaciones que el departamento jurídico prefirió evitar. Y Apache Superset, con licencia Apache 2.0 y un SDK de embebido, era la alternativa si el equipo hubiera tenido experiencia operando servicios de este tipo.

Eligió Power BI Embedded, con la seguridad por cliente definida una sola vez en el modelo semántico y pruebas automáticas con usuarios ficticios de varios despachos para garantizar que ninguno ve datos de otro. El capítulo 35 desarrollará la arquitectura multicliente que esta decisión exige. Lección: en analítica embebida, la unidad de precio de la herramienta debe parecerse a la unidad de ingresos del negocio; si se cobra por despacho, no se puede pagar por usuario.

Automoción: migrar para ahorrar licencias rara vez compensa

Un grupo de concesionarios multimarca llevaba años con Qlik Sense instalado en sus propios servidores para ventas y posventa, con unas sesenta aplicaciones y un equipo de analistas que valoraba mucho la exploración asociativa: qué clientes con el vehículo fuera de garantía no han vuelto al taller, qué combinaciones de modelo y acabado se quedan en stock. Sistemas propuso migrar a Power BI para homogeneizar con Microsoft 365, sin reparar en que sus licencias E3 no incluyen Power BI Pro y que los trescientos usuarios de consulta necesitarían una cada uno, unos 50.000 dólares anuales en licencias, a lo que habría que sumar la reconstrucción de las sesenta aplicaciones y la formación.

El cálculo del coste por usuario activo inclinó la balanza hacia el otro lado. El plan Standard de Qlik Cloud Analytics, con 25 GB de datos para análisis y sin coste por usuario adicional, cubría el volumen del grupo por una fracción de esa cifra. La decisión fue migrar a la nube del mismo fabricante, aprovechar la mudanza para retirar las veinte aplicaciones que nadie abría desde hacía un año —los informes zombis del capítulo 29— y no cambiar de herramienta. Lección: el coste de reconstruir el contenido forma parte del coste de la herramienta; cambiar para ahorrar licencias solo compensa si el ahorro paga la reconstrucción, la formación y la pérdida de productividad de la transición.

Anti-patrones de la selección de herramientas

Elegir por la demo. El comercial presenta su herramienta con un conjunto de datos limpio, un modelo perfecto y diez usuarios. La organización tiene datos con nulos, un modelo heredado y quinientas personas que abren el mismo cuadro de mando a las nueve de la mañana. Ninguna demo responde a cómo se comportará la herramienta con esos datos y esa concurrencia, y la única forma de saberlo es una prueba con los datos, la capa semántica y los usuarios propios.

El BI múltiple por acumulación. Tres herramientas compradas en momentos distintos, por áreas distintas, cada una con sus fórmulas. El escenario hotelero muestra que el número de herramientas importa menos que el número de definiciones, y el capítulo 30 explica cómo detectarlo con la prueba de la métrica única. Lo que convierte la convivencia en anti-patrón es la falta de una capa semántica común.

Open source «gratis» sin presupuesto de operación. Se instala Superset o Metabase en un servidor para ahorrar licencias y se olvida presupuestar quién lo actualiza, quién aplica los parches y quién responde cuando falla. A los dieciocho meses la plataforma va varias versiones por detrás, tiene vulnerabilidades conocidas sin corregir y depende de la única persona que la instaló.

Comprar la IA del anuncio. La decisión se toma por un asistente conversacional visto en una presentación, sin comprobar en qué edición está incluido —en Tableau Cloud, los agentes solo llegan con la edición Cloud+ y el paquete Tableau+; en Fabric, Copilot consume la capacidad contratada; en Looker, la conversación se mide en tokens— ni cómo responde sobre el modelo semántico real de la organización. Un asistente que responde bien sobre datos de demostración puede inventar fórmulas sobre un modelo mal documentado.

Dejar que el almacén pague la fiesta. Las herramientas que consultan en vivo el almacén de datos, como Looker, Lightdash o Superset, trasladan parte de su coste a la factura de la plataforma de datos. Una herramienta barata en licencia puede disparar el gasto en cómputo si cada apertura de un panel lanza decenas de consultas sin caché ni agregados. El capítulo 32 tratará el presupuesto de latencia y el capítulo de FinOps de la Parte VI, el reparto de ese coste; en la evaluación basta con medirlo.

Migrar sin inventario. Se cambia de herramienta y se reconstruye todo el contenido existente, incluidos cientos de informes que nadie abría. La migración es la mejor oportunidad para retirar contenido zombi, y desperdiciarla multiplica el coste y el plazo.

Elegir la herramienta antes que la capa semántica. Es el anti-patrón que conecta este capítulo con el anterior. Si las métricas se definen dentro de la herramienta elegida, la siguiente decisión de herramienta estará condicionada por todo lo que se haya modelado en ella. Decidir primero dónde viven las métricas convierte la elección de herramienta en una decisión reversible.

Selección de software: una evaluación en seis semanas

Una evaluación seria de herramientas de BI no necesita seis meses ni un concurso de cincuenta páginas. Necesita seis semanas bien aprovechadas, datos propios y criterios escritos antes de ver la primera demostración.

La primera semana se dedica al inventario: cuántos consumidores de cada tipo hay de verdad, con los registros de actividad de las herramientas actuales y las listas de distribución de informes; qué contenido existe y cuánto se usa; dónde viven hoy las definiciones de las métricas, y en qué peldaño de la escalera del capítulo 29 opera la mayor parte del consumo. El Test de Madurez Analítica de Dataprix ayuda a situar ese punto de partida. La segunda semana fija los criterios y sus pesos, y es la más importante, porque decide lo que se va a medir. Los criterios que no conviene omitir son el encaje con cada columna de la matriz de consumidores, la capacidad de leer la capa semántica elegida en lugar de sustituirla, la seguridad por fila con propagación de la identidad del usuario, la gobernanza de contenido, la experiencia en móvil y en la herramienta de colaboración corporativa, la analítica embebida si hay clientes externos, el modelo de licencia y su comportamiento con el crecimiento, la región de alojamiento y las condiciones de tratamiento de datos, la disponibilidad de profesionales y partners en España, el soporte en español y la facturación en euros.

Las semanas tercera a quinta son la prueba de concepto, con dos o tres herramientas como máximo y los datos de la organización. Cada herramienta resuelve tres casos, uno por consumidor: un análisis exploratorio real que hoy se hace en hojas de cálculo, un cuadro de mando ejecutivo consultado desde el móvil por usuarios reales y, si procede, un panel embebido con dos clientes ficticios que no deben ver los datos del otro. Se mide la concurrencia a la hora punta, el tiempo de respuesta, el cómputo generado en el almacén y el esfuerzo de construcción. La sexta semana convierte lo medido en un modelo de coste por usuario activo a tres años, con dos escenarios de adopción, y prepara la negociación: duración del contrato, revisión anual de precios, posibilidad de reducir licencias en la renovación y condiciones de salida.

El ranking de software de Business Intelligence y analítica de 2026 del directorio de Dataprix recoge el veredicto editorial de cada opción, con Microsoft Power BI, Tableau, Qlik Sense y Looker en las cuatro primeras posiciones, seguidos de SAP Analytics Cloud, Oracle Analytics Cloud, Domo, ThoughtSpot, Strategy One y Pyramid Analytics. Es el punto de partida natural para la lista corta, y cada ficha recoge capacidades, despliegue y licenciamiento. Para organizaciones pequeñas, el artículo de Dataprix sobre Business Intelligence para pymes recorre el escenario en el que el primer paso con más retorno suele ser un único modelo compartido en una herramienta sencilla, antes que cualquier comparativa.

Un último consejo para la fase de demostraciones, heredado del capítulo anterior: pedir a cada proveedor que conecte su herramienta a la capa semántica elegida, que consulte una métrica de ratio con un recuento distinto en el denominador y que la muestre a dos granularidades distintas, con un usuario que solo debe ver su región. Si la cifra cuadra con la de la capa, la seguridad se respeta y el proveedor explica sin titubear qué consulta se ha lanzado contra el almacén, la herramienta merece pasar a la prueba de concepto.

Checklist operativo: antes de firmar o renovar

• Contar los consumidores reales de cada tipo —analista explorador, consumidor ejecutivo, cliente embebido— con los registros de actividad y las listas de distribución, no con el organigrama.
• Definir por escrito el umbral de «usuario activo» y medirlo en la herramienta actual durante al menos un ciclo de negocio completo.
• Calcular el coste por usuario activo actual sumando licencias, capacidad, infraestructura, administración, formación, gobierno, cómputo del almacén e IA.
• Decidir dónde viven las métricas compartidas antes de evaluar herramientas, y exigir que la herramienta elegida las lea en lugar de redefinirlas.
• Ponderar los criterios de evaluación con el reparto real de consumidores y fijarlos antes de la primera demostración.
• Limitar la prueba de concepto a dos o tres herramientas, con datos propios, concurrencia de hora punta y un caso por tipo de consumidor.
• Medir en la prueba el cómputo que cada herramienta genera en el almacén de datos, además del tiempo de respuesta.
• Comprobar la seguridad por fila con propagación de la identidad y con usuarios ficticios que no deben ver los datos de otros.
• Verificar en qué edición están incluidas las funciones de IA, cómo se miden y qué ve un agente cuando consulta la herramienta.
• Para el open source, presupuestar la operación completa: actualizaciones, parches, copias, monitorización, SSO y soporte, y revisar la licencia si se va a embeber.
• Revisar región de alojamiento, contrato de encargado del tratamiento y transferencias internacionales con el delegado de protección de datos.
• Modelar el coste por usuario activo a tres años con dos escenarios de adopción y fijar por escrito el disparador para cambiar de modelo de licencia.
• Aprovechar cualquier migración para retirar el contenido sin uso en lugar de reconstruirlo.
• Negociar duración, revisión anual de precios, reducción de licencias en la renovación y condiciones de salida antes de firmar.

Formación recomendada

Para los equipos que van a evaluar o desplegar las dos herramientas que encabezan el ranking de Dataprix, estas opciones en español permiten tener criterio propio antes de la prueba de concepto:

• Introducción a Power BI (DataCamp): curso básico de unas tres horas y media, desarrollado junto con Microsoft, que recorre la carga y transformación de datos con Power Query, el modelo de datos y la creación de informes interactivos.
• Introducción a Tableau (DataCamp): curso básico de unas seis horas sobre conexión a datos, campos calculados, mapas, series temporales y construcción de cuadros de mando e historias.
• Data Analytics + Power BI (Udemy): formación práctica de análisis de datos y visualización con Power BI para quien vaya a construir el contenido de la prueba de concepto.

Enlaces de afiliado: Dataprix puede recibir una comisión si contratas a través de ellos.

Recursos y lecturas recomendadas

• Licencias de Microsoft Fabric y funciones para usuarios con licencia gratuita de Power BI (Microsoft Learn): la documentación oficial del umbral F64 y de lo que puede hacer cada tipo de licencia.
• Precios y ediciones de Tableau Cloud: roles, ediciones, comparativa de capacidades por licencia y condiciones del precio por capacidad.
• Looker pricing (Google Cloud): ediciones de plataforma, tipos de usuario, cuotas de API y medición de la analítica conversacional.
• Qlik Cloud Analytics, planes y precios: el modelo por volumen de datos explicado por el propio fabricante.
• Apache Superset 6.1.0: notas de la versión de mayo de 2026, con el marco de extensiones y el servicio MCP.
• Precios de Metabase y precios de Lightdash: qué incluye la edición abierta y qué queda en los planes de pago de cada uno.
• Texto de la licencia GNU AGPL v3: lectura obligada antes de integrar en un producto una herramienta publicada con esta licencia.
• TOP 10 Software de Business Intelligence y Analítica en 2026 y Business Intelligence para pymes (Dataprix): el ranking editorial y el punto de partida para organizaciones pequeñas.

Preguntas frecuentes

¿Cuál es la mejor herramienta de Business Intelligence en 2026?

Ninguna lo es para todas las organizaciones. La elección depende del tipo de consumidor dominante y del coste por usuario activo. Power BI destaca en el consumo masivo dentro del ecosistema Microsoft, Tableau en la exploración visual, Looker en el modelado de métricas como código y la analítica embebida, Qlik en la exploración asociativa con precio por volumen de datos, y Superset, Metabase o Lightdash cuando hay un equipo capaz de operarlos. El ranking de Dataprix de 2026 sitúa a Power BI, Tableau, Qlik Sense y Looker en las cuatro primeras posiciones.

¿Qué diferencia hay entre BI de exploración y BI de consumo?

El BI de exploración es la actividad de quien interroga los datos sin conocer de antemano la pregunta definitiva: pocos usuarios, sesiones largas y necesidad de expresividad y acceso amplio al modelo. El BI de consumo es la de quien abre contenido ya construido para seguir un indicador: muchos usuarios, sesiones breves y necesidad de rapidez, móvil y alertas. La distinción importa porque casi todas las herramientas cobran mucho más por explorar que por consumir, y la mayoría de los usuarios consume.

¿Cuánto cuesta Power BI frente a Tableau, Looker y Qlik en 2026?

A 19 de octubre de 2026, Power BI Pro cuesta 14 dólares por usuario y mes con pago anual (12,10 euros sin IVA en la web de Microsoft para España) y Premium por usuario, 24 dólares. Tableau Standard cobra 75, 42 y 15 dólares al mes por usuario Creator, Explorer y Viewer. Looker no publica precios: la plataforma y los usuarios se negocian con ventas. Qlik Cloud Analytics cobra por volumen de datos, desde 825 dólares al mes en su plan Standard, sin coste por usuario adicional. Para comparar con justicia hay que traducir cada modelo a coste por usuario activo.

¿Cuándo compensa una capacidad Fabric F64 frente a licencias Power BI Pro?

Cuando el número de lectores activos supera el punto en que la capacidad cuesta menos que sus licencias. Con la tarifa de referencia en regiones de Estados Unidos, una F64 reservada un año ronda los 5.000 dólares al mes, el equivalente a unas 350 licencias Pro. A partir de F64, los usuarios con licencia gratuita pueden ver contenido con el rol de visor, pero los creadores siguen necesitando una licencia Pro. Conviene medir el consumo real en pago por uso durante un ciclo de negocio completo antes de reservar.

¿Es realmente gratis el BI open source como Superset, Metabase o Lightdash?

Es gratis de licencia, pero tiene coste de operación. Alguien tiene que desplegarlo, actualizarlo, aplicar parches de seguridad, hacer copias, monitorizarlo e integrar el inicio de sesión corporativo. Además, las licencias difieren: Superset usa Apache 2.0, permisiva; la edición abierta de Metabase usa AGPL v3, con obligaciones si se modifica y se ofrece a terceros; y Lightdash publica su núcleo con licencia MIT y reserva las funciones empresariales a una licencia propia. Funciones como la seguridad por fila o el SSO corporativo pueden estar solo en los planes de pago.

¿Qué es el coste por usuario activo y cómo se calcula?

Es el coste total anual de una herramienta de BI dividido entre los usuarios que la usan de forma significativa. El coste incluye licencias o capacidad, infraestructura, administración, formación, gobierno del contenido, el cómputo del almacén de datos que generan sus consultas y el consumo de IA. Los usuarios activos se cuentan con un umbral definido de antemano, por ejemplo al menos un contenido abierto con interacción en los últimos 28 días, a partir de los registros de actividad de la propia herramienta.

La fecha de renovación como punto de partida

La mayoría de las organizaciones no elige su herramienta de BI una sola vez: la reelige en silencio en cada renovación, firmando el mismo número de licencias que el año anterior. Esa fecha, escrita en un contrato que pocas veces ha leído alguien del equipo de datos, es el mejor momento para aplicar este capítulo. Tres cifras bastan para preparar la conversación: cuántos usuarios activos tiene hoy la herramienta, cuánto cuesta cada uno y qué columna de la matriz de consumidores está peor servida. Si nadie en la organización puede darlas, esa ausencia ya dice mucho de cómo se gestiona el BI, y es motivo suficiente para revisar la decisión con alguien que no tenga una licencia que vender.

Con la herramienta elegida, la siguiente batalla se libra en segundos. Un directivo que espera demasiado a que cargue un panel deja de abrirlo, por muy acertada que haya sido la elección de plataforma, y el remedio está tanto en el diseño de lo que ve como en lo que ocurre por debajo: agregaciones, caché y el reparto del tiempo de respuesta entre almacenamiento, consulta y presentación. De ese presupuesto de latencia, y de los principios que hacen legible un cuadro de mando, se ocupa el capítulo 32.

Siguiente en la Parte IV: capítulo 32, Dashboards eficaces: principios de diseño y performance. · Capítulo anterior: Capa semántica y data marts · Volver a la Parte IV · Índice de la guía

Los ejemplos de este capítulo son ilustrativos y no corresponden a implantaciones concretas.

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones. Última actualización: 19 de octubre de 2026.