Manual Power Bi

Díganos qué opina sobre la experiencia de descarga del PDF.
Documentación de guía de Power BI

En la documentación de guía de Power BI se proporciona información sobre
procedimientos recomendados por parte del equipo que hay detrás de Power BI y las
personas que trabajan con nuestros clientes empresariales. También encontrará
información para mejorar el rendimiento y la eficacia de su trabajo con Power BI. A
medida que haya nueva información disponible, se actualizarán y ampliarán estos
materiales.
Guía de Power BI
ｅ INFORMACIÓN GENERAL
Instrucciones para Power BI
Guía de optimización para Power BI
Información general sobre las notas del producto
Transformar y dar forma a los datos
ｐ CONCEPTO
La importancia del plegado de consultas
Deshabilitación de la actualización en segundo plano de Power Query
Referencia de las consultas de Power Query
Procedimientos recomendados para flujos de datos
Modelado de datos
ｐ CONCEPTO
¿Qué es un esquema de estrella?
Técnicas de reducción de datos
Relaciones uno a uno
Relaciones de varios a varios
Relaciones activas frente a inactivas

Relaciones bidireccionales
Solución de problemas de relación
Guía del modelo DirectQuery
Guía del modelo compuesto
Guía de la Seguridad de nivel de fila (RLS)
DAX
ｐ CONCEPTO
Uso adecuado de las funciones de error
Impedimento de la conversión de BLANK en valores
Evitar el uso de FILTER como argumento de filtro
Referencias de columnas y medidas
Diferencias entre la función DIVIDE y el operador de división
Uso de COUNTROWS en lugar de COUNT
Uso de SELECTEDVALUE en lugar de VALUES
Uso de variables para mejorar las fórmulas
Informes de Power BI
ｐ CONCEPTO
Separación de informes y modelos
Uso de información sobre herramientas de la página de informes
Uso de detalles de la página del informe
Informes paginados de Power BI
ｐ CONCEPTO
Cuándo usar informes paginados
Guía de recuperación de datos

Guía de uso de imágenes
Uso de parámetros en cascada
Eliminación de páginas en blanco al imprimir
Migración de informes de SSRS a Power BI
Administración e implementación
ｐ CONCEPTO
Ajuste de tamaño de la puerta de enlace de datos local
Supervisión del rendimiento de los informes
Solución de problemas de rendimiento de los informes
Procedimientos recomendados para las canalizaciones de implementación
Acceso al registro de actividad de Power BI
Migración a Power BI
ｐ CONCEPTO
Información general sobre la migración
Preparar la migración
Reunir los requisitos
Planeamiento de la implementación
Realización de una prueba de concepto
Crear contenido
Implementación en Power BI
Aprender de las migraciones de Power BI de los clientes
Migración de modelos de AAS a Power BI Premium
Hoja de ruta de adopción
ｐ CONCEPTO
ｐ CONCEPTO
Información general
Cultura de los datos
Patrocinio ejecutivo
Propiedad del contenido
Ámbito de entrega del contenido
Centro de excelencia
Gobernanza
Mentoría y capacitación de los usuarios
Comunidad práctica
Asistencia técnica de usuario
ｐ CONCEPTO
Introducción
Escenarios de uso
Configuración del inquilino
Áreas de trabajo
Seguridad
Protección de información y DLP
Auditoría y supervisión
Centro de excelencia (COE)
ｐ CONCEPTO
Transformación de la BI de Microsoft
Establecimiento de un COE
Arquitectura de la solución de BI en el COE

Instrucciones para Power BI
Artículo • 23/03/2023 • Tiempo de lectura: 2 minutos
Aquí encontrará las instrucciones y los procedimientos recomendados para Power BI.
Las instrucciones se seguirán actualizando y ampliando.
Modelado de datos
Instrucciones Descripción
Descripción de un Se describe el diseño de un esquema de estrella y su importancia

esquema de estrella e para desarrollar modelos de datos de Power BI optimizados para el
importancia para Power BI rendimiento y la facilidad de uso.
Técnicas de reducción de Se describen distintas técnicas para ayudar a reducir los datos
datos para modelos de cargados en los modelos de importación.
importación
DAX
DAX: diferencias entre la función DIVIDE y el Se describe el uso correcto de la función

operador de división (/) DIVIDE en DAX.
Flujos de datos
Procedimientos recomendados Se describen los procedimientos recomendados para diseñar

para flujos de datos flujos de datos en Power BI.
¿Tiene más preguntas? Pruebe a preguntar a la comunidad de Power BI

Guía de optimización para Power BI
En este artículo se proporcionan instrucciones que permiten a los desarrolladores y

administradores generar y mantener soluciones de Power BI optimizadas. Puede
optimizar la solución en diferentes capas arquitectónicas. Las capas incluyen:
Orígenes de datos
Modelo de datos
Visualizaciones, incluidos paneles, informes de Power BI e informes paginados
Power BI
Entorno, incluidas las capacidades, las puertas de enlace de datos y la red
Optimización del modelo de datos

El modelo de datos es compatible con toda la experiencia de visualización. Los modelos
de datos se hospedan externa o internamente y, en Power BI, se hace referencia a ellos
como conjuntos de datos. Es importante conocer las opciones y elegir el tipo de
conjunto de datos apropiado para la solución. Hay tres modos de conjunto de datos:
Importación, DirectQuery y Composición. Para más información, vea Conjuntos de datos
en el servicio Power BI y Modos de conjuntos de datos en el servicio Power BI.
Para obtener instrucciones sobre el modo de conjunto de datos específico, vea:
Técnicas de reducción de datos para modelos de importación

Instrucciones del modelo de DirectQuery en Power BI Desktop
Guía de modelos compuestos de Power BI Desktop
Optimización de visualizaciones
Las visualizaciones de Power BI pueden ser paneles, informes de Power BI o informes
paginados de Power BI. Cada una tiene distintas arquitecturas, por lo que tienen
instrucciones independientes.
Paneles
Es importante saber que Power BI mantiene una memoria caché para los iconos del
panel, excepto los iconos de los informes dinámicos y los iconos de streaming. Si el
conjunto de datos aplica la Seguridad de nivel de fila (RLS) dinámica, asegúrese de
conocer las implicaciones del rendimiento, ya que los iconos se almacenarán en la caché
por cada usuario.
Al anclar iconos de informes dinámicos a un panel, no se sirven desde la memoria caché

de consultas. En su lugar, se comportan como los informes y realizan consultas a los
núcleos virtuales sobre la marcha.
Como sugiere su nombre, recuperar los datos de la memoria caché proporciona un

rendimiento mejor y más coherente que confiar en el origen de datos. Una manera de
aprovechar las ventajas de esta funcionalidad es hacer que los paneles sean la primera
página de inicio de los usuarios. Ancle los objetos visuales más utilizados y muy
solicitados en los paneles. De esta manera, los paneles se convierten en una valiosa
"primera línea de defensa", que ofrece un rendimiento coherente con menos carga en la
capacidad. Los usuarios también pueden hacer clic en un informe para analizar los
detalles.
Para DirectQuery y los conjuntos de datos de conexiones dinámicas, la memoria caché

se actualiza de forma periódica mediante una consulta al origen de datos. De forma
predeterminada, se produce cada hora, aunque puede configurar una frecuencia
diferente en la configuración del conjunto de datos. Cada actualización de la memoria
caché enviará consultas al origen de datos subyacente para actualizar la memoria caché.
El número de consultas que se generan depende del número de objetos visuales
anclados en los paneles que dependen de ese origen de datos. Tenga en cuenta que, si
está habilitada la seguridad de nivel de fila, se generan consultas para cada contexto de
seguridad. Por ejemplo, suponga que hay dos roles diferentes que categorizan a los
usuarios y tienen dos vistas diferentes de los datos. Durante la actualización de la
memoria caché de consultas, Power BI genera dos conjuntos de consultas.
Informes de Power BI
Hay varias recomendaciones para optimizar los diseños de los informes de Power BI.
７ Nota
Cuando los informes se basan en un conjunto de datos de DirectQuery, para

optimizaciones de diseño de informes adicionales, vea Instrucciones del modelo
de DirectQuery en Power BI Desktop (Optimización de los diseños de informes).
Aplicación de los filtros más restrictivos

Cuantos más datos tenga que mostrar un objeto visual, más lenta será su carga. Aunque
este principio parece obvio, es muy fácil olvidarlo. Por ejemplo: supongamos que tiene
un conjunto de datos grande. Sobre ese conjunto de datos, genera un informe con una
tabla. Los usuarios finales utilizan segmentaciones en la página para obtener las filas
que desean; normalmente, solo están interesados en algunas docenas de filas.
Un error común es tener la vista predeterminada de la tabla sin filtrar; por ejemplo, más
de 100 millones de filas. Los datos de estas filas se cargan en memoria y se
descomprimen en cada actualización. Este procesamiento crea enormes demandas de
memoria. La solución es usar el filtro "Primeros N" para reducir el número máximo de
elementos que se muestran de la tabla. Puede establecer el número máximo de
elementos a un número mucho mayor que el que los usuarios necesitarían, por ejemplo,
10 000. El resultado es que la experiencia del usuario final no cambia, pero el uso de
memoria se reduce considerablemente. Además, lo más importante es que el
rendimiento mejora.
Se recomienda un enfoque de diseño similar al descrito anteriormente para todos los

objetos visuales del informe. Hágase la siguiente pregunta: ¿son necesarios todos los
datos en este objeto visual? ¿Hay maneras de filtrar la cantidad de datos que se
muestran en el objeto visual con un impacto mínimo en la experiencia del usuario final?
Tenga en cuenta que las tablas en concreto pueden resultar caras.
Limitación de los objetos visuales de las páginas del informe
El principio anterior se aplica por igual al número de objetos visuales agregados a una
página del informe. Se recomienda limitar el número de objetos visuales de la página de
un informe concreto solo a aquellos que sean necesarios. Las páginas de obtención de
detalles y la información sobre herramientas de páginas de informes son una excelente
manera de proporcionar detalles adicionales sin crear una aglomeración de objetos
visuales en la página.
Evaluación del rendimiento de objetos visuales personalizados
Asegúrese de colocar cada objeto visual personalizado a su ritmo para asegurarse un

alto rendimiento. Los objetos visuales de Power BI mal optimizados pueden afectar
negativamente al rendimiento de todo el informe.
Informes paginados de Power BI

Los diseños de los informes paginados de Power BI se pueden optimizar con la
aplicación del diseño de procedimiento recomendado a la recuperación de datos del
informe. Para más información, vea Guía de recuperación de datos de informes
paginados.
Además, asegúrese de que la capacidad tiene suficiente memoria asignada para la carga
de trabajo de informes paginados.
Optimización del entorno

Puede optimizar el entorno de Power BI mediante la configuración de las opciones de
capacidad, el ajuste de tamaño de las puertas de enlace de datos y la reducción de la
latencia de red.
Configuración de la capacidad
Al usar capacidades, disponibles con las licencias de Power BI Premium (SKU P) y
Premium por usuario (PPU), o Power BI Embedded (SKU A y A4-A6), puede administrar
la configuración de la capacidad. Para más información, vea Administración de las
capacidades Premium.
Ajuste de tamaño de la puerta de enlace

Una puerta de enlace es necesaria cuando Power BI debe acceder a los datos que no
son accesibles directamente a través de Internet. Se puede instalar la puerta de enlace
de datos local en un servidor local o en una infraestructura como servicio (IaaS)
hospedada en la máquina virtual.
Para comprender las cargas de trabajo de puerta de enlace y las recomendaciones de

ajuste de tamaño, vea Ajuste de tamaño de la puerta de enlace de datos local.
Latencia de red
La latencia de red puede afectar al rendimiento de los informes si aumenta el tiempo
necesario para que las solicitudes alcancen el servicio Power BI y para la entrega de las
respuestas. Los inquilinos de Power BI se asignan a una región específica.
 Sugerencia
Para determinar dónde se encuentra el inquilino, vea ¿Dónde se encuentra mi

inquilino de Power BI?.
Cuando los usuarios de un inquilino acceden al servicio Power BI, sus solicitudes
siempre se enrutan a esta región. Cuando las solicitudes llegan al servicio Power BI, el
servicio puede enviar solicitudes adicionales —por ejemplo, al origen de datos
subyacente o a la puerta de enlace— que también están sujetas a la latencia de red.
Las herramientas como Azure Speed Test proporcionan una indicación de la latencia
de red entre el cliente y la región de Azure. En general, para minimizar el impacto de la
latencia de red, intente mantener los orígenes de datos, las puertas de enlace y la
capacidad de Power BI lo más cerca posible. Preferiblemente, residen en la misma
región. Si la latencia de red es un problema, intente ubicar las puertas de enlace y los
orígenes de datos más cerca de la capacidad de Power BI situándolos dentro de las
máquinas virtuales hospedadas en la nube.
Supervisión del rendimiento

Puede supervisar el rendimiento para identificar cuellos de botella. Las consultas o los
objetos visuales lentos deben ser objeto de optimización continua. La supervisión se
puede realizar en tiempo de diseño en Power BI Desktop o en cargas de trabajo de
producción en las capacidades de Power BI Premium. Para más información, vea
Supervisión del rendimiento de los informes en Power BI.
Pasos siguientes
Para más información sobre este artículo, consulte los recursos siguientes:
Guía de Power BI
Hoja de ruta de adopción de Power BI
¿Tiene alguna pregunta? Pruebe a preguntar a la comunidad de Power BI
¿Sugerencias? Ideas para contribuir a mejorar Power BI
Instrucciones de plegado de consultas
en Power BI Desktop
Este artículo se dirige a los modeladores de datos que desarrollan modelos en Power BI
Desktop. Proporciona instrucciones de procedimientos recomendados sobre cuándo y
cómo lograr el plegado de consultas de Power Query.
El plegado de consultas es la capacidad de una consulta de Power Query de generar una

instrucción de consulta única que recupera y transforma los datos de origen. Para
obtener más información, vea Plegado de consultas de Power Query.
Instrucciones
Las instrucciones sobre plegado de consultas difieren en función del modo de modelo.
Para una tabla del modo de almacenamiento DirectQuery o Dual, la consulta de

Power Query debe lograr el plegado de consultas.
En el caso de una tabla de Importación, es posible que se pueda conseguir el plegado

de consultas. Cuando la consulta se basa en un origen relacional, y si se puede construir
una sola instrucción SELECT, el mejor rendimiento de la actualización de datos se
consigue asegurándose de que se produce el plegado de consultas. Si todavía es
necesario que el motor de mashup de Power Query procese las transformaciones, debe
procurar minimizar el trabajo que tiene que hacer, en especial para los conjuntos de
datos grandes.
En la siguiente lista con viñetas se proporcionan instrucciones concretas.
Delegar todo el procesamiento que sea posible en el origen de datos: cuando no

se puedan plegar todos los pasos de una consulta de Power Query, descubra qué
paso impide el plegado de consultas. Cuando sea posible, adelante los pasos
finales en la secuencia, para que se puedan factorizar en el plegado de consultas.
Tenga en cuenta que el motor de mashup de Power Query puede ser lo
suficientemente inteligente como para reordenar los pasos de la consulta al
generar la consulta de origen.
En el caso de un origen de datos relacional, si el paso que impide el plegado de

consultas se puede lograr con una sola instrucción SELECT, o bien dentro de la
lógica de procedimiento de un procedimiento almacenado, considere la
posibilidad de usar una consulta SQL nativa, como se describe a continuación.
Usar una consulta SQL nativa: cuando una consulta de Power Query recupera
datos de un origen relacional, algunos orígenes pueden usar una consulta SQL
nativa. En realidad, la consulta puede ser cualquier instrucción válida, incluida la
ejecución de un procedimiento almacenado. Si la instrucción genera varios
conjuntos de resultados, solo se devolverá el primero. Los parámetros se pueden
declarar en la instrucción y se recomienda usar la función de M Value.NativeQuery.
Esta función se ha diseñado para pasar valores de parámetro de manera segura y
cómoda. Es importante comprender que el motor de mashup de Power Query no
puede plegar pasos de consulta posteriores, por lo que debe incluir toda la lógica
de transformación (o la mayor parte posible) en la instrucción de consulta nativa.
Existen dos consideraciones importantes que se deben tener en cuenta al usar

consultas SQL nativas:
En el caso de una tabla del modelo de DirectQuery, la consulta debe ser una
instrucción SELECT y no puede usar expresiones de tabla comunes (CTE) ni un
procedimiento almacenado.
La actualización incremental no puede usar una consulta SQL nativa. Por tanto,
obligaría al motor de mashup de Power Query a recuperar todas las filas de
origen y, después, aplicar filtros para determinar los cambios incrementales.
） Importante
Una consulta SQL nativa puede hacer más que recuperar datos. Se puede
ejecutar cualquier instrucción válida (y posiblemente varias veces), incluida
una que modifica o elimina datos. Es importante aplicar el principio de
privilegios mínimos para asegurarse de que la cuenta usada para acceder a la
base de datos solo tiene permiso de lectura en los datos necesarios.
Preparar y transformar los datos en el origen: al identificar que determinados

pasos de la consulta de Power Query no se pueden plegar, es posible aplicar las
transformaciones en el origen de datos. Las transformaciones se podrían lograr si
se escribe una vista de base de datos que transforme de forma lógica los datos de
origen. O bien, mediante la preparación física y la materialización de los datos,
antes de que Power BI los consulte. Un almacenamiento de datos relacional es un
excelente ejemplo de datos preparados, normalmente compuesto por orígenes de
datos de la organización integrados previamente.
Pasos siguientes
Artículo de concepto Plegado de consultas de Power Query
Actualización incremental de los conjuntos de datos
Referencia de las consultas de Power
Query
Este artículo está dirigido a modeladores de datos como usted que trabajan con
Power BI Desktop. Proporciona instrucciones al definir las consultas de Power Query que
hacen referencia a otras consultas.
Aclaremos lo que esto significa: Cuando una consulta hace referencia a una segunda
consulta, es como si los pasos de la segunda consulte se combinaran con los pasos de la
primera consulta y se ejecutaran antes de estos.
Considere varias consultas: Query1 obtiene los datos de un servicio web y su carga está
deshabilitada. Las consultas Query2, Query3 y Query4 hacen referencia a Query1 y sus
salidas se cargan en el modelo de datos.
Cuando se actualiza el modelo de datos, a menudo se presupone que Power Query

recupera el resultado de Query1 y que lo reutilizan las consultas a las que se hace
referencia. Esto no es correcto. De hecho, Power Query ejecuta las consultas Query2,
Query3 y Query4 por separado.
Puede pensar que la consulta Query2 tiene insertados los pasos de la consulta Query1.
Esto también pasa con las consultas Query3 y Query4. En el diagrama siguiente se
muestra una imagen más clara de cómo se ejecutan las consultas.
La consulta Query1 se ejecuta tres veces. Las diversas ejecuciones pueden dar lugar a
una actualización de datos lenta e influir negativamente en el origen de datos.
El uso de la función Table.Buffer en la consulta Query1 no eliminará la recuperación de

datos adicionales. Esta función almacena en búfer una tabla en la memoria. Además, la
tabla almacenada en búfer solo se puede usar dentro de la misma ejecución de
consulta. Por lo tanto, en el ejemplo, si la consulta Query1 se almacena en búfer cuando
se ejecuta la consulta Query2, los datos almacenados en búfer no se pueden usar
cuando se ejecutan las consultas Query3 y Query4. Ellos mismos almacenarán en búfer
los datos otras dos veces. (De hecho, este resultado podría componer el rendimiento
negativo, porque la tabla la almacenará en búfer cada consulta a la que se hace
referencia).
７ Nota
La arquitectura de almacenamiento en caché de Power Query es compleja y no es

el objetivo de este artículo. Power Query puede almacenar en caché los datos
recuperados de un origen de datos. Sin embargo, cuando ejecuta una consulta,
puede recuperar los datos del origen de datos más de una vez.
Recomendaciones
Por lo general, se recomienda hacer referencia a las consultas para evitar la duplicación
de lógica en las consultas. Sin embargo, tal como se describe en este artículo, este
enfoque de diseño puede contribuir a las actualizaciones de datos lentas y a los
orígenes de datos sobrecargados.
En su lugar, se recomienda crear un flujo de datos. Usar un flujo de datos puede mejorar
el tiempo de actualización de los datos y disminuir el impacto en los orígenes de datos.
Puede diseñar el flujo de datos para que encapsule los datos de origen y las
transformaciones. Como el flujo de datos es un almacén de datos persistente del
servicio Power BI, su recuperación de datos es rápida. Por lo tanto, incluso cuando las
consultas a las que se hace referencia generan varias solicitudes para el flujo de datos,
es posible mejorar los tiempos de actualización de los datos.
En el ejemplo, si la consulta Query1 se rediseña como una entidad de flujo de datos, las
consultas Query2, Query3 y Query4 pueden usarla como un origen de datos. Con este
diseño, la entidad que obtiene la consulta Query1 solo se evaluará una vez.
Pasos siguientes
Para obtener más información sobre este artículo, consulte los recursos siguientes:
Autoservicio de preparación de los datos en Power BI

Creación y uso de flujos de datos en Power BI
Deshabilitación de la actualización en
segundo plano de Power Query
Este artículo está dirigido a modeladores de datos de importación que trabajan con
Power BI Desktop.
De forma predeterminada, cuando Power Query importa datos, también almacena en

caché hasta 1000 filas de datos de vista previa para cada consulta. Los datos de vista
previa facilitan la presentación de una vista previa rápida de los datos de origen y los
resultados de transformación de cada paso de las consultas. Se almacenan por separado
en el disco y no dentro del archivo de Power BI Desktop.
Pero cuando el archivo de Power BI Desktop contiene muchas consultas, la recuperación

y el almacenamiento de datos de vista previa pueden ampliar el tiempo necesario para
completar una actualización.
Recomendación
Para lograr una actualización más rápida, establezca el archivo de Power BI Desktop para
actualizar la caché de vista previa en segundo plano. Para habilitarlo, en Power BI
Desktop, seleccione Archivo > Opciones y configuración > Opciones y luego seleccione la
página Carga de datos. Después, puede activar la opción Permitir que se descargue la
vista previa de datos en segundo plano. Tenga en cuenta que esta opción solo se
puede establecer para el archivo actual.
La habilitación de la actualización en segundo plano puede dar lugar a que los datos de
vista previa estén desactualizados. En ese caso, el Editor de Power Query le notificará la
siguiente advertencia:
Siempre se puede actualizar la caché de vista previa. Puede actualizarla para una sola
consulta o para todas mediante el comando Actualizar vista previa. Lo encontrará en la
cinta Inicio de la ventana del Editor de Power Query.
Pasos siguientes
Documentación de Power Query

Introducción a los flujos de datos y la
preparación de datos de autoservicio
Artículo • 25/04/2023
A medida que aumenta el volumen de datos, también se complica el desafío de limpiar

y transformar dichos datos en información accionable y con un formato correcto.
Queremos datos que estén listos para análisis, para rellenar objetos viduales, informes y
paneles, a fin de que podamos convertir los volúmenes de datos rápidamente en
información procesable. Con la preparación de los datos de autoservicio para los
macrodatos en Power BI, puede convertir los datos en información de Power BI con tan
solo unas acciones.
Cuándo usar los flujos de datos

Los flujos de datos están diseñados para admitir los siguientes escenarios:
Crear una lógica de transformación reutilizable que puedan compartir muchos

conjuntos de datos e informes en Power BI. Los flujos de datos promocionan la
reutilización de los elementos de datos subyacentes, lo que evita la necesidad de
crear conexiones independientes con los orígenes de datos locales o en la nube.
Conserve los datos en su propio almacenamiento de Azure Data Lake Gen 2, lo

que le permite exponerlos a otros servicios de Azure fuera de Power BI.
Cree un único origen de verdad, mantenido a partir de datos sin procesar
mediante definiciones estándar del sector, que pueden trabajar con otros servicios
y productos en Power Platform. Fomentar la adopción mediante la eliminación del
acceso de los analistas a los orígenes de datos subyacentes.
Reforzar la seguridad en torno a los orígenes de datos subyacentes mediante la

exposición de datos a los creadores de informes en flujos de datos. Este enfoque
permite limitar el acceso a los orígenes de datos subyacentes, reducir la carga en
los sistemas de origen y proporciona a los administradores un control más preciso
sobre las operaciones de actualización de datos.
Si quiere trabajar con grandes volúmenes de datos y realizar ETL a escala, los flujos
de datos con Power BI Premium se escalan de forma más eficaz y proporcionan
más flexibilidad. Los flujos de datos admiten una amplia variedad de orígenes en la
nube y locales.
Puede usar Power BI Desktop y el servicio Power BI con los flujos de datos para crear
conjuntos de datos, informes, paneles y aplicaciones que usen Common Data Model. A
partir de estos recursos, puede obtener información sobre sus actividades
empresariales. La programación de actualizaciones de los flujos de datos se administra
directamente desde el área de trabajo en la que se creó el flujo de datos, al igual que los
conjuntos de datos.
７ Nota
Los flujos de datos no están disponibles en el servicio Power BI para los clientes del
DoD de la Administración Pública de Estados Unidos. Para obtener más
información sobre qué características están disponibles y cuáles no, consulte
Disponibilidad de características de Power BI para los clientes de la
Administración Pública de Estados Unidos.
Pasos siguientes
En este artículo se proporciona información general sobre la preparación de datos de
autoservicio para macrodatos en Power BI y las numerosas formas en que puede usarse.
En los artículos siguientes encontrará más información sobre los flujos de datos y
Power BI:
Creación de un flujo de datos

Configurar y consumir un flujo de datos
Configuración del almacenamiento de flujo de datos para usar Azure Data Lake
Gen 2
Características prémium de flujos de datos
IA con flujos de datos
Consideraciones y limitaciones de flujos de datos
Procedimientos recomendados para flujos de datos
Escenarios de uso de Power BI: preparación de datos de autoservicio
Para más información sobre Common Data Service, puede leer su artículo de
introducción:
Introducción a Common Data Model

Descripción de un esquema de estrella e
importancia para Power BI
Este artículo va dirigido a los modeladores de datos de Power BI Desktop. En él se

describe el diseño de un esquema de estrella y su importancia para desarrollar modelos
de datos de Power BI optimizados para el rendimiento y la facilidad de uso.
Este artículo no pretende proporcionar una explicación completa del diseño del
esquema de estrella. Para obtener más detalles, vaya directamente el contenido
publicado, como The Data Warehouse Toolkit: The Complete Guide to Dimensional
Modeling (El kit de herramientas del almacenamiento de datos: guía completa del
modelado dimensional) (3.ª edición, 2013) de Ralph Kimball et al.
Información general del esquema de estrella

El esquema de estrella es un enfoque de modelado maduro ampliamente adoptado por
los almacenes de datos relacionales. Requiere que los modeladores clasifiquen las tablas
del modelo como dimensiones o hechos.
Las tablas de dimensiones describen entidades empresariales (las cosas que se

modelan). Las entidades pueden incluir productos, personas, lugares y conceptos,
incluido el propio tiempo. La tabla más coherente de un esquema de estrella es una
tabla de dimensiones de fecha. Una tabla de dimensiones contiene una columna (o
columnas) de clave que actúa como identificador único y columnas descriptivas.
Las tablas de hechos pueden almacenar observaciones o eventos, y pueden ser pedidos
de ventas, existencias, tasas de cambio, temperaturas, etc. Una tabla de hechos contiene
columnas de clave de dimensiones relacionadas con las tablas de dimensiones y
columnas de medida numéricas. Las columnas de clave de dimensiones determinan la
dimensionalidad de una tabla de hechos, mientras que los valores de clave de
dimensiones determinan la granularidad de una tabla de hechos. Por ejemplo, imagine
una tabla de hechos diseñada para almacenar objetivos de ventas que tiene dos
columnas de clave de dimensiones Date y ProductKey. Resulta fácil comprender que la
tabla tiene dos dimensiones. Pero la granularidad no se puede determinar sin tener en
cuenta los valores de clave de dimensiones. En este ejemplo, imagine que los valores
almacenados en la columna Date son el primer día de cada mes. En este caso, la
granularidad está en el nivel mes-producto.
Normalmente, las tablas de dimensiones contienen un número relativamente pequeño
de filas. Por el contrario, las tablas de hechos pueden contener un gran número de filas
y seguir creciendo con el tiempo.
Normalización frente a desnormalización

Para comprender algunos conceptos de los esquemas de estrella descritos en este
artículo, es importante conocer dos términos: normalización y desnormalización.
Normalización es el término que se usa para describir los datos almacenados de una
manera que reduce los datos repetitivos. Imagine una tabla de productos que tiene una
columna de valor de clave única, como la clave de producto, y columnas adicionales que
describen características de los productos, incluidos el nombre, la categoría, el color y el
tamaño. Una tabla de ventas se considera normalizada cuando almacena solo claves,
como la clave de producto. En la imagen siguiente, observe que solo la columna
ProductKey registra el producto.
Pero si la tabla de ventas almacena detalles de los productos más allá de la clave, se
considera desnormalizada. En la imagen siguiente, observe que ProductKey y otras
columnas relacionadas con los productos registran el producto.
Cuando se extraen datos de un archivo de exportación o de un extracto de datos, es

probable que representen un conjunto de datos desnormalizado. En este caso, use
Power Query para transformar y dar forma a los datos de origen en varias tablas
normalizadas.
Tal como se describe en este artículo, debe intentar desarrollar modelos de datos de
Power BI optimizados con tablas que representen hechos normalizados y datos de
dimensiones. Pero hay una excepción en la que se debe desnormalizar una dimensión
de copo de nieve para generar una sola tabla de modelo.
Relevancia del esquema de estrella para los

modelos de Power BI
El diseño de esquema de estrella y muchos conceptos relacionados presentados en este
artículo son muy importantes para desarrollar modelos de Power BI optimizados para el
rendimiento y la facilidad de uso.
Tenga en cuenta que cada objeto visual de informe de Power BI genera una consulta
que se envía al modelo de Power BI (lo que el servicio Power BI denomina un conjunto
de datos). Estas consultas se usan para filtrar, agrupar y resumir los datos del modelo.
Por tanto, un modelo bien diseñado es aquel que proporciona tablas para filtrar y
agrupar y tablas para resumir. Este diseño se ajusta bien a los principios de los
esquemas de estrella:
Las tablas de dimensiones admiten el filtrado y la agrupación

Las tablas de hechos admiten el resumen
Los modeladores no establecen ninguna propiedad de tabla para configurar el tipo de

tabla como dimensión o hecho. Es un hecho que las relaciones de modelo determinan.
Una relación de modelo establece una ruta de propagación de filtros entre dos tablas,
mientras que la propiedad Cardinalidad de la relación es la que determina el tipo de
tabla. Una cardinalidad de relación común es uno a varios o su inversa varios a uno. El
"uno" es siempre una tabla de tipo de dimensiones, mientras que el "varios" siempre es
una tabla de tipo de hechos. Para más información sobre las relaciones, consulte
Creación de relaciones de modelos en Power BI Desktop (Evaluación de relaciones).
Un diseño de modelo bien estructurado debe incluir tablas de tipo de dimensiones o de

tipo de hechos. Evite mezclar los dos tipos en una sola tabla. También se recomienda
intentar ofrecer el número correcto de tablas con las relaciones adecuadas aplicadas.
Además, es importante que las tablas de tipo de hechos siempre carguen datos en un
nivel de detalle coherente.
Por último, es importante entender que un diseño óptimo del modelo es en parte
ciencia y en parte arte. A veces, puede interrumpir con buena orientación cuando tenga
sentido hacerlo.
Hay muchos conceptos adicionales relacionados con el diseño de esquemas de estrella

que se pueden aplicar a un modelo de Power BI. Entre estos conceptos se incluyen los
siguientes:
Medidas
Claves suplentes
Dimensiones de copo de nieve
Dimensiones realizadoras de roles
Dimensiones de variación lenta
Dimensiones no deseadas
Dimensiones degeneradas
Tablas de hechos sin hechos
Medidas
En el diseño de esquemas de estrella, una medida es una columna de tabla de hechos
que almacena valores que se van a resumir.
En un modelo de Power BI, una medida tiene otra definición, aunque similar. Es una
fórmula escrita en Expresiones de análisis de datos (DAX) que permite resumir. Las
expresiones de medida suelen aprovechar funciones de agregación de DAX como SUM,
MIN, MAX, AVERAGE, etc. para generar un resultado de valor escalar en tiempo de
consulta (los valores nunca se almacenan en el modelo). La expresión de medida puede
abarcar desde agregaciones de columnas simples hasta fórmulas más sofisticadas que
invalidan las propagaciones de contexto o de relación de filtrado. Para obtener más
información, lea el artículo Aspectos básicos de DAX en Power BI Desktop.
Es importante comprender que los modelos de Power BI admiten un segundo método

para lograr el resumen. Cualquier columna (y, normalmente, las columnas numéricas) se
puede resumir mediante un informe visual o Preguntas y respuestas. Estas columnas se
conocen como medidas implícitas. Resultan cómodas para el desarrollador de modelos,
ya que en muchos casos no es necesario crear medidas. Por ejemplo, la columna de
ventas Importe de venta del distribuidor Adventure Works podría resumirse de varias
maneras (suma, recuento, media, mediana, mín., máx., etc.), sin necesidad de crear una
medida para cada tipo de agregación posible.
Pero hay tres razones de peso para crear medidas, incluso para resúmenes simples de
nivel de columna:
Si sabe que los autores del informe van a consultar el modelo mediante
Expresiones multidimensionales (MDX), el modelo debe incluir medidas explícitas.
Las medidas explícitas se definen mediante DAX. Este enfoque de diseño es muy
importante cuando se consulta un conjunto de datos de Power BI mediante MDX,
ya que MDX no puede resumir los valores de columna. En particular, se usará MDX
al ejecutar Analizar en Excel, porque las tablas dinámicas emiten consultas MDX.
Si sabe que los autores del informe van a crear informes paginados de Power BI
mediante el diseñador de consultas MDX, el modelo debe incluir medidas
explícitas. Solo el diseñador de consultas MDX admite agregados de servidor. Por
tanto, si los autores del informe necesitan que Power BI evalúe las medidas (y no lo
haga el motor de informes paginados), tendrán que usar el diseñador de consultas
MDX.
Cuando tiene que garantizar que los autores del informe solo puedan resumir
columnas de maneras concretas. Por ejemplo, la columna de ventas Precio unitario
del distribuidor (que representa una tarifa por unidad) se puede resumir, pero solo
mediante funciones de agregación específicas. Nunca se debe sumar, pero es
adecuado resumir mediante otras funciones de agregación, como mín., máx.,
media, etc. En esta instancia, el modelador puede ocultar la columna Precio
unitario y crear medidas para todas las funciones de agregación apropiadas.
Este enfoque de diseño funciona bien con los informes creados en el servicio Power BI y
Preguntas y respuestas. Pero las conexiones dinámicas de Power BI Desktop permiten a
los autores de informes mostrar los campos ocultos del panel Campos, lo que puede
dar lugar a la elusión de este enfoque de diseño.
Claves suplentes
Una clave suplente es un identificador único que se agrega a una tabla para admitir el
modelado de esquemas de estrella. Por definición, no se define ni se almacena en los
datos de origen. Normalmente, las claves suplentes se agregan a las tablas de
dimensiones del almacén de datos relacionales para proporcionar un identificador único
para cada fila de la tabla de dimensiones.
Las relaciones del modelo de Power BI se basan en una sola columna única de una tabla,
que propaga los filtros a una sola columna de otra tabla. Cuando una tabla de tipo de
dimensiones del modelo no incluye una sola columna única, debe agregar un
identificador único para que se convierta en el "uno" de una relación. En Power BI
Desktop, puede lograr fácilmente este requisito si crea una columna de índice de Power
Query.
Debe combinar esta consulta con la consulta "varios" para poder agregarle también la
columna de índice. Al cargar estas consultas en el modelo, puede crear una relación uno
a varios entre las tablas del modelo.
Dimensiones de copo de nieve

Una dimensión de copo de nieve es un conjunto de tablas normalizadas para una sola
entidad de negocio. Por ejemplo, Adventure Works clasifica los productos por categoría
y subcategoría. Los productos se asignan a subcategorías y, a su vez, las subcategorías
se asignan a categorías. En el almacén de datos relacionales de Adventure Works, la
dimensión de producto se normaliza y se almacena en tres tablas relacionadas:
DimProductCategory, DimProductSubcategory y DimProduct.
Si usa su imaginación, puede imaginarse las tablas normalizadas colocadas hacia fuera
de la tabla de hechos, formando un diseño de copo de nieve.
En Power BI Desktop, puede optar por imitar un diseño de dimensiones de copo de
nieve (quizás porque los datos de origen lo hacen) o integrar (desnormalizar) las tablas
de origen en una sola tabla del modelo. Por lo general, las ventajas de una sola tabla del
modelo compensan las ventajas de varias tablas del modelo. La decisión óptima puede
depender de los volúmenes de datos y de los requisitos de facilidad de uso del modelo.
Si elige imitar un diseño de dimensiones de copo de nieve:
Power BI carga más tablas, lo que resulta menos eficaz desde el punto del vista del
almacenamiento y el rendimiento. Estas tablas deben incluir columnas para admitir
las relaciones del modelo, lo que puede dar lugar a un mayor tamaño del modelo.
Las cadenas de propagación de filtros de relaciones más largas deben ser
transversales, lo que probablemente sea menos eficaz que la aplicación de filtros a
una sola tabla.
El panel Campos presenta más tablas del modelo a los autores de informes, lo que
puede dar lugar a una experiencia menos intuitiva, especialmente si las tablas de
dimensiones de copo de nieve contienen solo una o dos columnas.
No es posible crear una jerarquía que abarque las tablas.
Si elige integrar en una sola tabla del modelo, además puede definir una jerarquía que
abarque el mayor y menor nivel de detalle de la dimensión. Posiblemente, el
almacenamiento de datos desnormalizados redundantes pueda dar lugar a un mayor
tamaño de almacenamiento del modelo, especialmente en el caso de tablas de
dimensiones muy grandes.
Dimensiones de variación lenta
Una dimensión de variación lenta (SCD) es aquella que administra correctamente el
cambio de los miembros de la dimensión a lo largo del tiempo. Se aplica cuando los
valores de la entidad empresarial cambian con el tiempo y de forma ad hoc. Un buen
ejemplo de dimensión de variación lenta es una dimensión de cliente, concretamente
sus columnas de detalles de contacto, como la dirección de correo electrónico y el
número de teléfono. Por el contrario, algunas dimensiones se consideran de variación
rápida si un atributo de dimensión cambia con frecuencia, como el precio de mercado
de un artículo. El enfoque de diseño común en estas instancias es almacenar los valores
de atributo de variación rápida en una medida de tabla de hechos.
La teoría de diseño de esquemas de estrella hace referencia a dos tipos de SCD

comunes: Tipo 1 y tipo 2. Una tabla de tipo de dimensiones puede ser de tipo 1 o de
tipo 2, o admitir ambos tipos simultáneamente para columnas diferentes.
SCD de tipo 1
Una SCD de tipo 1 siempre refleja los valores más recientes y, cuando se detectan
cambios en los datos de origen, los datos de la tabla de dimensiones se sobrescriben.
Este enfoque de diseño es común para las columnas que almacenan valores auxiliares,
como la dirección de correo electrónico o el número de teléfono de un cliente. Cuando
cambia la dirección de correo electrónico o el número de teléfono de un cliente, la tabla
de dimensiones actualiza la fila del cliente con los nuevos valores. Es como si el cliente
tuviera siempre esta información de contacto.
Una actualización no incremental de una tabla de tipo de dimensiones del modelo de

Power BI logra el resultado de una SCD de tipo 1. Actualiza los datos de la tabla para
garantizar que se carguen los valores más recientes.
SCD de tipo 2
Una SCD de tipo 2 admite el control de versiones de los miembros de la dimensión. Si el
sistema de origen no almacena versiones, suele ser el proceso de carga de
almacenamiento de datos el que detecta los cambios y administra de forma adecuada el
cambio en una tabla de dimensiones. En este caso, la tabla de dimensiones debe usar
una clave suplente para proporcionar una referencia única a una versión del miembro de
la dimensión. También incluye columnas que definen la validez del intervalo de fechas
de la versión (por ejemplo, StartDate y EndDate) y, posiblemente, una columna de
marca (por ejemplo, IsCurrent) para filtrar fácilmente por miembros de la dimensión
actuales.
Por ejemplo, Adventure Works asigna vendedores a una región de ventas. Cuando un
vendedor se reasigna a otra región, debe crearse una nueva versión del vendedor para
asegurarse de que los hechos históricos sigan asociados a la región anterior. Para
admitir un análisis histórico preciso de ventas por vendedor, la tabla de dimensiones
debe almacenar versiones de vendedores y sus regiones asociadas. La tabla también
debe incluir valores de fecha de inicio y finalización para definir la validez temporal. Las
versiones actuales pueden definir una fecha de finalización vacía (o 31/12/9999), lo que
indica que la fila es la versión actual. La tabla también debe definir una clave suplente,
ya que la clave empresarial (en esta instancia, Id. de empleado) no es única.
Es importante comprender que si los datos de origen no almacenan versiones, debe

usar un sistema intermedio (como un almacenamiento de datos) para detectar y
almacenar los cambios. El proceso de carga de la tabla debe conservar los datos
existentes y detectar los cambios. Cuando se detecta un cambio, el proceso de carga de
la tabla debe hacer que expire la versión actual. Para registrar estos cambios actualiza el
valor EndDate e inserta una versión nueva con el valor StartDate que comienza a partir
del valor EndDate anterior. Además, los hechos relacionados deben usar una búsqueda
basada en tiempo para recuperar el valor de clave de dimensión pertinente para la fecha
de los hechos. Un modelo de Power BI con Power Query no puede generar este
resultado. Pero puede cargar datos de una tabla de dimensiones SCD de tipo 2
previamente cargada.
El modelo de Power BI debe admitir la consulta de datos históricos de un miembro,
independientemente del cambio, y de una versión del miembro, que representa un
estado determinado del miembro en el tiempo. En el contexto de Adventure Works, este
diseño permite consultar el vendedor con independencia de la región de ventas
asignada, o una versión determinada del vendedor.
Para lograr este requisito, la tabla de tipo de dimensión del modelo de Power BI debe
incluir una columna para filtrar el vendedor y otra para filtrar una versión específica del
vendedor. Es importante que la columna de versión proporcione una descripción no
ambigua, como "Michael Blythe (15/12/2008-26/06/2019)" o "Michael Blythe (actual)".
También es importante educar a los autores y usuarios de informes sobre los aspectos
básicos de la SCD de tipo 2 y cómo lograr diseños de informe adecuados mediante la
aplicación de los filtros correctos.
También es un buen procedimiento de diseño incluir una jerarquía que permita a los
objetos visuales obtener detalles hasta el nivel de versión.
Dimensiones realizadoras de roles
Una dimensión realizadora de roles es una dimensión que puede filtrar datos
relacionados de manera diferente. Por ejemplo, en Adventure Works, la tabla de
dimensiones de fecha tiene tres relaciones con los hechos de ventas del distribuidor. Se
puede usar la misma tabla de dimensiones para filtrar los hechos por fecha de pedido,
fecha de envío o fecha de entrega.
En un almacenamiento de datos, el enfoque de diseño aceptado es definir una sola

tabla de dimensiones de fecha. En tiempo de consulta, el "rol" de la dimensión de fecha
se establece mediante la columna de hechos que se usa para combinar las tablas. Por
ejemplo, al analizar las ventas por fecha de pedido, la combinación de tabla se relaciona
con la columna de fecha de pedido de ventas del distribuidor.
En un modelo de Power BI, este diseño se puede imitar mediante la creación de varias
relaciones entre dos tablas. En el ejemplo de Adventure Works, las tablas de fecha y
ventas del distribuidor tendrían tres relaciones. Aunque este diseño sea posible, es
importante entender que solo puede haber una relación activa entre dos tablas del
modelo de Power BI. Todas las demás relaciones se deben establecer en inactivas. El
tener una única relación activa significa que hay una propagación de filtros
predeterminada desde fecha a ventas del distribuidor. En esta instancia, la relación
activa se establece en el filtro más común que usan los informes, que en Adventure
Works es la relación de fecha de pedido.
La única forma de usar una relación inactiva es definir una expresión DAX que use la
función USERELATIONSHIP. En el ejemplo, el desarrollador del modelo debe crear
medidas para habilitar el análisis de las ventas del distribuidor por fecha de envío y
fecha de entrega. Este trabajo puede resultar tedioso, sobre todo si en la tabla del
distribuidor se definen muchas medidas. También crea aglomeración en el panel
Campos, con una gran cantidad de medidas. También hay otras limitaciones:
Si los autores de informes se basan en el resumen de columnas, en lugar de la

definición de medidas, no pueden conseguir un resumen de las relaciones
inactivas sin escribir una medida de nivel de informe. Las medidas de nivel de
informe solo se pueden definir al crear informes en Power BI Desktop.
Con solo una ruta de relación activa entre la fecha y las ventas del distribuidor, no
es posible filtrar simultáneamente las ventas del distribuidor por diferentes tipos
de fechas. Por ejemplo, no se puede generar un objeto visual que trace las ventas
de fecha de pedido por ventas enviadas.
Para superar estas limitaciones, una técnica de modelado común de Power BI es crear
una tabla de tipo de dimensiones para cada instancia realizadora de roles.
Normalmente, las tablas de dimensiones adicionales se crean como tablas calculadas
mediante DAX. Con las tablas calculadas, el modelo puede contener una tabla de fecha,
una tabla de fecha de envío y una tabla de fecha de entrega, cada una con una relación
única y activa con sus columnas respectivas de la tabla de ventas del distribuidor.
Este enfoque de diseño no requiere la definición de varias medidas para los distintos
roles de fecha y permite el filtrado simultáneo mediante diferentes roles de fecha. Pero
un precio menor que se paga con este enfoque de diseño es que existe duplicación de
la tabla de dimensiones de fecha que da lugar a un mayor tamaño de almacenamiento
del modelo. Como las tablas de tipo de dimensión suelen almacenar menos filas que las
tablas de tipo de hechos, esto no suele ser un problema.
Observe los siguientes procedimientos recomendados de diseño al crear tablas de tipo

de dimensiones del modelo para cada rol:
Asegúrese de que los nombres de columna sean autodescriptivos. Aunque es

posible tener una columna Año en todas las tablas de fecha (los nombres de
columna son únicos en su tabla), no se describe automáticamente mediante títulos
visuales predeterminados. Considere la posibilidad de cambiar el nombre de las
columnas de cada tabla de roles de dimensión, de modo que la tabla de fecha de
envío tenga una columna de año denominada Año de envío, etc.
Cuando proceda, asegúrese de que las descripciones de la tabla proporcionen
comentarios a los autores de informes (mediante la información sobre
herramientas del panel Campos) sobre cómo se configura la propagación de
filtros. Esta claridad es importante cuando el modelo contiene una tabla con
nombre genérico, como Fecha, que se usa para filtrar muchas tablas de tipo de
hechos. En el caso de que esta tabla tenga, por ejemplo, una relación activa con la
columna de fecha de pedido de ventas del distribuidor, considere la posibilidad de
proporcionar una descripción de la tabla como "Filtra las ventas del distribuidor
por fecha de pedido".
Para más información, consulte Instrucciones para relaciones activas frente a inactivas.
Dimensiones no deseadas
Una dimensión no deseada es útil cuando hay muchas dimensiones, especialmente si
constan de pocos atributos (quizás uno) y si estos atributos tienen pocos valores. Los
buenos candidatos incluyen columnas de estado de pedido o columnas demográficas
de clientes (sexo, grupo de edad, etc.).
El objetivo de diseño de una dimensión no deseada es consolidar muchas dimensiones

"pequeñas" en una sola dimensión a fin de reducir el tamaño de almacenamiento del
modelo y, además, minimizar la aglomeración del panel Campos mediante la exposición
de menos tablas del modelo.
Una tabla de dimensiones no deseadas es normalmente el producto cartesiano de todos

los miembros de atributos de dimensiones, con una columna de clave suplente. La clave
suplente proporciona una referencia única a cada fila de la tabla. Puede compilar la
dimensión en un almacenamiento de datos o al usar Power Query para crear una
consulta que realice combinaciones de consulta externas completas y luego agregue
una clave suplente (columna de índice).
Esta consulta se carga en el modelo como una tabla de tipo de dimensiones. También
debe combinar esta consulta con la consulta de hechos, de modo que la columna de
índice se cargue en el modelo para permitir la creación de una relación de modelo "uno
a varios".
Una dimensión degenerada hace referencia a un atributo de la tabla de hechos
necesario para el filtrado. En Adventure Works, el número de pedido de ventas del
distribuidor es un buen ejemplo. En este caso, no tiene sentido diseñar un modelo para
crear una tabla independiente que solo conste de esta columna, porque aumentaría el
tamaño de almacenamiento del modelo y la aglomeración del panel Campos.
En el modelo de Power BI, puede ser adecuado agregar la columna de número de

pedido de ventas a la tabla de tipo de hechos para permitir el filtrado o la agrupación
por número de pedido de ventas. Es una excepción a la regla presentada antes de que
no se deben mezclar tipos de tabla (por lo general, las tablas del modelo deben ser de
tipo de dimensión o de tipo de hechos).
Sin embargo, si la tabla de ventas de los revendedores de Adventure Works contiene el

número de pedido y columnas de número de línea de pedido, y estos son necesarios
para el filtrado, una tabla de dimensión degenerada sería un buen diseño. Para más
información, consulte Instrucciones para relaciones uno a uno (Dimensiones
degeneradas).
Tablas de hechos sin hechos

Una tabla de hechos sin hechos no incluye ninguna columna de medida. Solo contiene
claves de dimensión.
Una tabla de hechos sin hechos podría almacenar observaciones definidas por claves de
dimensión. Por ejemplo, en una fecha y hora determinadas, un cliente concreto ha
iniciado sesión en el sitio web. Puede definir una medida para contar las filas de la tabla
de hechos sin hechos a fin de realizar un análisis de cuántos clientes han iniciado sesión
y cuándo lo han hecho.
Un uso más atractivo de una tabla de hechos sin hechos es almacenar relaciones entre
dimensiones, y es el enfoque de diseño de modelos de Power BI que se recomienda
para definir relaciones de dimensión de varios a varios. En un diseño de relaciones de
dimensión de varios a varios, la tabla de datos sin datos se conoce como tabla de
puente.
Por ejemplo, imagine que los vendedores pueden asignarse a una o más regiones de
ventas. La tabla de puente se diseñaría como una tabla de hechos sin hechos de dos
columnas: clave de vendedor y clave de región. Los valores duplicados se pueden
almacenar en ambas columnas.
Este enfoque de diseño de varios a varios está bien documentado y se puede lograr sin
una tabla de puente. Pero el enfoque de tabla de puente se considera el procedimiento
recomendado al relacionar dos dimensiones. Para más información, consulte
Instrucciones para relaciones de varios a varios (Relación de dimensiones varios a
varios).
Pasos siguientes
Para obtener más información sobre el diseño de esquemas de estrella o el diseño del
modelo de Power BI, vea los siguientes artículos:
Artículo de la Wikipedia sobre el modelado dimensional

Crear y administrar relaciones en Power BI Desktop
Instrucciones para relaciones uno a uno
Instrucciones para relaciones de varios a varios
Instrucciones para relaciones bidireccionales
Instrucciones para relaciones activas frente a inactivas
Técnicas de reducción de datos para
modelos de importación
Este artículo va dirigido a los modeladores de datos de Power BI Desktop que

desarrollan modelos de importación. En él se explican distintas técnicas para ayudar a
reducir los datos cargados en los modelos de importación.
Los modelos de importación se cargan con datos comprimidos y optimizados y luego se

almacenan en disco mediante el motor de almacenamiento VertiPaq. Cuando los datos
de origen se cargan en la memoria, es posible ver una compresión por 10, por lo que es
razonable esperar que 10 GB de datos de origen se puedan comprimir a un tamaño de
aproximadamente 1 GB. Además, cuando se guardan en el disco, se puede lograr una
reducción adicional del 20 %.
A pesar de la eficacia lograda por el motor de almacenamiento VertiPaq, es importante

intentar minimizar los datos que se van a cargar en los modelos. Esto es especialmente
así en el caso de los modelos de gran tamaño, o bien de los modelos que se prevé que
vayan a crecer hasta alcanzar un gran tamaño con el tiempo. Los cuatro motivos de
peso incluyen:
Es posible que la capacidad no admita tamaños de modelo más grandes. La

capacidad compartida puede hospedar modelos de hasta 1 GB de tamaño,
mientras que las capacidades Premium pueden hospedar modelos de hasta 13 GB
de tamaño. Para obtener más información, lea el artículo Compatibilidad de Power
BI Premium con conjuntos de datos grandes.
Los tamaños de modelo más pequeños reducen la contención de los recursos de
capacidad, en particular, memoria. Permite que se carguen más modelos de forma
simultánea durante períodos de tiempo más largos, lo que da lugar a tasas de
expulsión inferiores.
Los modelos más pequeños logran una actualización de datos más rápida, lo que
da lugar a informes de latencia inferiores, mayor rendimiento de actualización de
conjuntos de datos y menos presión sobre el sistema de origen y los recursos de
capacidad.
Los recuentos de filas de tablas más pequeños pueden dar lugar a evaluaciones de
cálculo más rápidas, lo que puede proporcionar un mejor rendimiento general de
las consultas.
En este artículo se describen ocho técnicas de reducción de datos diferentes. Estas

técnicas incluyen:
Quitar columnas innecesarias
Quitar filas innecesarias
Agrupar y resumir
Optimizar tipos de datos de columna
Preferencia de columnas personalizadas
Deshabilitar la carga de consultas de Power Query
Deshabilitar fecha y hora automáticas
Cambiar al modo mixto
Quitar columnas innecesarias

Las columnas de las tablas del modelo tienen dos propósitos principales:
Creación de informes, para lograr diseños de informe que filtren, agrupen y

resuman los datos del modelo correctamente
Estructura del modelo, al admitir relaciones del modelo, cálculos del modelo, roles
de seguridad e incluso formato de colores de datos
Las columnas que no sirvan para estos propósitos probablemente se puedan quitar. La
eliminación de columnas se conoce como filtrado vertical.
Se recomienda diseñar modelos que tengan exactamente el número correcto de

columnas en función de los requisitos conocidos de creación de informes. Los requisitos
pueden cambiar con el tiempo, pero tenga en cuenta que es más fácil agregar columnas
más adelante que quitarlas. La eliminación de columnas puede interrumpir los informes
o la estructura del modelo.
Quitar filas innecesarias

Las tablas del modelo se deben cargar con el menor número de filas posible. Esto se
puede conseguir si se cargan conjuntos de filas filtrados en tablas del modelo por dos
motivos diferentes: para filtrar por entidad o por tiempo. La eliminación de filas se
conoce como filtrado horizontal.
El filtrado por entidad implica cargar un subconjunto de datos de origen en el modelo.

Por ejemplo, en lugar de cargar datos de ventas de todas las regiones de ventas, solo se
cargan los de una región. Este enfoque de diseño da lugar a muchos modelos más
pequeños, y también puede eliminar la necesidad de definir seguridad de nivel de fila
(pero exige la concesión de permisos específicos de conjunto de datos en el servicio
Power BI y la creación de informes "duplicados" que se conectan a cada conjunto de
datos). Puede aprovechar los parámetros de Power Query y los archivos de plantilla de
Power BI para simplificar la administración y la publicación. Para obtener más
información, lea la entrada de blog Información detallada sobre los parámetros de
consulta y las plantillas de Power BI .
El filtrado por tiempo implica limitar la cantidad de historial de datos que se carga en
las tablas de tipo de hechos (y limitar las filas de fecha cargadas en las tablas de fecha
del modelo). Se sugiere no cargar automáticamente todo el historial disponible, a
menos que se trate de un requisito conocido de creación de informes. Resulta útil
entender que los filtros de Power Query basados en tiempo se pueden parametrizar e
incluso definir para que usen períodos de tiempo relativos (con respecto a la fecha de
actualización, por ejemplo, los cinco últimos años). Además, tenga en cuenta que los
cambios retrospectivos en los filtros de tiempo no interrumpen los informes; solo dan
lugar a menos (o más) historial de datos disponible en los informes.
Agrupar y resumir
Quizás la técnica más eficaz para reducir el tamaño de un modelo es cargar datos
resumidos previamente. Esta técnica se puede usar para disminuir el nivel de detalle de
las tablas de tipo de hechos. La desventaja es la pérdida de detalle.
Por ejemplo, una tabla de hechos de ventas de origen almacena una fila por línea de
pedido. Se puede lograr una reducción considerable de los datos si se resumen todas
las métricas de ventas, al agrupar por fecha, cliente y producto. Por tanto, piense que se
puede lograr una reducción de datos aún mayor mediante la agrupación por fecha en el
nivel de mes. Se podría conseguir una reducción del 99 % del tamaño del modelo,
aunque ya no es posible crear informes en el nivel de día ni de pedido individual. La
decisión de resumir los datos de tipo de hechos siempre conlleva ventajas y desventajas.
Las desventajas se podrían mitigar mediante un diseño de modelo mixto, una opción
que se describe en la técnica Cambiar al modo mixto.
Optimizar tipos de datos de columna

El motor de almacenamiento VertiPaq usa estructuras de datos independientes para
cada columna. Por diseño, estas estructuras de datos logran las mayores optimizaciones
con los datos de columna numéricos, que usan codificación de valores. Pero los datos
de texto y otros no numéricos usan codificación hash. Esto requiere que el motor de
almacenamiento asigne un identificador numérico a cada valor de texto único incluido
en la columna. Así, es el identificador numérico el que después se almacena en la
estructura de datos, lo que exige una búsqueda hash durante el almacenamiento y la
consulta.
En algunas instancias específicas, puede convertir los datos de texto de origen en
valores numéricos. Por ejemplo, un número de pedido de ventas puede llevar siempre
como prefijo un valor de texto (como "SO123456"). Se puede quitar el prefijo y el valor
de número de pedido convertirse en número entero. En el caso de las tablas de gran
tamaño, esto puede dar lugar a una reducción considerable de datos, especialmente si
la columna contiene valores de cardinalidad únicos o elevados.
En este ejemplo, se recomienda establecer la propiedad de columna Resumen

predeterminado en "No resumir". Esto ayudará a minimizar el resumen inadecuado de
los valores de número de pedido.
Preferencia de columnas personalizadas

El motor de almacenamiento VertiPaq almacena las columnas calculadas del modelo
(definidas en DAX) lo mismo que las columnas normales cuyo origen es Power Query.
Pero las estructuras de datos se almacenan de forma ligeramente distinta y,
normalmente, se consigue una compresión menos eficaz. Además, se compilan una vez
que se cargan todas las tablas de Power Query, lo que puede dar lugar a tiempos de
actualización de datos prolongados. Por lo tanto, resulta menos eficaz agregar columnas
de tabla como columnas calculadas que como columnas calculadas de Power Query
(definidas en M).
La preferencia debería ser crear columnas personalizadas en Power Query. Cuando el

origen es una base de datos, se puede lograr una mayor eficacia de carga de dos
maneras. El cálculo se puede definir en la instrucción SQL (mediante el lenguaje de
consulta nativo del proveedor), o bien se puede materializar como una columna en el
origen de datos.
Pero, en algunos casos, las columnas calculadas del modelo pueden ser la mejor opción.
Este es el caso cuando la fórmula implica evaluar medidas o requiere una funcionalidad
de modelado específica que solo se admite en las funciones DAX. Para obtener
información sobre un ejemplo de este tipo, vea el artículo Descripción de las funciones
para jerarquías de elemento primario y secundario en DAX.
Deshabilitar la carga de consultas de Power

Query
Las consultas de Power Query diseñadas para permitir la integración de datos con otras
consultas no deben cargarse en el modelo. Para evitar la carga de la consulta en el
modelo, asegúrese de deshabilitar la carga de consultas en estas instancias.
Deshabilitar fecha y hora automáticas
Power BI Desktop incluye una opción llamada Fecha y hora automáticas. Cuando se
habilita, crea una tabla de fecha y hora automática oculta para las columnas de fecha a
fin de ayudar a los creadores de informes al configurar filtros, agrupar y realizar acciones
de exploración en profundidad durante períodos de tiempo de calendario. Las tablas
ocultas son en realidad tablas calculadas que aumentan el tamaño del modelo. Para
obtener instrucciones sobre el uso de esta opción, consulte el artículo Guía de fecha y
hora automáticas en Power BI Desktop.
Cambiar al modo mixto

En Power BI Desktop, un diseño de modo mixto genera un modelo compuesto.
Básicamente, permite determinar el modo de almacenamiento de cada tabla. Por lo
tanto, cada tabla puede tener su propiedad Modo de almacenamiento establecida en
Importar o DirectQuery (Dual es otra opción).
Una técnica eficaz para reducir el tamaño del modelo consiste en establecer la
propiedad Modo de almacenamiento de las tablas de tipo de hechos mayores en
DirectQuery. Piense que este enfoque de diseño podría funcionar bien con la técnica
Agrupar y resumir presentada antes. Por ejemplo, los datos de ventas resumidos se
podrían usar para lograr informes de "resumen" de alto rendimiento. Una página de
obtención de detalles podría mostrar las ventas pormenorizadas de un contexto de
filtrado (y delimitación) específico y mostrar todos los pedidos de ventas en contexto. En
este ejemplo, la página de obtención de detalles incluiría objetos visuales basados en
una tabla de DirectQuery para recuperar los datos de pedidos de ventas.
Pero hay muchas implicaciones de seguridad y rendimiento relacionadas con los

modelos compuestos. Para obtener más información, lea el artículo Usar modelos
compuestos en Power BI Desktop.
Pasos siguientes
Para obtener más información sobre el diseño del modelo de importación de Power BI,
vea los siguientes artículos:
Usar modelos compuestos en Power BI Desktop

Modo de almacenamiento en Power BI Desktop
Creación de tablas de fechas en
Power BI Desktop
Power BI Desktop. Se describen prácticas recomendadas de diseño para crear tablas de
fechas en los modelos de datos.
Para trabajar con las funciones de inteligencia de tiempo de las expresiones de análisis
de datos (DAX), hay un requisito previo para el modelo: Debe tener al menos una tabla
de fechas en el modelo. Una tabla de fechas es una tabla que cumple los siguientes
requisitos:
＂ Debe contener una columna de tipo de datos fecha, o fecha y hora, conocida como
la columna de fecha.
＂ La columna de fecha debe contener valores únicos.
＂ La columna de fecha no debe contener ESPACIOS EN BLANCO.
＂ En la columna de fecha no debe faltar ninguna fecha.
＂ La columna de fecha debe abarcar años completos. Un año no es necesariamente
un año natural (de enero a diciembre).
＂ La tabla de fechas debe estar marcada como una tabla de fechas.
Puede utilizar cualquiera de las distintas técnicas para agregar una tabla de fechas al
modelo:
Opción de fecha y hora automáticas

Power Query para conectarse a una tabla de dimensiones de fecha
Power Query para generar una tabla de fechas
DAX para generar una tabla de fechas
DAX para clonar una tabla de fechas existente
 Sugerencia
Una tabla de fechas es quizás la característica más coherente que agregará a

cualquiera de sus modelos. Además, dentro de una organización, una tabla de
fechas debe definirse de forma coherente. Por lo tanto, independientemente de la
técnica que decida usar, se recomienda crear una plantilla de Power BI Desktop
que contenga una tabla de fechas totalmente configurada. Comparta la plantilla
con todos los modeladores de su organización. Por lo tanto, cada vez que alguien
desarrolla un nuevo modelo, puede comenzar con una tabla de fechas definida de
forma coherente.
Uso de la fecha y hora automáticas

La opción Fecha y hora automáticas ofrece inteligencia de tiempo cómoda, rápida y fácil
de usar. Los autores de informes pueden trabajar con la inteligencia de tiempo al filtrar,
agrupar y explorar los períodos de tiempo de calendario.
Se recomienda mantener habilitada la opción Fecha y hora automáticas solo al trabajar

con períodos de tiempo de calendario y cuando tenga requisitos de modelo sencillos
con respecto al tiempo. Usar esta opción también puede ser útil cuando se crean
modelos ad hoc o se realiza la generación de perfiles o la exploración de datos. Sin
embargo, este enfoque no es compatible con un diseño de tabla de fechas único que
puede propagar filtros a varias tablas. Para más información, vea Guía sobre la fecha y
hora automáticas en Power BI Desktop.
Conexión con Power Query

Cuando el origen de datos ya tiene una tabla de fechas, se recomienda utilizarlo como
origen de la tabla de fechas del modelo. Este caso suele darse cuando se conecta a un
almacenamiento de datos, ya que tendrá una tabla de dimensiones de fecha. De este
modo, el modelo utiliza una única fuente de confianza para los aspectos temporales de
su organización.
Si va a desarrollar un modelo de DirectQuery y el origen de datos no incluye una tabla

de fechas, le recomendamos encarecidamente que agregue una tabla de fechas al
origen de datos. Debe cumplir todos los requisitos de modelado de una tabla de fechas.
A continuación, puede usar Power Query para conectarse a la tabla de fechas. De esta
manera, los cálculos del modelo pueden utilizar las funcionalidades de inteligencia de
tiempo de DAX.
Generación con Power Query

Puede generar una tabla de fechas mediante Power Query. Para más información,
consulte la entrada Generar una tabla de dimensiones de fecha en Power Query en el
log de Chris Webb.
 Sugerencia
Si no dispone de un almacenamiento de datos u otra definición coherente para los
aspectos temporales de su organización, considere la posibilidad de usar Power
Query para publicar un flujo de datos. A continuación, haga que todos los
modeladores de datos se conecten al flujo de datos para agregar tablas de fechas a
sus modelos. El flujo de datos se convierte en la única fuente de confianza para los
aspectos temporales de su organización.
Si necesita generar una tabla de fechas, considere la posibilidad de hacerlo con DAX. Es
posible que le resulte más fácil. Además, puede resultar más conveniente, ya que DAX
integra alguna inteligencia para simplificar la creación y administración de tablas de
fechas.
Generación con DAX

Puede generar una tabla de fechas en el modelo mediante la creación de una tabla
calculada con las funciones CALENDAR o CALENDARAUTO de DAX. Cada función
devuelve una tabla de fechas de una sola columna. A continuación, puede extender la
tabla calculada con columnas calculadas para admitir los requisitos de agrupación y
filtrado de intervalos de fechas.
Utilice la función CALENDAR cuando desee definir un intervalo de fechas. Se pasan

dos valores: la fecha de inicio y la fecha de finalización. Estos valores pueden
definirse con otras funciones de DAX, como MIN(Sales[OrderDate]) o
MAX(Sales[OrderDate]) .
Utilice la función CALENDARAUTO cuando desee que el intervalo de fechas

abarque automáticamente todas las fechas almacenadas en el modelo. Puede
pasar un solo parámetro opcional que sea el mes en que finaliza el año (si se trata
de un año natural, que finaliza en diciembre, no es necesario pasar ningún valor).
Es una función útil, ya que garantiza que se devuelvan años de fechas completos;
es un requisito para una tabla de fechas marcada. Además, no es necesario
administrar la extensión de la tabla a los próximos años: cuando se completa una
actualización de datos, desencadena el recálculo de la tabla. Un recálculo
extenderá automáticamente el intervalo de fechas de la tabla cuando se carguen
fechas de un año nuevo en el modelo.
 Sugerencia
Para más información sobre cómo crear tablas calculadas, incluido un ejemplo de
cómo crear una tabla de fechas, siga el módulo de aprendizaje Incorporación de
tablas y columnas calculadas a modelos de Power BI Desktop.
Clonación con DAX
Cuando el modelo ya tiene una tabla de fechas y necesita otra adicional, puede clonar
fácilmente la tabla de fechas existente. Esto sucede cuando la fecha es una dimensión
realizadora de roles. Puede clonar una tabla mediante la creación de una tabla
calculada. La expresión de tabla calculada es simplemente el nombre de la tabla de
fechas existente.
Pasos siguientes
Fecha y hora automáticas en Power BI Desktop

Guía sobre la fecha y hora automáticas en Power BI Desktop
Configuración y uso de tablas de fechas en Power BI Desktop
Autoservicio de preparación de los datos en Power BI
Función CALENDAR (DAX)
Función CALENDARAUTO (DAX)
Guía sobre la fecha y hora automáticas
en Power BI Desktop
Este artículo se dirige a los modeladores de datos que desarrollan modelos compuestos
o de importación en Power BI Desktop. Proporciona instrucciones, recomendaciones y
consideraciones al usar la funcionalidad Fecha y hora automáticas de Power BI Desktop
en situaciones específicas. Para información general sobre la funcionalidad Fecha y hora
automáticas, consulte Fecha y hora automáticas en Power BI Desktop.
La opción Fecha y hora automáticas ofrece inteligencia de tiempo cómoda, rápida y fácil
de usar. Los autores de informes pueden trabajar con la inteligencia de tiempo al filtrar,
agrupar y explorar los períodos de tiempo de calendario.
Consideraciones
En la lista con viñetas siguiente se describen las consideraciones (y posibles limitaciones)
relacionadas con la opción Fecha y hora automáticas.
Se aplica a todos o a ninguno: cuando la opción Fecha y hora automáticas está

habilitada, se aplica a todas las columnas de fechas en las tablas de importación
que no son el lado "varios" de una relación. No se puede habilitar ni deshabilitar
de manera selectiva columna por columna.
Solo períodos de calendario: las columnas de año y trimestre se relacionan con los
períodos de calendario. Significa que el año empieza el 1 de enero y finaliza el 31
de diciembre. No es posible personalizar la fecha de inicio (o finalización) del año.
Personalización: no es posible personalizar los valores que se usan para describir

los períodos de tiempo. Además, no es posible agregar otras columnas para
describir otros períodos de tiempo, por ejemplo, semanas.
Filtrado de año: los valores de la columnas Quarter, Month y Day no incluyen el

valor de año. Por ejemplo, la columna Month contiene solo los nombres de los
meses (es decir, enero, febrero, etc.). Los valores no son totalmente
autodescriptivos y es posible que, en algunos diseños de informes, no comuniquen
el contexto de filtro de año.
Esta es la razón por la que es importante que los filtros o agrupaciones se lleven a
cabo en la columna Year. Al explorar en profundidad mediante la jerarquía, se
filtrará el año, a menos que el nivel Year se quite de manera intencional. Si no hay
ningún filtro o grupo por año, una agrupación por mes, por ejemplo, resumiría los
valores de todos los años correspondientes a ese mes.
Filtrado de fecha de una sola tabla: como cada columna de fecha genera su
propia tabla de fecha y hora automáticas (oculta), no es posible aplicar un filtro de
tiempo a una tabla y hacer que lo propague a varias tablas de modelo. Filtrar de
esta manera es un requisito de modelado común cuando se notifican varios
asuntos (tablas de tipo de hechos), como las ventas y el presupuesto de ventas. Al
usar la fecha y hora automáticas, el autor de informe deberá aplicar filtros a cada
columna de fecha distinta.
Tamaño del modelo: para cada columna de fecha que genera una tabla de fecha y
hora automáticas oculta, generará un tamaño de modelo mayor y también
ampliará la hora de actualización de los datos.
Otras herramientas de informes: No es posible trabajar con tablas de fecha y hora

automáticas cuando:
Se usa Analizar en Excel.
Se usan diseñadores de consultas de Analysis Services en informes paginados
de Power BI.
Se establece una conexión al modelo con diseñadores de informes que no son
de Power BI.
Recomendaciones
Se recomienda mantener habilitada la opción Fecha y hora automáticas solo al trabajar
con períodos de tiempo de calendario y cuando tenga requisitos de modelo simplistas
con respecto al tiempo. Usar esta opción también puede ser útil cuando se crean
modelos ad hoc o se realiza la generación de perfiles o la exploración de datos.
Cuando el origen de datos ya define una tabla de dimensión de fecha, esta tabla se
debe usar para definir de manera coherente la hora dentro de la organización.
Seguramente será el caso si el origen de datos es un almacenamiento de datos. De lo
contrario, puede generar tablas de fechas en el modelo si usa las funciones CALENDAR
o CALENDARAUTO de DAX. Luego puede agregar columnas calculadas para admitir los
requisitos conocidos de agrupación y filtrado de tiempo. Este enfoque de diseño puede
permitirle crear una tabla de fechas única que se propague a todas las tablas de tipo de
hechos, lo que posiblemente resulte en una tabla única para aplicar los filtros de tiempo.
Para más información sobre cómo crear las tablas de fechas, lea el artículo
Configuración y uso de tablas de fechas en Power BI Desktop.
 Sugerencia
Para más información sobre cómo crear tablas calculadas, incluido un ejemplo de
cómo crear una tabla de fechas, siga el módulo de aprendizaje Incorporación de
tablas y columnas calculadas a modelos de Power BI Desktop.
Si la opción Fecha y hora automáticas no es pertinente para sus proyectos, le

recomendamos deshabilitar la opción Fecha y hora automáticas local. Esto garantizará
que todos los archivos de Power BI Desktop nuevos que cree no habilitarán la opción
Fecha y hora automáticas.
Pasos siguientes
Creación de tablas de fechas en Power BI Desktop

Fecha y hora automáticas en Power BI Desktop
Configuración y uso de tablas de fechas en Power BI Desktop
Power BI Desktop. Proporciona instrucciones sobre cómo trabajar con relaciones de
modelo de uno a uno. Se puede crear una relación uno a uno cuando ambas tablas
contienen una columna de valores comunes y únicos.
７ Nota
En este artículo no se incluye una introducción a las relaciones de modelo. Si no

está familiarizado con las relaciones, sus propiedades o cómo configurarlas, se
recomienda que primero lea el artículo Relaciones de modelos en Power BI
Desktop.
También es importante que conozca el diseño del esquema de estrella. Para más
información, vea Descripción de un esquema de estrella e importancia para
Power BI.
Hay dos escenarios que implican relaciones uno a uno:
Dimensiones degeneradas: puede derivar una dimensión degenerada de una tabla

de tipo de hechos.
Los datos de fila se distribuyen entre las tablas: una sola entidad de negocio o
asunto se carga como dos (o más) tablas de modelo, posiblemente porque sus
datos provienen de almacenes de datos diferentes. Este escenario puede ser
común para las tablas de tipos de dimensión. Por ejemplo, los detalles de los
productos maestros se almacenan en un sistema de ventas operativo y los detalles
adicionales de los productos se almacenan en un origen diferente.
Sin embargo, no es habitual que relacione dos tablas de tipo de hechos con una
relación uno a uno. El motivo es que ambas tablas de tipo de hechos necesitarían
tener la misma dimensionalidad y granularidad. Además, cada tabla de tipo de
hechos necesitaría columnas únicas para permitir la creación de la relación de
modelo que se va a crear.
Cuando se usan columnas de una tabla de tipo de hechos para filtrar o agrupar, puede
que le interese que estén disponibles en una tabla independiente. De este modo, se
separan las columnas usadas para el filtro o la agrupación de aquellas utilizadas para
resumir las filas de hechos. Esta separación puede:
Reducir el espacio de almacenamiento

Simplificar los cálculos del modelo
Contribuir a mejorar el rendimiento de las consultas
Ofrecer una experiencia del panel Campos más intuitiva a sus autores de informes
Considere una tabla de ventas de origen que almacena los detalles de pedidos de
ventas en dos columnas.
La columna OrderNumber almacena el número de pedido, y la columna

OrderLineNumber almacena una secuencia de líneas dentro del pedido.
En el siguiente diagrama de modelo, observe que el número de pedido y número de

línea de pedido no se han cargado en la tabla Sales. En cambio, sus valores se usaron
para crear una columna de clave suplente llamada SalesOrderLineID. (El valor clave se
calcula multiplicando el número de pedido por 1000 y luego agregando el número de
línea de pedido).
La tabla Sales Order proporciona una experiencia enriquecida para los autores de
informes con tres columnas: Sales Order, Sales Order Line y Line Number. También
incluye una jerarquía. Estos recursos de tabla admiten diseños de informes que
necesitan filtrar, agrupar o explorar en profundidad pedidos y líneas de pedido.
Como la tabla Sales Order se deriva de los datos de ventas, debe haber exactamente el
mismo número de filas en cada tabla. Además, debe haber valores coincidentes entre
cada columna SalesOrderLineID.
Los datos de fila se distribuyen entre las tablas

Considere un ejemplo en el que se incluyen dos tablas de tipo de dimensión con una
relación uno a uno: Product y Product Category. Cada tabla representa datos
importados y tiene una columna SKU (referencia de almacén) que contiene valores
únicos.
Aquí hay un diagrama de modelos parcial de las dos tablas.
La primera tabla se denomina Product y contiene tres columnas: Color, Product y SKU.
La segunda tabla se denomina Product Category y contiene dos columnas: Category y
SKU. Una relación uno a uno relaciona las dos columnas SKU. La relación se filtra en
ambas direcciones, que es siempre el caso de las relaciones uno a uno.
Para facilitar la descripción del funcionamiento de la propagación del filtro de

relaciones, se ha modificado el diagrama del modelo para mostrar las filas de la tabla.
Todos los ejemplos de este artículo se basan en estos datos.
７ Nota
No es posible mostrar filas de tabla en el diagrama de modelo de Power BI

Desktop. En este artículo se hace para complementar la explicación con ejemplos
claros.
Los detalles de las filas de las dos tablas se describen en la siguiente lista con viñetas:
La tabla Product tiene tres filas:

SKU CL-01, Product T-shirt, Color Green
SKU CL-02, Product Jeans, Color Blue
SKU AC-01, Product Hat, Color Blue
La tabla Product Category tiene dos filas:
SKU CL-01, Category Clothing
SKU AC-01, Category Accessories
Tenga en cuenta que la tabla Product Category no incluye una fila para el producto SKU
CL-02. Discutiremos las consecuencias de esta fila ausente más adelante en este artículo.
En el panel Campos, los autores de informes encontrarán campos relacionados con el

producto en dos tablas: Product y Product Category.
Veamos qué sucede cuando los campos de ambas tablas se agregan a un objeto visual
de tabla. En este ejemplo, la columna SKU se obtiene de la tabla Product.
Observe que el valor Category para el producto SKU CL-02 está EN BLANCO. El motivo
es que no hay una fila en la tabla Product Category para este producto.
Recomendaciones
Cuando sea posible, le recomendamos que evite crear relaciones de modelo uno a uno
cuando los datos de fila se distribuyan entre tablas de modelos. Es porque este diseño
puede:
Contribuir al desorden del panel Campos, enumerando más tablas de las

necesarias
Hacer que sea difícil para los autores de informes encontrar campos relacionados
porque están distribuidos en varias tablas
Limitar la capacidad de crear jerarquías, ya que sus niveles se deben basar en
columnas de la misma tabla
Generar resultados inesperados cuando no hay una coincidencia completa de filas
entre las tablas
Las recomendaciones específicas difieren dependiendo de si la relación uno a uno es

intragrupo de origen o entre grupos de origen. Para más información sobre la evaluación
de relaciones, consulte Creación de relaciones de modelos en Power BI Desktop
(Evaluación de relaciones).
Relación uno a uno intragrupo de origen

Cuando existe una relación uno a uno intragrupo de origen entre las tablas,
recomendamos consolidar los datos en una sola tabla de modelo. Se realiza
combinando las consultas de Power Query.
Los siguientes pasos presentan una metodología para consolidar y modelar los datos
relacionados uno a uno:
1. Combinar consultas: al combinar las dos consultas, tenga en cuenta la integridad

de los datos en cada consulta. Si una consulta contiene un conjunto completo de
filas (como una lista maestra), combine la otra consulta con ella. Configure la
transformación de combinación para usar una combinación externa izquierda, que
es el tipo de combinación predeterminado. Este tipo de combinación garantiza
que mantendrá todas las filas de la primera consulta y las complementará con las
filas coincidentes de la segunda consulta. Expanda todas las columnas requeridas
de la segunda consulta en la primera consulta.
2. Deshabilitar la carga de consultas: asegúrese de deshabilitar la carga de la

segunda consulta. De esta manera, no cargará su resultado como una tabla
modelo. Esta configuración reduce el tamaño de almacenamiento del modelo de
datos y ayuda a despejar el panel Campos.
En nuestro ejemplo, los autores de informes ahora encuentran una sola tabla
llamada Product en el panel Campos. Contiene todos los campos relacionados con
el producto.
3. Reemplazar los valores que faltan: si la segunda consulta tiene filas no

coincidentes, aparecerán valores NULL en las columnas introducidas desde ella.
Cuando sea apropiado, considere reemplazar los valores NULL por un valor de
token. El reemplazo de los valores que faltan es especialmente importante cuando
los autores de informes filtran o agrupan por los valores de la columna, ya que los
valores EN BLANCO podrían aparecer en los objetos visuales del informe.
En el siguiente objeto visual, observe que en la categoría del producto SKU CL-02
ahora pone [Sin definir] . En la consulta, las categorías nulas se reemplazaron por
este valor de texto de token.
4. Crear jerarquías: si existen relaciones entre las columnas de la tabla ahora
consolidada, puede ser recomendable crear jerarquías. De esta forma, los autores
de informes identificarán rápidamente las oportunidades para informar de la
exploración de objetos visuales.
En nuestro ejemplo, los autores de informes ahora pueden usar una jerarquía que
tiene dos niveles: Category y Product.
Si le gusta cómo las tablas independientes ayudan a organizar sus campos, todavía le
recomendamos consolidar en una sola tabla. Todavía puede organizar sus campos, pero
utilizando carpetas para mostrar.
En nuestro ejemplo, los autores de informes pueden encontrar el campo Category

dentro de la carpeta para mostrar Marketing.
Si de todas formas decide definir relaciones uno a uno intragrupo de origen en su
modelo, cuando sea posible, asegúrese de que haya filas coincidentes en las tablas
relacionadas. Como una relación uno a uno intragrupo de origen se evalúa como una
relación normal, podrían surgir problemas de integridad de datos en los objetos visuales
del informe como espacios en blanco. (Puede ver un ejemplo de una agrupación EN
BLANCO en el primer objeto visual de la tabla presentado en este artículo).
Relación uno a uno entre grupos de origen

Cuando existe una relación uno a uno entre grupos de origen entre las tablas, no hay un
diseño de modelo alternativo, a menos que consolide previamente los datos en los
orígenes de datos. Power BI evaluará la relación del modelo uno a uno como una
relación limitada. Por lo tanto, asegúrese de que haya filas coincidentes en las tablas
relacionadas, ya que las filas no coincidentes se eliminarán de los resultados de la
consulta.
Ahora se verá qué sucede cuando los campos de las dos tablas se agregan a un objeto
visual de tabla y existe una relación limitada entre las tablas.
La tabla solo muestra dos filas. El producto SKU CL-02 no está porque no hay una fila
coincidente en la tabla Product Category.
Pasos siguientes
Relaciones de modelos en Power BI Desktop

Descripción de un esquema de estrella e importancia para Power BI
Instrucciones para solución de problemas de relaciones
Instrucciones para relaciones de varios a
varios
Power BI Desktop. Describe tres escenarios diferentes de modelado de varios a varios.
También se proporcionan instrucciones sobre cómo diseñarlos correctamente en los
modelos.
７ Nota

Desktop.
Power BI.
En realidad, hay tres escenarios de varios a varios. Se pueden producir cuando tiene que:
Relacionar dos tablas de tipo de dimensión

Relacionar dos tablas de tipo de hechos
Relacionar tablas de tipo de hechos con un nivel de detalle más alto, cuando la
tabla de tipo de hechos almacena filas con un nivel de detalle más alto que las de
la tabla de tipo de dimensión
７ Nota
Power BI ahora admite de forma nativa relaciones de varios a varios. Para más
información, consulte Relaciones de varios a varios en Power BI Desktop.
Relación de dimensiones varios a varios

A continuación se considerará el primer tipo de escenario de varios a varios con un
ejemplo. En el escenario clásico se relacionan dos entidades: clientes de banco y cuentas
bancarias. Imagine que los clientes pueden tener varias cuentas y que las cuentas
pueden tener varios clientes. Cuando una cuenta tiene varios clientes, normalmente se
denominan titulares conjuntos de la cuenta.
El modelado de estas entidades es sencillo. En una tabla de tipo de dimensión se

almacenan las cuentas y en otra los clientes. Como es característico de las tablas de tipo
de dimensión, en cada una hay una columna de identificador. Para modelar la relación
entre las dos tablas, se requiere una tercera. Esta tabla se conoce comúnmente como
tabla de puente. En este ejemplo, su finalidad es almacenar una fila por cada asociación
de cuenta y cliente. Curiosamente, cuando esta tabla solo contiene columnas de
identificador, se denomina tabla de hechos sin hechos.
Este es un sencillo diagrama de modelo de las tres tablas.
La primera tabla se denomina Account (Cuenta) y contiene dos columnas: AccountID

(IdDeCuenta) y Account (Cuenta). La segunda tabla se denomina AccountCustomer
(ClienteCuenta) y contiene dos columnas: AccountID (IdDeCuenta) y CustomerID
(IdDeCliente). La tercera tabla se denomina Customer (Cliente) y contiene dos columnas:
CustomerID (IdDeCliente) y Customer (Cliente). No existen relaciones entre ninguna de
las tablas.
Se agregan dos relaciones uno a varios para relacionar las tablas. Este es un diagrama
de modelo actualizado de las tablas relacionadas. Se ha agregado una tabla de tipo de
hechos denominada Transaction (Transacción). Registra las transacciones de las cuentas.
Se han ocultado la tabla de puente y todas las columnas de identificador.
Para facilitar la descripción del funcionamiento de la propagación del filtro de
relaciones, se ha modificado el diagrama del modelo para mostrar las filas de la tabla.
７ Nota

claros.
Los detalles de las filas de las cuatro tablas se describen en la siguiente lista con viñetas:
La tabla Account tiene dos filas:

AccountID 1 es para Account-01
AccountID 2 es para Account-02
La tabla Customer tiene dos filas:
CustomerID 91 es para Customer-91
CustomerID 92 es para Customer-92
La tabla AccountCustomer tiene tres filas:
AccountID 1 se asocia a CustomerID 91
La tabla Transaction tiene tres filas:
Date January 1 2019, AccountID 1, Amount 100
Date February 2 2019, AccountID 2, Amount 200
Date March 3 2019, AccountID 1, Amount -25
A continuación se verá lo que sucede cuando se consulta el modelo.
A continuación se muestran dos objetos visuales que resumen la columna Amount de la

tabla Transaction. El primer objeto visual agrupa por cuenta y, por tanto, la suma de las
columnas Amount representa el saldo de cuenta. El segundo objeto visual agrupa por
cliente y, por tanto, la suma de las columnas Amount representa el saldo del cliente.
El nombre del primer objeto visual es Account Balance (Saldo de la cuenta) y tiene dos
columnas: Account (Cuenta) y Amount (Cantidad). Muestra el resultado siguiente:
El saldo de Account-01 es 75
El saldo de Account-02 es 200
El total es 275
El nombre del segundo objeto visual es Customer balance (Saldo del cliente) y tiene dos
columnas: Customer (Cliente) y Amount (Cantidad). Muestra el resultado siguiente:
El saldo de Customer-91 es 275

El total es 275
Un examen rápido de las filas de tabla y el objeto visual Account Balance muestra que
el resultado es correcto, para cada cuenta y la cantidad total. Se debe a que cada
agrupación de cuentas genera una propagación de filtro a la tabla Transaction de esa
cuenta.
Pero parece que algo no es correcto en el objeto visual Customer Balance. Cada cliente
del objeto visual Customer Balance tiene el mismo saldo que el saldo total. Este
resultado solo podría ser correcto si todos los clientes fueran titulares conjuntos de
todas las cuentas. Pero en este ejemplo no es el caso. El problema está relacionado con
la propagación del filtro. No fluye de forma completa hasta la tabla Transaction.
Siga las direcciones del filtro de relaciones desde la tabla Customer a la

tablaTransaction. Debe ser evidente que la relación entre la tabla Account y
AccountCustomer se propaga en la dirección equivocada. La dirección del filtro para
esta relación se debe establecer en Ambos.
Como se esperaba, no ha habido ningún cambio en el objeto visual Account Balance.
Pero ahora los objetos visuales Customer Balance muestran el siguiente resultado:
El total es 275
Ahora el objeto visual Customer Balance muestra un resultado correcto. Siga

personalmente las direcciones del filtro y vea cómo se han calculado los saldos del
cliente. Además, recuerde que el total visual significa todos los clientes.
Alguien que no esté familiarizado con las relaciones del modelo podría concluir que el
resultado es incorrecto. Se podría preguntar: ¿Por qué el saldo total de Customer-91 y
Customer-92 no es igual a 350 (75 + 275)?
La respuesta a su pregunta radica en comprender la relación varios a varios. Cada saldo
de cliente puede representar la suma de varios saldos de cuenta, y los saldos del cliente
no son aditivos.
Instrucciones para la relación de dimensiones varios a

varios
Si tiene una relación de varios a varios entre tablas de tipo de dimensión, siga las
instrucciones siguientes:
Agregue cada entidad relacionada de varios a varios como una tabla de modelo, y
asegúrese de que tiene una columna de identificador único (ID)
Agregue una tabla de puente para almacenar entidades asociadas
Cree relaciones de uno a varios entre las tres tablas
Configure una relación bidireccional para permitir que la propagación del filtro
continúe a las tablas de tipo de hechos
Si no es adecuado tener valores de identificador que faltan, establezca la
propiedad Admite valores NULL de las columnas ID en FALSE; después, se
producirá un error en la actualización de datos si hay valores que faltan en el
origen
Oculte la tabla de puente (a menos que contenga columnas o medidas adicionales
necesarias para la generación de informes)
Oculte las columnas de identificador que no sean adecuadas para los informes
(por ejemplo, cuando los identificadores son claves suplentes)
Si tiene sentido dejar visible una columna de identificador, asegúrese de que se
encuentra en el lado "uno" de la relación; oculte siempre la columna del lado
"varios". El resultado será el rendimiento óptimo de los filtros.
Para evitar confusiones o malinterpretaciones, comunique las explicaciones a los
usuarios del informe: puede agregar descripciones con cuadros de texto o
información sobre herramientas de encabezado a los objetos visuales
No se recomienda relacionar directamente las tablas de tipo de dimensión de varios a

varios. Este enfoque de diseño requiere la configuración de una relación con una
cardinalidad de varios a varios. Conceptualmente se puede lograr, pero implica que las
columnas relacionadas contendrán valores duplicados. Pero es un procedimiento
recomendado de diseño que las tablas de tipo de dimensión tengan una columna ID.
Las tablas de tipo de dimensión siempre deben usar la columna ID como el lado "uno"
de una relación.
Relación varios a varios de hechos

El segundo tipo de escenario de varios a varios implica la relación de dos tablas de tipo
de hechos. Dos tablas de tipo de hechos se pueden relacionar directamente. Esta técnica
de diseño puede ser útil para la exploración de datos rápida y sencilla. Pero para ser
claros, generalmente no se recomienda este enfoque de diseño. Más adelante en esta
sección se explicarán los motivos.
Considere un ejemplo con dos tablas de tipo de hechos: Order (Pedido) y Fulfillment
(Suministro). La tabla Order contiene una fila por línea de pedido y la tabla Fulfillment
puede contener cero o más filas por línea de pedido. Las filas de la tabla Order
representan pedidos de venta. Las filas de la tabla Fulfillment representan los artículos
de pedidos que se han enviado. Una relación varios a varios relaciona las dos columnas
OrderID, y el filtro solo se propaga desde la tabla Order (Order filtra Fulfillment).
La cardinalidad de relación se establece en varios a varios para admitir el

almacenamiento de valores OrderID duplicados en las dos tablas. En la tabla Order
pueden existir valores OrderID duplicados porque un pedido puede tener varias líneas.
En la tabla Fulfillment pueden existir valores OrderID duplicados porque los pedidos
pueden tener varias líneas, y las líneas de pedido se pueden cumplir con varios envíos.
A continuación se examinarán las filas de la tabla. En la tabla Fulfillment, observe que

varios pedidos se pueden cumplir mediante varios envíos. (La ausencia de una línea de
pedido significa que el pedido todavía no se ha cumplido).
Los detalles de las filas de las dos tablas se describen en la siguiente lista con viñetas:
La tabla Order tiene cinco filas:

OrderDate January 1 2019, OrderID 1, OrderLine 1, ProductID Prod-A,
OrderQuantity 5, Sales 50
OrderDate January 1 2019, OrderID 1, OrderLine 2, ProductID Prod-B,
OrderDate February 2 2019, OrderID 2, OrderLine 1, ProductID Prod-B,
OrderDate February 2 2019, OrderID 2, OrderLine 2, ProductID Prod-C,
OrderDate March 3 2019, OrderID 3, OrderLine 1, ProductID Prod-C,
La tabla Fulfillment tiene cuatro filas:
FulfillmentDate January 1 2019, FulfillmentID 50, OrderID 1, OrderLine 1,
FulfillmentQuantity 2
FulfillmentDate February 2 2019, FulfillmentID 51, OrderID 2, OrderLine 1,
FulfillmentDate February 2 2019, FulfillmentID 52, OrderID 1, OrderLine 1,
FulfillmentDate January 1 2019, FulfillmentID 53, OrderID 1, OrderLine 2,
A continuación se verá lo que sucede cuando se consulta el modelo. A continuación se

muestra un objeto visual de tabla en el que se comparan las cantidades de pedidos y de
cumplimiento por la columna OrderID de la tabla Order.
El objeto visual presenta un resultado exacto. Pero la utilidad del modelo es limitada:
solo se puede filtrar o agrupar por la columna OrderID de la tabla Order.
Instrucciones para la relación de hechos varios a varios

Por lo general, no se recomienda relacionar directamente dos tablas de tipo de hechos
mediante la cardinalidad de varios a varios. La razón principal es que el modelo no
proporcionará flexibilidad a los objetos visuales de informe para filtrar o agrupar. En el
ejemplo, solo es posible que los objetos visuales filtren o agrupen por la columna
OrderID de la tabla Order. Un motivo adicional está relacionado con la calidad de los
datos. Si los datos tienen problemas de integridad, es posible que algunas filas se
omitan durante las consultas debido a la naturaleza de la relación débil. Para más
información, consulte Creación de relaciones de modelos en Power BI Desktop
(Evaluación de las relaciones).
En lugar de relacionar directamente tablas de tipos de hechos, se recomienda adoptar

principios de diseño de esquema de estrella. Para ello, agregue tablas de tipo de
dimensión. Las tablas de tipo de dimensión se relacionan con las tablas de tipo de
hechos mediante relaciones de uno a varios. Este enfoque de diseño es robusto, ya que
ofrece opciones de informe flexibles. Permite filtrar o agrupar con cualquiera de las
columnas de tipo de dimensión y resumir cualquier tabla de tipo de hechos relacionada.
A continuación se considerará una solución mejor.

Tenga en cuenta los siguientes cambios de diseño:
Ahora el modelo tiene cuatro tablas adicionales: OrderLine, OrderDate, Product y

FulfillmentDate
Las cuatro tablas adicionales son todas de tipo de dimensión y las relaciones uno a
varios las relacionan con las tablas de tipo de hechos.
La tabla OrderLine contiene una columna OrderLineID, que representa el valor
OrderID multiplicado por 100, más el valor OrderLine, un identificador único para
cada línea de pedido
Las tablas Order y Fulfillment ahora contienen una columna OrderLineID y ya no
contienen las columnas OrderID ni OrderLine.
La tabla Fulfillment contiene ahora columnas OrderDate y ProductID.
La tabla FulfillmentDate solo está relacionada con la tabla Fulfillment.
Todas las columnas de identificador único están ocultas
Dedicar tiempo a aplicar los principios de diseño de esquema de estrella ofrece las
ventajas siguientes:
Los objetos visuales del informe pueden filtrar o agrupar por cualquier columna
visible de las tablas de tipo de dimensión.
Los objetos visuales del informe pueden resumir por cualquier columna visible de
las tablas de tipo de hechos.
Los filtros aplicados a las tablas OrderLine, OrderDate o Product se propagarán a
ambas tablas de tipo de hechos.
Todas las relaciones son de uno a varios, y cada una es una relación sólida. Los
problemas de integridad de los datos no se enmascaran. Para más información,
consulte Creación de relaciones de modelos en Power BI Desktop (Evaluación de
las relaciones).
Relación de hechos con un nivel de detalle más

alto
Este escenario de varios a varios es muy diferente de los otros dos que ya se han
descrito en este artículo.
A continuación se verá un ejemplo en el que se incluyen cuatro tablas: Date (Fecha),

Sales (Ventas), Product (Producto) y Target (Destino). Date y Product son tablas de tipo
de dimensión, y las relaciones de uno a varios las relacionan con la tabla de tipo de
hechos Sales. Hasta ahora, representa un buen diseño de esquema de estrella. Pero la
tabla Target todavía se tiene que relacionar con las demás tablas.
La tabla Target contiene tres columnas: Category, TargetQuantity y TargetYear. Las filas
de la tabla revelan una granularidad de año y categoría de producto. En otras palabras,
los destinos, que se usan para medir el rendimiento de las ventas, se establecen cada
año para cada categoría de producto.
Como en la tabla Target se almacenan datos en un nivel superior al de las tablas de tipo
de dimensión, no se puede crear una relación de uno a varios. Bueno, es cierto para una
sola de las relaciones. A continuación se verá cómo se puede relacionar la tabla Target
con las tablas de tipo de dimensión.
Relación de períodos de tiempo con un nivel de detalle

más alto
Una relación entre las tablas Date y Target debe ser de uno a varios. Se debe a que los
valores de la columna TargetYear son fechas. En este ejemplo, cada valor de columna
TargetYear es la primera fecha del año de destino.
 Sugerencia
Al almacenar hechos con una granularidad de tiempo superior a la de un día,

establezca el tipo de datos de la columna en Fecha (o Número entero si usa claves
de fecha). En la columna, almacene un valor que represente el primer día del
período de tiempo. Por ejemplo, un período de año se registra como el 1 de enero
del año, y un período de mes como el primer día de ese mes.
Pero debe tener cuidado para asegurarse de que los filtros de nivel de mes o de fecha
producen un resultado significativo. Sin una lógica de cálculo especial, los objetos
visuales de informe pueden notificar que las fechas de destino son literalmente el
primer día de cada año. Todos los demás días (y todos los meses excepto enero)
resumirán la cantidad de destino como en blanco.
En el siguiente objeto visual de matriz se muestra lo que sucede cuando el usuario del
informe profundiza en los meses de un año. El objeto visual resume la columna
TargetQuantity. (La opción Mostrar elementos sin datos se ha habilitado para las filas de
la matriz).
Para evitar este comportamiento, se recomienda controlar el resumen de los datos de
hechos mediante medidas. Una manera de controlar el resumen consiste en devolver un
valor en blanco cuando se consultan los períodos de tiempo de nivel inferior. Otra
manera, definida con sofisticadas funciones DAX, consiste en es prorratear los valores en
períodos de tiempo de nivel inferior.
Considere la siguiente definición de medida que usa la función DAX ISFILTERED. Solo
devuelve un valor cuando las columnas Date o Month no se filtran.
DAX
Target Quantity =
IF(
NOT ISFILTERED('Date'[Date])
&& NOT ISFILTERED('Date'[Month]),
SUM(Target[TargetQuantity])
)
El siguiente objeto visual de matriz usa ahora la medida Target Quantity (Cantidad de
destino). Muestra que todas las cantidades de destino mensuales están en blanco.
Relación con un nivel de detalle más alto (distinto de
fechas)
Al relacionar una columna que no sea de fecha de una tabla de tipo de dimensión con
una tabla de tipo de hechos (y en un nivel de detalle más alto que la tabla de tipo de
dimensión) se requiere otro enfoque de diseño.
Las columnas Category (de las tablas Product y Target) contienen valores duplicados.
Por tanto, no hay ningún "uno" para una relación de uno a varios. En este caso, tendrá
que crear una relación de varios a varios. La relación debe propagar los filtros en una
sola dirección, desde la tabla de tipo de dimensión a la de tipo de hechos.
A continuación se examinarán las filas de la tabla.
En la tabla Target hay cuatro filas: dos para cada año de destino (2019 y 2020) y dos
categorías (ropa y accesorios). En la tabla Product hay tres productos. Dos pertenecen a
la categoría de ropa y uno a la de accesorios. Uno de los colores de la ropa es el verde y
los dos restantes son azules.
Un objeto visual de tabla que agrupe por la columna Category de la tabla Product
genera el resultado siguiente.
Este objeto visual genera el resultado correcto. Ahora se verá qué sucede cuando se usa
la columna Color de la tabla Product para agrupar la cantidad de destino.
El objeto visual genera una representación incorrecta de los datos. ¿Qué sucede aquí?
Un filtro en la columna Color de la tabla Product genera dos filas. Una de las filas es
para la categoría Clothing y la otra para la categoría Accessories. Estos dos valores de
categoría se propagan como filtros a la tabla Target. En otras palabras, como los
productos de dos categorías usan el color azul, esas categorías se usan para filtrar los
destinos.
Para evitar este comportamiento, como se ha descrito antes, se recomienda controlar el

resumen de los datos de hechos mediante medidas.
Considere la siguiente definición de medida. Observe que todas las columnas de la tabla
Product que están debajo del nivel de categoría se prueban para los filtros.
DAX
Target Quantity =
IF(
NOT ISFILTERED('Product'[ProductID])
&& NOT ISFILTERED('Product'[Product])
&& NOT ISFILTERED('Product'[Color]),
SUM(Target[TargetQuantity])
)
El siguiente objeto visual de tabla usa ahora la medida Target Quantity (Cantidad de
destino). Muestra que todas las cantidades de destino de color están en blanco.
El diseño final del modelo es similar al siguiente.
Instrucciones para la relación de hechos con un nivel de

detalle más alto
Si necesita relacionar una tabla de tipo de dimensión con una de tipo de hechos, y la
tabla de tipo de hechos almacena filas con un nivel de detalle más alto que las filas de la
tabla de tipo de dimensión, siga estas instrucciones:
Para fechas de hechos con un nivel de detalle más alto:

En la tabla de tipo de hechos, almacene la primera fecha del período de tiempo
Cree una relación de uno a varios entre la tabla de fechas y la de tipo de hechos
Para otros hechos con un nivel de detalle más alto:
Cree una relación de varios a varios entre la tabla de tipo de dimensión y la de
tipo de hechos
Para los dos tipos:
Controle el resumen mediante lógica de medida: devuelva valores en blanco
cuando se usen columnas de tipo de dimensión de nivel inferior para filtrar o
agrupar
Oculte las columnas de tabla de tipo de hechos que se puedan resumir: de esta
forma, solo se podrán usar medidas para resumir la tabla de tipo de hechos.
Pasos siguientes

Instrucciones para elegir entre
relaciones activas e inactivas
Artículo • 04/05/2023
Power BI Desktop. Le proporciona instrucciones sobre cuándo crear relaciones de
modelo activas o inactivas. De forma predeterminada, las relaciones activas propagan
filtros a otras tablas. La relación inactiva, sin embargo, solo propaga los filtros cuando
una expresión DAX activa (usa) la relación.
７ Nota

Desktop.
Power BI.
Relaciones activas
Por lo general, se recomienda definir las relaciones activas siempre que sea posible.
Amplían el ámbito y el potencial del modo en que los autores de informes y los usuarios
que trabajan con Preguntas y respuestas pueden usar el modelo.
Piense, por ejemplo, en un modelo de importación diseñado para analizar la

puntualidad de una línea aérea. El modelo tiene una tabla Flight (Vuelo), que es una
tabla de tipo de hechos que almacena una fila por vuelo. Cada fila registra la fecha del
vuelo, el número de vuelo, los aeropuertos de salida y llegada y cualquier retraso (en
minutos). También hay un tabla Airport (Aeropuerto), que es una tabla de tipo de
dimensión que almacena una fila por aeropuerto. Cada fila describe el código del
aeropuerto, el nombre del aeropuerto y el país o región.

Existen dos relaciones de modelo entre las tablas Flight (Vuelo) y Airport (Aeropuerto).
En la tabla Flight (Vuelo), las columnas DepartureAirport (Aeropuerto de salida) y
ArrivalAirport (Aeropuerto de llegada) se relacionan con la columna Airport
(Aeropuerto) de la tabla Airport (Aeropuerto). En el diseño de esquemas de estrella, la
tabla Airport (Aeropuerto) se describe como una dimensión realizadora de roles. En este
modelo, los dos roles son el aeropuerto de salida y el aeropuerto de llegada.
Aunque este diseño funciona bien para los diseños de esquema de estrella, no sirve
para los modelos de Power BI. El motivo es que las relaciones de modelo son rutas de
acceso para la propagación de filtros y estas rutas de acceso deben ser deterministas.
Por esta razón, un modelo no puede tener varias relaciones activas entre dos tablas. Por
lo tanto, como se describe en este ejemplo, una relación está activa mientras la otra está
inactiva (representada por la línea discontinua). En concreto, es la relación con la
columna ArrivalAirport (Aeropuerto de llegada) la que está activa. Esto significa que los
filtros que se aplican a la tabla Airport (Aeropuerto) se propagan automáticamente a la
columna ArrivalAirport (Aeropuerto de llegada) de la tabla Flight (Vuelo).
Este diseño de modelo impone serias limitaciones a la forma en que se pueden

presentar los datos. En concreto, no es posible filtrar la tabla Airport (Aeropuerto) para
aislar automáticamente los detalles de los vuelos de un aeropuerto de salida. A medida
que los requisitos de los informes implican el filtrado (o la agrupación) de los
aeropuertos de salida y llegada al mismo tiempo, se necesitan dos relaciones activas. El
traslado de este requisito a un diseño de modelo de Power BI implica que el modelo
debe tener dos tablas de aeropuerto.
Este es el diseño mejorado del modelo.

El modelo tiene ahora dos tablas de aeropuertos: Departure Airport (Aeropuerto de
salida) y Arrival Airport (Aeropuerto de llegada). Las relaciones de modelo entre estas
tablas y la tabla Flight (Vuelo) están activas. Observe también que los nombres de
columna de las tablas Departure Airport (Aeropuerto de salida) y Arrival Airport
(Aeropuerto de llegada) llevan como prefijo la palabra Departure (Salida) o Arrival
(Llegada).
El diseño de modelo mejorado permite generar el siguiente diseño de informe.
La página del informe filtra por Melbourne como aeropuerto de salida y los grupos de
objetos visuales de la tabla por aeropuertos de llegada.
７ Nota
En el caso de los modelos de importación, la tabla adicional ha dado como

resultado un aumento del tamaño del modelo y tiempos de actualización más
largos. Como tal, contradice las recomendaciones descritas en el artículo Técnicas
de reducción de datos para modelos de importación. Sin embargo, en el ejemplo,
el requisito de tener solo relaciones activas invalida estas recomendaciones.
Además, es habitual que las tablas de tipo de dimensión contengan poca cantidad
de filas en relación con la cantidad de filas de la tabla de tipo de hechos. Por lo
tanto, no es probable que el tamaño del modelo y los tiempos de actualización
sean mucho más grandes.
Metodología de refactorización
A continuación se muestra una metodología para refactorizar un modelo de una sola
tabla de tipo de dimensión realizadora de roles a un diseño con una tabla por rol.
1. Quite todas las relaciones inactivas.
2. Considere la posibilidad de cambiar el nombre de la tabla de tipo de dimensión

realizadora de roles para describir mejor su rol. En el ejemplo, la tabla de Airport
(Aeropuerto) está relacionada con la columna ArrivalAirport (Aeropuerto de
llegada) de la tabla Flight (Vuelo), por lo que se le cambia el nombre a Arrival
Airport (Aeropuerto de llegada).
3. Cree una copia de la tabla realizadora de roles y proporcione un nombre que

refleje su rol. Si se trata de una tabla de importación, se recomienda definir una
tabla calculada. Si se trata de una tabla de DirectQuery, puede duplicar la consulta
de Power Query.
En el ejemplo, se ha creado la tabla Departure Airport (Aeropuerto de salida) con

la siguiente definición de tabla calculada.
DAX
Departure Airport = 'Arrival Airport'
4. Cree una relación activa para relacionar la nueva tabla.
5. Considere la posibilidad de cambiar el nombre de las columnas de las tablas para

que reflejen con precisión su rol. En el ejemplo, todas las columnas tienen como
prefijo la palabra Departure (Salida) o Arrival (Llegada). Estos nombres aseguran
que los objetos visuales del informe, de forma predeterminada, tendrán etiquetas
autodescriptivas y no ambiguas. También mejora la experiencia de Preguntas y
respuestas, lo que permite a los usuarios escribir fácilmente sus preguntas.
6. Considere la posibilidad de agregar descripciones a las tablas realizadoras de roles.
(En el panel Fields [Campos], aparece una descripción en la información sobre
herramientas cuando el autor del informe mantiene el cursor sobre la tabla). De
este modo, puede comunicar los detalles de propagación de filtros adicionales a
los autores de informes.
Relaciones inactivas
En determinadas circunstancias, las relaciones inactivas pueden satisfacer necesidades
especiales de informes.
Ahora vamos a considerar los diferentes requisitos de modelo e informes:
Un modelo de ventas contiene una tabla Sales (Ventas) que tiene dos columnas de
fecha: OrderDate (Fecha de pedido) y ShipDate (Fecha de expedición).
Cada fila de la tabla Sales (Ventas) registra un solo pedido.
Los filtros de fecha casi siempre se aplican a la columna OrderDate (Fecha de
pedido), que siempre almacena una fecha válida.
Solo una medida requiere la propagación del filtro de fecha a la columna ShipDate
(Fecha de expedición), que puede contener espacios en blanco (hasta que se envíe
el pedido).
No hay ningún requisito para filtrar simultáneamente los periodos de fechas de
pedido y expedición (o filtrar por ellos).
Existen dos relaciones de modelo entre las tablas Sales (Ventas) y Date (Fecha). En la
tabla Sales (Ventas), las columnas OrderDate (Fecha de pedido) y ShipDate (Fecha de
expedición) se relacionan con la columna Date (Fecha) de la tabla Date (Fecha). En este
modelo, los dos roles de la tabla Date (Fecha) son la fecha de pedido y la fecha de
expedición. Es la relación con la columna OrderDate (Fecha de pedido) la que está
activa.
Las seis medidas, excepto una, deben filtrarse por la columna OrderDate (Fecha de
pedido). Sin embargo, la medida Orders Shipped (Pedidos expedidos) debe filtrarse por
la columna ShipDate (Fecha de envío).
Esta es la definición de la medida Orders (Pedidos). Simplemente cuenta las filas de la

tabla Sales (Ventas) en el contexto del filtro. Los filtros aplicados a la tabla Date (Fecha)
se propagarán a la columna OrderDate (Fecha de pedido).
DAX
Orders = COUNTROWS(Sales)
Esta es la definición de la medida Orders Shipped (Pedidos expedidos). Usa la función

DAX USERELATIONSHIP, que activa la propagación de filtros para una relación específica
solo durante la evaluación de la expresión. En este ejemplo, se usa la relación con la
columna ShipDate. (Fecha de expedición).
DAX
Orders Shipped =
CALCULATE(
COUNTROWS(Sales)
,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)
Este diseño de modelo permite generar el siguiente diseño de informe.
La página del informe filtra por Q4 (cuarto trimestre) de 2019. El objeto visual de la tabla
agrupa por mes y muestra varias estadísticas de ventas. Las medidas Orders (Pedidos) y
Orders Shipped (Pedidos expedidos) generan resultados diferentes. Cada una de ellas
usa la misma lógica de resumen (recuento de filas de la tabla Sales [Ventas]), pero una
diferente propagación del filtro de tabla Date (Fecha).
Observe que la segmentación del trimestre incluye un elemento en blanco. Este

elemento de segmentación aparece como resultado de la expansión de tabla. Aunque
cada fila de tabla Sales (Ventas) tiene una fecha de pedido, algunas filas tienen una
fecha de envío en blanco; estos pedidos todavía faltan por enviarse. La expansión de
tablas también tiene en cuenta las relaciones inactivas, por lo que pueden aparecer
espacios en blanco por haber espacios en blanco en la mayoría de la relación o debido a
problemas de integridad de los datos.
７ Nota
Los filtros de seguridad de nivel de fila solo se propagan a través de relaciones

activas. Los filtros de seguridad de nivel de fila no se propagarán para las relaciones
inactivas aunque UseRelationship se agregue explícitamente a una definición de
medida.
Recomendaciones
En resumen, se recomienda definir relaciones activas siempre que sea posible,
especialmente cuando se definen roles de seguridad de nivel de fila para el modelo de
datos. Amplían el ámbito y el potencial del modo en que los autores de informes y los
usuarios que trabajan con Preguntas y respuestas pueden usar el modelo. Esto implica
que las tablas de tipo de dimensión realizadoras de roles deben duplicarse en el
modelo.
Sin embargo, en determinadas circunstancias, puede definir una o varias relaciones

inactivas para una tabla de tipo de dimensión realizadora de roles. Puede plantearse el
uso de este diseño cuando:
No hay ningún requisito para que los objetos visuales de informes filtren
simultáneamente por roles diferentes.
La función DAX USERELATIONSHIP se usa para activar una relación específica para
los cálculos de modelos pertinentes.
Pasos siguientes
Instrucciones para relaciones
bidireccionales
Power BI Desktop. Le proporciona instrucciones sobre cuándo crear relaciones de
modelo bidireccionales. Una relación bidireccional es aquella que se filtra en ambas
direcciones.
７ Nota

Desktop.
Power BI.
En general, recomendamos minimizar el uso de relaciones bidireccionales. Pueden

afectar negativamente al rendimiento de la consulta del modelo y, posiblemente,
ofrecer experiencias confusas para los usuarios del informe.
Hay tres escenarios en los que el filtrado bidireccional puede resolver requisitos
específicos:
Relaciones de modelos especiales

Elementos de segmentación "con datos"
Análisis de dimensión a dimensión
Relaciones de modelos especiales

Las relaciones bidireccionales desempeñan un rol importante al crear los dos tipos de
relaciones de modelos especiales siguientes:
Uno a uno: todas las relaciones uno a uno deben ser bidireccionales; no es posible
ninguna otra configuración. En general, no recomendamos crear estos tipos de
relaciones. Para una descripción completa y diseños alternativos, vea Instrucciones
para relaciones uno a uno.
Varios a varios: cuando se relacionan dos tablas de tipo de dimensión, se requiere
una tabla de puente. Se requiere un filtro bidireccional para asegurarse de que los
filtros se propagan a través de la tabla de puente. Para más información, consulte
Instrucciones para relaciones de varios a varios (Relación de dimensiones varios a
varios).
Elementos de segmentación "con datos"

Las relaciones bidireccionales pueden ofrecer segmentaciones que limitan los elementos
a donde hay datos. (Si está familiarizado con las tablas dinámicas y las segmentaciones
de datos de Excel, es el comportamiento predeterminado cuando se obtienen datos de
un conjunto de datos de Power BI o de un modelo de Analysis Services). Para ayudar a
explicar lo que significa, considere primero el siguiente diagrama del modelo.
La primera tabla se denomina Customer y contiene tres columnas: Country-Region,

Customer y CustomerCode. La segunda tabla se denomina Product y contiene tres
columnas: Color, Product y SKU. La tercer tabla se denomina Sales y contiene cuatro
columnas: CustomerCode, OrderDate, Quantity y SKU. Las tablas Customer y Product
son tablas de tipo de dimensión y cada una tiene una relación uno a varios con la tabla
Sales. Cada relación filtra en una sola dirección.
Para facilitar la descripción de cómo funciona el filtrado bidireccional, se ha modificado

el diagrama del modelo para mostrar las filas de la tabla. Todos los ejemplos de este
artículo se basan en estos datos.
７ Nota
claros.
Los detalles de las filas de las tres tablas se describen en la siguiente lista con viñetas:
La tabla Customer tiene dos filas:

CustomerCode CUST-01, Customer Customer-1, Country-Region United States
CustomerCode CUST-02, Customer Customer-2, Country-Region Australia
La tabla Product tiene tres filas:
SKU CL-01, Product T-shirt, Color Green
SKU CL-02, Product Jeans, Color Blue
SKU AC-01, Product Hat, Color Blue
La tabla Sales tiene tres filas:
OrderDate January 1 2019, CustomerCode CUST-01, SKU CL-01, Quantity 10
OrderDate February 2 2019, CustomerCode CUST-01, SKU CL-02, Quantity 20
OrderDate March 3 2019, CustomerCode CUST-02, SKU CL-01, Quantity 30
Ahora suponga la siguiente página de informe.
La página se compone de dos segmentaciones y un objeto visual de tarjeta. La primera

segmentación es para Country-Region y tiene dos elementos: Australia y United States.
Actualmente se segmenta por Australia. La segunda segmentación es para Product y
tiene tres elementos: Hat, Jeans y T-shirt. No se selecciona ningún elemento (lo que
significa no se filtra ningún producto). El objeto visual muestra una cantidad de treinta.
Cuando los usuarios de informes se segmentan por Australia, es posible que desee
limitar la segmentación Producto para mostrar los elementos donde los datos se
relacionan con las ventas australianas. Es lo que significa mostrar elementos de
segmentación "con datos". Puede lograr este comportamiento configurando la relación
entre las tablas Product y Sales para filtrar en ambas direcciones.
La segmentación de Product ahora enumera un solo artículo: T-shirt. Este artículo

representa el único producto vendido a clientes australianos.
Primero le recomendamos que considere cuidadosamente si este diseño funciona para

los usuarios de su informe. Algunos usuarios de informes encuentran la experiencia
confusa. No entienden por qué los artículos de segmentación aparecen o desaparecen
dinámicamente cuando interactúan con otras segmentaciones.
Si decide mostrar elementos de segmentación "con datos", no le recomendamos que
configure relaciones bidireccionales. Las relaciones bidireccionales requieren más
procesamiento y, por lo tanto, pueden tener afectar negativamente al rendimiento de
las consultas, especialmente a medida que aumenta el número de relaciones
bidireccionales en el modelo.
Hay una mejor manera de lograr el mismo resultado: en lugar de usar filtros
bidireccionales, puede aplicar un filtro de nivel de objeto visual a la propia
segmentación de Product.
Consideremos ahora que la relación entre la tablas Product y Sales ya no se filtra en

ambas direcciones. Y, la siguiente definición de medida se ha agregado a la tabla Sales.
DAX
Total Quantity = SUM(Sales[Quantity])
Para mostrar los artículos de segmentación de Product "con datos", simplemente se

necesita filtrar por la medida Cantidad total usando la condición "no está en blanco".
Análisis de dimensión a dimensión

Un escenario diferente que involucra relaciones bidireccionales trata una tabla de tipo
de hecho como una tabla de puente. De esta forma, admite el análisis de datos de tabla
de tipo de dimensión dentro del contexto de filtro de una tabla de tipo de dimensión
diferente.
Mediante el modelo de ejemplo en este artículo, considere cómo se pueden responder
las siguientes preguntas:
¿Cuántos colores se vendieron a clientes australianos?

¿Cuántos países/regiones compraron pantalones vaqueros?
Ambas preguntas pueden responderse sin resumir los datos en la tabla de tipo de
hecho de puente. Sin embargo, requieren que los filtros se propaguen de una tabla de
tipo de dimensión a la otra. Una vez que los filtros se propagan a través de la tabla de
tipo de hecho, se puede lograr el resumen de las columnas de la tabla de tipo de
dimensión mediante la función DAX DISTINCTCOUNT, y posiblemente las funciones DAX
MIN y MAX.
Como la tabla de tipo de hecho se comporta como una tabla de puente, puede seguir
las instrucciones de relación de varios a varios para relacionar dos tablas de tipo de
dimensión. Será necesario configurar al menos una relación para filtrar en ambas
direcciones. Para más información, consulte Instrucciones para relaciones de varios a
varios (Relación de dimensiones varios a varios).
Sin embargo, como ya se describió en este artículo, es probable que este diseño tenga
un impacto negativo en el rendimiento y que el usuario experimente consecuencias
relacionadas con los elementos de segmentación "con datos". Por lo tanto, le
recomendamos que active el filtrado bidireccional en una definición de medida
utilizando la función DAX CROSSFILTER en su lugar. La función CROSSFILTER se puede
usar para modificar las direcciones del filtro (o incluso deshabilitar la relación), durante
la evaluación de una expresión.
Considere la siguiente definición de medida agregada a la tabla Sales. En este ejemplo,

la relación del modelo entre las tablas Customer y Sales se ha configurado para filtrar
en una sola dirección.
DAX
Different Countries Sold =

CALCULATE(
DISTINCTCOUNT(Customer[Country-Region]),
CROSSFILTER(
Customer[CustomerCode],
Sales[CustomerCode],
BOTH
)
)
Durante la evaluación de la expresión de medida Different Countries Sold, la relación

entre las tablas Customer y Sales se filtra en ambas direcciones.
El siguiente objeto visual de tabla presenta estadísticas para cada producto vendido. La
columna Quantity es simplemente la suma de los valores de cantidad. La columna
Different Countries Sold representa el recuento distintivo de los valores de país-región
de todos los clientes que han comprado el producto.
Pasos siguientes

Instrucciones para relaciones de varios a varios
Instrucciones para solución de
problemas de relaciones
Power BI Desktop. Proporciona instrucciones sobre cómo solucionar problemas
específicos que pueden surgir al desarrollar modelos e informes.
７ Nota

Desktop.
Power BI.
Solución de problemas
Cuando un objeto visual de informe está configurado para usar campos de dos (o más)
tablas y no presenta el resultado correcto (o ningún resultado), es posible que el
problema esté relacionado con las relaciones de modelo.
En este caso, se muestra una lista de comprobación de solución de problemas general

que se debe seguir. Puede avanzar por los pasos propuestos en la lista de
comprobación hasta que identifique los problemas.
1. Cambie el objeto visual a una tabla o matriz, o abra el panel "Ver datos" —es más
fácil solucionar problemas cuando puede ver el resultado de la consulta—.
2. Si hay un resultado de consulta vacío, cambie a la vista de datos: compruebe que
las tablas se han cargado con filas de datos.
3. Cambie a la vista de modelo: es fácil ver las relaciones y determinar rápidamente
sus propiedades.
4. Compruebe que existen relaciones entre las tablas.
5. Compruebe que las propiedades de cardinalidad están configuradas
correctamente: podrían ser incorrectas si una columna de "varios" contiene en este
momento valores únicos y se ha configurado incorrectamente como de "uno".
6. Compruebe que las relaciones están activas (línea continua).
7. Compruebe que las direcciones de los filtros admiten la propagación (interprete
los cabezales de las flechas).
8. Compruebe que las columnas correctas están relacionadas: seleccione la relación o
mantenga el cursor sobre ella para mostrar las columnas relacionadas.
9. Compruebe que los tipos de datos de columna relacionados son los mismos, o al
menos compatibles; es posible relacionar una columna de texto con una columna
de número entero, pero los filtros no encontrarán ninguna coincidencia para
propagarse.
10. Cambie a la vista de datos y compruebe que los valores coincidentes se pueden
encontrar en columnas relacionadas.
Guía de solución de problemas

Esta es una lista de problemas junto con las posibles soluciones.
Problema Posible motivo:
El objeto visual no muestra - El modelo todavía debe cargarse con datos.

resultados. - No existe ningún dato en el contexto de filtro.
- Se aplica la seguridad de nivel de fila.
- Las relaciones no se propagan entre tablas, siga la lista de
comprobación anterior.
- Se aplica la seguridad de nivel de fila, pero no se habilita
la propagación de una relación bidireccional; consulte
Seguridad de nivel de fila (RLS) con Power BI Desktop
El objeto visual muestra el mismo - Las relaciones no existen.

valor para cada agrupación. - Las relaciones no se propagan entre tablas, siga la lista de
comprobación anterior.
El objeto visual muestra los - El objeto visual no está configurado correctamente.

resultados, pero no son correctos. - La lógica de medida es incorrecta.
- Los datos del modelo deben actualizarse.
- Los datos del informe son incorrectos.
- Las columnas de relación están incorrectamente
relacionadas (por ejemplo, la columna ProductID se asigna
a CustomerID).
- Es una relación entre dos tablas de DirectQuery y la
columna "uno" de una relación contiene valores duplicados.
Problema Posible motivo:
Aparecen agrupaciones o - - Se trata de una relación normal y la columna "varios"

elementos de filtro o segmentación contiene valores que no se almacenan en la columna "uno";
en blanco y las columnas de origen vea Relaciones de modelos en Power BI Desktop
no contienen espacios en blanco. (Relaciones normales)
- Se trata de una relación de uno a uno normal y las
columnas relacionadas contienen espacios en blanco; vea
Relaciones de modelos en Power BI Desktop (Relaciones
normales)
- La columna "varios" de una relación inactiva almacena
valores en blanco o tiene valores que no están
almacenados en el lado "uno".
Faltan datos en el objeto visual. - Se aplican filtros incorrectos o inesperados.

- Se aplica la seguridad de nivel de fila.
- Se trata de una relación limitada y hay espacios en blanco
en las columnas relacionadas, o problemas de integridad de
datos; vea Relaciones de modelos en Power BI Desktop
(Relaciones limitadas)
- Se trata de una relación entre dos tablas DirectQuery, la
relación se configura para asumir la integridad referencial,
pero hay problemas de integridad de datos (valores no
coincidentes en las columnas relacionadas).
La seguridad de nivel de fila no se - Las relaciones no se propagan entre tablas, siga la lista de
aplica correctamente. comprobación anterior.
- Se aplica la seguridad de nivel de fila, pero no se habilita
la propagación de una relación bidireccional; consulte
Seguridad de nivel de fila (RLS) con Power BI Desktop
Pasos siguientes

Instrucciones del modelo de
DirectQuery en Power BI Desktop
Este artículo está destinado a los modeladores de datos que desarrollan modelos de
DirectQuery de Power BI, desarrollados mediante Power BI Desktop o el servicio
Power BI. Describe los casos de uso, las limitaciones y la guía de DirectQuery.
Específicamente, la guía está diseñada para ayudarle a determinar si DirectQuery es el
modo adecuado para el modelo y para mejorar el rendimiento de los informes basados
en modelos de DirectQuery. Este artículo se aplica a los modelos de DirectQuery
hospedados en el servicio Power BI o en Power BI Report Server.
Este artículo no pretende proporcionar una explicación completa sobre el diseño del
modelo de DirectQuery. Para obtener una introducción, consulte el artículo Modelos de
DirectQuery en Power BI Desktop. Para obtener una explicación más detallada, consulte
directamente las notas del producto en DirectQuery en SQL Server 2016 Analysis
Services . Tenga en cuenta que en las notas del producto se describe el uso de
DirectQuery en SQL Server Analysis Services. Sin embargo, gran parte del contenido es
aplicable a los modelos de DirectQuery de Power BI.
７ Nota
Para ver las consideraciones sobre el uso del modo de almacenamiento de

DirectQuery para Dataverse, consulte Guía de modelado de Power BI para Power
Platform.
Este artículo no aborda directamente los modelos compuestos. Un modelo compuesto

contendrá al menos un origen de DirectQuery y, posiblemente, más. Las instrucciones
descritas en este artículo siguen siendo adecuadas, al menos en parte, en el diseño del
modelo compuesto. Pero las implicaciones de combinar tablas de importación con
tablas de DirectQuery no están en el ámbito de este artículo. Para más información,
consulte Usar modelos compuestos en Power BI Desktop.
Es importante comprender que los modelos de DirectQuery imponen otra carga de

trabajo en el entorno de Power BI (servicio Power BI o Power BI Report Server) y también
en los orígenes de datos subyacentes. Si determina que DirectQuery es el enfoque de
diseño adecuado, se recomienda que incorpore a las personas adecuadas al proyecto. A
menudo vemos que una implementación correcta del modelo de DirectQuery es el
resultado de un equipo de profesionales de TI que trabaja en estrecha colaboración.
Normalmente, el equipo se compone de desarrolladores de modelos y administradores
de las bases de datos de origen. También puede implicar a los arquitectos de datos y a
los desarrolladores de almacenamiento de datos y ETL. A menudo, es necesario aplicar
optimizaciones directamente al origen de datos para lograr buenos resultados de
rendimiento.
Optimización del rendimiento del origen de

datos
El origen de base de datos relacional se puede optimizar de varias maneras, como se
describe en la lista con viñetas siguiente.
７ Nota
Somos conscientes de que no todos los modeladores tienen los permisos o las
aptitudes necesarias para optimizar una base de datos relacional. Aunque es la
capa preferida para preparar los datos para un modelo de DirectQuery, también se
pueden lograr algunas optimizaciones en el diseño del modelo sin modificar la
base de datos de origen. Sin embargo, a menudo se logran mejores resultados de
optimización con la aplicación de optimizaciones a la base de datos de origen.
Asegúrese de que se ha completado la integridad de los datos: es especialmente

importante que las tablas de tipo dimensión contengan una columna de valores
únicos (clave de dimensión) que se asigna a las tablas de tipo hechos. También es
importante que las columnas de dimensión de tipo hechos contengan valores de
clave de dimensión válidos. Permitirán configurar relaciones de modelo más
eficaces que esperan valores coincidentes en ambos lados de las relaciones.
Cuando los datos de origen no tienen integridad, se recomienda agregar un
registro de dimensión "desconocido" para reparar los datos de forma eficaz. Por
ejemplo, puede agregar una fila a la tabla Product para que represente un
producto desconocido y, a continuación, asignarle una clave fuera del intervalo,
como -1. Si las filas de la tabla Ventas contienen un valor de clave de producto que
falta, sustitúyalas por -1. Esto garantizará que cada valor de clave de producto de
la tabla Ventas tiene una fila correspondiente en la tabla Producto.
Adición de índices: defina los índices adecuados, en tablas o vistas, para posibilitar
una recuperación eficaz de los datos para el filtrado y la agrupación visual
esperada del informe. Para orígenes de SQL Server, Azure SQL Database o Azure
Synapse Analytics (anteriormente, SQL Data Warehouse), vea Guía de diseño y
arquitectura de índices de SQL Server para obtener información útil sobre
instrucciones de diseño de índices. Para orígenes volátiles de SQL Server o
Azure SQL Database, vea Introducción al almacén de columnas para el análisis
operativo en tiempo real.
Diseño de tablas distribuidas: en el caso de los orígenes de Azure Synapse

Analytics (anteriormente, SQL Data Warehouse), que aprovechan la arquitectura de
procesamiento paralelo masivo (MPP), considere la posibilidad de configurar tablas
de tipo hechos grandes como tablas distribuidas por hash y tablas de tipo
dimensión para replicar en todos los nodos de proceso. Para más información, vea
Instrucciones para el diseño de tablas distribuidas en Azure Synapse Analytics
(anteriormente, SQL Data Warehouse).
Asegúrese de que se materializan las transformaciones de datos necesarias: para

orígenes de bases de datos relacionales de SQL Server (y otros orígenes de bases
de datos relacionales), se pueden agregar columnas calculadas a las tablas. Estas
columnas se basan en una expresión, como Cantidad multiplicado por
PrecioUnitario. Las columnas calculadas se pueden guardar (materializar) y, al
igual que las columnas normales, en ocasiones se pueden indexar. Para más
información, vea Índices en columnas calculadas.
Considere también el uso de vistas indexadas, que pueden agregar previamente

los datos de la tabla de hechos con un nivel de detalle más alto. Por ejemplo, si la
tabla Ventas almacena datos en el nivel de línea de pedido, puede crear una vista
para resumir estos datos. La vista se podría basar en una instrucción SELECT que
agrupa los datos de la tabla Ventas por fecha (en el nivel de mes), cliente y
producto, y resume los valores de medida como ventas, cantidad, etc. A
continuación, se puede indexar la vista. Para orígenes de SQL Server o
Azure SQL Database, vea Creación de vistas indexadas.
Materializar una tabla de fechas: un requisito común de modelado implica la

adición de una tabla de fechas para admitir el filtrado basado en el tiempo. Para
admitir los filtros basados en el tiempo conocidos de la organización, cree una
tabla en la base de datos de origen y asegúrese de que se carga con un intervalo
de fechas que abarcan las fechas de la tabla de hechos. Asegúrese también de que
incluye columnas para períodos de tiempo útiles, como año, trimestre, mes,
semana, etc.
Optimización del diseño del modelo

Un modelo de DirectQuery se puede optimizar de muchas maneras, como se describe
en la lista con viñetas siguiente.
Evitar consultas complejas de Power Query: se puede lograr un diseño de modelo
eficaz mediante la eliminación de la necesidad de que las consultas de
Power Query apliquen transformaciones. Esto significa que cada consulta se asigna
a una sola tabla o vista del origen de base de datos relacional. Puede obtener una
vista previa de una representación de la instrucción de la consulta SQL real
correspondiente a un paso aplicado de Power Query; para ello, seleccione la
opción Ver consulta nativa.
Examinar el uso de las columnas calculadas y los cambios de tipo de datos: los
modelos de DirectQuery admiten la adición de cálculos y pasos de Power Query
para convertir tipos de datos. Sin embargo, a menudo se consigue un mejor
rendimiento al materializar los resultados de la transformación en el origen de
base de datos relacional, siempre que sea posible.
No usar el filtrado de fechas relativas de Power Query: es posible definir el

filtrado de fechas relativas en una consulta de Power Query. Por ejemplo, para
recuperar los pedidos de ventas creados en el último año (con respecto a la fecha
de hoy). Este tipo de filtro se traduce en una consulta nativa ineficaz, como se
indica a continuación:
SQL
…
from [dbo].[Sales] as [_]
where [_].[OrderDate] >= convert(datetime2, '2018-01-01 00:00:00') and
[_].[OrderDate] < convert(datetime2, '2019-01-01 00:00:00'))
Un enfoque de diseño mejor consiste en incluir columnas de tiempo relativas en la

tabla de fechas. Estas columnas almacenan valores de desplazamiento en relación
con la fecha actual. Por ejemplo, en la columna RelativeYear (Año relativo), el valor
cero representa el año actual, -1 representa el año anterior, etc. Es preferible que la
columna RelativeYear se materialice en la tabla de fechas. Aunque es menos eficaz,
también se podría agregar como una columna calculada del modelo, en función de
la expresión con las funciones de DAX TODAY y DATE.
Simplificar las medidas: al menos inicialmente, se recomienda limitar las medidas

a agregados simples. Las funciones de agregado incluyen SUM, COUNT, MIN, MAX
y AVERAGE. Después, si las medidas tienen la suficiente capacidad de respuesta,
puede experimentar con medidas más complejas, pero se debe prestar atención al
rendimiento de cada una. Aunque la función DAX CALCULATE se puede usar para
generar expresiones de medida sofisticadas que manipulan el contexto del filtro,
pueden generar consultas nativas costosas que no tienen buen rendimiento.
Evitar relaciones en las columnas calculadas: las relaciones del modelo solo
pueden relacionar una sola columna de una tabla con una sola columna de otra
tabla. Sin embargo, a veces es necesario relacionar las tablas mediante el uso de
varias columnas. Por ejemplo, las tablas Ventas y Geografía se relacionan con dos
columnas: PaísRegión y Ciudad. Para crear una relación entre las tablas, se
requiere una sola columna y, en la tabla Geografía, la columna debe contener
valores únicos. La concatenación del país o región y la ciudad con un guión
separador podría conseguir este resultado.
La columna combinada se puede crear con una columna personalizada de

Power Query o bien en el modelo como una columna calculada. Pero se debe
evitar, ya que la expresión de cálculo se insertará en las consultas de origen. No
solo es ineficaz, sino que normalmente impide el uso de índices. En su lugar,
agregue columnas materializadas en el origen de base de datos relacional y
considere la posibilidad de indexarlas. También puede considerar la posibilidad de
agregar columnas de clave suplente a las tablas de tipo dimensión, que es una
práctica común en los diseños de almacenamientos de datos relacionales.
Hay una excepción a esta guía y se refiere al uso de la función de DAX

COMBINEVALUES. El propósito de esta función es admitir relaciones de varias
columnas en el modelo. En lugar de generar una expresión que la relación utilizará,
genera un predicado de combinación SQL de varias columnas.
Evitar las relaciones en columnas de "identificador único": Power BI no admite de

forma nativa el tipo de datos de identificador único (GUID). Al definir una relación
entre columnas de este tipo, Power BI generará una consulta de origen con una
combinación que implica una conversión. Esta conversión de datos en tiempo de
consulta suele provocar un rendimiento deficiente. Hasta que este caso se
optimice, la única solución es materializar columnas de un tipo de datos
alternativo en la base de datos subyacente.
Ocultar la columna del lado uno de las relaciones: se debe ocultar la columna del
lado uno de una relación. (Normalmente, es la columna de clave principal de las
tablas de tipo de dimensión). Cuando está oculta, no está disponible en el panel
Campos y, por tanto, no se puede usar para configurar un objeto visual. La
columna del lado varios puede estar visible si resulta útil para agrupar o filtrar los
informes por los valores de columna. Por ejemplo, considere un modelo en el que
existe una relación entre las tablas Ventas y Producto. Las columnas de la relación
contienen valores de SKU (Unidades de stock) del producto. Si se debe agregar el
valor de SKU del producto a los objetos visuales, debe ser visible solo en la tabla
Ventas. Cuando esta columna se usa para filtrar o agrupar en un objeto visual,
Power BI generará una consulta que no necesita combinar las tablas Ventas y
Producto.
Establecer relaciones para aplicar la integridad: la propiedad Asumir integridad

referencial de las relaciones de DirectQuery determina si Power BI generará
consultas del origen mediante una combinación interna en lugar de una
combinación externa. Normalmente, esto mejora el rendimiento de las consultas,
aunque depende de los detalles específicos del origen de base de datos relacional.
Para más información, vea Configuración de Asumir integridad referencial en
Power BI Desktop.
Evitar el uso del filtrado de relaciones bidireccional: El uso del filtrado de

relaciones bidireccional puede conducir a instrucciones de consulta que no tienen
buen rendimiento. Use esta característica de la relación solo cuando sea necesario,
como es habitual al implementar una relación de varios a varios en una tabla
puente. Para más información, vea Relaciones con una cardinalidad de varios a
varios en Power BI Desktop.
Limitar las consultas paralelas: puede establecer el número máximo de

conexiones que abre DirectQuery para cada origen de datos subyacente. Controla
el número de consultas que se envían de forma simultánea al origen de datos.
La configuración solo está habilitada cuando hay al menos un origen de
DirectQuery en el modelo. El valor se aplica a todos los orígenes de DirectQuery y
a los nuevos orígenes de DirectQuery agregados al modelo.
El aumento del valor de Conexiones máximas por origen de datos garantiza que
se puedan enviar más consultas (hasta el número máximo especificado) al origen
de datos subyacente, lo que resulta útil cuando hay muchos objetos visuales en
una sola página o bien cuando muchos usuarios acceden a un informe al mismo
tiempo. Una vez alcanzado el número máximo de conexiones, las consultas
siguientes se ponen en cola hasta que haya disponible una conexión. El aumento
de este límite tiene como resultado más carga en el origen de datos subyacente,
por lo que la configuración no garantiza que mejore el rendimiento general.
Cuando el modelo se publica en Power BI, el número máximo de consultas

simultáneas enviadas al origen de datos subyacente también depende del entorno.
Los distintos entornos (como Power BI, Power BI Premium o Power BI Report
Server) pueden imponer diferentes restricciones de rendimiento. Para más
información sobre las limitaciones de los recursos de capacidad Premium de
Power BI, vea Implementación y administración de capacidades Premium de
Power BI.
Optimización de los diseños de informes

Los informes basados en un conjunto de datos de DirectQuery se pueden optimizar de
muchas maneras, como se describe en la lista con viñetas siguiente.
Habilitar técnicas de reducción de consultas: en Opciones y configuración de

Power BI Desktop se incluye una página Reducción de consulta. Esta página tiene
tres opciones útiles. Se puede deshabilitar el resaltado cruzado y el filtrado
cruzado de forma predeterminada, aunque esto se puede invalidar mediante la
edición de interacciones. También es posible mostrar un botón Aplicar en las
segmentaciones y los filtros. Las opciones de segmentación o filtro no se aplicarán
hasta que el usuario del informe haga clic en el botón. Si habilita estas opciones, se
recomienda que lo haga al crear el informe por primera vez.
Aplique primero los filtros: al diseñar los informes por primera vez, se recomienda
aplicar los filtros correspondientes (en el nivel de informe, página u objeto visual)
antes de asignar campos a los campos del objeto visual. Por ejemplo, en lugar de
arrastrar las medidas PaísRegión y Ventas y, a continuación, filtrar por un año
determinado, aplique primero el filtro en el campo Año. Se debe a que cada paso
de la creación de un objeto visual enviará una consulta y, aunque es posible
realizar otro cambio antes de que se complete la primera consulta, se crea una
carga innecesaria en el origen de datos subyacente. Al aplicar los filtros al
principio, normalmente las consultas intermedias se convierten en menos costosas
y más rápidas. Además, si no se aplican los filtros temprano, se puede superar el
límite de un millón de filas, como se ha descrito en Sobre DirectQuery.
Limite la cantidad de objetos visuales de una página: Cuando se abre una página
del informe (y cuando se aplican los filtros de la página), se actualizan todos los
objetos visuales de dicha página. Sin embargo, hay un límite en el número de
consultas que se pueden enviar en paralelo, impuestas por el entorno de Power BI
y la configuración Conexiones máximas por origen de datos del modelo, como se
ha descrito anteriormente. Por lo tanto, a medida que aumenta el número de
objetos visuales de la página, es más probable que se actualicen en serie. Esto
aumenta el tiempo necesario para actualizar toda la página y también la
posibilidad de que los objetos visuales puedan mostrar resultados incoherentes
(para orígenes de datos volátiles). Por estos motivos, se recomienda limitar el
número de objetos visuales de cualquier página y, en su lugar, tener páginas más
sencillas. El reemplazo de varios objetos visuales de tarjeta por un solo objeto
visual de tarjeta de varias filas puede lograr un diseño de página similar.
Desactivar la interacción entre objetos visuales: las interacciones de resaltado

cruzado y de filtrado cruzado requieren el envío de consultas al origen subyacente.
A menos que estas interacciones sean necesarias, se recomienda que se desactiven
si el tiempo que se tarda en responder a las selecciones de los usuarios es
demasiado largo. Estas interacciones se pueden desactivar, ya sea para todo el
informe (como se ha descrito antes para las opciones de reducción de consulta), o
bien caso por caso. Para más información, vea Aplicación de un filtro cruzado entre
objetos visuales de un informe de Power BI.
Además de la lista anterior de técnicas de optimización, cada una de las funcionalidades

de informes siguientes puede contribuir a los problemas de rendimiento:
Filtros de medidas: los objetos visuales que contienen medidas (o agregados de

columnas) pueden tener filtros aplicados a dichas medidas. Por ejemplo, el objeto
visual siguiente muestra Sales (Ventas) por Category (Categoría), pero solo para
aquellas categorías con más de 15 millones de dolares de ventas.
Esto puede dar lugar a que se envíen dos consultas al origen subyacente:
La primera consulta recuperará las categorías que cumplen la condición (Ventas
> 15 millones de dólares)
La segunda consulta recuperará los datos necesarios para el objeto visual,
agregando las categorías que cumplen la condición a la cláusula WHERE
Por lo general tiene un buen rendimiento si existen cientos o miles de categorías,

como en este ejemplo. Pero el rendimiento se puede degradar si el número de
categorías es mucho mayor (y, de hecho, la consulta generará un error si hay más
de un millón de categorías que cumplen la condición, debido al límite de un millón
de filas descrito antes).
Filtros TopN: se pueden definir filtros avanzados para filtrar solo los N valores
superiores (o inferiores) clasificados por una medida. Por ejemplo, para mostrar
solo las cinco categorías principales del objeto visual anterior. Como sucede con
los filtros de medida, esto también da lugar a que se envíen dos consultas al
origen de datos subyacente. Sin embargo, la primera consulta devolverá todas las
categorías del origen subyacente y, luego, se determinan los N valores principales
según los resultados devueltos. En función de la cardinalidad de la columna en
cuestión, esto puede generar problemas de rendimiento (o errores de consulta
debido al límite de un millón de filas).
Mediana: Por lo general, cualquier agregación (SUM, COUNT, DISTINCT, etc.) se

envía al origen subyacente. Pero esto no sucede con Mediana, ya que
habitualmente este agregado no es compatible con el origen subyacente. En tales
casos, los datos detallados se recuperan del origen subyacente y Power BI evalúa la
mediana a partir de los resultados devueltos. Es correcto cuando la mediana se va
a calcular sobre un número relativamente pequeño de resultados, pero se
producirán problemas de rendimiento (o errores en la consulta debido al límite de
un millón de filas) si la cardinalidad es grande. Por ejemplo, el valor medio de la
población de un país o región puede ser razonable, pero el valor medio del precio
de ventas podría no serlo.
Segmentaciones de selección múltiple: permitir la selección múltiple en

segmentaciones y filtros puede causar problemas de rendimiento. Esto se debe a
que, a medida que el usuario selecciona elementos adicionales de la segmentación
(por ejemplo, al crear los diez productos que le interesan), cada nueva selección
genera el envío de una nueva consulta al origen subyacente. Aunque el usuario
pueda seleccionar el elemento siguiente antes de que se complete la consulta, el
resultado es una carga adicional en el origen subyacente. Esta situación se puede
evitar si se muestra el botón Aplicar, tal como se ha descrito anteriormente en las
técnicas de reducción de consultas.
Totales visuales: de forma predeterminada, las tablas y matrices muestran los

totales y subtotales. En muchos casos, se deben enviar consultas adicionales al
origen subyacente para obtener los valores de los totales. Esto se aplica cada vez
que se usan los agregados Count, Distinct o Median, y en todos los casos en los
que se usa DirectQuery en SAP HANA o SAP Business Warehouse. Estos totales
deben desactivarse (mediante el panel Formato) si no son necesarios.
Conversión a un modelo compuesto

Las ventajas de los modelos de importación y de DirectQuery se pueden combinar en
un único modelo mediante la configuración del modo de almacenamiento de las tablas
del modelo. El modo de almacenamiento de las tablas puede ser Importar, DirectQuery
o ambos, conocido como Dual. Cuando un modelo contiene tablas con modos de
almacenamiento diferentes, se conoce como modelo compuesto. Para más información,
consulte Usar modelos compuestos en Power BI Desktop.
Hay muchas mejoras funcionales y de rendimiento que se pueden lograr mediante la

conversión de un modelo de DirectQuery en un modelo compuesto. Un modelo
compuesto puede integrar más de un origen de DirectQuery y también puede incluir
agregaciones. Las tablas de agregación se pueden agregar a las tablas de DirectQuery
para importar una representación resumida de la tabla. Pueden conseguir importantes
mejoras de rendimiento cuando los objetos visuales consultan agregados de nivel
superior. Para más información, vea Agregaciones en Power BI Desktop.
Educación de los usuarios
Es importante educar a los usuarios sobre cómo trabajar de forma eficaz con los
informes basados en conjuntos de datos de DirectQuery. Los autores de informes deben
instruirse en el contenido que se describe en la sección Optimización de los diseños de
informes.
Se recomienda educar a los consumidores del informe sobre los informes que se basan
en conjuntos de datos de DirectQuery. Puede resultarles útil comprender la arquitectura
de datos general, incluidas las limitaciones pertinentes que se describen en este artículo.
Hágales saber que las respuestas de actualización y el filtrado interactivo pueden ser
lentos en ocasiones. Cuando los usuarios de los informes entienden por qué se produce
la degradación en el rendimiento, es menos probable que pierdan confianza en los
informes y los datos.
Al entregar informes sobre orígenes de datos volátiles, asegúrese de educar a los

usuarios de los informes sobre el uso del botón Actualizar. Indíqueles que también
podrían ver resultados incoherentes y que una actualización del informe puede resolver
las incoherencias de la página del informe.
Pasos siguientes
Para más información acerca de DirectQuery, revise los siguientes recursos:
Modelos de DirectQuery en Power BI Desktop

Usar DirectQuery en Power BI Desktop
Solución de problemas del modelo de DirectQuery en Power BI Desktop
Guía de modelos compuestos de
Power BI Desktop
Este artículo va dirigido a los modeladores de datos que desarrollan modelos

compuestos de Power BI. En él se describen los casos de uso de modelos compuestos y
se proporciona una guía de diseño. En concreto, la guía puede ayudarle a determinar si
un modelo compuesto es adecuado para su solución. En caso afirmativo, este artículo
también le ayudará a diseñar modelo compuestos e informes óptimos.
７ Nota
El artículo no incluye una introducción a los modelos compuestos. Si no está

totalmente familiarizado con los modelos compuestos, le recomendamos que
primero lea el artículo Usar modelos compuestos en Power BI Desktop.
Dado que los modelos compuestos constan de al menos un origen de DirectQuery,

también es importante comprender perfectamente las relaciones del modelo, los
modelos de DirectQuery y la guía de diseño de modelos de DirectQuery.
Casos de uso del modelo compuesto

Por definición, un modelo compuesto combina varios grupos de orígenes. Un grupo de
orígenes puede representar datos importados o una conexión a un origen de
DirectQuery. Un origen de DirectQuery puede ser una base de datos relacional u otro
modelo tabular, que puede ser un conjunto de datos de Power BI o un modelo tabular
de Analysis Services. Cuando un modelo tabular se conecta a otro modelo tabular, se
conoce como encadenamiento. Para más información, consulte Uso de DirectQuery para
conjuntos de datos de Power BI y Analysis Services.
７ Nota
Cuando un modelo se conecta a un modelo tabular, pero no lo extiende con datos

adicionales, no es un modelo compuesto. En este caso, es un modelo de
DirectQuery que se conecta a un modelo remoto, por lo que consta solo del grupo
de orígenes. Puede crear este tipo de modelo para modificar las propiedades de los
objetos del modelo de origen, como un nombre de tabla, un criterio de ordenación
de columnas o una cadena de formato.
La conexión a modelos tabulares es especialmente interesante al extender un modelo
semántico empresarial (cuando se trata de un conjunto de datos de Power BI o un
modelo de Analysis Services). Un modelo semántico empresarial es fundamental para el
desarrollo y el funcionamiento de un almacenamiento de datos. Proporciona una capa
de abstracción sobre los datos del almacenamiento de datos para presentar definiciones
y terminología de negocio. Normalmente se usa como vínculo entre los modelos de
datos físicos y las herramientas de informes, como Power BI. En la mayoría de las
organizaciones, se administra mediante un equipo central y por eso se describe como
empresarial. Para más información, consulte el escenario de uso de BI empresarial.
Además, puede considerar el desarrollo de un modelo compuesto en las siguientes

situaciones.
El modelo podría ser un modelo de DirectQuery, pero quiere mejorar el

rendimiento. En un modelo compuesto, puede mejorar el rendimiento
configurando el almacenamiento adecuado para cada tabla. También puede
incorporar agregaciones definidas por el usuario. Estas dos optimizaciones se
describen más adelante en este artículo.
Quiere combinar un modelo de DirectQuery con datos adicionales, que se deben
importar en el modelo. Los datos importados se pueden cargar desde un origen
de datos diferente o desde tablas calculadas.
Desea combinar dos o más orígenes de datos DirectQuery en un único modelo.
Estos orígenes podrían ser bases de datos relacionales u otros modelos tabulares.
７ Nota
Los modelos compuestos no pueden incluir conexiones a determinadas bases de

datos analíticas externas. Entre estas bases de datos se incluyen SAP Business
Warehouse y SAP HANA cuando se trata SAP HANA como un origen
multidimensional.
Evaluación de otras opciones de diseño de

modelos
Aunque los modelos compuestos de Power BI pueden resolver desafíos de diseño
concretos, pueden contribuir a ralentizar el rendimiento. Además, en algunas
situaciones, pueden producirse resultados de cálculo inesperados (descritos más
adelante en este artículo). Por estos motivos, evalúe otras opciones de diseño de
modelos cuando existan.
Siempre que sea posible, es mejor desarrollar un modelo en modo de importación. Este
modo proporciona la mayor flexibilidad de diseño y el mejor rendimiento.
Sin embargo, los modelos de importación no pueden resolver los desafíos relacionados
con grandes volúmenes de datos o con la generación de informes sobre datos casi en
tiempo real. En cualquiera de estos casos, puede considerar un modelo DirectQuery,
siempre y cuando los datos se almacenen en un único origen de datos que sea
compatible con el modo DirectQuery. Para más información, consulte Modelos de
DirectQuery en Power BI Desktop.
 Sugerencia
Si el objetivo es ampliar un modelo tabular existente con más datos, siempre que
sea posible, agregue esos datos al origen de datos existente.
Modo Table Storage

En un modelo compuesto, puede configurar el modo de almacenamiento de cada tabla
(excepto las tablas calculadas).
DirectQuery: se recomienda establecer este modo para las tablas que representan
grandes volúmenes de datos o que deben proporcionar resultados casi en tiempo
real. Los datos nunca se importarán en estas tablas. Normalmente, estas tablas
serán tablas de tipo hechos, que son tablas que se resumen.
Importación: se recomienda establecer este modo para las tablas que no se usan
para el filtrado y la agrupación de tablas de hechos en modo híbrido o
DirectQuery. También es la única opción para las tablas basadas en orígenes no
compatibles con el modo DirectQuery. Las tablas calculadas siempre son tablas de
importación.
Dual: se recomienda establecer este modo para las tablas de tipo dimensión,
cuando exista la posibilidad de que se realicen consultas en ellas junto con las
tablas de tipo hechos de DirectQuery del mismo origen.
Híbrido: se recomienda configurar este modo agregando particiones de
importación y una partición de DirectQuery a una tabla de hechos cuando quiera
incluir los cambios de datos más recientes en tiempo real, o bien proporcionar
acceso rápido a los datos usados con más frecuencia mediante particiones de
importación, pero quiera dejar la mayor parte de los datos usados con menos
frecuencia en el almacenamiento de datos.
Hay varios escenarios posibles cuando Power BI consulta un modelo compuesto.

Consulta solo tablas de importación o duales: Power BI recupera todos los datos
de la caché del modelo. Este escenario proporcionará el rendimiento más rápido
posible. Es común para las tablas de tipo dimensión consultadas mediante filtros u
objetos visuales de segmentación de datos.
Consulta tablas duales o tablas de DirectQuery del mismo origen: Power BI
recupera todos los datos mediante el envío de una o varias consultas nativas al
origen de DirectQuery. Este escenario proporcionará un rendimiento óptimo,
especialmente cuando existan índices adecuados en las tablas de origen. Este
escenario es común para las consultas que relacionan tablas duales de tipo
dimensión y tablas de DirectQuery de tipo hechos. Estas consultas son intragrupo
de origen y, por tanto, todas las relaciones de uno a uno o de uno a varios se
evalúan como relaciones normales.
Consulta tablas duales o híbridas del mismo origen: este escenario es una
combinación de los dos escenarios anteriores. Power BI recupera datos de la caché
de modelos cuando está disponible en las particiones de importación; de lo
contrario, envía una o varias consultas nativas al origen de DirectQuery. Este
escenario proporcionará el rendimiento más rápido posible, ya que solo se
consulta un segmento de datos en el almacenamiento de datos, especialmente
cuando existan índices adecuados en las tablas de origen. En cuanto a las tablas
duales de tipo dimensión y las tablas DirectQuery de tipo hechos, estas consultas
son intragrupo, por lo que todas las relaciones uno a uno o uno a varios se evalúan
como relaciones normales.
Todas las demás consultas: estas consultas implican relaciones entre grupos de
origen. O bien porque una tabla de importación se relaciona con una tabla de
DirectQuery o una tabla dual se relaciona con una tabla de DirectQuery de un
origen diferente, en cuyo caso se comporta como una tabla de importación. Todas
las relaciones se evalúan como relaciones limitadas. También significa que las
agrupaciones aplicadas a tablas que no son DirectQuery deben enviarse al origen
de DirectQuery como subconsultas materializadas. En este caso, la consulta nativa
puede ser ineficaz, en especial con conjuntos de agrupamiento grandes.
En resumen, se recomienda que:
Considere detenidamente que un modelo compuesto sea la solución correcta: si

bien permite la integración de nivel de modelo de distintos orígenes de datos,
también presenta complejidades de diseño con posibles consecuencias (que se
describen más adelante en este artículo).
Establezca el modo de almacenamiento en DirectQuery cuando una tabla sea una
tabla de tipo hechos que almacene grandes volúmenes de datos, o cuando
necesite ofrecer resultados casi en tiempo real.
Considere la posibilidad de usar el modo híbrido definiendo una directiva de
actualización incremental y datos en tiempo real, o creando particiones de la tabla
de hechos mediante TOM, TMSL o una herramienta de terceros. Para más
información, consulte Actualización incremental y datos en tiempo real para
conjuntos de datos y el escenario de uso Administración avanzada de modelos de
datos.
Establezca el modo de almacenamiento en Dual cuando una tabla sea una tabla de
tipo dimensión y se vaya a consultar junto con tablas de DirectQuery o híbridas de
tipo hechos que están en el mismo origen.
Configure las frecuencias de actualización adecuadas para mantener sincronizada
la caché de modelos de tablas duales e híbridas (y las tablas calculadas
dependientes) con las bases de datos de origen.
Asegúrese de garantizar la integridad de los datos entre grupos de orígenes
(incluida la caché de modelos) porque relaciones limitadas eliminarán las filas de
los resultados de la consulta cuando los valores de columna relacionados no
coincidan.
Siempre que sea posible, optimice los orígenes de datos de DirectQuery con los
índices adecuados para conseguir combinaciones, filtrados y agrupaciones
eficaces.
Agregaciones definidas por el usuario

Puede incorporar agregaciones definidas por el usuario a tablas de DirectQuery. Su
finalidad es mejorar el rendimiento de las consultas de más alto nivel de detalle.
Cuando se almacenan en caché agregaciones en el modelo, se comportan como tablas

de importación (aunque no se pueden usar como una tabla de modelo). Incorporar
agregaciones de importación a un modelo de DirectQuery dará como resultado un
modelo compuesto.
７ Nota
Las tablas híbridas no admiten agregaciones porque algunas de las particiones

funcionan en modo de importación. No es posible incorporar agregaciones a nivel
de particiones de DirectQuery individuales.
Se recomienda que una agregación siga una regla básica: su recuento de filas debe ser
al menos un factor de 10 inferior a la tabla subyacente. Por ejemplo, si la tabla
subyacente almacena mil millones de filas, la tabla de agregación no debe superar los
100 millones de filas. Esta regla garantiza una ganancia de rendimiento adecuada en
relación con el costo de la creación y el mantenimiento de la agregación.
Relaciones entre grupos de origen

Cuando una relación de modelos abarca grupos de orígenes, se conoce como una
relación de grupo entre orígenes. Las relaciones de grupos entre orígenes también son
relaciones limitadas porque no hay ningún lado "uno" garantizado. Para más
información, vea Evaluación de las relaciones.
７ Nota
En algunas situaciones, puede evitar la creación de una relación de grupo entre

orígenes. Consulte el tema Uso de segmentaciones de sincronización más
adelante en este artículo.
Al definir relaciones de grupo entre orígenes, tenga en cuenta las siguientes

recomendaciones.
Use columnas de relación de cardinalidad baja: para obtener el mejor

rendimiento, se recomienda que las columnas de relación sean de cardinalidad
baja, lo que significa que deben almacenar menos de 50 000 valores únicos. Esta
recomendación es especialmente cierta al combinar modelos tabulares y para
columnas que no son de texto.
Evite el uso de columnas de relación de texto grandes: si debe usar columnas de
texto en una relación, calcule la longitud de texto esperada para el filtro
multiplicando la cardinalidad por la longitud media de la columna de texto. La
longitud de texto posible no debe superar el 1 000 000 de caracteres.
Aumente la granularidad de la relación: si es posible, cree relaciones con un nivel
superior de granularidad. Por ejemplo, en lugar de relacionar una tabla de fechas
en su clave de fecha, use mejor su clave de mes. Este enfoque de diseño requiere
que la tabla relacionada incluya una columna de clave de mes y los informes no
podrán mostrar hechos diarios.
Esfuércese por lograr un diseño de relación simple: cree solo una relación de
grupo entre orígenes cuando sea necesario e intente limitar el número de tablas
de la ruta de acceso de relación. Este enfoque de diseño ayudará a mejorar el
rendimiento y evitar rutas de acceso de relación ambiguas.
２ Advertencia
Dado que Power BI Desktop no valida exhaustivamente las relaciones entre grupos,
es posible crear relaciones ambiguas.
Escenario de relación de grupos entre orígenes 1

Considere un escenario de un diseño de relaciones complejas y cómo podría producir
resultados diferentes, pero válidos.
En este escenario, la tabla Region del grupo de orígenes A tiene una relación con la
tabla Date y la tabla Sales del grupo de orígenes B. La relación entre la tabla Region y la
tabla Date está activa, mientras que la relación entre la tabla Region y la tabla Sales está
inactiva. Además, hay una relación activa entre la tabla Region y la tabla Sales, ambas de
las cuales están en el grupo de orígenes B. La tabla Sales incluye una medida
denominada TotalSales y la tabla Region incluye dos medidas llamadas RegionalSales y
RegionalSalesDirect.
Estas son las definiciones de medida.
DAX
TotalSales = SUM(Sales[Sales])
RegionalSales = CALCULATE([TotalSales], USERELATIONSHIP(Region[RegionID],
Sales[RegionID]))
RegionalSalesDirect = CALCULATE(SUM(Sales[Sales]),
USERELATIONSHIP(Region[RegionID], Sales[RegionID]))
Observe cómo la medida RegionalSales hace referencia a la medida TotalSales, mientras

que la medida RegionalSalesDirect no. En su lugar, la medida RegionalSalesDirect usa
la expresión SUM(Sales[Sales]) , que es la expresión de la medida TotalSales.
La diferencia en el resultado es sutil. Cuando Power BI evalúa la medida RegionalSales,

aplica el filtro de la tabla Region a la tabla Sales y a la tabla Date. Por lo tanto, el filtro
también se propaga de la tabla Date a la tabla Sales. Por el contrario, cuando Power BI
evalúa la medida RegionalSalesDirect, solo se propaga el filtro de la tabla Region a la
tabla Sales. Los resultados devueltos por la medida RegionalSales y la medida
RegionalSalesDirect podrían diferir, aunque las expresiones sean semánticamente
equivalentes.
） Importante
Siempre que use la función CALCULATE con una expresión que sea una medida en
un grupo de orígenes remoto, pruebe los resultados del cálculo exhaustivamente.

Considere un escenario en el que una relación de grupo entre orígenes tiene columnas
de relación de cardinalidad alta.
En este escenario, la tabla Date está relacionada con la tabla Sales en las columnas
DateKey. El tipo de datos de las columnas DateKey es entero, y almacena números
enteros que usan el formato aaaammdd. Las tablas pertenecen a diferentes grupos de
orígenes. Además, es una relación de cardinalidad alta porque la fecha más antigua de
la tabla Date es el 1 de enero de 1900 y la fecha más reciente es el 31 de diciembre de
2100, por lo que hay un total de 73 414 filas en la tabla (una fila para cada fecha en el
intervalo de tiempo 1900-2100).
Hay dos problemas.
En primer lugar, cuando use las columnas de la tabla Date como filtros, la propagación
del filtro hará que se filtre la columna DateKey de la tabla Sales para evaluar las
medidas. Al filtrar por un solo año, como 2022, la consulta DAX incluirá una expresión
de filtro como Sales[DateKey] IN { 20220101, 20220102, …20221231 } . El tamaño de
texto de la consulta puede crecer hasta llegar a ser extremadamente grande cuando el
número de valores de la expresión de filtro es grande o cuando los valores de filtro son
cadenas largas. Para Power BI resulta costoso generar la consulta larga y para el origen
de datos ejecutar la consulta.
En segundo lugar, cuando se usan columnas de la tabla Date (como Year, Quarter o
Month) como columnas de agrupación, se traducen en filtros que incluyen todas las
combinaciones únicas de año, trimestre o mes y los valores de la columna DateKey. El
tamaño de cadena de la consulta, que contiene filtros en las columnas de agrupación y
la columna de relación, puede ser extremadamente grande. Esto es especialmente cierto
cuando el número de columnas de agrupación o la cardinalidad de la columna de
combinación (la columna DateKey) es grande.
Para solucionar los problemas de rendimiento, puede hacer lo siguiente:
Agregue la tabla Date al origen de datos, lo que da lugar a un modelo de grupo

de un solo origen (es decir, ya no es un modelo compuesto).
Aumente la granularidad de la relación. Por ejemplo, podría agregar una columna
MonthKey a ambas tablas y crear la relación en esas columnas. Sin embargo, al
aumentar la granularidad de la relación, se pierde la capacidad de informar sobre
la actividad diaria de ventas (a menos que use la columna DateKey de la tabla
Sales).

Considere un escenario en el que no hay valores coincidentes entre las tablas en una
relación de grupos entre orígenes.
En este escenario, la tabla Date del grupo de orígenes B tiene una relación con la tabla
Sales de ese grupo de orígenes y también con la tabla Target del grupo de orígenes A.
Todas las relaciones son de uno a varios desde la tabla Date relacionada con las
columnas Year. La tabla Sales incluye una columna SalesAmount que almacena los
importes de ventas, mientras que la tabla Target incluye una columna TargetAmount
que almacena los importes de destino.
La tabla Date almacena los años 2021 y 2022. La tabla Sales almacena los importes de
ventas de los años 2021 (100) y 2022 (200), mientras que la tabla Target almacena los
importes de destino para 2021 (100), 2022 (200) y 2023 (300).
Cuando el objeto visual de una tabla de Power BI consulta el modelo compuesto

agrupando por la columna Year de la tabla Date y sumando las columnas SalesAmount
y TargetAmount, no mostrará un importe de destino para 2023. Esto se debe a que la
relación de grupo entre orígenes es una relación limitada y, por tanto, usa semántica
INNER JOIN , que elimina las filas en las que no hay ningún valor coincidente en ambos
lados. Sin embargo, se generará un total correcto del importe de destino (600), porque
un filtro de tabla Date no se aplica a su evaluación.
Si la relación entre la tabla Date y la tabla Target es una relación de grupo dentro del
origen (suponiendo que la tabla Target pertenezca al grupo de orígenes B), el objeto
visual incluirá un año (En blanco) para mostrar el importe de destino de 2023 (y
cualquier otro año no coincidente).
） Importante
Para evitar informes incorrectos, asegúrese de que haya valores coincidentes en las
columnas de relación cuando las tablas de dimensiones y de hechos residen en
diferentes grupos de orígenes.
Para más información sobre las relaciones limitadas, consulte Evaluación de relaciones.
Cálculos
Al agregar columnas calculadas y grupos de cálculo a un modelo compuesto, debe
tener en cuenta las limitaciones específicas.
Columnas calculadas
Las columnas calculadas agregadas a una tabla de DirectQuery cuyos datos proceden
de una base de datos relacional, como Microsoft SQL Server, se limitan a expresiones
que operan en una sola fila a la vez. Estas expresiones no pueden usar funciones de
iterador DAX, como SUMX , o funciones de modificación del contexto de filtro, como
CALCULATE .
７ Nota
No es posible agregar columnas ni tablas calculadas que dependan de modelos

tabulares encadenados.
Una expresión de columna calculada en una tabla de DirectQuery remota solo se limita
a la evaluación dentro de la fila. No obstante, puede crear esta expresión, si bien
producirá un error cuando se use en un objeto visual. Por ejemplo, si agrega una
columna calculada a una tabla de DirectQuery remota denominada DimProduct
mediante la expresión [Product Sales] / SUM (DimProduct[ProductSales]) , podrá
guardar correctamente la expresión en el modelo. Sin embargo, cuando se use en un
objeto visual, se producirá un error porque infringe la restricción de la evaluación dentro
de la fila.
En cambio, las columnas calculadas agregadas a una tabla de DirectQuery remota que
es un modelo tabular, que es un conjunto de datos de Power BI o un modelo de
Analysis Services, son más flexibles. En este caso, se permiten todas las funciones DAX
porque la expresión se evaluará dentro del modelo tabular de origen.
Muchas expresiones requieren Power BI para materializar la columna calculada antes de
usarla como un grupo o filtro, o agregarla. Cuando una columna calculada se materializa
en una tabla grande, puede ser costoso en términos de CPU y memoria, dependiendo
de la cardinalidad de las columnas de las que depende la columna calculada. En este
caso, se recomienda agregar esas columnas calculadas al modelo de origen.
７ Nota
Al agregar columnas calculadas a un modelo compuesto, asegúrese de probar

todos los cálculos del modelo. Es posible que los cálculos ascendentes no
funcionen correctamente porque no consideran su influencia en el contexto de
filtro.
Grupos de cálculo
Si existen grupos de cálculo en un grupo de origen que se conecta a un conjunto de
datos de Power BI o a un modelo de Analysis Services, Power BI podría devolver
resultados inesperados. Para más información, consulte Evaluación de medidas,
consultas y grupos de cálculo.
Diseño de modelos
Optimice siempre un modelo de Power BI mediante la adopción de un diseño de
esquema de estrella.
 Sugerencia
Para más información, vea Descripción de un esquema de estrella e importancia

para Power BI.
Asegúrese de crear tablas de dimensiones independientes de las tablas de hechos para

que Power BI pueda interpretar las combinaciones correctamente y generar planes de
consulta eficaces. Aunque esta guía es válida para cualquier modelo de Power BI, es
especialmente válida para los modelos que reconozca que se convertirán en un grupo
de orígenes de un modelo compuesto. Va a permitir una integración más sencilla y
eficaz de otras tablas en modelos descendentes.
Siempre que sea posible, evite tener tablas de dimensiones en un grupo de orígenes
que se relacionen con una tabla de hechos en un grupo de orígenes diferentes. El
motivo es que es mejor tener relaciones de grupo dentro del origen que relaciones de
grupo entre orígenes, especialmente en el caso de las columnas de relación de
cardinalidad alta. Como se ha descrito anteriormente, las relaciones de grupo entre
orígenes dependen de tener valores coincidentes en las columnas de relación; de lo
contrario, pueden mostrarse resultados inesperados en los objetos visuales del informe.
Seguridad de nivel de fila

Si el modelo incluye agregaciones definidas por el usuario, columnas calculadas en
tablas de importación o tablas calculadas, asegúrese de que la seguridad de nivel de fila
(RLS) esté configurada correctamente y se haya probado.
Si el modelo compuesto se conecta a otros modelos tabulares, las reglas de RLS solo se
aplican en el grupo de orígenes (modelo local) donde se definen. No se aplicarán a
otros grupos de orígenes (modelos remotos). Además, no puede definir reglas RLS en
una tabla de otro grupo de orígenes ni puede definirlas en una tabla local que tenga
una relación con otro grupo de orígenes.
Diseño del informe

En algunas situaciones, puede mejorar el rendimiento de un modelo compuesto
mediante el diseño de un informe optimizado.
Objetos visuales de grupos de origen único

Siempre que sea posible, cree objetos visuales que usen campos de un grupo de origen
único. El motivo es que las consultas generadas por objetos visuales funcionarán mejor
cuando el resultado se recupere de un grupo de origen único. Considere la posibilidad
de crear dos objetos visuales colocados en paralelo que recuperen datos de dos grupos
de origen diferentes.
Uso de segmentaciones de sincronización

En algunas situaciones, puede configurar segmentaciones de sincronización para evitar
crear una relación de grupo entre orígenes en el modelo. Esto puede permitirle
combinar grupos de orígenes visualmente que puedan funcionar mejor.
Considere un escenario en el que el modelo tiene dos grupos de orígenes. Cada grupo
de orígenes tiene una tabla de dimensiones de producto que se usa para filtrar el
revendedor y las ventas por Internet.
En este escenario, el grupo de orígenes A contiene la tabla Product relacionada con la
tabla ResellerSales. El grupo de orígenes B contiene la tabla Product2 relacionada con
la tabla InternetSales. No hay ninguna relación de grupo entre orígenes.
En el informe, se agrega una segmentación que filtra la página mediante la columna

Color de la tabla Product. De forma predeterminada, la segmentación filtra la tabla
ResellerSales, pero no la tabla InternetSales. A continuación, agregue una
segmentación oculta mediante la columna Color de la tabla Product2. Al establecer un
nombre de grupo idéntico (que se encuentra en las opciones avanzadas de
segmentaciones de sincronización), los filtros aplicados a la segmentación visible se
propagan automáticamente a la segmentación oculta.
７ Nota
Aunque el uso de segmentaciones de sincronización puede evitar la necesidad de

crear una relación de grupo entre orígenes, aumenta la complejidad del diseño del
modelo. Asegúrese de informar a otros usuarios sobre por qué ha diseñado el
modelo con tablas de dimensiones duplicadas. Evite confusiones ocultando las
tablas de dimensiones que no quiera que usen otros usuarios. También puede
agregar texto de descripción a las tablas ocultas para documentar su propósito.
Para más información, consulte Sincronización de segmentaciones independientes.
Otra guía
Estos son algunos otros consejos que le ayudarán a diseñar y mantener los modelos
compuestos.
Rendimiento y escala: si los informes estaban conectados previamente de forma

dinámica a un conjunto de datos de Power BI o a un modelo de Analysis Services,
el servicio Power BI podría reutilizar las cachés de objetos visuales en los informes.
Después de convertir la conexión dinámica para crear un modelo de DirectQuery
local, los informes ya no se beneficiarán de esas cachés. Como resultado, puede
experimentar un rendimiento más lento o incluso errores de actualización.
Además, la carga de trabajo del servicio Power BI aumentará, lo que puede
requerir que escale verticalmente la capacidad o que distribuya la carga de trabajo
entre otras capacidades. Para más información sobre la actualización y el
almacenamiento en caché de datos, consulte Actualización de datos en Power BI.
Cambio de nombre: no se recomienda cambiar el nombre de los conjuntos de
datos usados por los modelos compuestos ni cambiar el nombre de sus áreas de
trabajo. Esto se debe a que los modelos compuestos se conectan a conjuntos de
datos de Power BI mediante el uso de los nombres de área de trabajo y de
conjunto de datos (y no sus identificadores únicos internos). Cambiar el nombre de
un conjunto de datos o de un área de trabajo podría interrumpir las conexiones
usadas por el modelo compuesto.
Gobernanza: no se recomienda que el modelo de versión única de la verdad sea un
modelo compuesto. Esto se debe a que dependería de otros orígenes de datos o
modelos, lo que, si se actualiza, podría provocar la interrupción del modelo
compuesto. En su lugar, se recomienda publicar un modelo semántico empresarial
como única versión de la verdad. Considere este modelo como una base confiable.
A continuación, otros modeladores de datos pueden crear modelos compuestos
que extiendan el modelo base para crear modelos especializados.
Linaje de datos: use las características de linaje de datos y análisis de impacto para
conjuntos de datos antes de publicar cambios en el modelo compuesto. Estas
características están disponibles en el servicio Power BI y pueden ayudarle a
comprender cómo se relacionan y usan los conjuntos de datos. Es importante
comprender que no se puede realizar un análisis de impacto en conjuntos de
datos externos que se muestren en la vista de linaje pero que en realidad se
encuentran en otra área de trabajo. Para realizar el análisis de impacto en un
conjunto de datos externo, debe navegar hasta el área de trabajo de origen.
Actualizaciones de esquema: debe actualizar el modelo compuesto en Power BI
Desktop cuando se realicen cambios de esquema en orígenes de datos
ascendentes. A continuación, tendrá que volver a publicar el modelo en el servicio
Power BI. Asegúrese de probar exhaustivamente los cálculos y los informes
dependientes.
Pasos siguientes
Para más información sobre este artículo, consulte los recursos siguientes.
Usar modelos compuestos en Power BI Desktop

Modelos de DirectQuery en Power BI Desktop
Usar DirectQuery en Power BI Desktop
Uso de DirectQuery para conjuntos de datos de Power BI y Analysis Services
Modo de almacenamiento en Power BI Desktop
Agregaciones definidas por el usuario
Instrucciones de seguridad de nivel de
fila (RLS) en Power BI Desktop
Artículo • 23/05/2023
Power BI Desktop. Describe las prácticas de diseño adecuadas para aplicar seguridad de
nivel de fila (RLS) en los modelos de datos.
Es importante comprender las filas de tabla de los filtros de RLS. No se pueden

configurar para restringir el acceso a los objetos de modelo, como tablas, columnas o
medidas.
７ Nota
En este artículo no se describe RLS ni cómo configurarlo. Para obtener más

información, consulte Restricción del acceso a datos con seguridad de nivel de fila
(RLS) en Power BI Desktop.
Además, no se trata la aplicación de RLS en conexiones dinámicas a modelos

hospedados externamente con Azure Analysis Services o SQL Server Analysis
Services. En estos casos, es Analysis Services quien aplica RLS. Cuando Power BI se
conecta mediante inicio de sesión único (SSO), Analysis Services aplicará RLS (a
menos que la cuenta tenga privilegios de administrador).
Crear roles
Es posible crear varios roles. Cuando piense en las necesidades de permisos que
requiere un único usuario de informes, procure crear un único rol que conceda todos
esos permisos, en lugar de optar por un diseño en el que un usuario de informes sea
miembro de varios roles. El motivo es que un usuario de informes podría asignarse a
varios roles, ya sea directamente mediante su cuenta de usuario o indirectamente
mediante la pertenencia a grupos de seguridad. Las asignaciones de roles múltiples
pueden producir resultados inesperados.
Cuando se asigna un usuario de informes a varios roles, los filtros RLS se vuelven
aditivos. Esto significa que los usuarios de informes pueden ver filas de tabla que
representan la unión de esos filtros. Pero aún hay más: en algunos escenarios no es
posible garantizar que un usuario de informes no vea las filas de una tabla. Por lo tanto,
a diferencia de los permisos aplicados a objetos de base de datos de SQL Server (y otros
modelos de permisos), no se aplica el principio "una vez denegado, denegado siempre".
Considere un modelo con dos roles: El primer rol, llamado Workers (Trabajadores),
restringe el acceso a todas las filas de la tabla Payroll (Nómina) mediante la siguiente
expresión de regla:
DAX
FALSE()
７ Nota
Una regla no devolverá ninguna fila de la tabla cuando su expresión se evalúe

como FALSE .
Aún así, un segundo rol, denominado Managers (Directivos), permite el acceso a todas
las filas de la taba Payroll (Nómina) mediante la siguiente expresión de regla:
DAX
TRUE()
Atención: Si un usuario de informes se asigna a ambos roles, verá todas las filas de la
tabla Payroll (Nómina).
Optimización de RLS
RLS funciona aplicando filtros automáticamente a cada consulta DAX, y estos filtros
pueden tener un impacto negativo en el rendimiento de las consultas. Por lo tanto, la
eficacia de RLS se reduce a un buen diseño del modelo. Es importante seguir las
instrucciones para el diseño de modelos, como se describe en los siguientes artículos:

Todos los artículos de la guía de instrucciones de la relación se encuentran en la
documentación de orientación de Power BI.
En general, suele ser más eficaz aplicar filtros RLS en tablas de tipo de dimensión y no
tablas de tipo de hechos. Y basarse en relaciones bien diseñadas para garantizar que los
filtros RLS se propaguen a otras tablas de modelos. Los filtros RLS solo se propagan a
través de relaciones activas. Por lo tanto, evite usar la función DAX LOOKUPVALUE
cuando las relaciones de modelo puedan lograr el mismo resultado.
Siempre que se apliquen filtros RLS en las tablas de DirectQuery y existan relaciones con
otras tablas de DirectQuery, asegúrese de optimizar la base de datos de origen. Puede
implicar el diseño de índices adecuados o el uso de columnas calculadas persistentes.
Para obtener más información, vea Instrucciones del modelo de DirectQuery en Power BI
Desktop.
Medición del impacto de RLS

Es posible medir el impacto en el rendimiento de los filtros de RLS en Power BI Desktop
mediante el Analizador de rendimiento. En primer lugar, determine la duración de las
consultas visuales de informes cuando no se aplique RLS. A continuación, use el
comando Ver como en la pestaña Modelado de la cinta de opciones para aplicar RLS y
determinar y comparar las duraciones de la consulta.
Configuración de las asignaciones de roles

Una vez publicados en Power BI, debe asignar miembros a los roles del conjunto de
datos. Solo los propietarios del conjunto de datos o los administradores del área de
trabajo pueden agregar miembros a los roles. Para más información, consulte Seguridad
de nivel de fila (RLS) con Power BI (Administración de la seguridad en el modelo).
Los miembros pueden ser cuentas de usuario, grupos de seguridad, grupos de

distribución o grupos habilitados para correo. Siempre que sea posible, se recomienda
asignar grupos de seguridad a los roles de los conjuntos de seguridad. Implica la
administración de pertenencias a grupos de seguridad en Azure Active Directory.
Posiblemente, delega la tarea a los administradores de red.
Validación de roles
Pruebe cada rol para asegurarse de que filtra el modelo correctamente. Se realiza
fácilmente mediante el uso del comando Ver como en la pestaña de la cinta Modelado.
Cuando el modelo tenga reglas dinámicas que usen la función DAX USERNAME,
asegúrese de comprobar los valores esperados e inesperados. Al insertar contenido de
Power BI, en concreto con el escenario Inserción para los clientes, la lógica de la
aplicación puede pasar cualquier valor como un nombre de usuario de identidad
efectivo. Siempre que sea posible, asegúrese de que los valores accidentales o
malintencionados den como resultado filtros que no devuelven ninguna fila.
Considere un ejemplo que use Power BI insertado, donde la aplicación pasa el rol de
trabajo del usuario como el nombre de usuario efectivo: Es "Manager"(Directivo) o
"Worker" (Trabajador). Los administradores pueden ver todas las filas, pero los
trabajadores solo pueden ver las filas en las que el valor de la columna Tipo es
"Interno".
Se define la siguiente expresión de regla:
DAX
IF(
USERNAME() = "Worker",
[Type] = "Internal",
TRUE()
)
El problema con esta expresión de regla es que todos los valores, excepto "Worker"
(Trabajador), devuelven todas las filas de la tabla. Por lo tanto, un valor accidental, como
"Wrker", devuelve involuntariamente todas las filas de la tabla. Así pues, es más seguro
escribir una expresión que pruebe cada valor esperado. En la expresión de regla
mejorada siguiente, un valor inesperado hace que la tabla no devuelva ninguna fila.
DAX
IF(
USERNAME() = "Worker",
[Type] = "Internal",
IF(
USERNAME() = "Manager",
TRUE(),
FALSE()
)
)
RLS de diseño parcial

A veces, los cálculos necesitan valores que no están restringidos por filtros de RLS. Por
ejemplo, es posible que en un informe se tenga que mostrar la relación entre los
ingresos obtenidos para la región de ventas del usuario del informe y todos los ingresos
obtenidos.
Aunque no es posible que una expresión DAX invalide RLS —de hecho, no puede
determinar ni siquiera que se aplique RLS—, puede usar una tabla de modelo de
resumen. La tabla del modelo de resumen se consulta para recuperar los ingresos de
"todas las regiones" y no está restringida por ningún filtro de RLS.
Veamos cómo podría implementar este requisito de diseño. En primer lugar, tenga en
cuenta el siguiente diseño de modelo:
El modelo consta de cuatro tablas:
La tabla Salesperson (Comercial) almacena una fila por comercial. Incluye la

columna EmailAddress (Dirección de correo electrónico), que almacena la
dirección de correo electrónico de cada vendedor. Esta tabla está oculta.
La tabla Sales (Ventas) almacena una fila por pedido. Incluye la medida Revenue %
All Region (% ingresos toda la región), que está diseñada para devolver una
relación de los ingresos obtenidos por la región del usuario del informe con
respecto a los ingresos obtenidos por todas las regiones.
La tabla Date (Fecha) almacena una fila por fecha y permite filtrar y agrupar el año
y el mes.
SalesRevenueSummary (Resumen de los ingresos por ventas) es una tabla
calculada. Almacena los ingresos totales para cada fecha de pedido. Esta tabla está
oculta.
La siguiente expresión define la tabla calculada SalesRevenueSummary (Resumen de los

ingresos por ventas):
DAX
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
７ Nota
Una tabla de agregación podría lograr el mismo requisito de diseño.
La siguiente regla de RLS se aplica a la tabla Salesperson (Comercial):
DAX
[EmailAddress] = USERNAME()
En la tabla siguiente se describe cada una de las tres relaciones del modelo:
Relación Descripción
Hay una relación de varios a varios entre las tablas Salesperson (Comercial) y Sales
(Ventas). La regla de RLS filtra la columna EmailAddress (Dirección de correo
electrónico) de la tabla oculta Salesperson (Comercial) mediante la función de DAX
USERNAME. El valor de la columna Region (Región) (para el usuario del informe) se
propaga a la tabla Sales (Ventas).
Hay una relación de uno a varios entre las tablas Date (Fecha) y Sales (Ventas).
Hay una relación de uno a varios entre las tablas Date (Fecha) y
SalesRevenueSummary (Resumen de los ingresos por ventas).
La expresión siguiente define la medida Revenue % All Region (% ingresos toda la

región):
DAX
Revenue % All Region =

DIVIDE(
SUM(Sales[Revenue]),
SUM(SalesRevenueSummary[RevenueAllRegion])
)
７ Nota
Tenga cuidado y evite la divulgación de hechos confidenciales. Si solo hay dos

regiones en este ejemplo, un usuario del informe puede calcular los ingresos de la
otra región.
Cuándo evitar el uso de RLS
A veces tiene sentido evitar el uso de RLS. Si tiene solo un pequeño número de reglas
de RLS simplista que aplican filtros estáticos, considere la posibilidad de publicar varios
conjuntos de valores en su lugar. Ninguno de los conjuntos de datos define roles
porque cada conjunto de datos contiene datos de un público de usuario de informes
específico, que tiene los mismos permisos de datos. A continuación, cree un área de
trabajo por público y asigne permisos de acceso al área de trabajo o a la aplicación.
Por ejemplo, una empresa que tiene solo dos regiones de ventas decide publicar un
conjunto de datos para cada región de ventas para diferentes áreas de trabajo. Los
conjuntos de valores no aplican RLS. Sin embargo, usan parámetros de consulta para
filtrar los datos de origen. De este modo, el mismo modelo se publica en cada área de
trabajo; solo tienen valores de parámetro de conjunto de datos diferentes. A los
comerciales se les asigna acceso a solo una de las áreas de trabajo (o aplicaciones
publicadas).
Hay varias ventajas asociadas con la evitación de RLS:
Mejor rendimiento de las consultas: puede dar lugar a un rendimiento mejorado

gracias a la reducción de filtros.
Modelos más pequeños: Aunque da como resultado más modelos, su tamaño es
menor. Los modelos más pequeños pueden mejorar la capacidad de respuesta de
la consulta y la actualización de datos, especialmente si la capacidad de hospedaje
experimenta presión sobre los recursos. Además, es más fácil mantener los
tamaños de modelo por debajo de los límites de tamaño impuestos por su
capacidad. Por último, es más fácil equilibrar las cargas de trabajo entre diferentes
capacidades, ya que puede crear áreas de trabajo en distintas capacidades —o
mover áreas de trabajo a estas—.
Características adicionales: se pueden usar características de Power BI que no
funcionan con RLS, como Publicar en Web.
Sin embargo, hay desventajas asociadas a evitar RLS:
Varias áreas de trabajo: se requiere un área de trabajo para cada audiencia de

usuario de informes. Si se publican aplicaciones, también hay una aplicación por
cada audiencia del usuario de informes.
Duplicación de contenido: los informes y paneles se deben crear en cada área de
trabajo. Su configuración y mantenimiento requiere un esfuerzo adicional, además
de tiempo.
Usuarios con privilegios elevados: los usuarios con privilegios elevados, que
pertenecen a varias audiencias de usuarios de informes, no pueden ver una vista
consolidada de los datos. Tendrán que abrir varios informes (desde diferentes
áreas de trabajo o aplicaciones).
Solución de problemas de RLS

Si RLS produce resultados inesperados, compruebe los siguientes problemas:
Existen relaciones incorrectas entre las tablas del modelo, en cuanto a las
asignaciones de columnas y las direcciones de filtro. Tenga en cuenta que los
filtros de RLS solo se propagan a través de relaciones activas.
La propiedad de relación Aplicar filtro de seguridad en ambas direcciones no se
ha configurado correctamente. Para obtener más información, vea Instrucciones
para relaciones bidireccionales.
Las tablas no contienen datos.
Se cargan valores incorrectos en las tablas.
El usuario está asignado a varios roles.
El modelo incluye tablas de agregación, y las reglas de RLS no filtran de forma
coherente las agregaciones y los detalles. Para obtener más información, vea Uso
de agregaciones en Power BI Desktop (RLS para agregaciones).
Cuando un usuario específico no puede ver ningún dato, podría deberse a que su UPN
no está almacenado o se ha escrito incorrectamente. Puede suceder repentinamente
porque su cuenta de usuario ha cambiado como resultado de un cambio de nombre.
 Sugerencia
Con fines de prueba, agregue una medida que devuelva la función DAX
USERNAME. Puede asignarle un nombre similar a "Who Am I" (Quién soy). A
continuación, agregue la medida a un objeto visual de tarjeta en un informe y
publíquela en Power BI.
Los creadores y consumidores con solo permiso de lectura en el conjunto de datos solo
podrán ver los datos que pueden ver (en función de su asignación de roles de RLS).
Cuando un usuario ve un informe en un área de trabajo o en una aplicación, es posible

que RLS se aplique o no en función de sus permisos de conjunto de datos. Por este
motivo, es fundamental que los consumidores de contenido y los creadores solo tengan
permiso de lectura en el conjunto de datos subyacente cuando se debe aplicar RLS. Para
obtener más información sobre las reglas de permisos que determinan si se aplica RLS,
consulte el artículo Planeamiento de la seguridad del consumidor de informes.
Pasos siguientes
Seguridad de nivel de fila (RLS) con Power BI

Restricción del acceso a datos con seguridad de nivel de fila (RLS) en Power BI
Desktop
Planeación de la implementación de Power BI: Planeamiento de la seguridad del
consumidor de informes
Migración de Azure Analysis Services a
Power BI Premium
Artículo • 22/05/2023
Este artículo se dirige a los modeladores y administradores de datos de Azure Analysis

Services (AAS). Proporciona instrucciones y razones para ayudar a migrar sus bases de
datos de AAS a Power BI Premium o Power BI Embedded.
Fondo
Power BI ha evolucionado en la plataforma líder para inteligencia empresarial (BI)
administrada por TI y autoservicio. Con el crecimiento exponencial en volúmenes de
datos y complejidad, los clientes de Power BI exigen soluciones de BI empresariales que
se escalan a petabytes, son seguras, fáciles de administrar y accesibles para todos los
usuarios de la mayor parte de las organizaciones.
Durante más de dos décadas, Microsoft ha seguido invirtiendo profundamente en BI

empresarial. AAS y SQL Server Analysis Services (SSAS) se basan en la tecnología de
modelado de datos de BI madura que usan innumerables empresas. Hoy en día, esa
misma tecnología está en el corazón de los conjuntos de datos de Power BI.
７ Nota
En este artículo, los términos modelo de datos, modelo semántico, modelo de BI,
modelo tabular, base de datos y conjunto de datos de Power BI tienen el mismo
significado. En este artículo se usan normalmente los términos modelo de datos
para el modelo de AAS y el conjunto de datos para el modelo de Power BI. En este
artículo se describe el proceso de migración a Power BI Premium, pero también se
aplica a Power BI Embedded.
En los últimos años, Microsoft ha dado grandes pasos para ofrecer funcionalidades de
AAS para Power BI Premium . Para ello, Power BI heredó instantáneamente un gran
ecosistema de desarrolladores, asociados, herramientas de BI y soluciones que se
crearon durante décadas. En la actualidad, el conjunto completo de cargas de trabajo,
características y funcionalidades de Power BI Premium ahora da como resultado una
plataforma moderna de BI en la nube que va mucho más allá de la funcionalidad
comparable disponible en AAS o SSAS.
En la actualidad, muchos clientes tienen informes de Power BI que se conectan
dinámicamente a AAS. Naturalmente, estos clientes preguntan si hay una oportunidad
de consolidar mediante el hospedaje de sus modelos de datos junto con sus informes
en Power BI. A menudo hacen preguntas como:
¿Depende toda la funcionalidad de AAS que dependemos del trabajo en Power BI?
¿Power BI es compatible con las herramientas y los procesos de AAS?
¿Qué funcionalidades solo están disponibles en Power BI?
¿Cómo se comparan los costos entre AAS y Power BI?
¿Por qué Microsoft está convergiendo la empresa y la BI de autoservicio?
¿Cómo se migra de AAS a Power BI Premium?
¿AAS está marcado para desuso?
¿Cuál es la hoja de ruta de Microsoft para los modelos de datos empresariales?
Las respuestas a muchas de estas preguntas se describen en este artículo.
７ Nota
La decisión de migrar a Power BI Premium depende de los requisitos de cada

cliente. Los clientes deben evaluar cuidadosamente las ventajas adicionales para
tomar una decisión informada. Esperamos ver la migración orgánica a Power BI
Premium a lo largo del tiempo, y nuestra intención es que se produzca en términos
con los que el cliente se sienta cómodo.
Para ser claro, actualmente no hay ningún plan para dejar de usar AAS. Hay una
prioridad para centrar la inversión en Power BI Premium para el modelado de datos
empresariales, por lo que el valor adicional proporcionado por Power BI Premium
aumentará con el tiempo. Los clientes que elijan Power BI Premium pueden esperar
beneficiarse de la alineación con la hoja de ruta del producto de Microsoft BI.
Convergencia de BI empresarial y de autoservicio

La consolidación de elementos (como informes y paneles) en Power BI da como
resultado una detección y administración simplificadas debido a la colocalización. Una
vez consolidado, no es necesario salvar la brecha entre AAS y Power BI. A continuación,
los equipos de TI centrales pueden adoptar más fácilmente elementos de autoservicio
que se han vuelto populares, pero que resultan en una carga de administración para la
empresa. El TI puede asumir estos elementos. Pueden ponerlas en funcionamiento para
la toma de decisiones críticas en función de los datos regulados alineados con los
estándares corporativos y con la transparencia del linaje. Simplificar este flujo de trabajo
compartiendo una plataforma común promueve una mejor colaboración entre la
empresa y el departamento de TI.
Power BI Premium
Gracias a su arquitectura distribuida, Power BI Premium es menos sensible a la carga
general, los picos temporales y la alta simultaneidad. Al consolidar las capacidades en
SKU de Power BI Premium más grandes, los clientes pueden lograr un mayor
rendimiento.
Las ventajas de escalabilidad asociadas a Power BI Premium se describen más adelante

en este artículo.
Comparación de características
AAS proporciona el motor de base de datos de Analysis Services para hospedar
modelos de datos, que es un componente principal de una arquitectura de BI
empresarial de Microsoft. De hecho, Power BI Premium es un superconjunto de AAS
porque proporciona mucha más funcionalidad. En la tabla siguiente se enumeran las
características admitidas en AAS y Power BI Premium. La tabla se centra en las
funcionalidades relacionadas con el conjunto de datos de Power BI, pero no se limita a
ellas.
Característica AAS Power BI

Premium
Cargas de trabajo Premium
Informes paginados, que son ideales para los informes diseñados para No Sí
imprimirse, especialmente cuando los datos de tabla se desbordan en varias
páginas
Flujos de datos, que almacenan fragmentos de datos diseñados para su uso en No Sí

un conjunto de datos de Power BI
Inteligencia artificial con flujos de datos, que usan inteligencia artificial (IA) con No Sí
Cognitive Services, Aprendizaje automático automatizado e integración de
Azure Machine Learning (AML)
Métricas, que protegen las medidas empresariales clave y permiten el No Sí

seguimiento de los objetivos
Habilitación empresarial
Premium
Distribución ilimitada de informes a cualquier persona (incluso fuera de la No Sí

organización)
Informes interactivos, áreas de trabajo y aplicaciones controlados por la No Sí

empresa
Escalabilidad y resistencia de la plataforma
Arquitectura de Power BI Premium, que admite un mayor escalado y No Sí

rendimiento
Administración de memoria del conjunto de datos optimizada No Sí
Límites de escala por modelo de datos en lugar de por servidor No Sí
Suavizado de CPU para la resistencia de actualización No Sí
Escalabilidad automática, que añade automáticamente capacidad de cálculo No Sí

para evitar ralentizaciones en caso de uso intensivo
Continuidad empresarial y recuperación ante desastres (BCDR) con regiones de No Sí

Azure y zonas de disponibilidad
Análisis interactivo sobre macrodatos
Tamaños de modelo grandes (hasta 400 GB con compresión) Sí Sí
Tablas híbridas, que componen particiones en memoria y DirectQuery que No Sí

pueden ayudar a ofrecer resultados casi en tiempo real en tablas grandes.
Agregaciones automáticas, que utilizan el aprendizaje automático (ML) más No Sí

avanzado para optimizar continuamente el rendimiento de DirectQuery
Agregaciones definidas por el usuario, que pueden mejorar el rendimiento de No Sí

las consultas en tablas de DirectQuery muy grandes
Escalado horizontal de consultas, que distribuye las consultas de cliente entre Sí Sí

servidores replicados
Seguridad
Bring Your Own Key (BYOK), que permite a los clientes usar su propia clave de No Sí
cifrado para cifrar los datos almacenados en la nube de Microsoft.
Conectividad de red virtual, que permite que Power BI funcione sin problemas No Sí
en la red virtual (VNet) de una organización.
Azure Private Link, que proporciona acceso seguro para el tráfico de datos en No Sí
Power BI
Premium
Inicio de sesión único (SSO) para orígenes de DirectQuery, que permite No Sí

conectarse a orígenes de datos mediante la identidad del usuario del informe
Seguridad de nivel de fila (RLS), que restringe el acceso a filas de datos Sí Sí

específicas para usuarios específicos
Seguridad de nivel de objeto (OLS), que restringe el acceso a tablas o Sí Sí

columnas específicas para usuarios específicos
Firewall, que cuando está habilitado, permite establecer intervalos de Sí No 1

direcciones IP permitidos
Gobernanza
Integración de Microsoft Purview, que ayuda a los clientes a administrar y No Sí

controlar los elementos de Power BI
Microsoft Information Protection (MIP) etiquetas de sensibilidad e integración No Sí

con Microsoft Defender for Cloud Apps para la prevención de la pérdida de
datos
Aprobación del contenido, para promover o certificar elementos valiosos y de No Sí

alta calidad de Power BI
Modelos semánticos
Compatibilidad con Power BI Desktop No Sí
Modelos compuestos, incluido el uso de DirectQuery para conjuntos de datos No Sí

de Power BI y AAS
Traducciones para versiones de modelos de varios lenguajes observadas por el No Sí

servicio Power BI
Modelado semántico del motor de Analysis Service Sí Sí
Administración de modelos
Actualización incremental, que usa directivas para automatizar la No Sí

administración de particiones y puede ayudar a ofrecer informes casi en
tiempo real (consulte tablas híbridas).
Canalizaciones de implementación, que administran el ciclo de vida del No Sí

contenido de Power BI
Actualización programada, que mantiene actualizados los datos del conjunto No Sí

de datos almacenados en caché.
Premium
Actualización mejorada, que permite que cualquier lenguaje de programación Sí Sí

realice actualizaciones asincrónicas de conjuntos de datos mediante una
llamada API REST.
Copia de seguridad y restauración Sí Sí
Configuración de la carga de trabajo del conjunto de datos, que controla las No Sí

cargas de trabajo de capacidad Premium
Propiedades del servidor, que controlan las propiedades de la instancia del Sí Sí

servidor de Analysis Services
Nombres de servidor de alias, que permiten conectarse a una instancia de Sí No

servidor de Analysis Services mediante un alias más corto
API habilitadas para puntos de conexión XMLA para scripting y compatibilidad Sí Sí

con servicios para automatización y ALM, incluidos Azure Functions, Azure
Automation y Azure DevOps
Conectividad
Compatibilidad con todos los orígenes de datos de Power BI No Sí
Punto de conexión XMLA, que permite la conectividad de plataforma abierta Sí Sí

para las herramientas de visualización y consumo del modelo de datos,
incluidas las herramientas de terceros.
Característica Multi-Geo, que ayuda a los clientes multinacionales a abordar los Sí Sí

requisitos de residencia de datos regionales, específicos del sector o de la
organización.
Detectabilidad
Integración del centro de datos, que ayuda a los usuarios a detectar, explorar y No Sí
usar conjuntos de datos de Power BI
Vista del linaje de datos y análisis del impacto del conjunto de datos, que No Sí
ayudan a los usuarios a comprender y evaluar las dependencias de los
elementos de Power BI
Supervisión y registro de diagnóstico
Aplicación de métricas de capacidad Premium, que proporciona No Sí

funcionalidades de supervisión para las capacidades de Power BI
Registro de auditoría de Power BI, que realiza un seguimiento de las No Sí

actividades del usuario en Power BI y Microsoft 365
Premium
Integración de Azure Log Analytics (LA), que permite a los administradores Sí Sí

configurar una conexión de Log Analytics para un área de trabajo de Power BI
Alertas de métricas en Azure Monitor, que proporcionan una forma de recibir Sí No

notificaciones cuando una de sus métricas multidimensionales cruza un umbral
Punto de conexión XMLA, que permite conexiones de herramientas de registro Sí Sí

de diagnóstico, incluidas SQL Server Profiler
SQL Server Eventos extendidos (xEvents), que es un sistema ligero de Sí No

seguimiento y supervisión del rendimiento útil para diagnosticar problemas
1
Utilice la conectividad VNet y Azure Private Link en su lugar
Comparación de costos
Al comparar los costos de Power BI Premium con AAS, asegúrese de tener en cuenta
otros factores más allá del precio por núcleo. Power BI ofrece un costo reducido de valor
empresarial y de propiedad, con muchas características que solo están disponibles para
los modelos de datos de Power BI.
Además, en el supuesto de que ya use Power BI en su organización, calcule los costos en

función del perfil existente que combina AAS y Power BI. Compare el perfil existente con
el perfil de destino en Power BI Premium. Para determinar el perfil de destino, asegúrese
de tener en cuenta los puntos siguientes:
Requisitos de la región.
El tamaño del modelo de datos de AAS más grande en cada región.
Número de usuarios de cada región.
Número de usuarios necesarios para desarrollar y administrar contenido.
El consumo de CPU en AAS y Power BI Premium.
） Importante
El consumo de CPU en AAS y Power BI Premium puede variar significativamente

debido a numerosos factores. Entre estos puede incluirse el uso de otras cargas de
trabajo en las mismas capacidades, patrones de actualización y patrones de
consulta. Se recomienda realizar un análisis detallado para cuantificar el consumo
comparativo de CPU en AAS y Power BI Premium para los modelos migrados.
 Sugerencia
Para ayudar a determinar el tipo adecuado y el número de licencias para sus

requisitos y circunstancias empresariales, consulte este artículo relacionado.
Oportunidad de consolidación
Muchos clientes de AAS ya tienen informes de Power BI que se conectan a AAS. Por lo
tanto, la migración a Power BI puede representar una oportunidad para consolidar los
elementos de BI en Power BI Premium. La consolidación hace que las SKU Premium de
mayor tamaño sea más económicamente viables y pueden ayudar a proporcionar
mayores niveles de rendimiento y escalabilidad.
Licencias de PPU
La licencia Premium por usuario (PPU) es una licencia por usuario que proporciona un
punto de precio de menor costo para Premium. Normalmente, las licencias PPU son
adquiridas por pequeñas y medianas empresas. Admiten todas las funcionalidades
Premium para el modelado de datos enumerados anteriormente.
 Sugerencia
Es posible actualizar incrementalmente Power BI Pro licencias a licencias PPU.
licencias profesionales
Se requiere una licencia pro (o PPU) para publicar y administrar contenido de Power BI.
Normalmente, las licencias pro se asignan a desarrolladores y administradores, no a los
usuarios finales.
Entornos de desarrollo y pruebas

AAS ofrece las SKU D y B a un costo menor con acuerdos de nivel de servicio reducidos
o menos características que las SKU S. Algunos clientes de AAS usan estas SKU para
entornos de desarrollo y pruebas. Aunque no hay ningún equivalente directo en Power
BI, es posible que tenga sentido usar licencias PPU para entornos de desarrollo y
pruebas. Normalmente, estos entornos no tienen un gran número de usuarios porque
están limitados a desarrolladores y evaluadores. Como alternativa, considere la
posibilidad de usar una SKU A en Azure para probar la funcionalidad de capacidad
Premium.
Para más información, consulte:
Precios de Power BI
Precios de Azure Analysis Services
Compra de SKU A para pruebas y otros escenarios
Ventajas de escalabilidad
Power BI Premium ofrece ventajas de escalabilidad, rendimiento y costo de propiedad
que no están disponibles en AAS.
Power BI Premium proporciona características que permiten un análisis interactivo

rápido sobre macrodatos. Estas características incluyen agregaciones, modelos
compuestos y tablas híbridas. Cada característica ofrece una manera diferente de
combinar de forma óptima los modos de almacenamiento de importación y
DirectQuery, lo que reduce eficazmente el uso de memoria. Por otro lado, AAS no
admite estas funcionalidades; el modelo de datos completo usa el modo de
almacenamiento de importación o DirectQuery.
Power BI Premium limita la memoria por conjunto de datos y no por capacidad o

servidor. Por el contrario, AAS requiere que todos los modelos de datos se ajusten a la
memoria en un único servidor. Ese requisito puede obligar a los clientes con modelos de
datos grandes a comprar tamaños de SKU mayores.
Gracias a la naturaleza distribuida de la arquitectura Premium, se pueden actualizar más

conjuntos de datos en paralelo. La realización de actualizaciones simultáneas en el
mismo servidor de AAS puede provocar errores de actualización debido a la superación
de los límites de memoria del servidor.
En Power BI Premium, el consumo de CPU durante la actualización se distribuye entre

períodos de 24 horas. Power BI Premium evalúa el rendimiento de la capacidad para
proporcionar resistencia a picos temporales en la demanda de recursos de proceso.
Cuando sea necesario, puede retrasar las actualizaciones hasta que haya suficientes
recursos disponibles. Este comportamiento automático reduce la necesidad de que los
clientes realicen análisis detallados y administren scripts de automatización para escalar
o reducir verticalmente los servidores. Los clientes de Premium deben decidir el tamaño
óptimo de la SKU para sus requisitos generales de consumo de CPU.
Otra ventaja de Power BI Premium es que es capaz de equilibrar dinámicamente los

conjuntos de datos en función de la carga del sistema. Este comportamiento automático
garantiza que los conjuntos de datos ocupados o activos obtengan los recursos de CPU
y memoria necesarios, mientras que se pueden expulsar o migrar más conjuntos de
datos inactivos a otros nodos. Los conjuntos de datos son candidatos para la expulsión
cuando no se usan. Se cargarán a petición para que solo se carguen los datos necesarios
en la memoria sin tener que cargar todo el conjunto de datos. Por otro lado, AAS
requiere que todos los modelos de datos se carguen completamente en la memoria
siempre. Este requisito significa que las consultas a AAS pueden depender de que el
modelo de datos esté disponible, pero, especialmente para las capacidades de Power BI
con un gran número de modelos de datos cuando algunos de ellos se usan con poca
frecuencia, la administración de memoria dinámica puede hacer un uso más eficaz de la
memoria.
Por último, Power BI Premium puede usar mejor los lanzamientos de hardware de
próxima generación para beneficiarse de las mejoras de escalabilidad y rendimiento.
Consideraciones y limitaciones
Hay consideraciones y limitaciones que se deben tener en cuenta en el planeamiento
antes de migrar a Power BI Premium.
Permisos
AAS y SSAS usan roles para administrar el acceso al modelo de datos. Existen dos tipos
de roles: el rol servidor y el rol base de datos. El rol de servidor es un rol fijo que concede
acceso de administrador a la instancia del servidor de Analysis Services. Los roles de
base de datos, que establecen los modeladores de datos y los administradores,
controlan el acceso a la base de datos y a los datos de los usuarios que no son
administradores.
A diferencia de AAS, en Power BI, solo se usan roles para aplicar RLS o OLS. Para
conceder permisos más allá de RLS y OLS, use el modelo de seguridad de Power BI
(roles de área de trabajo y permisos de conjunto de datos). Para más información, vea
Permisos del conjunto de datos.
Para obtener más información sobre los roles de modelo de Power BI, vea Conectividad
del conjunto de datos con el punto de conexión XMLA (roles de modelo).
Al migrar un modelo de datos de AAS a Power BI Premium, debe tener en cuenta los
siguientes puntos:
Los usuarios a los que se les concedió el permiso Lectura sobre un modelo en AAS
deben recibir el permiso Compilación sobre el conjunto de datos de Power BI
migrado.
Los usuarios a los que se les concedió el permiso Administrador en un modelo en
AAS deben tener el permiso Escritura en el conjunto de datos de Power BI
migrado.
Actualización de la automatización
Power BI Premium es compatible con las API habilitadas por XMLA para la creación de
scripts, como el lenguaje de scripting del modelo tabular (TMSL), el lenguaje de
scripting del modelo tabular (TMSL), y el módulo SqlServer de PowerShell. Estas API
tienen interfaces casi simétricas a AAS. Para más información, vea Conectividad del
conjunto de datos con el punto de conexión XMLA (aplicaciones cliente y herramientas).
La compatibilidad con los servicios para la automatización, incluidos Azure Functions,

Azure Automation y Azure Logic Apps, se habilita de la misma manera.
Por lo general, los scripts y los procesos que automatizan la administración y el

procesamiento de particiones en AAS funcionarán en Power BI Premium. Tenga en
cuenta que los conjuntos de datos de Power BI Premium admiten la característica de
actualización incremental, que proporciona una administración automatizada de las
particiones para las tablas que cargan frecuentemente datos nuevos y actualizados.
Al igual que para AAS, puede usar una entidad de servicio como una cuenta de
automatización para las operaciones de administración de conjuntos de datos de Power
BI, como las actualizaciones. Para más información, vea Conectividad del conjunto de
datos con el punto de conexión XMLA (entidades de servicio).
Seguridad personalizada
Al igual que en el caso de AAS, las aplicaciones pueden utilizar un servicio principal para
consultar un conjunto de datos de Power BI Premium por capacidad o de Power BI
Embedded utilizando la característica CustomData.
Sin embargo, no se puede asignar una entidad de servicio a un rol de modelo en Power
BI Premium. En su lugar, una entidad de servicio obtiene acceso mediante la asignación
al rol de administrador o miembro del área de trabajo.
７ Nota
No se puede usar la característica CustomData al consultar conjuntos de datos

Premium por usuario (PPU) porque se infringían los términos y condiciones de
licencia.
Suplantación para pruebas
Las técnicas de suplantación, incluidas las propiedades EffectiveUserName y la cadena
de conexión Roles, son compatibles con AAS y Power BI Premium. Normalmente, los usa
al probar los roles de seguridad.
Seguridad de las redes

La configuración de la seguridad de red en AAS requiere habilitar el firewall y configurar
intervalos de direcciones IP solo para los equipos que acceden al servidor.
Power BI no tiene una característica de firewall. En su lugar, Power BI ofrece un modelo

de seguridad de red superior mediante redes virtuales y vínculos privados. Para más
información, vea ¿Qué es una red virtual (VNet)?.
Orígenes de datos y credenciales

AAS define las credenciales de cada origen de datos declarado en los metadatos
tabulares de TOM. Sin embargo, Power BI no funciona de esa manera. Dado que Power
BI puede compartir credenciales de orígenes de datos en varios conjuntos de datos, las
credenciales se establecen en el servicio Power BI.
Se debe reemplazar cualquier proceso basado en XMLA que establezca las credenciales
del origen de datos. Para obtener más información, vea Conectividad del conjunto de
datos con el punto de conexión XMLA (Implementación de proyectos de modelo desde
Visual Studio).
Copia de seguridad y restauración

La copia de seguridad y restauración en AAS requiere Azure Blob Storage, mientras que
en Power BI Premium requiere una cuenta de Azure Data Lake Storage Gen2 (ADLS
Gen2). Además de la diferencia de la cuenta de almacenamiento, la copia de seguridad y
la restauración funcionan de la misma manera en ambos productos.
Para más información, vea Copia de seguridad y restauración de conjuntos de datos con
Power BI Premium.
Puerta de enlace de datos local

Tanto AAS como Power BI Premium usan la misma puerta de enlace de datos local para
conectarse a orígenes de datos. Sin embargo, los pasos de configuración son diferentes.
Para obtener información sobre cómo configurar orígenes de datos de puerta de enlace
para Power BI Premium, vea Agregar o quitar un origen de datos de puerta de enlace.
Propiedades del servidor

A diferencia de AAS, Power BI Premium no admite propiedades del servidor. En su lugar,
administra la configuración de la capacidad Premium.
Archivos de vínculo
A diferencia de AAS, Power BI Premium no admite nombres de servidor de alias.
Vistas de administración dinámica (DMV)

Algunas DMV que funcionan en AAS no son accesibles en Power BI Premium porque
requieren permisos de administrador del servidor de Analysis Services. Power BI tiene
roles de área de trabajo, pero no hay un rol de área de trabajo que conceda permisos
de administrador de servidor de Analysis Services.
PowerShell
Puede usar los cmdlets de AAS del módulo sqlServer de PowerShell para automatizar
las tareas de administración de conjuntos de datos, incluidas las operaciones de
actualización. Para obtener más información, vea Referencia de Analysis Services
PowerShell.
Sin embargo, los cmdlets de AAS del módulo Az.AnalysisServices no son compatibles
con los conjuntos de datos de Power BI. En su lugar, use los cmdlets de Microsoft Power
BI para Windows PowerShell y PowerShell Core.
Registro de diagnóstico
AAS se integra con Azure Monitor para el registro de diagnóstico. El destino más común
para los registros de AAS es las áreas de trabajo de Log Analytics.
Power BI Premium también admite el registro en áreas de trabajo de Log Analytics.

Actualmente, los eventos enviados a Log Analytics son principalmente eventos del
motor AS. Sin embargo, no todos los eventos admitidos para AAS son compatibles con
Power BI. El esquema de Log Analytics para Power BI contiene diferencias en
comparación con AAS, lo que significa que es posible que las consultas existentes en
AAS no funcionen en Power BI.
Power BI ofrece otra funcionalidad de registro de diagnóstico que no se ofrece en AAS.

Para más información, consulte Uso de la aplicación de métricas Premium.
Los eventos extendidos de SQL Server (xEvents) son compatibles con AAS pero no con
Power BI Premium. Para más información, vea Supervisar Analysis Services con SQL
Server Extended Events.
Negocio a negocio (B2B)

Tanto AAS como Power BI admiten la colaboración B2B de Azure AD, que permite y rige
el uso compartido con usuarios externos. En concreto, el formato de nombre principal
de usuario (UPN) requerido por AAS es diferente a Power BI.
Para identificar al usuario, Power BI usa una notificación de nombre único en Azure AD,
mientras que AAS usa una notificación de correo electrónico. Aunque puede haber
muchas instancias en las que estos dos identificadores se alineen, el formato de nombre
único es más estricto. Si usa RLS dinámico en Power BI, asegúrese de que el valor de la
tabla de identidad de usuario coincida con la cuenta usada para iniciar sesión en Power
BI.
Escalado horizontal
La escalabilidad horizontal de Azure Analysis Services es compatible con Power BI
Premium. Para más información, consulte Escalabilidad horizontal del conjunto de datos
de Power BI.
Característica de migración
La característica de migración de Microsoft Azure Analysis Services a Microsoft Power BI
Premium de Power BI migra como base de datos de AAS a un conjunto de datos en
Power BI Premium, a Power BI Premium por usuario o al área de trabajo de Power BI
Embedded. Para más información, consulte Migración de Azure Analysis Services a
Power BI.
Pasos siguientes
Migración de Azure Analysis Services a Power BI Premium: escenarios de migración
Migración de Azure Analysis Services a Power BI (versión preliminar)
¿Tiene alguna pregunta? Pruebe a preguntar a la Comunidad de Power BI
Los partners de Power BI están disponibles para ayudar a su organización a tener éxito
en el proceso de migración. Para ponerse en contacto con un partner de Power BI, visite
el portal de partners de Power BI .
Migración de Azure Analysis Services a
Power BI Premium: escenarios de
migración
En este artículo se comparan seis escenarios hipotéticos al realizar la migración de

Azure Analysis Services (AAS) a Power BI Premium. Estos escenarios pueden ayudarle a
determinar el tipo y el número adecuados de licencias para sus requisitos y
circunstancias empresariales.
７ Nota
Se ha intentado garantizar que estos escenarios sean representativos de las

migraciones de los clientes reales; sin embargo, los escenarios de clientes
individuales serán, por supuesto, diferentes. Además, en este artículo no se
incluyen detalles de precios. Aquí puede encontrar los precios actuales:
Precios de Power BI
Al comparar los costos de Power BI Premium con AAS, asegúrese de tener en cuenta
otros factores más allá del precio por núcleo. Power BI ofrece un costo reducido de valor
empresarial y de propiedad, con muchas características que solo están disponibles para
los modelos de datos de Power BI.
Además, en el supuesto de que ya use Power BI en su organización, calcule los costos en

función del perfil existente que combina AAS y Power BI. Compare el perfil existente con
el perfil de destino en Power BI Premium. Para determinar el perfil de destino, asegúrese
de tener en cuenta los puntos siguientes:
Requisitos de la región.
El tamaño del modelo de datos de AAS más grande en cada región.
Número de usuarios de cada región.
Número de usuarios necesarios para desarrollar y administrar contenido.
El consumo de CPU en AAS y Power BI Premium.
） Importante
El consumo de CPU en AAS y Power BI Premium puede variar significativamente
debido a numerosos factores. Entre estos puede incluirse el uso de otras cargas de
trabajo en las mismas capacidades, patrones de actualización y patrones de
consulta. Se recomienda realizar un análisis detallado para cuantificar el consumo
comparativo de CPU en AAS y Power BI Premium para los modelos migrados.
Escenario de migración 1
En el primer escenario de migración, el cliente usa Power BI Premium para el front-end y
AAS para el back-end. Hay 20 desarrolladores, cada uno de ellos responsable de los
entornos de desarrollo y prueba, así como de la implementación en producción.
Estas son sus licencias de AAS actuales:
Entorno Modelo más grande AAS SKU
Producción 60 GB S4
Prueba 5 GB B1
Desarrollo 1 GB D1
Estas son sus licencias de Power BI actuales:
Entorno Licencia de Power BI Usuarios
Producción Premium P2 5\.000
Pruebas y desarrollo Premium P1 20
Producción, pruebas y desarrollo Pro 20
Una vez que se haya migrado a Power BI Premium:
Los tres modelos de producción existentes de AAS se pueden consolidar para

ejecutarse en una capacidad Premium P3.
Los 20 desarrolladores necesitarán licencias Premium por usuario (PPU) para
acceder a los modelos de prueba con un tamaño superior a 1 GB.
Estas son las licencias de Power BI propuestas:

Entorno Licencia de Power BI Usuarios Modelo más grande
Producción Premium P3 5\.000 60 GB
Producción, pruebas y desarrollo PPU 20 5 GB
En este escenario de migración, el cliente usa Power BI Premium para el front-end y AAS
para el back-end. Los entornos de producción se ejecutan en regiones diferentes. Hay
20 desarrolladores, cada uno de ellos responsable de los entornos de desarrollo y
prueba, así como de la implementación en producción.
Región Entorno Modelo más grande AAS SKU
Oeste de Europa Producción 60 GB S4
Sur de Brasil Producción 30 GB S2
Oeste de EE. UU. Producción 15 GB S1
Oeste de EE. UU. Prueba 5 GB B1
Oeste de EE. UU. Desarrollo 1 GB D1
Región Entorno Licencia de Power BI Usuarios
Oeste de Europa Producción Premium P1 2\.000
Sur de Brasil Producción Premium P1 2\.000
Oeste de EE. UU. Producción Premium P1 2\.000
Oeste de EE. UU. Pruebas y desarrollo Premium P1 20
Oeste de EE. UU. Producción, pruebas y desarrollo Pro 20
El cliente necesita una capacidad Premium en cada una de las tres regiones
(porque los tres modelos de producción existentes de AAS se ejecutan en regiones
distintas). El tamaño de cada capacidad se basa en el modelo más grande.
Los 20 desarrolladores necesitarán licencias PPU para acceder a los modelos de
prueba de un tamaño superior a 1 GB.
Región Entorno Licencia de Usuarios Modelo más

Power BI grande
Oeste de Producción Premium P3 2\.000 60 GB

Europa
Sur de Brasil Producción Premium P2 2\.000 30 GB
Oeste de EE. Producción Premium P1 2\.000 15 GB

UU.
Oeste de EE. Producción, pruebas y PPU 20 5 GB

UU. desarrollo
En este escenario de migración, el cliente tiene disponibles licencias de Power BI Pro
para todos los usuarios con la suscripción de Office 365 E5 y se usa AAS para el back-
end. Hay 15 desarrolladores, cada uno de ellos responsable de los entornos de
desarrollo y prueba, así como de la implementación en producción.
Prueba 5 GB B1
Desarrollo 1 GB D1
Producción Pro (como parte de E5) 4\.000
Producción, pruebas y desarrollo Pro (como parte de E5) 15

Los dos modelos AAS de producción existentes se pueden consolidar para
prueba de un tamaño superior a 1 GB. (Hay un complemento disponible para
pasar de Pro a PPU).
Producción Premium P2 4\.000 35 GB
En este escenario de migración, el cliente tiene licencias de Power BI Pro para todos los
usuarios y se utiliza AAS para el back-end. Hay cinco desarrolladores, cada uno de ellos
responsable de los entornos de desarrollo y prueba, así como de la implementación en
producción.
Prueba 5 GB B1
Desarrollo 1 GB D1
Producción Pro 350
Los dos modelos de producción existentes de AAS se pueden ejecutar en áreas de

trabajo de PPU.
Todos los usuarios finales y los desarrolladores necesitarán licencias PPU.
Producción PPU 350 35 GB
En este escenario de migración, el cliente usa Power BI Premium para el front-end y AAS
para el back-end. Hay 25 desarrolladores, cada uno de ellos responsable de los entornos
de desarrollo y prueba, así como de la implementación en producción.
Prueba 5 GB B1
Desarrollo 1 GB D1
Producción Premium P3 7 500
Producción Premium P2 4500
Pruebas y desarrollo Premium P1 25
Los tres modelos de producción existentes de AAS se pueden consolidar para

prueba de un tamaño superior a 1 GB.
Producción Premium P5 12,000 220 GB
En este escenario de migración, una empresa de ISV tiene 400 clientes. Cada cliente
tiene su propio modelo multidimensional de SQL Server Analysis Services (SSAS)
(también conocido como cubo). En el análisis siguiente se compara Azure Analysis
Services con la alternativa Power BI Embedded.
A los 400 inquilinos acceden principalmente 50 analistas de la empresa de ISV, así

como dos usuarios (de media) desde cada cliente.
El tamaño total de los modelos es de aproximadamente 100 GB.
Estas son sus licencias de AAS estimadas:
Producción 8 GB S4
Prueba 8 GB B1
Desarrollo 1 GB D1
Usuarios Licencia de Power BI Usuarios
Clientes Pro 800
Analistas Pro 50
Desarrolladores Pro 20
La SKU A1/P4 se ha elegido para permitir el crecimiento futuro del tamaño del
modelo (la SKU EM3/A3 también puede funcionar).
Los 50 analistas necesitarán licencias PPU para acceder a los modelos de prueba
de un tamaño superior a 1 GB.
El tamaño total de los 400 modelos no es relevante para los precios; solo es
importante el tamaño de modelo más grande.
Entorno Licencia de Power BI Usuarios Modelo más

grande
Producción Premium P1 / Power BI No es 25 GB

Embedded A4 aplicable
Pruebas y desarrollo Premium EM3 / Power BI No es 10 GB

Embedded A3 aplicable
Desarrolladores Pro 20 No es aplicable
Producción, pruebas y PPU 50 No es aplicable

desarrollo
Ventajas de migración de Premium

Los clientes pueden obtener muchas ventajas al migrar de AAS a Power BI Premium.
Pueden realizar la consolidación en una sola plataforma, lo que reduce la

duplicación de costos que implica pagar tanto por AAS como por Power BI
Premium.
Al usar Premium para toda la pila de BI, los clientes pueden obtener un mayor
rendimiento y más características. Solo se necesitan licencias Pro para los
desarrolladores y los administradores, pero no para los usuarios finales.
Los clientes pueden usar la escalabilidad de Power BI Premium para reducir sus
requisitos de capacidad, ya que la memoria se limita por conjunto de datos y no se
compara con el total del servidor, como se hace en AAS. Para más información,
consulte Asignación de memoria.
En los entornos de desarrollo y prueba, los clientes pueden aprovechar las licencias
PPU en lugar de tener capacidades Premium. Las licencias PPU proporcionan a los
usuarios acceso a características Premium como el punto de conexión XMLA, las
canalizaciones de implementación y las características de flujos de datos Premium.
Además, pueden trabajar con modelos que tengan un tamaño superior a 1 GB.
Pasos siguientes
Migración de Azure Analysis Services a Power BI Premium

¿Qué es Power BI Premium?
Precios de Power BI
¿Tiene alguna pregunta? Pruebe a preguntar a la Comunidad de Power BI
Uso adecuado de las funciones de error
Como modelador de datos, al escribir una expresión DAX que podría generar un error
en tiempo de evaluación, puede considerar el uso de dos funciones DAX útiles.
La función ISERROR, que toma una sola expresión y devuelve TRUE si se produce
un error.
La función IFERROR, que toma dos expresiones. Si la primera expresión genera un
error, se devuelve el valor de la segunda expresión. En realidad, es una
implementación más optimizada del anidamiento de la función ISERROR dentro de
una función IF.
Sin embargo, aunque estas funciones pueden ser útiles y pueden contribuir a escribir
expresiones fáciles de entender, también pueden degradar significativamente el
rendimiento de los cálculos. Puede suceder ya que estas funciones aumentan el número
de exámenes del motor de almacenamiento necesarios.
La mayoría de los errores en tiempo de evaluación se deben a valores BLANK o cero

inesperados, o bien a una conversión de tipo de datos no válida.
Recomendaciones
Es mejor evitar el uso de las funciones ISERROR e IFERROR. En su lugar, aplique
estrategias defensivas al desarrollar el modelo y escribir expresiones. Las estrategias
pueden incluir lo siguiente:
Garantizar que se cargan datos de calidad en el modelo: Utilice transformaciones

de Power Query para quitar o sustituir valores no válidos o ausentes, y para
establecer los tipos de datos correctos. También se puede utilizar una
transformación de Power Query para filtrar las filas cuando se producen errores,
como la conversión de datos no válida.
También se puede controlar la calidad de los datos si se establece la propiedad Is

Nullable de la columna del modelo en Off, lo que producirá un error en la
actualización de los datos en caso de que se encuentren valores BLANK. Si se
produce este error, los datos cargados como resultado de una actualización
correcta permanecerán en las tablas.
Uso de la función IF: La expresión de la prueba lógica de la función IF puede

determinar si se produciría un resultado de error. Tenga en cuenta que, al igual
que las funciones ISERROR e IFERROR, esta función puede producir exámenes
adicionales del motor de almacenamiento, pero es probable que funcione mejor
que estos ya que no es necesario generar ningún error.
Usar funciones tolerantes a errores: Algunas funciones de DAX probarán y

compensarán las condiciones de error. Estas funciones permiten especificar un
resultado alternativo que se devolvería en su lugar. La funciónDIVIDE es un
ejemplo de este tipo. Para obtener más información sobre esta función, lea el
artículo DAX: función DIVIDE frente al operador de división (/).
Ejemplo
La expresión de medida siguiente comprueba si se produciría un error. Devuelve BLANK
en esta instancia (que es el caso cuando no se proporciona la función IF con una
expresión de valor por si es falso).
DAX
Profit Margin
= IF(ISERROR([Profit] / [Sales]))
La siguiente versión de la expresión de medida se ha mejorado mediante el uso de la

función IFERROR en lugar de las funciones IF e ISERROR.
DAX
Profit Margin
= IFERROR([Profit] / [Sales], BLANK())
Sin embargo, esta versión final de la expresión de medición consigue el mismo

resultado, pero de forma más eficaz y elegante.
DAX
Profit Margin
= DIVIDE([Profit], [Sales])
Consulte también
Ruta de aprendizaje: Uso de DAX en Power BI Desktop
Impedimento de la conversión de
BLANK en valores
Como modelador de datos, al escribir expresiones de medida es posible que se

encuentre casos en los que no se puede devolver un valor significativo. En tales casos,
es posible que le tiente devolver un valor (por ejemplo, cero). Se recomienda decidir
detenidamente si este diseño es eficaz y práctico.
Tenga en cuenta la siguiente definición de medida, que convierte de forma explícita los
resultados en blanco en cero.
DAX
Sales (No Blank) =

IF(
ISBLANK([Sales]),
0,
[Sales]
)
Tenga en cuenta otra definición de medida, que también convierte los resultados en
blanco en cero.
DAX
Profit Margin =
DIVIDE([Profit], [Sales], 0)
La función DIVIDE divide la medida Profit por la medida Sales. Si el resultado es cero o
está en blanco, se devolverá el tercer argumento: el resultado alternativo (que es
opcional). En este ejemplo, dado que se pasa cero como resultado alternativo, se
garantiza que la medida siempre devolverá un valor.
Estos diseños de medida son ineficaces y dan lugar a diseños de informes deficientes.
Cuando se agregan a un objeto visual de informe, Power BI intenta recuperar todas las
agrupaciones del contexto del filtro. La evaluación y la recuperación de resultados de
consultas de gran tamaño suelen comportar una representación lenta de los informes.
Cada medida de ejemplo convierte de forma eficaz un cálculo disperso en uno denso, lo
que fuerza que Power BI use más memoria de la necesaria.
Además, si hay demasiadas agrupaciones, los usuarios de los informes podrían
saturarse.
Veamos lo que sucede cuando se agrega la medida Profit Margin a un objeto visual de
tabla, agrupando por cliente.
El objeto visual de tabla muestra un enorme número de filas (en realidad hay 18 484
clientes en el modelo, por lo que la tabla intenta mostrarlos todos). Tenga en cuenta que
los clientes de la vista no han conseguido ninguna venta. Pero como la medida Profit
Margin siempre devuelve un valor, estos se muestran.
７ Nota
Cuando hay demasiados puntos de datos para mostrarlos en un objeto visual,

Power BI puede usar las estrategias de reducción de datos para quitar o resumir los
resultados de consultas de gran tamaño. Para obtener más información, consulte
Límites de punto de datos y estrategias por tipo de objeto visual.
Veamos lo que sucede cuando se mejora la definición de la medida Profit Margin.

Ahora devuelve un valor solo si la medida Sales no está en blanco (o cero).
DAX
Profit Margin =
DIVIDE([Profit], [Sales])
El objeto visual de tabla ahora muestra solo los clientes que han tenido ventas en el
contexto de filtro actual. La medida mejorada da como resultado una experiencia más
eficaz y práctica para los usuarios de los informes.
 Sugerencia
Si es necesario, puede configurar un objeto visual para mostrar todas las

agrupaciones (que devuelven valores o en blanco) dentro del contexto de filtro
habilitando la opción Mostrar elementos sin datos.
Recomendación
Se recomienda que las medidas devuelvan un valor en blanco si no se puede devolver
un valor significativo.
Este enfoque de diseño es eficaz, lo que permite a Power BI representar los informes
con mayor rapidez. Además, la devolución de un valor BLANK es más indicada ya que,
de forma predeterminada, los objetos visuales de los informes eliminan las
agrupaciones cuando los resúmenes están en blanco.
Consulte también
Evitar el uso de FILTER como argumento
de filtro
Como modelador de datos, es habitual que escriba expresiones DAX que se deban
evaluar en un contexto de filtro modificado. Por ejemplo, puede escribir una definición
de medida para calcular las ventas de "productos de margen alto". Este cálculo se
describe más adelante.
７ Nota
Este artículo resulta especialmente pertinente para los cálculos de modelos que
aplican filtros a las tablas de importación.
Las funciones DAX CALCULATE y CALCULATETABLE son importantes y útiles. Le permiten

escribir cálculos que quitan o agregan filtros, o que modifican las rutas de acceso de las
relaciones. Se realiza pasando argumentos de filtro, que son expresiones booleanas,
expresiones de tabla o funciones de filtro especiales. En este artículo solo trataremos las
expresiones booleanas y de tabla.
Valore la siguiente definición de medida, que calcula las ventas de productos de color
rojo mediante una expresión de tabla. Reemplazará todos los filtros que se puedan
aplicar a la tabla Producto.
DAX
Red Sales =
CALCULATE(
[Sales],
FILTER('Product', 'Product'[Color] = "Red")
)
La función CALCULATE acepta una expresión de tabla devuelta por la función DAX
FILTER, que evalúa su expresión de filtro para cada fila de la tabla Producto. Obtiene el
resultado correcto: el de ventas de los productos rojos. Sin embargo, se podría lograr de
forma mucho más eficaz mediante el uso de una expresión booleana.
Esta es una definición de medida mejorada, que usa una expresión booleana en lugar de
la expresión de tabla. La función DAX KEEPFILTERS garantiza que se conservan los filtros
existentes aplicados a la columna de Color y no se sobrescriban.
DAX
Red Sales =
CALCULATE(
[Sales],
KEEPFILTERS('Product'[Color] = "Red")
)
Se recomienda pasar argumentos de filtro como expresiones booleanas, siempre que

sea posible. Se debe a que las tablas de modelo de importación son almacenes de
columnas en memoria. Están optimizadas explícitamente para filtrar de forma eficaz las
columnas de esta manera.
Sin embargo, hay restricciones que se aplican a expresiones booleanas cuando se usan
como argumentos de filtro. Son las siguientes:
No se puede hacer referencia a columnas de varias tablas

No pueden hacer referencia a una medida.
No pueden usar funciones CALCULATE anidadas.
No pueden usar funciones que examinen o devuelvan una tabla.
Esto significa que necesitará usar expresiones de tabla para requisitos de filtro más
complejos.
Tome ahora una definición de medida diferente. Esta vez, el requisito es calcular las
ventas, pero solo para los meses en los que se haya logrado un beneficio.
DAX
Sales for Profitable Months =

CALCULATE(
[Sales],
FILTER(
VALUES('Date'[Month]),
[Profit] > 0)
)
)
En este ejemplo se debe usar la función FILTER. Se debe a que es necesario evaluar la
medida Beneficio para eliminar los meses en los que no se logró un beneficio. No es
posible usar una medida en una expresión booleana cuando se usa como un argumento
de filtro.
Recomendaciones
Para obtener el mejor rendimiento, se recomienda usar expresiones booleanas como
argumentos de filtro, siempre que sea posible.
Por lo tanto, la función FILTER solo debe usarse cuando sea necesario. Puede utilizarla
para realizar comparaciones de columnas complejas de filtro. Estas comparaciones de
columnas pueden implicar:
Medidas
Otras columnas
Uso de la función DAX OR o el operador lógico OR (||)
Consulte también
Funciones de filtro (DAX)
Referencias de columnas y medidas
Como modelador de datos, las expresiones DAX harán referencia a las columnas y
medidas del modelo. Las columnas y las medidas siempre están asociadas a las tablas
del modelo, pero estas asociaciones son diferentes, por lo que son diferentes las
recomendaciones sobre cómo hacer referencia a ellas en las expresiones.
Columnas
Una columna es un objeto de nivel de tabla y los nombres de columna deben ser únicos
en una tabla. Por tanto, se puede usar el mismo nombre de columna varias veces en el
modelo, siempre que pertenezca a tablas diferentes. Hay una regla más: un nombre de
columna no puede ser el mismo que el de una medida o una jerarquía de la misma
tabla.
Por lo general, DAX no forzará el uso de una referencia completa a una columna. Una
referencia completa significa que el nombre de la tabla precede al nombre de la
columna.
Este es un ejemplo de una definición de columna calculada en la que solo se usan

referencias de nombre de columna. Las columnas Sales y Cost pertenecen a una tabla
denominada Orders.
DAX
Profit = [Sales] - [Cost]
Se puede volver a escribir la misma definición con referencias de columna completas.
DAX
Profit = Orders[Sales] - Orders[Cost]
Pero, en ocasiones, se le pedirá que use referencias de columna completas cuando

Power BI detecte ambigüedades. Al escribir una fórmula, se le avisará mediante un
mensaje de error con una línea ondulada de color rojo. Además, algunas funciones DAX,
como LOOKUPVALUE, requieren el uso de columnas completas.
Se recomienda usar siempre nombres completos para las referencias de columna. Los
motivos se proporcionan en la sección Recomendaciones.
Medidas
Una medida es un objeto de nivel de modelo. Por esta razón, los nombres de medida
deben ser únicos en el modelo. Pero en el panel Campos, los autores del informe verán
cada medida asociada a una sola tabla de modelo. Esta asociación se establece por
motivos cosméticos y puede configurarla si establece la propiedad Tabla inicial de la
medida. Para obtener más información, vea Medidas en Power BI Desktop (organización
de las medidas).
Es posible usar una medida completa en las expresiones. IntelliSense para DAX ofrecerá
incluso la sugerencia. Pero no es necesario y no es un procedimiento recomendado. Si
cambia la tabla inicial de una medida, se interrumpirán todas las expresiones en las que
se use una referencia de medida completa. Después, tendrá que editar cada fórmula
interrumpida para quitar (o actualizar) la referencia de la medida.
Se recomienda no calificar nunca las referencias de medidas. Los motivos se

proporcionan en la sección Recomendaciones.
Recomendaciones
Nuestras recomendaciones son sencillas y fáciles de recordar:
Usar siempre nombres completos de referencias de columna

No usar nunca nombres completos de referencias de medida
Aquí se detallan los motivos:
Entrada de fórmula: se aceptarán expresiones, ya que no habrá ninguna referencia

ambigua que resolver. Además, cumplirá los requisitos para las funciones DAX que
requieren referencias de columna completas.
Solidez: las expresiones seguirán funcionando, incluso cuando cambie una
propiedad de la tabla inicial de la medida.
Legibilidad: las expresiones serán rápidas y fáciles de entender: determinará
rápidamente que es una columna o medida, en función de si está completa o no.
Consulte también
Función DIVIDE frente al operador de
división (/)
Como modelador de datos, al escribir una expresión DAX para dividir un numerador por
un denominador, puede usar la función DIVIDE o el operador de división (/: barra
diagonal).
Cuando se usa la función DIVIDE, se deben pasar expresiones de numerador y

denominador. Opcionalmente, puede pasar un valor que representa un resultado
alternativo.
DAX
DIVIDE(<numerator>, <denominator> [,<alternateresult>])
La función DIVIDE se ha diseñado para controlar de forma automática los casos de

división entre cero. Si no se pasa un resultado alternativo y el denominador es cero o
está en blanco, la función devuelve un valor en blanco. Al pasar un resultado alternativo,
se devuelve, en lugar de ofrecer un valor en blanco.
La función DIVIDE es útil porque guarda la expresión para que no tenga que probar
primero el valor del denominador. La función también está mejor optimizada para
probar el valor del denominador que la función IF. La mejora del rendimiento es
importante, ya que la búsqueda de la división entre cero resulta costosa. El uso adicional
de DIVIDE da lugar a una expresión más concisa y elegante.
Ejemplo
La siguiente expresión de medición genera una división segura, pero implica el uso de
cuatro funciones DAX.
DAX
Profit Margin =
IF(
OR(
ISBLANK([Sales]),
[Sales] == 0
),
BLANK(),
[Profit] / [Sales]
)
Esta expresión de medición consigue el mismo resultado, pero de forma más eficaz y
elegante.
DAX
Profit Margin =
DIVIDE([Profit], [Sales])
Recomendaciones
Se recomienda usar la función DIVIDE siempre que el denominador sea una expresión
que pueda devolver cero o BLANK.
En el caso de que el denominador sea un valor constante, se recomienda el uso del

operador de división. En este caso, la división tiene la garantía de que se realizará
correctamente y la expresión funcionará mejor porque evitará pruebas innecesarias.
Considere detenidamente si la función DIVIDE debe devolver un valor alternativo. En el

caso de las medidas, normalmente se trata de un mejor diseño, ya que devuelven un
valor BLANK. La devolución de un valor BLANK es más indicada ya que, de forma
predeterminada, los objetos visuales de los informes eliminan las agrupaciones cuando
los resúmenes están en blanco. Esto permite que el objeto visual se centre en los grupos
en los que existen los datos. Si es necesario, en Power BI puede configurar el objeto
visual para mostrar todos los grupos (que devuelven valores o BLANK) dentro del
contexto de filtro si habilita la opción Mostrar elementos sin datos.
Consulte también
Uso de COUNTROWS en lugar de
COUNT
Como modelador de datos, en ocasiones es posible que tenga que escribir una
expresión DAX que cuente las filas de una tabla. La tabla puede ser una tabla modelo o
una expresión que devuelve una tabla.
Su requisito se puede satisfacer de dos formas. Puede usar la función COUNT para
contar los valores de la columna o bien puede usar la función COUNTROWS para contar
las filas de la tabla. Ambas funciones lograrán el mismo resultado, siempre y cuando la
columna contada no contenga ningún valor en blanco.
La siguiente definición de medida presenta un ejemplo. Calcula el número de valores de

columna OrderDate.
DAX
Sales Orders =
COUNT(Sales[OrderDate])
Siempre que la granularidad de la tabla Sales sea una fila por pedido de venta y la
columna OrderDate no contenga ningún valor en blanco, la medida devolverá un
resultado correcto,
pero la siguiente definición de medida es una solución mejor.
DAX
Sales Orders =
COUNTROWS(Sales)
Hay tres motivos por los que la segunda definición de medida es mejor:
Es más eficaz y, por lo tanto, funcionará mejor.

No tiene en cuenta los valores en blanco incluidos en las columnas de la tabla.
La intención de la fórmula es más clara, hasta el punto de ser autodescriptiva.
Recomendación
Si su intención es contar las filas de una tabla, se recomienda usar siempre la función
COUNTROWS.
Consulte también
Uso de SELECTEDVALUE en lugar de
VALUES
Como modelador de datos, es posible que en ocasiones tenga que escribir una
expresión DAX que compruebe si una columna está filtrada por un valor específico.
En versiones anteriores de DAX, este requisito se satisfacía de forma segura con un

patrón que implicaba tres funciones DAX: IF, HASONEVALUE y VALUES. La siguiente
definición de medida presenta un ejemplo. Calcula el importe del impuesto de ventas,
pero solo de las ventas efectuadas a los clientes de Australia.
DAX
Australian Sales Tax =

IF(
HASONEVALUE(Customer[Country-Region]),
IF(
VALUES(Customer[Country-Region]) = "Australia",
[Sales] * 0.10
)
)
En el ejemplo, la función HASONEVALUE devuelve TRUE solo cuando un único valor de

la columna Country-Region es visible en el contexto de filtro actual. Si es TRUE, la
función VALUES se compara con el texto literal "Australia". Si la función VALUES
devuelve TRUE, la medida Sales se multiplica por 0,10 (que representa el 10%). Si la
función HASONEVALUE devuelve FALSE (ya que más de un valor filtra la columna), la
primera función IF devolverá un valor en blanco.
El uso de HASONEVALUE es una técnica defensiva. Es necesario porque es posible que

varios valores filtren la columna Country-Region. En este caso, la función VALUES
devuelve una tabla de varias filas. La comparación de una tabla de varias filas con un
valor escalar genera un error.
Recomendación
Se recomienda usar la función SELECTEDVALUE. Logra el mismo resultado que el patrón
que se describe en este artículo, pero de forma más eficaz y elegante.
Con la función SELECTEDVALUE, ahora se reescribe la definición de la medida de

ejemplo.
DAX
Australian Sales Tax =

IF(
SELECTEDVALUE(Customer[Country-Region]) = "Australia",
[Sales] * 0.10
)
 Sugerencia
Es posible pasar un valor de resultado alternativo a la función SELECTEDVALUE. Se

devuelve el valor de resultado alternativo cuando no se aplica ningún filtro (o se
aplican varios) a la columna.
Consulte también
Uso de variables para mejorar las
fórmulas DAX
Como modelador de datos, escribir y depurar algunos cálculos DAX puede ser complejo.
Es habitual que los requisitos de cálculos complejos impliquen a menudo la escritura de
expresiones compuestas o complejas. Las expresiones compuestas pueden implicar el
uso de muchas funciones anidadas y, posiblemente, la reutilización de la lógica de
expresión.
El uso de variables en las fórmulas DAX puede ayudarle a escribir cálculos complejos y
eficaces. Las variables pueden mejorar el rendimiento, la fiabilidad y la legibilidad, y
reducir la complejidad.
En este artículo se mostrarán las tres primeras ventajas con una medida de ejemplo para
el crecimiento de ventas de año a año (YoY). (La fórmula del crecimiento de ventas YoY
es la siguiente: ventas por periodo, menos ventas del mismo periodo del año pasado,
dividido por las ventas del mismo periodo del año pasado).
Comencemos con la siguiente definición de medida.
DAX
Sales YoY Growth % =

DIVIDE(
([Sales] - CALCULATE([Sales], PARALLELPERIOD('Date'[Date], -12,
MONTH))),
CALCULATE([Sales], PARALLELPERIOD('Date'[Date], -12, MONTH))
)
La medida genera el resultado correcto, pero veamos cómo se puede mejorar.
Mejorar el rendimiento
Observe que la fórmula repite la expresión que calcula "el mismo período del año
pasado". Esta fórmula es ineficaz, ya que fuerza a Power BI a evaluar la misma expresión
dos veces. La definición de la medida se puede hacer más eficaz usando una variable,
VAR.
La siguiente definición de medida representa una mejora. Usa una expresión para
asignar el resultado "del mismo período del año pasado" a una variable denominada
SalesPriorYear. Entonces, la variable se usa dos veces en la expresión RETURN.
DAX

VAR SalesPriorYear =
RETURN
DIVIDE(([Sales] - SalesPriorYear), SalesPriorYear)
La medida sigue generando el resultado correcto y lo hace en más o menos la mitad del
tiempo de consulta.
Mejorar la legibilidad
En la definición de medida anterior, observe cómo la elección del nombre de la variable
hace que la expresión RETURN sea más fácil de entender. La expresión es breve y
autodescriptiva.
Simplificar la depuración
Las variables también pueden ayudarle a depurar una fórmula. Para probar una
expresión asignada a una variable, debe reescribir temporalmente la expresión RETURN
para generar la variable.
La siguiente definición de medida solo devuelve la variable SalesPriorYear. Observe

cómo quita la marca de comentario de la expresión RETURN deseada. Con esta técnica
puede revertirla fácilmente una vez concluida la depuración.
DAX

VAR SalesPriorYear =
RETURN
--DIVIDE(([Sales] - SalesPriorYear), SalesPriorYear)
SalesPriorYear
Reducir la complejidad
En versiones anteriores de DAX, las variables aún no eran compatibles. Las expresiones
complejas que incorporaban nuevos contextos de filtro eran necesarias para usar las
funciones DAX EARLIER o EARLIEST para hacer referencia a contextos de filtro externos.
Desafortunadamente, para los modeladores de datos estas funciones eran difíciles de
comprender y de usar.
Las variables siempre se evalúan fuera de los filtros a los que se aplica la expresión
RETURN. Por este motivo, a la hora de usar una variable dentro de un contexto de filtro
modificado, se obtiene el mismo resultado que con la función EARLIEST. Por lo tanto, se
puede evitar el uso de las funciones EARLIER o EARLIEST. Es decir, ahora puede escribir
fórmulas menos complejas y más fáciles de entender.
Observe la siguiente definición de columna calculada que se ha agregado a la tabla

Subcategoría. Evalúa un rango para cada subcategoría de producto en función de los
valores de la columna Subcategory Sales (Ventas por subcategoría).
DAX
Subcategory Sales Rank =

COUNTROWS(
FILTER(
Subcategory,
EARLIER(Subcategory[Subcategory Sales]) < Subcategory[Subcategory
Sales]
)
) + 1
La función EARLIER sirve para hacer referencia al valor de la columna Subcategory

Salesen el contexto de fila actual.
La definición de la columna calculada se puede mejorar usando una variable en lugar de

la función EARLIER. La variable CurrentSubcategorySales almacena el valor de la
columna Subcategory Salesen el contexto de fila actual y la expresión RETURN la usa en
un contexto de filtro modificado.
DAX
Subcategory Sales Rank =

VAR CurrentSubcategorySales = Subcategory[Subcategory Sales]
RETURN
COUNTROWS(
FILTER(
Subcategory,
CurrentSubcategorySales < Subcategory[Subcategory Sales]
)
) + 1
Consulte también
Artículo DAX VAR
Modelo de ejemplo de DAX
El modelo de ejemplo Adventure Works DW 2020 de Power BI Desktop está diseñado

para admitir el aprendizaje de DAX. El modelo se basa en el ejemplo de almacenamiento
de datos de Adventure Works para AdventureWorksDW2017, pero los datos se
modificaron para satisfacer los objetivos del modelo de ejemplo.
El modelo de ejemplo no contiene ninguna fórmula DAX. Sin embargo, admite cientos
o, incluso, miles de posibles fórmulas de cálculo y consultas. Algunas funciones de
ejemplo, como las de CALCULATE, DATESBETWEEN, DATESIN PERIOD, IF y
LOOKUPVALUE, se pueden agregar al modelo de ejemplo sin modificaciones. Estamos
trabajando para incluir más ejemplos en otros artículos de referencia de funciones que
operan con el modelo de ejemplo.
Escenario
La empresa Adventure Works representa a un fabricante de bicicletas que vende

bicicletas y accesorios en mercados globales. La empresa tiene sus datos de
almacenamiento de datos almacenados en una instancia de Azure SQL Database.
Estructura del modelo

El modelo tiene siete tablas:
Tabla Descripción
Customer Describe los clientes y su ubicación geográfica. Los clientes compran productos en
línea (ventas por Internet).
Date Hay tres relaciones entre las tablas Date y Sales, para la fecha del pedido, la fecha de
envío y la fecha de vencimiento. La relación de fecha de pedido está activa. Los
informes de ventas de la empresa usan un año fiscal que comienza el 1 de julio de
cada año. La tabla se marca como una tabla de fechas con la columna Date.
Tabla Descripción
Producto Almacena solo los productos terminados.
Reseller Describe los revendedores y su ubicación geográfica. Revendedor en la venta de

productos a sus clientes.
Sales Almacena filas en la línea de pedido de ventas. Todos los valores financieros están en
dólares estadounidenses (USD). La fecha de pedido más temprana es el 1 de julio de
2017 y la fecha del último pedido es el 15 de junio de 2020.
Sales Describe los números de pedido de ventas y los números de línea de pedido, además
Order del canal de ventas, que es Revendedor o Internet. Esta tabla tiene una relación uno
a uno con la tabla Sales.
Sales Los territorios de ventas están organizados en grupos (Norteamérica, Europa y

Territory Pacífico), países y regiones. Solo el grupo de Estados Unidos vende productos en el
nivel de región.
Descarga de un ejemplo
Descargue el archivo de modelo de ejemplo de Power BI Desktop aquí .
Consulte también
Informes independientes de los
modelos en Power BI Desktop
Al crear una nueva solución de Power BI Desktop, una de las primeras tareas que debe
hacer es obtener los datos. La obtención de los datos puede dar lugar a dos resultados
distintos. Podría:
Crear una conexión dinámica a un modelo ya publicado, que puede ser un

conjunto de datos de Power BI o un modelo de Analysis Services hospedado de
forma remota.
Iniciar el desarrollo de un nuevo modelo, que puede ser un modelo de
importación, DirectQuery o compuesto.
Este artículo está relacionado con el segundo escenario. En él se proporcionan

instrucciones sobre si un informe y un modelo deben combinarse en un único archivo
de Power BI Desktop.
Solución de un solo archivo

Una solución de un solo archivo funciona bien cuando solo hay un informe basado en el
modelo. En este caso, es probable que tanto el modelo como el informe sean producto
del esfuerzo de la misma persona. Se define como una solución de BI personal, aunque
el informe podría compartirse con otros usuarios. Estas soluciones pueden representar
informes de ámbito de rol o evaluaciones únicas de un desafío empresarial, que a
menudo se describen como informes ad hoc.
Archivos de informes independientes

Tiene sentido separar el desarrollo del modelo y el informe en archivos de Power BI
Desktop independientes cuando:
Los modeladores de datos y los autores del informe son personas diferentes.
Se entiende que un modelo será el origen de varios informes, ahora o en el futuro.
Los modeladores de datos pueden seguir usando la experiencia de creación de informes

de Power BI Desktop para probar y validar sus diseños de modelo. Pero solo después de
publicar su archivo en el servicio Power BI podrán quitar el informe del área de trabajo.
Además, deben acordarse de quitar el informe cada vez que vuelvan a publicar y
sobrescribir el conjunto de datos.
Conservación de la interfaz de modelo

A veces, los cambios en el modelo son inevitables. Los modeladores de datos deben
tener cuidado de no interrumpir la interfaz de modelo. Si lo hacen, es posible que se
interrumpan los objetos visuales del informe o los iconos del panel relacionados. Los
objetos visuales interrumpidos aparecen como errores y pueden causar frustración a los
autores y consumidores de informes. Y, lo que es peor, pueden reducir la confianza en
los datos.
Por lo tanto, administre los cambios del modelo con cuidado. Si es posible, evite los
cambios siguientes:
Cambiar el nombre de tablas, columnas, jerarquías, niveles de jerarquía o medidas.

Modificar tipos de datos de columna.
Modificar expresiones de medida para que devuelvan un tipo de datos diferente.
Mover medidas a una tabla inicial diferente. Se debe a que mover una medida
podría interrumpir las medidas de ámbito de informe que califican totalmente las
medidas con el nombre de la tabla inicial. No se recomienda escribir expresiones
DAX mediante nombres de medidas completos. Para obtener más información, vea
DAX: Referencias de columnas y medidas.
Agregar nuevas tablas, columnas, jerarquías, niveles de jerarquía o medidas es seguro,

con una excepción: es posible que un nuevo nombre de medida entre en conflicto con
un nombre de medida con ámbito de informe. Para evitar colisiones, recomendamos
que los autores de informes adopten una convención de nomenclatura al definir
medidas en sus informes. Pueden prefijar nombres de medidas de ámbito de informe
con un guion bajo u otros caracteres.
Si debe realizar cambios importantes en los modelos, se recomienda lo siguiente:
Consulte el contenido relacionado con el conjunto de datos en el servicio Power BI.

Explore la vista de linaje de datos en el servicio Power BI.
Ambas opciones permiten identificar rápidamente los informes y paneles relacionados.

La vista de linaje de datos es probablemente la mejor opción, ya que es fácil ver la
persona de contacto para cada elemento relacionado. De hecho, es un hipervínculo que
abre un mensaje de correo electrónico dirigido al contacto en cuestión.
Se recomienda que se ponga en contacto con el propietario de cada elemento

relacionado para informarle de los cambios importantes planeados. De este modo,
puede prepararse para corregir y volver a publicar sus informes, lo que ayuda a
minimizar el tiempo de inactividad y la frustración.
Pasos siguientes
Conexión a conjuntos de datos del servicio Power BI desde Power BI Desktop

Visualización del contenido relacionado en el servicio Power BI
Linaje de datos
Extensión de objetos visuales con la
información en pantalla de la página del
informe
Este artículo está dirigido a usted como autor de informes que diseña informes de
Power BI. Proporciona sugerencias y recomendaciones a la hora de crear información
sobre herramientas de páginas de informes.
Sugerencias
La información sobre herramientas de páginas de informes puede mejorar la experiencia
de los usuarios de los informes. La información sobre herramientas de páginas permite a
los usuarios de los informes obtener información más detallada de un objeto visual de
forma rápida y eficaz. Pueden asociarse a diferentes objetos de informe:
Objetos visuales: puede configurar qué objetos visuales van a mostrar la

información sobre herramientas de página objeto a objeto. En cada objeto visual
se puede hacer que no muestre información sobre herramientas, que tenga como
valor predeterminado la información sobre herramientas del objeto visual
(configurada en el panel de campos de objetos visuales) o que use cierta
información sobre herramientas de página.
Encabezados visuales: puede configurar objetos visuales específicos para mostrar
información sobre herramientas de página. Los usuarios de los informes pueden
mostrar la información sobre herramientas de una página cuando sitúan el cursor
sobre el icono del encabezado visual; cerciórese de educar a los usuarios sobre
este icono.
７ Nota
Un objeto visual de informe solo puede mostrar cierta información sobre

herramientas de página si los filtros de página de información sobre herramientas
son compatibles con el diseño del objeto visual. Por ejemplo, un objeto visual que
agrupa por producto será compatible con una página de información sobre
herramientas que filtre por producto.
La información sobre herramientas de página no admite la interactividad. Si quiere

que los usuarios de los informes interactúen, deberá crear una página de
obtención de detalles.
Estos son algunos escenarios de diseño propuestos:
Perspectiva diferente
Agregar detalle
Agregar ayuda
Perspectiva diferente
La información sobre herramientas de página puede visualizar los mismos datos que el
objeto visual de origen. Para ello, se deben usar los mismos grupos dinámicos y de
objetos visuales, o bien distintos tipos de objetos visuales. La información sobre
herramientas de página también puede aplicar distintos filtros que los que se aplican al
objeto visual de origen.
En el ejemplo siguiente se muestra lo que sucede cuando el usuario de un informe

mantiene el cursor sobre el valor EnabledUsers. El contexto de filtro del valor es Yammer
en noviembre de 2018.
Se muestra la información sobre herramientas de una página. Presenta un objeto visual

de datos diferente (gráfico de líneas y columnas agrupadas) y aplica un filtro de tiempo
de contraste. Observe que el contexto de filtro del punto de datos es el mes de
noviembre de 2018, pero la información sobre herramientas de la página muestra la
tendencia sobre un año completo de meses.
Agregar detalle
La información sobre herramientas de página puede mostrar más datos y agregar
contexto.

mantiene el cursor sobre el valor Average of Violation Points (Promedio de puntos de
infracción) para el código postal 98022.
Se muestra la información sobre herramientas de una página. Presenta atributos y
estadísticas específicos para el código postal 98022.
Agregar ayuda
Los encabezados visuales se pueden configurar para mostrar la información sobre
herramientas de página en los encabezados visuales. Puede agregar documentación de
ayuda a la información sobre herramientas de una página mediante cuadros de texto
con formato enriquecido. También es posible agregar imágenes y formas.
Curiosamente, los botones, imágenes, cuadros de texto y formas también pueden

mostrar información sobre herramientas de página de un encabezado visual.

mantiene el cursor sobre el icono de encabezado visual.
Se muestra la información sobre herramientas de una página. Muestra texto con

formato enriquecido en cuatro cuadros de texto y una forma (línea). La información
sobre herramientas de la página transmite ayuda mediante la descripción de los
acrónimos que se muestran en el objeto visual.
Recomendaciones
En el momento del diseño del informe, se recomienda aplicar las siguientes prácticas:
Tamaño de página: configure la información sobre herramientas de página para

que sea pequeña. Puede usar la opción integrada Información sobre herramientas
(320 píxeles de ancho y 240 píxeles de alto). También puede establecer
dimensiones personalizadas. Tenga cuidado de no usar un tamaño de página
demasiado grande: podría ocultar los objetos visuales de la página de origen.
Vista de página: en el diseñador de informes, establezca la vista de página en
Tamaño real (el valor predeterminado de la vista de página es Ajustar a la página).
De esta forma, puede ver el tamaño real de la información sobre herramientas de
la página a medida que la diseña.
Estilo: considere la posibilidad de diseñar la información sobre herramientas de
página para usar el mismo tema y estilo que el informe. De este modo, a los
usuarios les parece que se encuentran en el mismo informe. También puede
diseñar un estilo gratuito para la información sobre herramientas. No olvide aplicar
este estilo a toda la información sobre herramientas de página.
Filtros de información sobre herramientas: asigne filtros a la información sobre
herramientas de página para poder obtener una vista previa de un resultado
realista a medida que la diseña. Asegúrese de quitar estos filtros antes de publicar
el informe.
Visibilidad de página: oculte siempre las páginas de información sobre
herramientas: los usuarios no deben acceder directamente a ellas.
Pasos siguientes
Creación de información sobre herramientas basada en páginas de informes en

Power BI Desktop
Personalización de la información sobre herramientas en Power BI Desktop
Uso de elementos visuales para mejorar los informes de Power BI
Uso de detalles de la página del informe
Este artículo está dirigido a usted como autor de informes que diseña informes de
Power BI. Proporciona sugerencias y recomendaciones a la hora de crear una obtención
de detalles de páginas de informes.
Se recomienda diseñar el informe para que los usuarios de los informes puedan tener el
siguiente flujo:
1. Ver una página de informe.

2. Identificar un elemento visual para analizarlo con mayor profundidad.
3. Hacer clic con el botón derecho en el objeto visual para la obtención de detalles.
4. Llevar a cabo un análisis gratuito.
5. Volver a la página del informe de origen.
Sugerencias
Se recomienda tener en cuenta dos tipos de escenarios de obtención de detalles:
Profundidad adicional
Perspectiva más amplia
Profundidad adicional
Cuando la página del informe muestra los resultados resumidos, una página de
obtención de detalles puede dirigir a los usuarios de los informes a los detalles de nivel
de transacción. Este enfoque de diseño les permite ver las transacciones auxiliares (solo
cuando sea necesario).
En el ejemplo siguiente se muestra lo que sucede cuando un usuario de un informe

profundiza a partir de un resumen de ventas mensuales. La página de obtención de
detalles contiene una lista detallada de pedidos de un mes determinado.
Perspectiva más amplia
Una página de obtención de detalles puede tener el efecto contrario de la profundidad
adicional. Este escenario es excelente para profundizar en una vista holística.
En el ejemplo siguiente se muestra lo que sucede cuando un usuario de un informe

profundiza a partir de un código postal. En la página de obtención de detalles se
muestra información general sobre ese código postal.
Recomendaciones
En el momento del diseño del informe, se recomienda aplicar las siguientes prácticas:
Estilo: considere la posibilidad de diseñar la página de obtención de detalles para

usar el mismo tema y estilo que el informe. De este modo, a los usuarios les parece
que se encuentran en el mismo informe.
Filtros de obtención de detalles: establezca filtros de obtención de detalles para
poder obtener una vista previa de un resultado realista al diseñar la página de
obtención de detalles. Asegúrese de quitar estos filtros antes de publicar el
informe.
Funciones adicionales: una página de obtención de detalles es como cualquier
página de informe. Incluso puede mejorarla con más capacidades interactivas,
como las segmentaciones o los filtros.
Valores en blanco: evite agregar objetos visuales que puedan mostrar valores en
blanco o generar errores al aplicar filtros de obtención de detalles.
Visibilidad de la página: considere la posibilidad de ocultar las páginas de
obtención de detalles. Si decide mantener visible una página de obtención de
detalles, no olvide agregar un botón que permita a los usuarios borrar todos los
filtros de obtención de detalles establecidos previamente. Asigne un marcador al
botón. El marcador se debe configurar para quitar todos los filtros.
Botón Atrás: al asignar un filtro de obtención de detalles, se agrega
automáticamente un botón Atrás. Es buena idea conservarlo. De esta forma, los
usuarios del informe podrán volver fácilmente a la página de origen.
Detección: ayude a promover la conciencia de una página de obtención de
detalles al establecer un texto de icono de encabezado del objeto visual, o bien
mediante la adición de instrucciones a un cuadro de texto. También puede diseñar
una superposición, como se describe en esta entrada de blog .
 Sugerencia
También se puede configurar la obtención de detalles en los informes paginados

de Power BI. Puede hacerlo agregando vínculos a los informes de Power BI. Los
vínculos pueden definir parámetros de dirección URL .
Pasos siguientes
Uso de la obtención de detalles en Power BI Desktop

Cuándo usar informes paginados en
Power BI
Este artículo está dirigido a los diseñadores de informes para Power BI. Proporciona
sugerencias para ayudarle a decidir cuándo desarrollar informes paginados de Power BI.
Los informes paginados de Power BI están optimizados para la impresióno generación

de PDF. También permiten producir diseños de gran formato con una pixelación
perfecta. Por lo tanto, los informes paginados son ideales para los informes operativos,
como las facturas de ventas.
Por otra parte, los informes de Power BI están optimizados para la exploración e
interactividad. Además, pueden presentar los datos mediante una amplia gama de
objetos visuales muy modernos. Los informes de Power BI, por lo tanto, son ideales para
informes analíticos, lo que permite a los usuarios de los informes explorar los datos y
detectar relaciones y patrones.
Se recomienda que considere la posibilidad de usar un informe paginado de Power BI

en los siguientes casos:
Sabe que el informe debe imprimirse o mostrarse como un documento PDF.

Los diseños de cuadrícula de datos pueden expandirse y desbordarse. Tenga en
cuenta que una tabla o una matriz en un informe de Power BI no se puede cambiar
de tamaño dinámicamente para mostrar todos los datos; en su lugar, se
proporcionarán barras de desplazamiento. Sin embargo, si se imprimen, no será
posible desplazarse para mostrar los datos que no estén a la vista.
Las características y capacidades paginadas de Power BI son una gran ventaja.
Muchos de estos escenarios de informes se describen más adelante en este
artículo.
Informes heredados
Si ya tiene informes de Report Definition Language (RDL) de SQL Server Reporting
Services (SSRS), puede volver a desarrollarlos como informes de Power BI o migrarlos
como informes paginados a Power BI. Para obtener más información, consulte
Migración de informes de SQL Server Reporting Services a Power BI.
Una vez publicados en un área de trabajo de Power BI, los informes paginados están
disponibles en paralelo con los de Power BI. A continuación, se pueden distribuir
fácilmente mediante las aplicaciones de Power BI.
Podría valorar la posibilidad de volver a desarrollar informes de SSRS, en lugar de

migrarlos. Es especialmente útil para los informes que están diseñados para ofrecer
experiencias analíticas. En estos casos, los informes de Power BI probablemente ofrezcan
mejores experiencias de usuario.
Escenarios de informes paginados

Hay muchos escenarios atractivos en los que puede preferir el desarrollo de un informe
paginado de Power BI. Muchas son características o capacidades que no se admiten en
los informes de Power BI.
Listos para imprimir: Los informes paginados están optimizados para la impresión
o generación de PDF. Cuando sea necesario, las regiones de datos se pueden
expandir y desbordar en varias páginas de una manera controlada. Los diseños de
los informes pueden definir los márgenes, los encabezados y los pies de página.
Formatos de representación: Power BI puede representar informes paginados en
formatos diferentes. Los formatos incluyen Microsoft Excel, Microsoft Word,
Microsoft PowerPoint, PDF, CSV, XML y MHTML. (El servicio Power BI usa el
formato MHTML para representar los informes). Los usuarios del informe pueden
decidir exportarlo en el formato que prefieran.
Diseño de precisión: Puede realizar diseños de gran formato y con una pixelación
perfecta, con el tamaño y la ubicación exactos, configurados en fracciones de
pulgadas o centímetros.
Diseño dinámico: Puede generar diseños con gran capacidad de respuesta
estableciendo muchas propiedades de informe para usar expresiones VB.NET. Las
expresiones tienen acceso a muchas de las principales bibliotecas de .NET
Framework.
Diseño específico para representación: Puede usar expresiones para modificar el
diseño del informe en función del formato de representación aplicado. Por
ejemplo, puede diseñar el informe a fin de deshabilitar la visibilidad de alternancia
(para la exploración en profundidad y la obtención de detalles) al representarlo
con un formato no interactivo, como PDF.
Consultas nativas: No es necesario que desarrolle primero un conjunto de datos
de Power BI. Es posible crear consultas nativas del autor (o usar procedimientos
almacenados) para cualquier origen de datos admitido. Las consultas pueden
incluir parametrización.
Diseñadores gráficos de consultas: Power BI Report Builder incluye diseñadores
gráficos de consultas para ayudarle a escribir y probar sus consultas de conjuntos
de datos.
Conjuntos de datos estáticos: Puede definir un conjunto de datos y escribir los
datos directamente en la definición del informe. Esta funcionalidad es
especialmente útil para respaldar una demostración o para ofrecer una prueba de
concepto (POC).
Integración de datos: Puede combinar datos de distintos orígenes de datos o con
conjuntos de datos estáticos. Para ello, se crean campos personalizados mediante
expresiones VB.NET.
Parametrización: Puede diseñar experiencias de parametrización muy
personalizadas, incluidos parámetros basados en datos y en cascada. También es
posible definir los valores predeterminados de los parámetros. Estas experiencias
pueden diseñarse para ayudar a los usuarios de los informes a establecer
rápidamente los filtros adecuados. Además, no es necesario que los parámetros
filtren los datos del informe; se pueden usar para admitir escenarios de tipo "y si",
filtrado o estilo dinámico.
Datos de imagen: El informe puede representar imágenes cuando se almacenan
en formato binario en un origen de datos.
Código personalizado: Puede desarrollar bloques de código de las funciones de
VB.NET en el informe y usarlos en cualquier expresión de informe.
Subinformes: Puede incrustar otros informes paginados de Power BI (desde la
misma área de trabajo) en el informe.
Cuadrículas de datos flexibles: Tiene un control exhaustivo de los diseños de
cuadrícula mediante el uso de la región de datos Tablix. También admite diseños
complejos, incluidos los grupos anidados y adyacentes. Además, se puede
configurar para repetir los encabezados cuando se imprimen en varias páginas.
También puede insertar un subinforme u otras visualizaciones, incluidas barras de
datos, minigráficos e indicadores.
Tipos de datos espaciales: La región de datos de mapa puede visualizar tipos de
datos espaciales de SQL Server. Por lo tanto, los tipos de datos GEOGRAPHY y
GEOMETRY se pueden usar para visualizar puntos, líneas o polígonos. También es
posible visualizar polígonos definidos en archivos de forma ESRI.
Medidores modernos: Los medidores radiales y lineales se pueden usar para
mostrar valores de KPI y estado. Incluso se pueden incrustar en regiones de datos
de cuadrícula, que se repiten dentro de grupos.
Representación en HTML: Puede mostrar texto con formato enriquecido cuando
se almacena como HTML.
Combinar correspondencia: Puede usar los marcadores de posición de cuadro de
texto para insertar valores de datos en el texto. De este modo, puede generar un
informe de combinación de correspondencia.
Características de interactividad: entre las características interactivas se incluyen la
alternancia de la visibilidad (para la exploración en profundidad y la obtención de
detalles), vínculos, organización interactiva e información sobre herramientas.
También puede agregar vínculos que permitan obtener detalles sobre los informes
de Power BI u otros informes paginados de Power BI. Los vínculos pueden incluso
saltar a otra ubicación dentro del mismo informe.
Suscripciones: Power BI puede proporcionar informes paginados según una
programación como correos electrónicos con datos adjuntos de informe en
cualquier formato admitido.
Diseños por usuario: Puede crear diseños de informe con gran capacidad de
respuesta basados en el usuario autenticado que abre el informe. Puede diseñar el
informe para filtrar los datos de manera diferente, ocultar las regiones de datos o
visualizaciones, aplicar formatos diferentes o establecer valores predeterminados
de parámetros específicos del usuario.
Pasos siguientes
¿Qué son los informes paginados en Power BI?

Migración de informes de SQL Server Reporting Services a Power BI
Guía de recuperación de datos de
informes paginados
Este artículo está dirigido a los autores de informes que diseñan informes paginados de
Power BI. En él se proporcionan recomendaciones que le ayudarán a diseñar una
recuperación de datos eficaz.
Tipos de origen de datos

Los informes paginados admiten de forma nativa orígenes de datos relacionales y
analíticos. Estos orígenes se clasifican aún más como locales o en la nube. Los orígenes
de datos locales (ya sean hospedados localmente o en una máquina virtual) requieren
una puerta de enlace de datos para que Power BI pueda conectarse a ellos, mientras
que en el caso de los basados en la nube, Power BI se puede conectar a ellos
directamente con una conexión a Internet.
Si puede elegir el tipo de origen de datos (posiblemente sea el caso cuando el proyecto
es nuevo), se recomienda usar orígenes de datos basados en la nube. Los informes
paginados pueden conectarse con una latencia de red menor, especialmente cuando los
orígenes de datos residen en la misma región que el inquilino de Power BI. Además,
existe la posibilidad de conectarse a estos orígenes mediante inicio de sesión único
(SSO). Esto significa que la identidad del usuario del informe puede fluir hasta el origen
de datos, lo que permite que se apliquen permisos de nivel de fila por usuario.
Actualmente, el inicio de sesión único solo se admite en orígenes de datos locales
SQL Server y Oracle (vea Orígenes de datos admitidos para informes paginados de
Power BI).
７ Nota
Aunque actualmente no es posible conectarse a bases de datos locales mediante

SSO, sí que se pueden aplicar permisos de nivel de fila. Para ello, se pasa el campo
integrado UserID a un parámetro de consulta de conjunto de datos. El origen de
datos deberá almacenar los valores de nombre principal de usuario (UPN) de forma
tal que sea posible filtrar correctamente los resultados de la consulta.
Imaginemos, por ejemplo, que cada vendedor se almacena como una fila en una
tabla denominada Vendedores. La tabla tiene columnas para UPN y, también, la
región de ventas del vendedor. En el momento de la consulta, la tabla se filtra por
el UPN del usuario del informe y, asimismo, se relaciona con hechos de ventas
mediante una combinación interna. De este modo, la consulta filtra eficazmente las
filas de hechos de ventas para mostrar los de la región de ventas del usuario del
informe en cuestión.
Orígenes de datos relacionales

Por lo general, los orígenes de datos relacionales son adecuados con informes de estilo
operativo, como las facturas de ventas. También son apropiados en informes donde es
necesario recuperar conjuntos de datos de gran tamaño (más de 10 000 filas). Aparte de
esto, los orígenes de datos relacionales pueden definir procedimientos almacenados
que los conjuntos de datos del informe pueden ejecutar. Los procedimientos
almacenados reportan diversas ventajas:
Parametrización
Encapsulación de la lógica de programación, lo que permite una preparación de
datos más compleja (por ejemplo, tablas temporales, cursores o funciones
escalares definidas por el usuario)
Mejor capacidad de mantenimiento, lo que permite actualizar la lógica del
procedimiento almacenado con suma facilidad. En algunos casos, esto se puede
hacer sin necesidad de modificar y volver a publicar los informes paginados (los
nombres de columna y los tipos de datos permanecen inalterados).
Mejor rendimiento, ya que los planes de ejecución se almacenan en la memoria
caché para que se puedan reutilizar
Reutilización de procedimientos almacenados en varios informes
En Power BI Report Builder, se puede usar el diseñador de consultas relacionales para

crear gráficamente una instrucción de consulta, pero esto solo es posible con orígenes
de datos de Microsoft.
Orígenes de datos analíticos

Los orígenes de datos analíticos son adecuados en informes operativos y analíticos, y
pueden proporcionar resultados de consulta de resumen rápido incluso con volúmenes
de datos muy grandes. Los KPI y las medidas de modelo pueden encapsular reglas de
negocio complejas para obtener un resumen de los datos, pero estos orígenes de datos
no son adecuados en informes donde es necesario recuperar conjuntos de datos de
gran tamaño (más de 10 000 filas).
En Power BI Report Builder puede elegir entre dos diseñadores de consultas: el

diseñador de consultas DAX de Analysis Services y el diseñador de consultas MDX de
Analysis Services. Estos diseñadores se pueden usar con orígenes de datos de conjuntos
de datos de Power BI o con cualquier modelo de SQL Server Analysis Services o
Azure Analysis Services, sea tabular o multidimensional.
Le recomendamos que use el diseñador de consultas de DAX, siempre y cuando

satisfaga por completo sus necesidades de consulta. Si el modelo no define las medidas
que necesita, deberá cambiar al modo de consulta. En este modo, puede personalizar la
instrucción de consulta agregando expresiones (para obtener un resumen).
El diseñador de consultas de MDX requiere que el modelo incluya medidas. Este

diseñador tiene dos funciones que el diseñador de consultas de DAX no admite. En
concreto, permite lo siguiente:
Definir miembros calculados en el nivel de consulta (en MDX).

Configurar regiones de datos para solicitar agregados de servidor en grupos no
detallados. Si es necesario que el informe muestre resúmenes de medidas de suma
parcial o de no suma (como medidas de cálculo de inteligencia de tiempo o
medidas de recuento distintivas), probablemente sea más práctico usar agregados
de servidor que recuperar las filas de detalle de bajo nivel y hacer que el informe
calcule los resúmenes.
Tamaño del resultado de la consulta

En general, lo mejor es recuperar únicamente los datos que son necesarios en el
informe, de modo que no recupere columnas ni filas prescindibles en el informe.
Para limitar las filas, conviene aplicar siempre los filtros más restrictivos y definir
consultas de agregado. Las consultas de agregado agrupan y resumen los datos de
origen para recuperar los resultados más pormenorizados. Por ejemplo, imaginemos
que el informe debe mostrar un resumen de las ventas de los vendedores. En lugar de
recuperar todas las filas de pedidos de ventas, crearemos una consulta de conjunto de
datos que agrupe por vendedor y que resuma las ventas de cada grupo.
Campos basados en expresiones

Un conjunto de datos de informe se puede extender con campos basados en
expresiones. Por ejemplo, si un conjunto de datos contiene nombres y apellidos de
clientes, probablemente nos interese un campo que concatene ambos campos para
generar el nombre completo del cliente. Para lograr este cálculo, existen dos opciones.
Puede:
Crear un campo calculado, que es un campo de conjunto de campos basado en
una expresión.
Insertar una expresión directamente en la consulta del conjunto de datos (usando
el lenguaje nativo del origen de datos) y esto dará como resultado un campo de
conjunto de datos normal.
Siempre que sea posible, recomendamos la última opción. Existen dos motivos de peso
por los que es mejor insertar expresiones directamente en la consulta del conjunto de
datos:
Puede que el origen de datos esté optimizado para evaluar la expresión de forma
más eficaz que Power BI (es el caso específicamente de las bases de datos
relacionales).
El rendimiento del informe es mejor, porque no es necesario que Power BI
materialice los campos calculados antes de representar el informe. Los campos
calculados pueden ampliar considerablemente el tiempo de representación del
informe cuando los conjuntos de datos recuperan un gran número de filas.
Nombres de campo
Cuando se crea un conjunto de datos, el nombre que se asigna automáticamente a los
campos es el mismo que el de las columnas de consulta, cuando es probable que estos
nombres no sean descriptivos o intuitivos. También es posible que los nombres de
columna de la consulta de origen contengan caracteres que no se pueden usar en los
identificadores de objeto de lenguaje RDL (Report Definition Language), como, por
ejemplo, espacios y símbolos. En este caso, los caracteres prohibidos se reemplazan por
un carácter de subrayado (_).
Se recomienda comprobar antes que todos los nombres de campo son descriptivos,
concisos y tienen sentido. Si no es así, se recomienda cambiarles el nombre antes de
empezar el diseño del informe, ya que los campos cuyo nombre ha cambiado no
propagan esos cambios a las expresiones que se usan en el diseño del informe. Si, en
cambio, decide cambiar el nombre de los campos después de haber iniciado el diseño
del informe, deberá encontrar y actualizar todas las expresiones incorrectas.
Filtro frente a parámetro

Es bastante probable que los diseños de informes paginados tengan parámetros de
informe. Los parámetros de informe se suelen usar para pedir al usuario del informe que
filtre el informe. Como autor de un informe paginado, tiene dos maneras filtrar un
informe. Puede asignar un parámetro de informe a:
Un filtro de conjunto de datos, en cuyo caso los valores de parámetro del informe
se usan para filtrar los datos ya recuperados por el conjunto de datos.
Un parámetro de conjunto de datos, en cuyo caso los valores del parámetro de
informe se insertan en la consulta nativa que se envía al origen de datos.
７ Nota
Todos los conjuntos de datos de informe se almacenan en la memoria caché de

cada sesión durante 10 minutos desde su último uso. Un conjunto de datos se
puede reutilizar cuando se envían nuevos valores de parámetro (filtrado), cuando el
informe se representa en un formato diferente o cuando se interactúa de algún
modo con el diseño del informe, como al alternar la visibilidad o al ordenar.
Veamos pues un ejemplo de un informe de ventas que tiene un único parámetro de

informe para filtrar el informe por un único año. El conjunto de datos recupera las
ventas de todos los años, debido a que el parámetro de informe se asigna a los filtros
del conjunto de datos. El informe muestra los datos del año solicitado, que es un
subconjunto de los datos del conjunto de datos. Cuando el usuario del informe cambia
el parámetro de informe a otro año y visualiza el informe, Power BI no necesita
recuperar ningún dato de origen, sino que aplica un filtro distinto al conjunto de datos
ya almacenado en la memoria caché. Cuando el conjunto de datos está almacenado en
la memoria caché, se puede filtrar con enorme rapidez.
Veamos ahora un diseño de informe diferente. Esta vez, el diseño de informe asigna el
parámetro de informe de año de ventas a un parámetro de conjunto de datos. De este
modo, Power BI inserta el valor de año en la consulta nativa y el conjunto de datos
recupera solo los datos de ese año. Cada vez que el usuario del informe cambia el valor
del parámetro de informe de año y visualiza el informe, el conjunto de datos recupera
un nuevo resultado de la consulta, exclusivo de ese año.
Ambos métodos de diseño permiten filtrar los datos del informe y pueden funcionar
bien con sus diseños de informe. Con todo, un diseño optimizado dependerá de los
volúmenes de datos anticipados, de la volatilidad de los datos y de los
comportamientos anticipados de los usuarios del informe.
Le recomendamos que use el filtrado de conjunto de datos si prevé que un subconjunto

diferente de filas del conjunto de datos se va a reutilizar muchas veces (con lo que
ahorrará mucho tiempo de representación, ya que no es necesario recuperar datos
nuevos). En este escenario, está claro que el coste de recuperar un conjunto de datos de
gran volumen se compensa con el número de veces que se va a volver a usar. Por lo
tanto, resulta útil para las consultas que tardan mucho tiempo en generarse. Pero
cuidado: almacenar en la memoria caché conjuntos de datos grandes de cada usuario
puede afectar negativamente al funcionamiento y al rendimiento de la capacidad.
Le recomendamos que use la parametrización de conjunto de datos cuando prevea que

es poco probable que se solicite un subconjunto diferente de filas del conjunto de
datos, o si existe la posibilidad de que el número de filas del conjunto de datos que se
van a filtrar sea muy grande (lo cual es poco práctico almacenar en la memoria caché).
Este método de diseño también funciona bien cuando el almacén de datos es volátil. En
este caso, con cada cambio del valor de parámetro del informe se recuperarán datos
actualizados.
Orígenes de datos no nativos

Si necesita desarrollar informes paginados basados en orígenes de datos que no se
admiten de forma nativa en los informes paginados, puede desarrollar en primer lugar
un modelo de datos de Power BI Desktop. De este modo, podrá conectarse a más de
100 orígenes de datos de Power BI. Una vez publicado en el servicio Power BI, puede
desarrollar un informe paginado que se conecte al conjunto de datos de Power BI.
Integración de datos
Si necesita combinar datos procedentes de varios orígenes de datos, tiene dos opciones:
Combinar conjuntos de datos de informes: si los orígenes de datos se admiten de

forma nativa en los informes paginados, puede plantearse crear campos calculados
que usen las funciones de Report Builder Lookup o LookupSet.
Desarrollar un modelo de Power BI Desktop: probablemente sea más eficaz
desarrollar un modelo de datos de Power BI Desktop. Puede usar Power Query
para combinar consultas basadas en cualquier origen de datos compatible. Una
vez publicado en el servicio Power BI, puede desarrollar un informe paginado que
se conecte al conjunto de datos de Power BI.
Latencia de red
La latencia de red puede afectar al rendimiento de los informes si aumenta el tiempo
necesario para que las solicitudes alcancen el servicio Power BI y para la entrega de las
respuestas. Los inquilinos de Power BI se asignan a una región específica.
 Sugerencia
Para determinar dónde se encuentra el inquilino, vea ¿Dónde se encuentra mi
inquilino de Power BI?.
Cuando los usuarios de un inquilino acceden al servicio Power BI, sus solicitudes
siempre se enrutan a esta región. Cuando las solicitudes llegan al servicio Power BI, el
servicio puede enviar solicitudes adicionales —por ejemplo, al origen de datos
subyacente o a la puerta de enlace— que también están sujetas a la latencia de red. En
general, para minimizar el impacto de la latencia de red, intente mantener los orígenes
de datos, las puertas de enlace y la capacidad de Power BI lo más cerca posible.
Preferiblemente, residen en la misma región. Si la latencia de red es un problema,
intente ubicar las puertas de enlace y los orígenes de datos más cerca de la capacidad
de Power BI situándolos dentro de las máquinas virtuales hospedadas en la nube.
Tipos de datos complejos de SQL Server

Como SQL Server es un origen de datos local, Power BI se debe conectar a través de una
puerta de enlace, pero las puertas de enlace no admiten la recuperación de datos de
tipos de datos complejos. Entre los tipos de datos complejos se incluyen tipos
integrados como los tipos de datos espaciales GEOMETRY y GEOGRAPHY, así como
hierarchyid. También engloban tipos definidos por el usuario que se implementan a
través de una clase de un ensamblado de Common Language Runtime (CLR) de
Microsoft .NET Framework.
El trazado de datos espaciales y análisis en la visualización de mapa requiere datos

espaciales de SQL Server. Por lo tanto, no se puede trabajar con la visualización de mapa
cuando SQL Server es el origen de datos. Para ser claros, funcionará si el origen de datos
es Azure SQL Database, ya que Power BI no se conecta a través de una puerta de enlace.
Imágenes relacionadas con datos

Se pueden usar imágenes para agregar logotipos o fotos al diseño del informe. Cuando
se relacionan imágenes con las filas recuperadas por un conjunto de datos, existen dos
opciones:
Puede que los datos de imagen se puedan recuperar también del origen de datos
(si ya están almacenados en una tabla).
Cuando las imágenes están almacenadas en un servidor web, se puede usar una
expresión dinámica para crear la ruta de dirección URL de la imagen.
Para más información y obtener sugerencias, vea Guía de imágenes de informes

paginados.
Recuperación de datos redundantes
Es posible que el informe recupere datos redundantes. Esto puede suceder cuando se
eliminan campos de consulta del conjunto de datos o cuando el informe tiene conjuntos
de datos sin usar. Evite este tipo de situaciones, ya que suponen una carga innecesaria
en los orígenes de datos, la red y los recursos de capacidad de Power BI.
Campos de consulta eliminados

En la página Campos de la ventana Propiedades del conjunto de datos, se pueden
eliminar campos de consulta del conjunto de datos (los campos de consulta se asignan a
las columnas recuperadas por la consulta del conjunto de datos). Sin embargo, Report
Builder no quita las columnas correspondientes de la consulta del conjunto de datos.
Si necesita eliminar campos de consulta del conjunto de datos, le recomendamos quitar

las columnas correspondientes de la consulta desde el conjunto de datos. Report
Builder quitará automáticamente todos los campos de consulta redundantes. Si elimina
campos de consulta, asegúrese de modificar también la instrucción de consulta del
conjunto de datos para quitar las columnas.
Conjuntos de datos sin usar

Cuando se ejecuta un informe, se evalúan todos los conjuntos de objetos, incluso si no
están enlazados a objetos de informe. Por esta razón, asegúrese de quitar todos los
conjuntos de datos de prueba o de desarrollo antes de publicar un informe.
Pasos siguientes
Orígenes de datos admitidos para informes paginados de Power BI

Guía de uso de imágenes para informes
paginados
Power BI. Proporciona sugerencias para trabajar con imágenes. Normalmente, las
imágenes de los diseños de informes pueden mostrar un gráfico como un logotipo de
empresa o ilustraciones.
Las imágenes se pueden almacenar en tres ubicaciones diferentes:
Dentro del informe (insertadas)

En un servidor web (externo)
En una base de datos, que se puede recuperar mediante un conjunto de datos
Después, se pueden usar en distintos escenarios en los diseños de informe:
Logotipo de posición libre o imagen

Imágenes asociadas a filas de datos
Fondo de elementos de informe concretos:
Cuerpo del informe
Cuadro de texto
Rectángulo
Región de datos Tablix (tabla, matriz o lista)
Sugerencias
Tenga en cuenta las sugerencias siguientes para ofrecer diseños de informes
profesionales, facilitar el mantenimiento y optimizar el rendimiento de los informes:
Usar el tamaño más pequeño posible: se recomienda preparar imágenes con un

tamaño pequeño pero con un aspecto nítido. Es un equilibrio entre la calidad y el
tamaño. Considere la posibilidad de usar un editor de gráficos (como MS Paint)
para reducir el tamaño del archivo de imagen.
Evitar imágenes insertadas:en primer lugar, las imágenes insertadas pueden

aumentar el tamaño del archivo de informe, lo que puede contribuir a una
representación de informes más lenta. En segundo lugar, las imágenes insertadas
pueden convertirse rápidamente en una pesadilla de mantenimiento si tiene que
actualizar muchas imágenes de informe (como podría ser si cambia el logotipo de
la empresa).
Usar almacenamiento de servidor web: el almacenamiento de imágenes en un
servidor web es una buena opción, especialmente para el logotipo de la empresa,
que puede tener como origen el sitio web de la empresa. Pero tenga cuidado si los
usuarios del informe van a acceder a los informes fuera de la red. En este caso,
asegúrese de que las imágenes están disponibles a través de Internet y de que no
se requiere autenticación ni un inicio de sesión adicional para acceder a la imagen.
Las imágenes almacenadas en un servidor web no deben superar los 4 MB de
tamaño o no se cargarán en el servicio Power BI.
Cuando las imágenes están relacionadas con los datos (como las de los
vendedores), asigne un nombre a los archivos de imagen para que una expresión
de informe pueda generar dinámicamente la ruta de la dirección URL de la imagen.
Por ejemplo, puede asignar un nombre a las imágenes de los vendedores con el
número de empleado de cada uno. Si el conjunto de datos del informe recupera el
número de empleado, puede escribir una expresión para generar la ruta de acceso
completa de la dirección URL de la imagen.
Usar almacenamiento de base de datos: cuando una base de datos relacional

almacena datos de imagen, tiene sentido obtener los datos de imagen
directamente de las tablas de base de datos, especialmente cuando las imágenes
no son demasiado grandes.
Imágenes de fondo adecuadas: si decide usar imágenes de fondo, evite que

distraigan al usuario del informe de los datos del informe.
Además, asegúrese de usar imágenes con estilo de marca de agua. Por lo general,
las imágenes con estilo de marca de agua tienen un fondo transparente (o el
mismo color de fondo que usa el informe). También usan colores tenues. Algunos
ejemplos comunes de imágenes con estilo de marca de agua son el logotipo de la
empresa o las etiquetas de confidencialidad, como "Borrador" o "Confidencial".
Pasos siguientes

Uso de parámetros en cascada en
informes paginados
Power BI. Proporciona escenarios para diseñar parámetros en cascada. Los parámetros
en cascada son parámetros de informe con dependencias. Cuando un usuario del
informe selecciona un valor (o valores) de parámetro, se usa para establecer los valores
disponibles para otro parámetro.
７ Nota
En este artículo no se incluye una introducción a los parámetros en cascada y cómo

configurarlos. Si no está familiarizado con los parámetros en cascada, se
recomienda que primero lea Agregar parámetros en cascada a un informe en
Power BI Report Builder.
Escenarios de diseño
Existen dos escenarios de diseño para el uso de parámetros en cascada. Se pueden usar
de forma eficaz para:
Filtrar conjuntos grandes de elementos

Presentar elementos pertinentes
Base de datos de ejemplo

Los ejemplos presentados en este artículo se basan en una instancia de Azure SQL
Database. La base de datos registra las operaciones de ventas y contiene varias tablas
que almacenan revendedores, productos y pedidos de venta.
Una tabla llamada Reseller almacena un registro para cada revendedor y contiene varios
miles de registros. La tabla Reseller tiene las siguientes columnas:
ResellerCode (entero)
ResellerName
País-región
State-Province
Ciudad
Código postal
También hay una tabla denominada Sales. Almacena los registros de pedidos de ventas
y tiene una relación de clave externa con la tabla Reseller, en la columna ResellerCode.
Requisito de ejemplo
Hay un requisito para desarrollar un informe de perfil del revendedor. El informe debe
estar diseñado para mostrar información para un único revendedor. No se recomienda
que el usuario del informe escriba un código de revendedor, ya que raramente lo
memoriza.
Filtrado de grandes conjuntos de elementos

Echemos un vistazo a tres ejemplos que le ayudarán a limitar grandes conjuntos de
elementos disponibles, como los revendedores. Son las siguientes:
Filtrado por columnas relacionadas

Filtrado por una columna de agrupación
Filtrado por un patrón de búsqueda
Filtrado por columnas relacionadas

En este ejemplo, el usuario del informe interactúa con cinco parámetros de informe.
Deben seleccionar país-región, estado-provincia, ciudad y código postal. A
continuación, un parámetro final enumera los revendedores que residen en esa
ubicación geográfica.
A continuación se muestra cómo puede desarrollar los parámetros en cascada:
1. Cree los cinco parámetros de informe ordenados en la secuencia correcta.

2. Cree el conjunto de datos CountryRegion que recupera valores de país y región
distintos mediante la siguiente instrucción de consulta:
SQL
SELECT DISTINCT
[Country-Region]
FROM
[Reseller]
ORDER BY
[Country-Region]
3. Cree el conjunto de datos StateProvince que recupera valores de estado y

provincia distintos para la región y país seleccionada mediante la siguiente
instrucción de consulta:
SQL
SELECT DISTINCT
[State-Province]
FROM
[Reseller]
WHERE
[Country-Region] = @CountryRegion
ORDER BY
[State-Province]
4. Cree el conjunto de datos City que recupera valores de ciudad distintos para la
región y país seleccionada mediante la siguiente instrucción de consulta:
SQL
SELECT DISTINCT
[City]
FROM
[Reseller]
WHERE
AND [State-Province] = @StateProvince
ORDER BY
[City]
5. Continúe con este patrón para crear el conjunto de datos PostalCode.
6. Cree el conjunto de datos Reseller para recuperar todos los revendedores de los
valores geográficos seleccionados mediante la siguiente instrucción de consulta:
SQL
SELECT
[ResellerCode],
[ResellerName]
FROM
[Reseller]
WHERE
AND [State-Province] = @StateProvince
AND [City] = @City
AND [PostalCode] = @PostalCode
ORDER BY
[ResellerName]
7. Para cada conjunto de datos excepto el primero, asigne los parámetros de consulta
a los parámetros de informe correspondientes.
７ Nota
Todos los parámetros de consulta (con el prefijo del símbolo @) que se muestran
en estos ejemplos se pueden insertar en las instrucciones SELECT o pasarse a los
procedimientos almacenados.
Por lo general, los procedimientos almacenados son un enfoque de diseño mejor.

Se debe a que sus planes de consulta se almacenan en caché para una ejecución
más rápida y permiten desarrollar lógica más sofisticada cuando sea necesario. Sin
embargo, no se admiten actualmente para orígenes de datos relacionales de puerta
de enlace, lo que significa SQL Server, Oracle y Teradata.
Por último, siempre debe asegurarse de que existan índices adecuados para admitir
la recuperación eficaz de datos. De lo contrario, los parámetros de informe pueden
tardar en rellenarse y la base de datos podría sobrecargarse. Para más información
sobre la indización de SQL Server, consulte Guía de diseño y de arquitectura de
índices de SQL Server.
Filtrado por una columna de agrupación

En este ejemplo, el usuario del informe interactúa con un parámetro de informe para
seleccionar la primera letra del revendedor. Un segundo parámetro muestra a los
revendedores cuando el nombre comienza con la letra seleccionada.
1. Cree los parámetros de informe ReportGroup y Reseller, ordenados en la

secuencia correcta.
2. Cree el conjunto de datos ReportGroup para recuperar las primeras letras usadas
por todos los revendedores, mediante la siguiente instrucción de consulta:
SQL
SELECT DISTINCT
LEFT([ResellerName], 1) AS [ReportGroup]
FROM
[Reseller]
ORDER BY
[ReportGroup]
3. Cree el conjunto de datos Reseller para recuperar todos los revendedores que
empiezan con la letra seleccionada mediante la siguiente instrucción de consulta:
SQL
SELECT
[ResellerCode],
[ResellerName]
FROM
[Reseller]
WHERE
LEFT([ResellerName], 1) = @ReportGroup
ORDER BY
[ResellerName]
4. Asigne el parámetro de consulta del conjunto de datos Revendedor al parámetro

de informe correspondiente.
Es más eficaz agregar la columna de agrupación a la tabla Reseller. Cuando se

almacenan y se indexan, ofrece el mejor resultado. Para más información, consulte
Specify Computed Columns in a Table.
SQL
ALTER TABLE [Reseller]

ADD [ReportGroup] AS LEFT([ResellerName], 1) PERSISTED
Esta técnica puede ofrecer incluso mayor potencial. Considere el siguiente script que
agrega una nueva columna de agrupación para filtrar a los revendedores por bandas
predefinidas de letras. También crea un índice para recuperar de forma eficaz los datos
requeridos por los parámetros de informe.
SQL
ALTER TABLE [Reseller]

ADD [ReportGroup2] AS CASE
WHEN [ResellerName] LIKE '[A-C]%' THEN 'A-C'
WHEN [ResellerName] LIKE '[D-H]%' THEN 'D-H'
WHEN [ResellerName] LIKE '[I-M]%' THEN 'I-M'
WHEN [ResellerName] LIKE '[N-S]%' THEN 'N-S'
WHEN [ResellerName] LIKE '[T-Z]%' THEN 'T-Z'
ELSE '[Other]'
END PERSISTED
GO
CREATE NONCLUSTERED INDEX [Reseller_ReportGroup2]

ON [Reseller] ([ReportGroup2]) INCLUDE ([ResellerCode], [ResellerName])
GO
Filtrado por patrón de búsqueda

En este ejemplo, el usuario del informe interactúa con un parámetro de informe para
especificar un patrón de búsqueda. Un segundo parámetro muestra después a los
revendedores cuando el nombre contiene el patrón.
1. Cree los parámetros de informe Search y Reseller, ordenados en la secuencia

correcta.
contienen el texto de búsqueda, mediante la siguiente instrucción de consulta:
SQL
SELECT
[ResellerCode],
[ResellerName]
FROM
[Reseller]
WHERE
[ResellerName] LIKE '%' + @Search + '%'
ORDER BY
[ResellerName]
3. Asigne el parámetro de consulta del conjunto de datos Revendedor al parámetro

de informe correspondiente.
 Sugerencia
Puede mejorar este diseño para proporcionar más control a los usuarios del
informe. Permite definir su propio valor de coincidencia de patrones. Por ejemplo,
el valor de búsqueda "red%" filtrará a los revendedores cuyos nombres empiecen
con los caracteres en "rojo".
Para más información, consulte LIKE (Transact-SQL).
A continuación se indica cómo puede permitir que los usuarios del informe definan su
propio patrón.
SQL
WHERE
[ResellerName] LIKE @Search
Sin embargo, muchos profesionales que no dominan las bases de datos no conocen el
carácter comodín de porcentaje (%). Por el contrario, están familiarizados con el carácter
asterisco (*). Mediante la modificación de la cláusula WHERE, puede permitirles utilizar
este carácter.
SQL
WHERE
[ResellerName] LIKE SUBSTITUTE(@Search, '%', '*')
Presentación de elementos relevantes
En este escenario, puede usar datos factuales para limitar los valores disponibles. Los
usuarios del informe se presentarán con los elementos en los que se ha registrado la
actividad.
En este ejemplo, el usuario del informe interactúa con tres parámetros de informe. Los
dos primeros establecen un intervalo de fechas de pedidos de venta. El tercer parámetro
muestra a continuación los revendedores que han creado pedidos durante ese período
de tiempo.
1. Cree los parámetros de informe OrderDateStart, OrderDateEnd y Reseller,

ordenados en la secuencia correcta.
crearon pedidos en el período de fecha mediante la siguiente instrucción de
consulta:
SQL
SELECT DISTINCT
[r].[ResellerCode],
[r].[ResellerName]
FROM
[Reseller] AS [r]
INNER JOIN [Sales] AS [s]
ON [s].[ResellerCode] = [r].[ResellerCode]
WHERE
[s].[OrderDate] >= @OrderDateStart
AND [s].[OrderDate] < DATEADD(DAY, 1, @OrderDateEnd)
ORDER BY
[r].[ResellerName]
Recomendaciones
Se recomienda diseñar los informes con parámetros en cascada, siempre que sea
posible. Se debe a que:
Proporcionan experiencias intuitivas y útiles para los usuarios del informe.

Son eficaces, ya que recuperan conjuntos más pequeños de valores disponibles.
Asegúrese de optimizar los orígenes de datos mediante:
El uso de procedimientos almacenados, siempre que sea posible

La adición de índices adecuados para una recuperación eficaz de datos
La materialización de valores de columna (e incluso filas) para evitar evaluaciones
de tiempo de consulta costosas
Pasos siguientes
Parámetros de informe en el Generador de informes de Power BI

Adición de parámetros en cascada a un informe (Report Builder)
Eliminación de páginas en blanco al
imprimir informes paginados
Power BI. Proporciona recomendaciones para ayudarle a evitar las páginas en blanco al
exportarse su informe a un formato de página en disco, como PDF o Microsoft Word, o
imprimirse.
Configurar página
Las propiedades de tamaño de página del informe determinan la orientación, las
dimensiones y los márgenes de la página. Obtenga acceso a estas propiedades de
informe de las siguientes maneras:
Uso de la página de propiedades del informe: haga clic con el botón derecho en
el área gris oscuro de fuera del lienzo del informe y, a continuación, seleccione
Propiedades de informe.
Uso del panel Propiedades: haga clic en el área gris oscuro de fuera del lienzo del
informe para seleccionar el objeto de informe. Asegúrese de que el panel
Propiedades está abierto.
La página Configurar página del informe Página de propiedades proporciona una

interfaz descriptiva para ver y actualizar las propiedades de configuración de página.
Asegúrese de que todas las propiedades de tamaño de página están correctamente
configuradas:
Propiedad Recomendación
Unidades de Seleccione las unidades pertinentes (pulgadas o centímetros).

página
Orientación Seleccione la opción correcta (vertical u horizontal).
Tamaño de Seleccione un tamaño de papel o asigne valores de ancho y alto

papel personalizados.
Márgenes Establezca los valores adecuados para los márgenes izquierdo, derecho,
superior e inferior.
Ancho del cuerpo del informe

Las propiedades de tamaño de página determinan el espacio disponible para los
objetos del informe. Los objetos del informe pueden ser regiones de datos,
visualizaciones de datos u otros elementos de informe.
Un motivo habitual por el que se generan páginas en blanco es que el ancho del cuerpo
del informe supera el espacio de página disponible.
Solo puede ver y establecer el ancho del cuerpo del informe mediante el panel
Propiedades. En primer lugar, haga clic en cualquier parte de un área vacía del cuerpo
del informe.
Asegúrese de que el valor de ancho no supera el ancho de página disponible. Déjese

guiar por la siguiente fórmula:
Report body width <= Report page width - (Left margin + Right margin)
７ Nota
No es posible reducir el ancho del cuerpo del informe cuando ya hay objetos de
informe en el espacio que desea quitar. Primero debe cambiar su posición o
tamaño antes de reducir el ancho.
Además, el ancho del cuerpo del informe puede aumentar de forma automática al
agregar nuevos objetos o cambiar el tamaño o la posición de los objetos
existentes. El diseñador de informes siempre amplía el cuerpo para adaptarlo a la
posición y el tamaño de sus objetos contenidos.
Alto del cuerpo del informe

Otro motivo por el que se genera una página en blanco es que hay un exceso de
espacio en el cuerpo del informe, después del último objeto.
Le recomendamos que reduzca siempre el alto del cuerpo para quitar los espacios
finales.
Opciones de salto de página

Cada región y visualización de datos tiene opciones de salto de página. Puede obtener
acceso a estas opciones en su página de propiedades, o bien en el panel Propiedades.
Asegúrese de que la propiedad Agregar un salto de página después no está habilitada

innecesariamente.
Consumir el espacio en blanco del contenedor
Si el problema de la página en blanco persiste, también puede intentar deshabilitar la
propiedad ConsumeContainerWhitespace del informe. Solo puede establecerse en el
panel Propiedades.
De forma predeterminada, está habilitada. Indica si debe consumirse el espacio en

blanco mínimo de los contenedores, como el cuerpo del informe o un rectángulo. Solo
se ve afectado el espacio en blanco a la derecha y debajo del contenido.
Tamaño del papel de la impresora

Por último, si imprime el informe en papel, asegúrese de que la impresora tiene el papel
correcto cargado. El tamaño del papel físico debe corresponder al tamaño del papel del
informe.
Pasos siguientes

Paginación en informes paginados de Power BI
Planeamiento de la migración de
informes .rdl a Power BI
Artículo • 23/03/2023
SE APLICA A: Power BI Report Builder Power BI Desktop Power BI 2022

Report Server SQL Server 2022 Reporting Services
Este artículo está dirigido a los creadores de informes de Power BI Report Server y
SQL Server Reporting Services (SSRS) y a los administradores de Power BI. Proporciona
instrucciones para ayudarle a migrar informes en lenguaje RDL (Report Definition
Language; .rdl) a Power BI.
Diagrama de flujo que muestra la ruta para migrar informes .rdl del entorno local a
informes paginados del servicio Power BI.
７ Nota
En Power BI, los informes .rdl se denominan informes paginados.
Las instrucciones se dividen en cuatro etapas. Se recomienda leer primero el artículo

completo antes de migrar los informes.
1. Antes de empezar
2. Etapa previa a la migración
3. Etapa de migración
4. Etapa posterior a la migración
Puede llevar a cabo la migración sin tiempo de inactividad en los servidores de informes
ni interrupciones para los usuarios de los informes. Es importante comprender que no
es necesario quitar datos ni informes. Por lo tanto, puede mantener su entorno actual en
su lugar hasta que esté a punto para su retirada.
Antes de empezar
Antes de iniciar la migración, compruebe que el entorno cumple ciertos requisitos
previos. Describiremos estos requisitos previos y también le presentaremos una
herramienta de migración útil.
Preparación de la migración
Cuando prepare la migración de los informes a Power BI, compruebe primero que tiene
una licencia de Power BI Pro o Premium por usuario para cargar contenido en el área de
trabajo de destino.
Versiones compatibles
Puede migrar instancias del servidor de informes que se ejecutan en el entorno local o
en máquinas virtuales hospedadas por proveedores de nube, como Azure.
La siguiente lista incluye las versiones de SQL Server Reporting Services que se admiten
para la migración a Power BI:
＂ SQL Server Reporting Services 2012

También puede migrar archivos .rdl desde Power BI Report Server.
Herramienta de migración para Power BI Report Server y

SQL Server Reporting Services 2017+
Si usa Power BI Report Server o SQL Server Reporting Services después de
SQL Server 2016, hay una herramienta integrada para publicar los informes en Power BI.
Para obtener más información, consulte Publicación de archivos .rdl en Power BI desde
Power BI Report Server y Reporting Services.
Herramienta de migración para versiones anteriores de
SQL Server
En versiones anteriores de SQL Server Reporting Services, se recomienda usar la
herramienta RdlMigration para ayudar a preparar y migrar los informes. Microsoft
desarrolló esta herramienta para ayudar a los clientes a migrar informes .rdl desde sus
servidores SSRS a Power BI. Está disponible en GitHub y documenta un tutorial de un
extremo a otro del escenario de migración.
La herramienta automatiza las tareas siguientes:
Comprueba si hay orígenes de datos no admitidos y características de informe no

admitidas.
Convierte cualquier recurso compartido en recursos incrustados:
Los orígenes de datos compartidos se convierten en orígenes de datos
incrustados.
Los conjuntos de datos compartidos se convierten en conjuntos de datos
incrustados.
Publica informes que pasan comprobaciones como informes paginados en un área
de trabajo de Power BI especificada.
No modifica ni quita los informes existentes. Al finalizar, la herramienta genera un

resumen de todas las acciones completadas correcta o incorrectamente.
Con el tiempo, Microsoft puede mejorar la herramienta. También animamos a la

comunidad a contribuir y ayudar a mejorarla.
Etapa previa a la migración

Después de comprobar que la organización cumple los requisitos previos, todo está
listo para iniciar la etapa previa a la migración. Esta etapa tiene tres partes:
1. Descubra
2. Evaluar
3. Preparación
Descubra
El objetivo de la fase Detección es identificar las instancias que hay del servidor de
informes. Este proceso implica examinar la red para identificar todas las instancias del
servidor de informes de la organización.
Puede usar Microsoft Assessment and Planning Toolkit . También conocida como
"MAP Toolkit", esta herramienta detecta y notifica las instancias, versiones y
características instaladas del servidor de informes. Se trata de una herramienta eficaz
para el inventario, la valoración y la elaboración de informes que puede simplificar el
proceso de planeamiento de la migración.
Las organizaciones pueden tener cientos de informes de SQL Server Reporting Services
(SSRS). Algunos de esos informes pueden quedar obsoletos debido a la falta de uso. El
artículo Búsqueda y retirada de informes .rdl sin usar puede ayudarle a detectar
informes sin usar y a crear una cadencia para la limpieza.
Evaluar
Una vez detectadas las instancias del servidor de informes, el objetivo de la fase
Evaluación es saber qué informes .rdl (o elementos del servidor) no se pueden migrar.
Solo los informes .rdl se pueden migrar desde servidores de informes a Power BI. Cada
informe .rdl migrado se convierte en un informe paginado en Power BI.
Sin embargo, los siguientes tipos de elementos del servidor de informes no se pueden
migrar a Power BI:
Orígenes de datos compartidos y conjuntos de datos compartidos: la

herramienta RdlMigration convierte automáticamente los orígenes de datos y
los conjuntos de datos compartidos en orígenes de datos y conjuntos de datos
incrustados, siempre que usen orígenes de datos admitidos.
Recursos como archivos de imagen.
Los informes vinculados se migran, tanto si se selecciona como si no el informe
primario vinculado a ellos. En el servicio Power BI, son informes .rdl normales.
KPI: Power BI Report Server o Reporting Services 2016 o posterior, solo Enterprise
Edition.
Informes móviles: Power BI Report Server o Reporting Services 2016 o posterior,
solo Enterprise Edition.
Modelos de informes: en desuso.
Partes de informes: en desuso.
Si los informes .rdl dependen de características que todavía no se admiten para los
informes paginados de Power BI, puede plantearse volver a desarrollarlos como
informes de Power BI cuando sea oportuno.
Para obtener más información sobre los orígenes de datos admitidos para los informes
paginados en el servicio Power BI, consulte Orígenes de datos admitidos para informes
paginados de Power BI.
Por lo general, los informes paginados de Power BI están optimizados para la
impresióno generación de PDF. Los informes de Power BI están optimizados para la
exploración e interactividad. Para obtener más información, consulte Cuándo usar
informes paginados en Power BI.
No se permite hacer referencia a archivos .dll de código personalizado dentro de un

informe.
Suele haber diferencias en la salida con formato PDF si se usa una fuente que no admite
caracteres no latinos en un informe y, después, se agregan caracteres no latinos al
informe. Debe comprobar la salida de representación en PDF tanto en el servidor de
informes como en los equipos cliente para comprobar que el informe se representa
correctamente.
Preparación
El objetivo de la fase de Preparación es dejarlo todo listo. En él se describe la
configuración del entorno de Power BI, el planeamiento de la protección y publicación
de los informes, así como ideas para volver a desarrollar los elementos del servidor de
informes que no se pueden migrar.
1. Compruebe la compatibilidad de los orígenes de datos del informe y configure

una puerta de enlace de Power BI para permitir la conectividad con orígenes de
datos locales.
2. Familiarícese con la seguridad de Power BI y planee cómo reproducirá las carpetas
y los permisos del servidor de informes con las áreas de trabajo de Power BI.
3. Familiarícese con el uso compartido de Power BI y planee cómo va a distribuir el
contenido publicando aplicaciones de Power BI.
4. Considere la posibilidad de usar conjuntos de datos compartidos de Power BI en
lugar de orígenes de datos compartidos del servidor de informes.
5. Use Power BI Desktop para desarrollar informes optimizados para dispositivos
móviles, quizá usando el objeto visual de KPI personalizado de Power BI en lugar
de los informes para dispositivos móviles y KPI del servidor de informes.
6. Vuelva a evaluar el uso del campo integrado UserID en los informes. Si confía en el
valor de UserID para proteger los datos del informe, sepa que para los informes
paginados (cuando se hospedan en el servicio Power BI) devuelve el nombre
principal de usuario (UPN). Por tanto, en lugar de devolver el nombre de cuenta de
NT, por ejemplo AW\mblythe, el campo integrado devolverá algo como
adelev@adventureworks.com. Tendrá que revisar las definiciones del conjunto de
datos y, posiblemente, los datos de origen. Una vez revisadas y publicadas, se
recomienda probar exhaustivamente los informes para asegurarse de que los
permisos de datos funcionan según lo previsto.
7. Vuelva a evaluar el uso del campo integrado ExecutionTime en los informes. En el
caso de los informes paginados (cuando se hospedan en la servicio Power BI), el
campo integrado devuelve la fecha y hora en hora universal coordinada (o UTC).
Esto podría afectar a los valores predeterminados de los parámetros del informe y
a las etiquetas de tiempo de ejecución del informe (normalmente se agregan a los
pies de página del informe).
8. Si el origen de datos es SQL Server (local), confirme que los informes no usan
visualizaciones de mapa. Las visualizaciones de mapa dependen de tipos de datos
espaciales de SQL Server, y estos no son compatibles con la puerta de enlace. Para
más información, vea Guía de recuperación de datos de informes paginados (tipos
de datos complejos de SQL Server).
9. Asegúrese de que los creadores de informes tengan instalado Power BI Report
Builder y que las publicaciones más recientes se puedan distribuir fácilmente en
toda la organización.
10. Utilice la documentación sobre el planeamiento de la capacidad para los informes
paginados.
Etapa de migración
Después de preparar el entorno y los informes de Power BI, está todo listo para la etapa
de Migración.
Hay dos opciones de migración: manual y automatizada. La migración manual es

adecuada para un número de informes pequeño o para informes que se deban
modificar antes de migrarse. La migración automatizada es adecuada para migrar un
gran número de informes.
Migración manual
Cualquiera que tenga permiso para acceder a la instancia del servidor de informes y al
área de trabajo de Power BI puede migrar manualmente los informes a Power BI. Estos
son los pasos que debe seguir:
1. Abra el portal del servidor de informes que contiene los informes que quiere
migrar.
2. Descargue cada definición de informe, guardando los archivos .rdl localmente.
3. Abra la versión más reciente de Power BI Report Builder y conéctese al servicio
Power BI con sus credenciales de Azure AD.
4. Abra cada informe en Power BI Report Builder y:
a. Compruebe que todos los orígenes de datos y conjuntos de datos están
incrustados en la definición de informe y que son orígenes de datos admitidos.
b. Obtenga una vista previa del informe para asegurarse de que se representa
correctamente.
c. Seleccione Publicar y después Servicio Power BI.
d. Seleccione el área de trabajo donde quiera guardar el informe.
e. Compruebe que el informe se guarda. Si aún no se admiten determinadas
características del diseño del informe, se producirá un error en la acción de
guardar. Se le notificará de las razones. Después deberá revisar el diseño del
informe e intentar guardarlo de nuevo.
Migración automatizada
Hay tres opciones para llevar a cabo una migración automatizada. Puede usar:
Para Power BI Report Server y SQL Server 2022, consulte Publicación de archivos
.rdl en Power BI desde Power BI Report Server y Reporting Services.
Para versiones anteriores de Reporting Services, use la herramienta RdlMigration
en GitHub.
API disponibles públicamente para Power BI Report Server, Reporting Services y
Power BI.
También puede usar las API de Power BI Report Server, Reporting Services y Power BI
disponibles públicamente para automatizar la migración del contenido. Aunque la
herramienta de migración de RDL ya usa estas API, puede desarrollar una herramienta
personalizada que se adapte a sus requisitos exactos.
Para obtener más información sobre las API, vea:
API REST de Power BI

API REST de SQL Server Reporting Services
Etapa posterior a la migración

Una vez que haya completado correctamente la migración, estará a punto para la etapa
posterior a la migración. Esta etapa implica realizar una serie de tareas posteriores a la
migración para asegurarse de que todo funciona correctamente y de forma eficaz.
Establecimiento del tiempo de espera de consulta para

conjuntos de datos incrustados
Los valores de tiempo de espera de consulta se especifican durante la creación del
informe, cuando se define un conjunto de datos incrustado. El valor de tiempo de
espera se almacena con el informe, en el elemento Timeout de la definición del informe.
Configuración de orígenes de datos

Una vez que los informes se han migrado a Power BI, deberá asegurarse de que los
orígenes de datos estén configurados correctamente. Puede implicar la asignación a
orígenes de datos de puerta de enlace y el almacenamiento seguro de las credenciales
de origen de datos. Estas acciones no se realizan mediante la herramienta de migración
de RDL.
Comprobación del rendimiento de los informes

Se recomienda completar las siguientes acciones para garantizar la mejor experiencia
posible del usuario de informes:
1. Pruebe los informes en cada explorador admitido para Power BI con el fin de
confirmar que el informe se representa correctamente.
2. Ejecute pruebas para comparar los tiempos de representación de los informes en
el servidor de informes y en el servicio Power BI. Compruebe que los informes de
Power BI se representan en un tiempo aceptable.
3. En el caso de los informes de representación prolongada, considere la posibilidad
de que Power BI los entregue a los usuarios como suscripciones de correo
electrónico con datos adjuntos de informe.
4. En el caso de los informes de Power BI basados en conjuntos de datos de Power BI,
revise los diseños del modelo para asegurarse de que están totalmente
optimizados.
Solución de problemas
La fase posterior a la migración es fundamental para solucionar los problemas y resolver
cualquier problema de rendimiento. Agregar la carga de trabajo de informes paginados
a una capacidad puede atrasar el rendimiento de informes paginados y otro contenido
almacenado en la capacidad.
Pasos siguientes
Publicación de archivos .rdl en Power BI desde Power BI Report Server y SQL Server
Reporting Services
Herramienta RdlMigration para versiones anteriores de Reporting Services
Generador de informes de Power BI
Guía de recuperación de datos de informes paginados
Cuándo usar informes paginados en Power BI
Informes paginados en Power BI: Preguntas frecuentes
Curso en línea: Informes paginados en un día
Acerca de la configuración de inquilinos
Artículo • 24/05/2023
La configuración de inquilinos permite controlar de manera pormenorizada las

características que están disponibles para su organización. Si le preocupa la información
confidencial, algunas de nuestras características pueden no ser adecuadas para su
organización, o puede que solo quiera que una determinada característica esté
disponible para un grupo concreto.
La configuración de inquilinos que controla la disponibilidad de características en la

interfaz de usuario de Power BI puede ayudar a establecer directivas de gobernanza,
pero no es una medida de seguridad. Por ejemplo, el valor Exportar datos no restringe
los permisos de un usuario de Power BI en un conjunto de datos. Los usuarios de
Power BI con acceso de lectura a un conjunto de datos tienen permiso para consultarlo
y es posible que puedan conservar los resultados sin usar la característica Exportar
datos de la interfaz de usuario de Power BI.
７ Nota
Un cambio de configuración puede tardar hasta 15 minutos en aplicarse para todos

los usuarios de la organización.
Nueva configuración de inquilino

Para ayudarle a identificar rápidamente los cambios y responder, aparece un mensaje en
la parte superior de la página de configuración del inquilino cuando hay un cambio. El
mensaje muestra la nueva configuración de inquilinos y los cambios en la configuración
existente.
Puede identificar la nueva configuración según su nuevo icono.
Cómo llegar a la configuración de inquilinos

Vaya al portal de administración y seleccione Configuración de inquilinos.
Cómo usar la configuración de inquilinos
Muchos de los parámetros de configuración pueden tener uno de estos tres estados:
Deshabilitado para toda la organización: ninguna persona de la organización

puede usar esta característica.
Habilitado para toda la organización: todas las personas de la organización

pueden usar esta característica.
Habilitado para un subconjunto de la organización: Los grupos de seguridad

específicos de su organización pueden usar esta característica.
También puede habilitar la característica para toda la organización, Excepto

grupos de seguridad específicos.
También puede combinar opciones para habilitar la característica solo para un
grupo específico de usuarios y deshabilitarla para otro. El uso de este enfoque
garantiza que determinados usuarios no tengan acceso a la característica, aunque
pertenezcan al grupo permitido. Se aplica al usuario la configuración más
restrictiva.
Secciones de configuración de inquilinos

Las secciones de la página de configuración de inquilinos se enumeran en la tabla
siguiente.
Configuración de ayuda y soporte técnico

Configuración del área de trabajo
Protección de la información
Configuración de exportación y uso compartido
Configuración de detección
Configuración de paquetes de contenido y de aplicaciones
Configuración de integración
Objetos visuales de Power BI
Configuración de objetos visuales de R y Python
Configuración de auditoría y uso
Configuración del panel
Configuración de desarrollador
Configuración de la API de administración
Configuración de flujo de datos
Configuración de aplicación de plantilla
Configuración de Preguntas y respuestas
Seguridad del conjunto de datos
Redes avanzadas
Configuración de métricas
Experimentos en la experiencia del usuario
Comparta datos con los servicios de Microsoft 365
La configuración de las conclusiones
Configuración de sugerencias de medida rápida
Pasos siguientes
Acerca del Portal de administración
Ajuste de tamaño de la puerta de enlace
de datos local
Este artículo va dirigido a los administradores de Power BI que necesitan instalar y

administrar la puerta de enlace de datos local.
La puerta de enlace es necesaria cuando Power BI debe acceder a los datos que no son
accesibles directamente a través de Internet. Se puede instalar en un servidor local o en
una infraestructura como servicio (IaaS) hospedada en la máquina virtual.
Cargas de trabajo de puerta de enlace

La puerta de enlace de datos local admite dos cargas de trabajo. Es importante que
comprenda primero estas cargas de trabajo antes de pasar a las recomendaciones y el
tamaño de la puerta de enlace.
Carga de trabajo de datos en caché

La carga de trabajo de datos en caché recupera y transforma los datos de origen para
cargarlos en conjuntos de datos de Power BI. Emplea tres pasos:
1. Conexión: la puerta de enlace se conecta a los datos de origen.

2. Recuperación y transformación de datos: los datos se recuperan y, cuando es
necesario, se transforman. Siempre que sea posible, el motor de mashup de Power
Query inserta pasos de transformación en el origen de datos, lo que se conoce
como plegado de consultas . Cuando no es posible, las transformaciones deben
hacerse mediante la puerta de enlace. En este caso, la puerta de enlace consumirá
más recursos de CPU y memoria.
3. Transferencia: los datos se transfieren al servicio Power BI: se necesita una
conexión a Internet confiable y rápida, en especial con grandes volúmenes de
datos.
Cargas de trabajo de conexión dinámica y DirectQuery
La carga de trabajo de conexión dinámica y DirectQuery funciona principalmente en
modo de paso a través. El servicio Power BI envía consultas y la puerta de enlace
responde con los resultados de la consulta. Por lo general, los resultados de la consulta
son de pequeño tamaño.
Para más información sobre la conexión dinámica, consulte Conjuntos de datos del
servicio Power BI (modelos hospedados externamente).
Para más información sobre DirectQuery, consulte Modos de conjunto de datos en
el servicio Power BI (modo DirectQuery).
Esta carga de trabajo requiere recursos de CPU para el enrutamiento y los resultados de
las consultas. Normalmente, hay mucha menos demanda de CPU de la que precisa la
carga de trabajo de datos en caché, en especial cuando es necesaria para transformar
los datos para el almacenamiento en caché.
Es importante una conectividad confiable, rápida y coherente para garantizar que los
usuarios de informes tengan experiencias que respondan.
Consideraciones de tamaño
La determinación del tamaño correcto de la máquina de puerta de enlace puede
depender de las siguientes variables:
En el caso de cargas de trabajo de datos de caché:

El número de actualizaciones simultáneas del conjunto de datos
Los tipos de orígenes de datos (base de datos relacional, base de datos
analítica, fuentes de distribución de datos o archivos)
El volumen de datos que se van a recuperar de los orígenes de datos
Las transformaciones que debe realizar el motor de mashup de Power Query
El volumen de datos que se va a transferir al servicio Power BI
En el caso de las cargas de trabajo de conexión dinámica y DirectQuery:
El número de usuarios simultáneos del informe
El número de objetos visuales en las páginas del informe (cada uno de ellos
envía al menos una consulta)
La frecuencia de las actualizaciones de la caché de consultas del panel de
Power BI
El número de informes en tiempo real mediante la característica Actualización
automática de páginas
Si los conjuntos de datos exigen Seguridad de nivel de fila (RLS)
Por lo general, las cargas de trabajo de conexión dinámica y DirectQuery requieren una
CPU suficiente, mientras que las cargas de trabajo de datos de caché requieren más CPU
y memoria. Ambas cargas de trabajo dependen de una buena conectividad con el
servicio Power BI y los orígenes de datos.
７ Nota
Las capacidades de Power BI imponen límites sobre el paralelismo de las

actualizaciones de los modelos y sobre el rendimiento de la conexión dinámica y
DirectQuery. No tiene sentido ajustar el tamaño de las puertas de enlace para que
proporcionen más capacidad de la que admite el servicio Power BI. Los límites
difieren en la SKU Premium (y en la SKU A de tamaño equivalente). Para más
información, consulte ¿Qué es Power BI Premium? (Nodos de capacidad).
Recomendaciones
Las recomendaciones de tamaño de la puerta de enlace dependen de muchas variables.
En esta sección, se proporcionan recomendaciones generales que puede tener en
cuenta.
Tamaño inicial
Puede ser difícil calcular con precisión el tamaño correcto. Se recomienda comenzar con
una máquina con al menos 8 núcleos de CPU, 8 GB de RAM y varios adaptadores de red
Gigabit. Después, puede medir una carga de trabajo típica de puerta de enlace
mediante el registro de los contadores del sistema de memoria y CPU. Para más
información, consulte Supervisión y optimización del rendimiento de la puerta de enlace
de datos local.
Conectividad
Planee la mejor conectividad posible entre el servicio Power BI y la puerta de enlace y
entre la puerta de enlace y los orígenes de datos.
Busque confiabilidad, velocidad rápida y latencias sistemáticamente bajas

Elimine (o reduzca) los saltos de máquina entre la puerta de enlace y los orígenes
de datos.
Quite todas las limitaciones de red impuestas por la capa de proxy del firewall.
Para más información sobre los puntos de conexión de Power BI, consulte
Incorporación de direcciones URL de Power BI a la lista de permitidos.
Configure Azure ExpressRoute para establecer conexiones privadas y administradas
a Power BI
En el caso de los orígenes de datos de máquinas virtuales de Azure, asegúrese de
que las máquinas virtuales estén colocadas con el servicio Power BI
En el caso de cargas de trabajo de conexión dinámica a SQL Server Analysis
Services (SSAS) que supongan RLS dinámico, asegúrese de que la conectividad
entre la máquina de puerta de enlace y Active Directory local sea correcta.
Agrupación en clústeres
En el caso de implementaciones a gran escala, puede crear una puerta de enlace con
varios miembros de clúster. Los clústeres evitan puntos únicos de error y pueden
equilibrar la carga del tráfico entre puertas de enlace. Puede:
Instalar una o varias puertas de enlace en un clúster

Aislar las cargas de trabajo en puertas de enlace independientes o clústeres de
servidores de puerta de enlace
Para más información, consulte Administración de clústeres de alta disponibilidad y

equilibrio de carga de la puerta de enlace de datos local.
Diseño y configuración del conjunto de datos

El diseño del conjunto de datos y su configuración pueden afectar a las cargas de
trabajo de puerta de enlace. Para reducir la carga de trabajo de puerta de enlace, puede
considerar las siguientes acciones.
Con conjuntos de datos de importación:
Configurar la actualización de datos menos frecuente

Configurar la actualización incremental para reducir la cantidad de datos que se
van a transferir
Siempre que sea posible, asegurarse de que tiene lugar el plegado de consultas
En especial, en el caso de grandes volúmenes de datos o que haya una necesidad
de resultados de baja latencia, convierta el diseño a un modelo DirectQuery o
compuesto.
Con conjuntos de datos DirectQuery:
Optimizar los diseños de orígenes de datos, modelos e informes. Para más

información, consulte Instrucciones del modelo de DirectQuery en Power
BI Desktop.
Crear agregaciones para almacenar en caché los resultados de nivel superior con el
fin de reducir el número de solicitudes de DirectQuery.
Restringir los intervalos de actualización automática de páginas en diseños de
informe y configuraciones de capacidad.
En especial, cuando se aplica RLS dinámico, restringir la frecuencia de actualización
de la caché de paneles.
En especial, en el caso de volúmenes de datos más pequeños o de datos no
volátiles, convertir el diseño en un modelo de importación o compuesto.
Con conjuntos de datos de conexión dinámica:
En especial, cuando se aplica RLS dinámico, restringir la frecuencia de actualización

de la caché de paneles.
Pasos siguientes
Guía para la implementación de una puerta de enlace de datos para Power BI

Configuración de los valores del proxy para la puerta de enlace de datos local
Supervisión y optimización del rendimiento de la puerta de enlace de datos local
Solución de problemas de puertas de enlace: Power BI
Solución de problemas con la puerta de enlace de datos local
La importancia del plegado de consultas
Supervisión del rendimiento de los
informes en Power BI
Artículo • 14/04/2023
Supervise el rendimiento de los informes en Power BI Desktop mediante el Analizador

de rendimiento. La supervisión le ayudará a obtener información sobre dónde están los
cuellos de botella y cómo puede mejorar el rendimiento de los informes.
La supervisión del rendimiento es importante en las siguientes situaciones:
La actualización del modelo de datos de importación es lenta.

Los informes DirectQuery o LiveConnection son lentos.
Los cálculos del modelo son lentos.
Las consultas o los objetos visuales lentos deben ser objeto de optimización continua.
７ Nota
No se puede usar el analizador de rendimiento para supervisar la capacidad o las

actividades de Premium por usuario (PPU).
Uso de Diagnóstico de consulta

Use Diagnóstico de consulta en Power BI Desktop para determinar el comportamiento
de Power Query al previsualizar o aplicar consultas. Además, use la función Paso del
diagnóstico para registrar información de evaluación detallada de cada paso de la
consulta. Los resultados se ponen a disposición de Power Query, y puede aplicar
transformaciones para comprender mejor la ejecución de las consultas.
Uso del Analizador de rendimiento

Use el Analizador de rendimiento en Power BI Desktop para saber el comportamiento
de cada uno de los elementos de informe, como los objetos visuales y las fórmulas DAX.
Es especialmente útil para determinar si la representación de las consultas o de los
objetos visuales contribuye a los problemas de rendimiento.
Uso de SQL Server Profiler

También puede usar SQL Server Profiler para identificar las consultas que son lentas.
７ Nota
SQL Server Profiler está disponible como parte de SQL Server Management Studio.
Use SQL Server Profiler cuando el origen de datos sea:
SQL Server
SQL Server Analysis Services
Azure Analysis Services
Ｕ Precaución
Power BI Desktop admite la conexión a un puerto de diagnóstico. El puerto de

diagnóstico permite que otras herramientas se conecten a los seguimientos del
rendimiento para fines de diagnóstico. La realización de cambios en el modelo de
datos de Power Desktop solo se admite para operaciones específicas. Otros
cambios en el modelo de datos con operaciones que no se admiten pueden
provocar daños y pérdida de datos.
Para crear un seguimiento de SQL Server Profiler, siga estas instrucciones:
1. Abra el informe de Power BI Desktop (para que sea fácil localizar el puerto en el
paso siguiente, cierre cualquier otro informe abierto).
2. Para determinar el puerto que Power BI Desktop usa, en PowerShell (con
privilegios de administrador), o en el símbolo del sistema, escriba el siguiente
comando:
netstat -b -n
El resultado debe ser una lista de aplicaciones y sus puertos abiertos. Busque el
puerto usado por msmdsrv.exe y tome nota para su uso posterior. Se trata de la
instancia de Power BI Desktop.
3. Para conectar SQL Server Profiler al informe de Power BI Desktop:
a. Abra SQL Server Profiler.
b. En SQL Server Profiler, en el menú Archivo, seleccione Nuevo seguimiento.
c. En Tipo de servidor, seleccione Analysis Services.
d. En Nombre del servidor, escriba localhost:[el puerto anotado anteriormente] .
e. Haga clic en Ejecutar: ahora el seguimiento de SQL Server Profiler es dinámico y
genera de forma activa los perfiles de las consultas de Power BI Desktop.
4. A medida que se ejecutan las consultas de Power BI Desktop, verá las duraciones y
los tiempos de CPU correspondientes. Dependiendo del tipo de origen de datos,
es posible que vea otros eventos que indican cómo se ejecutó la consulta. Con
esta información, puede determinar qué consultas son los cuellos de botella.
Una ventaja de utilizar SQL Server Profiler es que es posible guardar un seguimiento de
la base de datos de SQL Server (relacional). El seguimiento puede convertirse en una
entrada del Asistente para la optimización de motor de base de datos. De este modo,
puede recibir recomendaciones sobre cómo optimizar el origen de datos.
Supervisión de métricas en Premium

Supervise el rendimiento del contenido implementado en la capacidad Power BI
Premium de su organización con ayuda de la aplicación Premium Metrics.
Pasos siguientes
Diagnóstico de consulta
Analizador de rendimiento
Solución de problemas de rendimiento de los informes en Power BI
Aplicación Métricas de Power BI Premium
Solución de problemas de rendimiento
de los informes en Power BI
En este artículo se proporcionan instrucciones que permiten a los desarrolladores y

administradores solucionar problemas de rendimiento reducido de los informes. Se
aplica a los informes de Power BI y también a los informes paginados de Power BI.
Los usuarios pueden identificar los informes lentos como aquellos que tardan en
cargarse o en actualizarse al interactuar con las segmentaciones de usuarios u otras
características. Cuando los informes se hospedan en una capacidad Premium, los
informes lentos también se pueden identificar mediante la supervisión de la aplicación
Métricas de Power BI Premium. Esta aplicación le ayuda a supervisar el estado y la
capacidad de su suscripción de Power BI Premium.
Seguimiento de los pasos del diagrama de flujo

Use el siguiente diagrama de flujo para comprender la causa del rendimiento reducido y
determinar la acción que debe llevarse a cabo.
Hay seis terminadores de diagramas de flujo, cada uno de los cuales describe la acción
que se debe realizar:
Terminador Acciones
Administración de capacidad
Escalar la capacidad
Investigación de la actividad de capacidad durante el uso habitual del informe
Cambio de arquitectura
Consideración de Azure Analysis Services
Comprobación de la puerta de enlace local
Consideración de Azure Analysis Services

Consideración de Power BI Premium
Uso del Analizador del rendimiento de Power BI Desktop

Optimización del informe, modelo o DAX
Terminador Acciones
Creación de una incidencia de soporte técnico
Realizar acción
La primera consideración es comprender si el informe lento se hospeda en una
capacidad Premium.
Capacidad Premium
Si el informe se hospeda en una capacidad Premium, use la aplicación Métrica de
Power BI Premium para determinar si la capacidad de hospedaje del informe suele
superar los recursos de la capacidad. Si hay presión sobre los recursos, puede que sea
necesario administrar o escalar la capacidad (terminador de diagrama de flujo 1). Si los
recursos son adecuados, investigue la actividad de capacidad durante el uso habitual del
informe (terminador de diagrama de flujo 2).
Capacidad compartida
Si el informe se hospeda en una capacidad compartida, no es posible supervisar el
estado de la capacidad. Deberá tomar un enfoque de investigación diferente.
En primer lugar, determine si se produce un rendimiento reducido a horas específicas

del día o del mes. Si es así, y muchos usuarios están abriendo el informe a esas horas,
valore dos opciones:
Aumentar el rendimiento de las consultas mediante la migración del conjunto de

datos a Azure Analysis Services o a una capacidad Premium (terminador de
diagrama de flujo 4).
Usar el Analizador de rendimiento en Power BI Desktop para conocer el
comportamiento de cada uno de los elementos de informe, como los objetos
visuales y las fórmulas DAX. Es especialmente útil para determinar si la
representación de las consultas o de los objetos visuales contribuye a los
problemas de rendimiento (terminador de diagrama de flujo 5).
Si determina que no hay ningún patrón horario, considere la posibilidad de que el

rendimiento reducido se limite a una zona geográfica o región específica. Si es así, es
probable que el origen de datos sea remoto y que haya una comunicación de red lenta.
En este caso, valore lo siguiente:
Cambiar la arquitectura mediante Azure Analysis Services (terminador de diagrama
de flujo 3).
Optimizar el rendimiento de puerta de enlace de datos local (terminador de
diagrama de flujo 3).
Por último, si determina que no hay ningún patrón horario y el rendimiento reducido se
produce en todas las regiones, investigue si se produce en determinados dispositivos,
clientes o exploradores web. Si no es así, use el Analizador de rendimiento de Power BI
Desktop, como se describió anteriormente, para optimizar el informe o modelo
(terminador de diagrama de flujo 5).
Al determinar que dispositivos, clientes o exploradores web específicos contribuyen a un

rendimiento reducido, se recomienda crear una incidencia a través de la página de
soporte técnico de Power BI (terminador de diagrama de flujo 6).
Pasos siguientes
Guía de Power BI
Analizador de rendimiento
Procedimientos recomendados para las
canalizaciones de implementación
Artículo • 09/03/2023
En este artículo se proporcionan instrucciones para los creadores de inteligencia

empresarial (BI) que están administrando su contenido a lo largo del ciclo de vida. El
artículo se centra en el uso de canalizaciones de implementación como una herramienta
de administración del ciclo de vida del contenido de BI.
El artículo se divide en cuatro secciones:
Preparación del contenido: prepare el contenido para la administración del ciclo

de vida.
Desarrollo: conozca las mejores formas de crear contenido en la fase de desarrollo

de las canalizaciones de implementación.
Prueba: aprenda a usar la fase de prueba de las canalizaciones de implementación

para probar el entorno.
Producción: use la fase de producción de las canalizaciones de implementación

cuando ponga el contenido a disposición para su consumo.
Preparación del contenido

Prepare el contenido para la administración continua a lo largo de su ciclo de vida.
Revise la información de esta sección antes de:
Publicar el contenido en producción.
Empezar a usar una canalización de implementación para un área de trabajo

específica.
Publicar el trabajo.
Tratamiento de cada área de trabajo como un paquete

completo de análisis
Idealmente, un área de trabajo debe contener una vista completa de un aspecto (como
departamento, unidad de negocio, proyecto o vertical) en la organización. El
tratamiento de cada área de trabajo como un paquete completo facilita la
administración de los permisos para distintos usuarios y permite controlar las versiones
del contenido de todo el área de trabajo conforme a una programación planeada.
Si usa conjuntos de datos centralizados que se usan en la organización, se recomienda

crear dos tipos de áreas de trabajo:
Áreas de trabajo de modelado y datos: estas áreas de trabajo contienen todos los
conjuntos de datos centralizados.
Áreas de trabajo de informes: estas áreas de trabajo contienen todos los informes
y paneles dependientes.
Planeamiento del modelo de permiso

Una canalización de implementación es un objeto de Power BI con sus propios
permisos. Además, la canalización contiene áreas de trabajo que tienen sus propios
permisos.
Para implementar un flujo de trabajo seguro y sencillo, planee quién va a acceder a cada
parte de la canalización. Algunas consideraciones a tener en cuenta son las siguientes:
¿Quién debe tener acceso a la canalización?
¿Qué operaciones deben realizar los usuarios con acceso de canalización en cada
fase?
¿Quién está revisando el contenido en la fase de prueba?
¿Tienen acceso los revisores de la fase de pruebas a la canalización?
¿Quién supervisa la implementación en la fase de producción?
¿Qué área de trabajo está asignando?
¿En qué fase está asignando el área de trabajo?
¿Necesita realizar cambios en los permisos del área de trabajo que está
asignando?
Conexión de distintas fases a diferentes bases de datos

Una base de datos de producción siempre debe ser estable y estar disponible. Es mejor
no sobrecargarlo con las consultas generadas por los creadores de BI para sus conjuntos
de datos de desarrollo o prueba. Cree bases de datos separadas para desarrollo y
pruebas, con el fin de proteger los datos de producción y no sobrecargar la base de
datos de desarrollo con todo el volumen de datos de producción.
７ Nota
Si la organización usa conjunto de datos centralizados compartidos, puede omitir

esta recomendación.
Uso de parámetros en el modelo

Dado que no se pueden editar los orígenes de datos de los conjuntos de datos en el
servicio Power BI, se recomienda usar parámetros para almacenar los detalles de
conexión, como los nombres de instancia y los nombres de base de datos. El uso de
parámetros en lugar de cadenas de conexión estáticas permite administrar las
conexiones a través del portal web del servicio Power BI, o bien usar API, en una fase
posterior.
En las canalizaciones de implementación, puede configurar reglas de parámetros para

establecer diferentes valores para cada fase de implementación. También puede
establecer reglas para los informes paginados.
Si no usa parámetros para la cadena de conexión, puede definir reglas de origen de

datos para especificar una cadena de conexión para un conjunto de datos determinado.
Sin embargo, en las canalizaciones de implementación, no se admiten reglas para todos
los orígenes de datos. Para comprobar que puede configurar las reglas para el origen de
datos, consulte Limitaciones de las reglas de implementación.
Los parámetros tienen también otros usos, como la realización de cambios en las
consultas, los filtros y el texto que se muestra en el informe.
Desarrollo
En esta sección se proporcionan instrucciones para trabajar con la fase de desarrollo de
canalizaciones de implementación.
Uso de Power BI Desktop para editar los informes y

conjuntos de datos
Considere la posibilidad de Power BI Desktop como su entorno de desarrollo local.
Power BI Desktop permite probar, explorar y revisar las actualizaciones de los informes y
conjuntos de datos. Una vez realizado el trabajo, puede cargar la nueva versión en la
fase de desarrollo. Se recomienda editar los archivos .pbix en Desktop (no en el servicio
Power BI) por los siguientes motivos:
Es más fácil colaborar con otros creadores en el mismo archivo .pbix, si todos los
cambios se realizan en la misma herramienta.
El proceso de realizar cambios en línea, descargar el archivo .pbix y volver a

cargarlo crea informes y conjuntos de datos duplicados.
Puede usar el control de versiones para mantener actualizados los archivos .pbix.
Control de versiones de los archivos PBIX

Si quiere administrar el historial de versiones de los informes y conjuntos de datos, use
la sincronización automática de Power BI con OneDrive. La sincronización automática
mantiene los archivos actualizados con la versión más reciente y permite recuperar
versiones anteriores si es necesario.
７ Nota
Sincronice los datos con OneDrive (o cualquier otro repositorio) solo con los
archivos .pbix en la fase de desarrollo de la canalización de implementación. La
sincronización de los archivos .pbix en las fases de prueba y producción de la
canalización de implementación causa problemas al implementar contenido a
través de la canalización.
Separación del desarrollo de modelos del desarrollo de

informes y paneles
En el caso de las implementaciones a escala empresarial, se recomienda separar el
desarrollo de los conjuntos de datos del desarrollo de los informes y paneles. Para
promover los cambios a un solo informe o un conjunto de datos, use la opción de
implementación selectiva de las canalizaciones de implementación.
Empiece por crear un archivo .pbix aparte para los conjuntos de datos y los informes en
Power BI Desktop. Por ejemplo, puede crear un archivo .pbix para el conjunto de datos y
cargarlo en la fase de desarrollo. Más adelante, los creados de informes pueden crear un
archivo .pbix sólo para el informe y conectarlo al conjunto de datos publicado mediante
una conexión dinámica. Esta técnica permite que distintos creadores trabajen por
separado en el modelado y las visualizaciones, y los implementen en producción de
forma independiente.
Cree conjuntos de datos compartidos para usar este método entre áreas de trabajo.
Administración de los modelos mediante funcionalidades

de lectura y escritura de XMLA
Cuando separa el desarrollo de modelos del desarrollo de informes y paneles, también
puede aprovechar funcionalidad avanzada, como el control de código fuente, la
combinación de cambios de diferencias y procesos automatizados. Realice estos
cambios en la fase de desarrollo, de modo que el contenido final pueda implementarse
en las fases de prueba y producción. De esta forma, los cambios pasan por un proceso
unificado con otros elementos dependientes antes de que se implementen en la fase de
producción.
Puede separar el desarrollo de modelos de las visualizaciones administrando un

conjunto de datos compartido en un área de trabajo externa, con las características de
lectura y escritura de XMLA. El conjunto de datos compartidos puede conectarse a
varios informes en varias áreas de trabajo que se administran en varias canalizaciones.
Probar
En esta sección se proporcionan instrucciones para trabajar con la fase de prueba de
Simulación del entorno de producción

Además de comprobar que los nuevos informes o paneles se ven bien, también es
importante ver cómo funcionan desde la perspectiva del usuario final. La fase de prueba
de canalizaciones de implementación permite simular un entorno de producción real
con fines de prueba.
Asegúrese de que estos tres factores se aborden en el entorno de prueba:
Volumen de datos
Volumen de uso
Una capacidad similar a la de producción

Al realizar pruebas, puede usar la misma capacidad que la fase de producción. Sin
embargo, si se utiliza la misma capacidad, puede hacer que la producción sea inestable
durante las pruebas de carga. Para evitar una producción inestable, realice las pruebas
en una capacidad diferente que sea similar en recursos a la capacidad de producción.
Para evitar costos extra, use una capacidad donde pueda pagar solo por el tiempo que
duren las pruebas.
Uso de reglas de implementación con un origen de datos

real
Si usa la fase de prueba para simular el uso de datos de la vida real, se recomienda
separar los orígenes de datos de desarrollo y pruebas. La base de datos de desarrollo
debe ser relativamente pequeña y la base de datos de prueba debe ser lo más parecida
posible a la base de datos de producción. Use las reglas del origen de datos para
cambiar los orígenes de datos en la fase de prueba.
Si usa un origen de datos de producción en la fase de prueba, resulta útil controlar la

cantidad de datos que importa del origen de datos. Puede controlar la cantidad de
datos que importa agregando un parámetro a la consulta del origen de datos en
Power BI Desktop. Use las reglas de parámetros para controlar la cantidad de datos
importados o edite el valor del parámetro. También puede usar este enfoque para no
sobrecargar la capacidad.
Medir el rendimiento
Cuando simule una fase de producción, compruebe la carga del informe y las
interacciones, y averigüe si los cambios que ha realizado les afectan.
También debe supervisar la carga en la capacidad, para poder detectar cargas extremas
antes de que lleguen a producción.
７ Nota
Se recomienda volver a supervisar las cargas de la capacidad después de

implementar actualizaciones en la fase de producción.
Comprobación de elementos relacionados

Los cambios realizados en conjuntos de datos o informes también pueden afectar a los
tiempos relacionados. Durante las pruebas, compruebe que los cambios no afecten o
interrumpan el rendimiento de los elementos existentes, que pueden depender de los
actualizados.
Puede buscar fácilmente los elementos relacionados mediante la vista de linaje del área
de trabajo.
Prueba de la aplicación
Si va a distribuir contenido a los usuarios finales por medio de una aplicación, revise la
nueva versión de la aplicación antes de que llegue a producción. Puesto que cada fase
de una canalización de implementación tiene su propia área de trabajo, puede publicar
y actualizar fácilmente las aplicaciones para las fases de desarrollo y pruebas. La
publicación y actualización de las aplicaciones le permite probar la aplicación desde el
punto de vista del usuario final.
） Importante
El proceso de implementación no incluye la actualización del contenido o la

configuración de la aplicación. Para aplicar cambios al contenido o a la
configuración, debe actualizar manualmente la aplicación en la fase requerida de la
canalización.
Producción
En esta sección se proporcionan instrucciones para la fase de producción de
Administración de quién puede realizar la

implementación en producción
Como la implementación en producción debe controlarse con cuidado, se recomienda
que solo personas específicas administren esta operación sensible. Sin embargo, es
probable que quiera que todos los creadores de BI de un área de trabajo específica
tengan acceso a la canalización. Utilice los permisos del área de trabajo en producción
para administrar los permisos de acceso.
Para implementar contenido entre fases, los usuarios deben tener permisos de miembro
o administrador en ambas fases. Asegúrese de que solo las personas que desee
implementar en producción tienen estos permisos. Otros usuarios pueden tener roles de
colaborador o visor en el área de trabajo de producción. Los usuarios con roles de
colaborador o visor pueden ver el contenido dentro de la canalización, pero no lo
pueden implementar.
Además, debe limitar el acceso a la canalización concediendo permisos para la

canalización solo a los usuarios que forman parte del proceso de creación de contenido.
Establecimiento de reglas para garantizar la

disponibilidad de la fase de producción
Las reglas de implementación son una manera eficaz de garantizar que los datos de
producción estén siempre conectados y disponibles para los usuarios. Con las reglas de
implementación aplicadas, las implementaciones se pueden ejecutar mientras tenga la
seguridad de que los usuarios finales podrán ver la información pertinente sin
perturbaciones.
Asegúrese de establecer las reglas de implementación de producción para los orígenes

de datos y los parámetros definidos en el conjunto de datos.
En el caso de un cambio importante en el conjunto de datos, actualice el conjunto de

datos.
Actualización de la aplicación de producción

La implementación en una canalización actualiza el contenido del área de trabajo, pero
no actualiza automáticamente la aplicación asociada. Si usa una aplicación para la
distribución de contenido, no se olvide de actualizar la aplicación después de
implementarla en producción, para que los usuarios finales puedan usar
inmediatamente la versión más reciente.
Correcciones rápidas del contenido

A veces surgen problemas en producción que requieren una corrección rápida. No
cargue nunca una nueva versión del archivo .pbix directamente en la fase de producción
ni haga un cambio en línea en el servicio Power BI. No se puede implementar la
corrección en una fase anterior cuando ya hay contenido en esas fases. Además, la
implementación de una corrección sin probarla primero es una práctica incorrecta. Por
tanto, implemente siempre la corrección en la fase de desarrollo e insértela en el resto
de las fases de la canalización de implementación. La implementación en la fase de
desarrollo permite comprobar que la corrección funciona antes de implementarla en
producción. La implementación en toda la canalización solo tarda unos minutos.
Pasos siguientes
Introducción a las canalizaciones de implementación
Introducción a las canalizaciones de implementación
Asignación de un área de trabajo a una fase de canalización
Historial de implementación
Descripción del proceso de las canalizaciones de implementación
Automatización de la canalización de implementación mediante API y DevOps
Solución de problemas de las canalizaciones de implementación

Acceso al registro de actividad de
Power BI
Artículo • 08/05/2023
Este artículo está destinado a los administradores de Power BI que necesitan acceder y
analizar orígenes de datos del registro de actividad de Power BI. Se centra en la
recuperación mediante programación de actividades de Power BI mediante el cmdlet
Get-PowerBIActivityEvent del módulo de administración de Power BI. Hasta 30 días de
historial disponibles. Este cmdlet usa la operación Obtener eventos de actividad de la
API REST de Power BI, que es una API de administración. Los cmdlets de PowerShell
agregan una capa de abstracción sobre las API subyacentes. Por lo tanto, el cmdlet de
PowerShell simplifica el acceso al registro de actividad de Power BI.
Hay otras formas, tanto manuales como mediante programación, de recuperar

actividades de Power BI. Para obtener más información, consulte Acceso a los datos de
actividad del usuario.
El análisis del registro de actividad de Power BI es fundamental para la gobernanza, el

cumplimiento y realizar un seguimiento de los esfuerzos de adopción . Para obtener
más información sobre el registro de actividad de Power BI, consulte Seguimiento de
actividades de usuario en Power BI.
 Sugerencia
Le recomendamos que revise completamente el artículo Auditoría de nivel de

inquilino . En este artículo se tratan las actividades de planeamiento, decisiones
clave, requisitos previos y desarrollo de soluciones clave que se deben tener en
cuenta al crear una solución de auditoría de un extremo a otro.
Ejemplos disponibles
El objetivo de este artículo es proporcionarle ejemplos para ayudarle a empezar. Los
ejemplos incluyen scripts que recuperan datos del registro de actividad mediante el
módulo PowerShell de administración de Power BI.
２ Advertencia
Los scripts no están listos para producción porque solo están diseñados para fines
educativos. Sin embargo, puede adaptar los scripts con fines de producción
mediante la adición de lógica para el registro, el control de errores, las alertas y la
refactorización para la reutilización y la modularización del código.
Dado que están pensados para aprender, los ejemplos son simplistas, pero son reales.
Le recomendamos que revise todos los ejemplos para comprender cómo aplican
técnicas ligeramente diferentes. Una vez que identifique el tipo de datos de actividad
que necesita, puede mezclar y hacer coincidir las técnicas para generar un script que se
adapte mejor a sus requisitos.
En este artículo se incluyen los ejemplos siguientes.
Nombre del ejemplo Tipo de datos de actividad
Autenticación con el servicio Power BI N/A
Ver todas las actividades de un usuario durante un All

día
Ver una actividad durante N días Compartir informe (vínculo o acceso directo)
Ver tres actividades durante N días Creación, actualización e instalación de una

aplicación
Ver todas las actividades de un área de trabajo All

durante un día
Exportar todas las actividades de los N días All

anteriores
Para simplificar, la mayoría de los ejemplos generan el resultado en la pantalla. Por

ejemplo, en Visual Studio Code, los datos se generan en el panel de terminal , que
contiene un conjunto de datos en memoria de búfer.
La mayoría de los ejemplos recuperan datos JSON sin procesar. Trabajar con los datos
JSON sin procesar tiene muchas ventajas.
Se devuelve toda la información disponible para cada evento de actividad. Esto

resulta útil para aprender qué datos están disponibles. Tenga en cuenta que el
contenido de una respuesta de API difiere en función del evento de actividad real.
Por ejemplo, los datos disponibles para un evento CreateApp son diferentes al
evento ViewReport .
Dado que los datos que están disponibles en el registro de actividad cambian a
medida que Power BI evoluciona con el tiempo, también puede esperar que las
respuestas de la API cambien. De este modo, no se perderán los nuevos datos
introducidos. El proceso también es más resistente al cambio y menos probable
que se produzca un error.
Los detalles de una respuesta de API pueden diferir para la nube comercial de
Power BI y las nubes nacionales.
Si tiene diferentes miembros del equipo (como ingenieros de datos) que participan
en este proceso, simplificar el proceso inicial para extraer los datos facilita que
varios equipos trabajen juntos.
 Sugerencia
Le recomendamos que mantenga los scripts que extraigan los datos lo más
sencillos posible. Por lo tanto, evite analizar, filtrar o dar formato a los datos del
registro de actividad a medida que se extraiga. Este enfoque usa una metodología
ELT, que tiene pasos independientes para extraer, cargar y transformar datos. Este
artículo solo se centra en el primer paso, que se refiere a la extracción de los datos.
Requisitos
Para usar los scripts de ejemplo, debe cumplir los siguientes requisitos.
Herramienta cliente de PowerShell: Use la herramienta preferida para ejecutar

comandos de PowerShell. Todos los ejemplos se probaron mediante la extensión
de PowerShell para Visual Studio Code con PowerShell 7. Para obtener
información sobre las herramientas de cliente y las versiones de PowerShell,
consulte Auditoría de nivel de inquilino.
Módulo de administración de Power BI: Instale todos los módulos de PowerShell
de Power BI. Si los instaló anteriormente, se recomienda actualizar los módulos
para asegurarse de que usa la versión publicada más reciente.
Rol de administrador de Power BI: Los scripts de ejemplo están diseñados para
usar un flujo de autenticación interactiva. Por lo tanto, el usuario que ejecuta los
scripts de ejemplo de PowerShell debe iniciar sesión para usar las API de REST de
Power BI. Para recuperar los datos del registro de actividad, el usuario autenticado
debe pertenecer al rol de administrador de Power BI (porque la recuperación de
eventos de actividad se realiza con una API de administración). La autenticación de
entidad de servicio está fuera del ámbito de estos ejemplos de aprendizaje.
En el resto de este artículo se incluyen scripts de ejemplo que muestran diferentes

formas de recuperar los datos del registro de actividad.
Ejemplo 1: Autenticación con el servicio Power
BI
Todas las operaciones de la API REST de Power BI requieren que inicie sesión. La
autenticación (quien realiza la solicitud) y la autorización (lo que el usuario tiene permiso
para hacer) se administran mediante la Plataforma de identidad de Microsoft. En el
ejemplo siguiente se usa el cmdlet Connect-PowerBIServiceAccount del módulo de
administración de Power BI. Este cmdlet admite un método sencillo para iniciar sesión.
Solicitud de ejemplo 1
El primer script le redirige a un explorador para completar el proceso de inicio de sesión.
Las cuentas de usuario que tienen habilitada la autenticación multifactor (MFA) pueden
usar este flujo de autenticación interactiva para iniciar sesión.
PowerShell
Connect-PowerBIServiceAccount
） Importante
Los usuarios sin privilegios de administrador de Power BI no pueden ejecutar

ninguno de los scripts de ejemplo siguientes en este artículo. Los administradores
de Power BI tienen permiso para administrar el servicio Power BI y recuperar
metadatos de todo el inquilino (como los datos del registro de actividad). Aunque
el uso de la autenticación de entidad de servicio está fuera del ámbito de estos
ejemplos, se recomienda encarecidamente configurar una entidad de servicio para
scripts desatendidos listos para producción que se ejecutarán según una
programación.
Asegúrese de iniciar sesión antes de ejecutar cualquiera de los siguientes scripts.
Ejemplo 2: Ver todas las actividades de un

usuario durante un día
A veces es necesario comprobar todas las actividades que ha realizado un usuario
específico en un día específico.
 Sugerencia
Al extraer datos del registro de actividad mediante el cmdlet de PowerShell, cada
solicitud puede extraer datos durante un día (un máximo de 24 horas). Por lo tanto,
el objetivo de este ejemplo es empezar simplemente comprobando un usuario
durante un día. Hay otros ejemplos más adelante en este artículo que muestran
cómo usar un bucle para exportar datos durante varios días.
Este script declara dos variables de PowerShell para facilitar la reutilización del script:
$UserEmailAddr : la dirección de correo electrónico del usuario que le interesa.
$ActivityDate : la fecha en la que está interesado. El formato es AAAA-MM-DD
(formato ISO 8601). No se puede solicitar una fecha anterior a 30 días antes de la
fecha actual.
PowerShell
#Input values before running the script:

$UserEmailAddr = 'jordan@contoso.com'
$ActivityDate = '2023-03-15'
#----------------------------------------------------------------------
#View activity events:
Get-PowerBIActivityEvent `
-StartDateTime ($ActivityDate + 'T00:00:00.000') `
-EndDateTime ($ActivityDate + 'T23:59:59.999') `
-User $UserEmailAddr
７ Nota
Es posible que observe un carácter de verso (') al final de algunas de las líneas de
los scripts de PowerShell. En PowerShell, una manera de usar el carácter de verso es
como un carácter de continuación de línea. Lo hemos usado para mejorar la
legibilidad de los scripts de este artículo.
 Sugerencia
En el script, cada una de las variables de PowerShell se correlaciona con un valor

de parámetro obligatorio o opcional en el cmdlet Get-PowerBIActivityEvent . Por
ejemplo, el valor que se asigna a la variable $UserEmailAddr se pasa al parámetro -
User . Declarar variables de PowerShell de esta manera es un enfoque ligero para
evitar valores de codificación rígida que podrían cambiar en el script. Ese es un

buen hábito de adoptar y será útil a medida que los scripts se vuelven más
complejos. Los parámetros de PowerShell son más sólidos que las variables, pero
están fuera del ámbito de este artículo.
Respuesta de ejemplo 2
Aquí se muestra una respuesta JSON de ejemplo. Incluye dos actividades que realizó el
usuario:
La primera actividad muestra que un usuario ha visto un informe.

La segunda actividad muestra que un administrador exportó datos del registro de
actividad de Power BI.
JSON
[
{
"Id": "10af656b-b5a2-444c-bf67-509699896daf",
"RecordType": 20,
"CreationTime": "2023-03-15T15:18:30Z",
"Operation": "ViewReport",
"OrganizationId": "927c6607-8060-4f4a-a5f8-34964ac78d70",
"UserType": 0,
"UserKey": "100FFF92C7717B",
"Workload": "PowerBI",
"UserId": "jordan@contoso.com",
"ClientIP": "192.168.1.1",
"Activity": "ViewReport",
"ItemName": "Gross Margin Analysis",
"WorkSpaceName": "Sales Analytics",
"DatasetName": "Sales Data",
"ReportName": "Gross Margin Analysis",
"WorkspaceId": "e380d1d0-1fa6-460b-9a90-1a5c6b02414c",
"ObjectId": "Gross Margin Analysis",
"DatasetId": "cfafbeb1-8037-4d0c-896e-a46fb27ff229",
"ReportId": "94e57e92-Cee2-486d-8cc8-218c97200579",
"ArtifactId": "94e57e92-Cee2-486d-8cc8-218c97200579",
"ArtifactName": "Gross Margin Analysis",
"IsSuccess": true,
"ReportType": "PowerBIReport",
"RequestId": "53451b83-932b-f0b0-5328-197133f46fa4",
"ActivityId": "beb41a5d-45d4-99ee-0e1c-b99c451e9953",
"DistributionMethod": "Workspace",
"ConsumptionMethod": "Power BI Web",
"SensitivityLabelId": "e3dd4e72-5a5d-4a95-b8b0-a0b52b827793",
"ArtifactKind": "Report"
},
{
"Id": "5c913f29-502b-4a1a-a089-232edaf176f7",
"RecordType": 20,
"CreationTime": "2023-03-15T17:22:00Z",
"Operation": "ExportActivityEvents",
"UserType": 2,
"ClientIP": "192.168.1.1",
"UserAgent": "MicrosoftPowerBIMgmt/1.2.1111.0",
"Activity": "ExportActivityEvents",
"IsSuccess": true,
"RequestId": "2af6a22d-6f24-4dc4-a26a-5c234ab3afad",
"ActivityId": "00000000-0000-0000-0000-000000000000",
"ExportEventStartDateTimeParameter": "2023-03-17T00:00:00Z",
"ExportEventEndDateTimeParameter": "2023-03-17T23:59:59.999Z"
}
]
 Sugerencia
Extraer los datos del registro de actividad de Power BI también es una operación
registrada, como se muestra en la respuesta anterior. Al analizar las actividades del
usuario, es posible que quiera omitir las actividades de administrador, o analizarlas
por separado.
Ejemplo 3: Ver una actividad durante N días

A veces, es posible que desee investigar un tipo específico de actividad durante una
serie de días. En este ejemplo se muestra cómo recuperar actividades de uso
compartido de informes por elemento . Usa un bucle para recuperar actividades de los
siete días anteriores.
El script declara dos variables:
$ActivityType : nombre de la operación de la actividad que está investigando.

$NbrOfDaysToCheck : cuántos días le interesa comprobar. Realiza un bucle
trabajando hacia atrás desde el día actual. El valor máximo permitido es 30 días
(porque la fecha más antigua que se puede recuperar es de 30 días antes del día
actual).
PowerShell
$ActivityType = 'ShareReport'
$NbrOfDaysToCheck = 7
#-----------------------------------------------------------------------
#Use today to start counting back the number of days to check:

$DayUTC = (([datetime]::Today.ToUniversalTime()).Date)
#Iteratively loop through each of the last N days to view events:

For($LoopNbr=0; $LoopNbr -le $NbrOfDaysToCheck; $LoopNbr++)
{
$PeriodStart=$DayUTC.AddDays(-$LoopNbr)
$ActivityDate=$PeriodStart.ToString("yyyy-MM-dd")
Write-Verbose "Checking $ActivityDate" -Verbose
#Check activity events once per loop (once per day):

Get-PowerBIActivityEvent `
-StartDateTime ($ActivityDate + 'T00:00:00.000') `
-EndDateTime ($ActivityDate + 'T23:59:59.999') `
-ActivityType $ActivityType
}
 Sugerencia
Puede usar esta técnica de bucle para comprobar cualquiera de las operaciones
registradas en el registro de actividad.
Aquí se muestra una respuesta JSON de ejemplo. Incluye dos actividades que realizó el
usuario:
La primera actividad muestra que se creó un vínculo para compartir para un

usuario. Tenga en cuenta que el valor SharingAction difiere en función de si el
usuario creó un vínculo, editó un vínculo o eliminó un vínculo. Por motivos de
brevedad, solo se muestra un tipo de actividad de vínculo de uso compartido en la
respuesta.
La segunda actividad muestra que se creó el uso compartido de acceso directo
para un grupo. Tenga en cuenta que el valor SharingInformation difiere en función
de la acción realizada. Por motivos de brevedad, solo se muestra un tipo de
actividad de acceso directo de uso compartido en la respuesta.
JSON
[
{
"Id": "be7506e1-2bde-4a4a-a210-bc9b156142c0",
"RecordType": 20,
"CreationTime": "2023-03-15T19:52:42Z",
"Operation": "ShareReport",
"UserType": 0,
"UserKey": "900GGG12D2242A",
"UserId": "morgan@contoso.com",
"ClientIP": "192.168.1.1",
"UserAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0)
Gecko/20100101 Firefox/110.0",
"Activity": "ShareReport",
"ItemName": "Call Center Stats",
"SharingInformation": [
{
"RecipientEmail": "ellis@contoso.com",
"RecipientName": "Turner",
"ObjectId": "fc9bbc6c-e39b-44cb-9c8a-d37d5665ec57",
"ResharePermission": "ReadReshare",
"UserPrincipalName": "ellis@contoso.com"
}
],
"ObjectId": "Call Center Stats",
"Datasets": [
{
"DatasetId": "fgagrwa3-9044-3e1e-228f-k24bf72gg995",
"DatasetName": "Call Center Data"
}
],
"ArtifactId": "81g22w11-vyy3-281h-1mn3-822a99921541",
"ArtifactName": "Call Center Stats",
"IsSuccess": true,
"RequestId": "7d55cdd3-ca3d-a911-5e2e-465ac84f7aa7",
"ActivityId": "4b8b53f1-b1f1-4e08-acdf-65f7d3c1f240",
"SharingAction": "CreateShareLink",
"ShareLinkId": "J_5UZg-36m",
"ArtifactKind": "Report",
"SharingScope": "Specific People"
},
{
"Id": "b4d567ac-7ec7-40e4-a048-25c98d9bc304",
"RecordType": 20,
"CreationTime": "2023-03-15T11:57:26Z",
"Operation": "ShareReport",
"UserType": 0,
"UserKey": "900GGG12D2242A",
"ClientIP": "69.132.26.0",
"Activity": "ShareReport",
"ItemName": "Gross Margin Analysis",
"SharingInformation": [
{
"RecipientName": "SalesAndMarketingGroup-NorthAmerica",
"ObjectId": "ba21f28b-6226-4296-d341-f059257a06a7",
"ResharePermission": "Read"
}
],
"CapacityId": "1DB44EEW-6505-4A45-B215-101HBDAE6A3F",
"CapacityName": "Shared On Premium - Reserved",
"ObjectId": "Gross Margin Analysis",
"Datasets": [
{
"DatasetId": "cfafbeb1-8037-4d0c-896e-a46fb27ff229",
"DatasetName": "Sales Data"
}
],
"ArtifactId": "94e57e92-Cee2-486d-8cc8-218c97200579",
"ArtifactName": "Gross Margin Analysis",
"IsSuccess": true,
"RequestId": "82219e60-6af0-0fa9-8599-c77ed44fff9c",
"ActivityId": "1d21535a-257e-47b2-b9b2-4f875b19855e",
"SensitivityLabelId": "16c065f5-ba91-425e-8693-261e40ccdbef",
"SharingAction": "Direct",
"ArtifactKind": "Report",
"SharingScope": "Specific People"
}
]
７ Nota
Esta respuesta JSON muestra que la estructura de datos es diferente en función del
tipo de evento. Incluso el mismo tipo de evento puede tener características
diferentes que producen una salida ligeramente diferente. Como se recomienda
anteriormente en este artículo, debería acostumbrarse a recuperar los datos sin
procesar.
Ejemplo 4: Ver tres actividades durante N días

A veces, es posible que quiera investigar varias actividades relacionadas. En este
ejemplo se muestra cómo recuperar tres actividades específicas para los siete días
anteriores. Se centra en las actividades relacionadas con las aplicaciones de Power BI,
incluida la creación de una aplicación, la actualización de una aplicación y la instalación
de una aplicación.
El script declara las siguientes variables:
$NbrOfDaysToCheck : cuántos días le interesa comprobar. Realiza un bucle que

trabaje hacia atrás desde el día actual. El valor máximo permitido es 30 días
actual).
$Activity1 : nombre de la operación de la primera actividad que está
investigando. En este ejemplo, se buscan actividades de creación de aplicaciones
de Power BI.
$Activity2 : el nombre de la segunda operación. En este ejemplo, se buscan
actividades de actualización de aplicaciones de Power BI.
$Activity3 : el nombre de la tercera operación. En este ejemplo, se buscan
actividades de instalación de aplicaciones de Power BI.
Solo puede recuperar eventos de actividad para una actividad a la vez. Por lo tanto, el
script busca cada operación por separado. Combina los resultados de búsqueda en una
variable denominada $FullResults , que luego genera en la pantalla.
Ｕ Precaución
La ejecución de muchos bucles muchas veces aumenta considerablemente la

probabilidad de limitación de API. La limitación puede producirse cuando se supera
el número de solicitudes que puede realizar en un período de tiempo determinado.
La operación Obtener eventos de actividad está limitada a 200 solicitudes por
hora. Al diseñar los scripts, tenga cuidado de no recuperar los datos originales más
veces de lo que necesita. Por lo general, es recomendable extraer todos los datos
sin procesar una vez al día y, a continuación, consultar, transformar, filtrar o dar
formato a esos datos por separado.
El script muestra los resultados del día actual.
７ Nota
Para recuperar resultados solo para el día anterior (evitar resultados parciales del
día), consulte el ejemplo Exportar todas las actividades de los N días anteriores).
PowerShell

$NbrOfDaysToCheck = 7
$Activity1 = 'CreateApp'
$Activity2 = 'UpdateApp'
$Activity3 = 'InstallApp'
#-----------------------------------------------------------------------
#Initialize array which will contain the full resultset:
$FullResults = @()
#Use today to start counting back the number of days to check:

$DayUTC = (([datetime]::Today.ToUniversalTime()).Date)
#Iteratively loop through each day (<Initilize> ; <Condition> ; <Repeat>)

#Append each type of activity to an array:
For($LoopNbr=0; $LoopNbr -le $NbrOfDaysToCheck; $LoopNbr++)
{
$PeriodStart=$DayUTC.AddDays(-$LoopNbr)
$ActivityDate=$PeriodStart.ToString("yyyy-MM-dd")
Write-Verbose "Checking $ActivityDate" -Verbose
#Get activity 1 and append its results into the full resultset:
$Activity1Results = @()
$Activity1Results += Get-PowerBIActivityEvent `
-StartDateTime ($ActivityDate+'T00:00:00.000') `
-EndDateTime ($ActivityDate+'T23:59:59.999') `
-ActivityType $Activity1 | ConvertFrom-Json
If ($null -ne $Activity1Results) {$FullResults += $Activity1Results}
-ActivityType $Activity2 |
ConvertFrom-Json
-ActivityType $Activity3 |
ConvertFrom-Json
}
#Convert all of the results back to a well-formed JSON object:
$FullResults = $FullResults | ConvertTo-Json
#Display results on the screen:

$FullResults
Aquí se muestra una respuesta JSON de ejemplo. Incluye tres actividades que realizó el
usuario:
La primera actividad muestra que se creó una aplicación de Power BI.

La segunda actividad muestra que se actualizó una aplicación de Power BI.
La tercera actividad muestra que un usuario instaló una aplicación de Power BI.
２ Advertencia
La respuesta solo incluye los permisos de usuario que se modificaron. Por ejemplo,
es posible que se hayan creado tres audiencias en un evento CreateApp. En el
evento UpdateApp, si solo ha cambiado una audiencia, solo aparecerá una
audiencia en los datos de OrgAppPermission. Por ese motivo, confiar en el evento
UpdateApp para realizar el seguimiento de todos los permisos de la aplicación está
incompleto porque el registro de actividad solo muestra lo que ha cambiado.
Para obtener una instantánea de todos los permisos de aplicación de Power BI, use
la operación Obtener usuarios de la aplicación como Administración de API en su
lugar.
JSON
[
{
"Id": "65a26480-981a-4905-b3aa-cbb3df11c7c2",
"RecordType": 20,
"CreationTime": "2023-03-15T18:42:13Z",
"Operation": "CreateApp",
"UserType": 0,
"ClientIP": "192.168.1.1",
"Activity": "CreateApp",
"ItemName": "Sales Reconciliations App",
"WorkSpaceName": "Sales Reconciliations",
"OrgAppPermission": {
"recipients": "Sales Reconciliations App(Entire Organization)",
"permissions": "Sales Reconciliations App(Read,CopyOnWrite)"
},
"WorkspaceId": "9325a31d-067e-4748-a592-626d832c8001",
"ObjectId": "Sales Reconciliations App",
"IsSuccess": true,
"RequestId": "ab97a4f1-9f5e-4a6f-5d50-92c837635814",
"ActivityId": "9bb54a9d-b688-4028-958e-4d7d21ca903a",
"AppId": "42d60f97-0f69-470c-815f-60198956a7e2"
},
{
"Id": "a1dc6d26-b006-4727-bac6-69c765b7978f",
"RecordType": 20,
"CreationTime": "2023-03-16T18:39:58Z",
"Operation": "UpdateApp",
"UserType": 0,
"UserKey": "100GGG12F9921B",
"ClientIP": "192.168.1.1",
"Activity": "UpdateApp",
"ItemName": "Sales Analytics",
"OrgAppPermission": {
"recipients": "Sales Reps Audience(SalesAndMarketingGroup-
NorthAmerica,SalesAndMarketingGroup-Europe)",
"permissions": "Sales Reps Audience(Read,CopyOnWrite)"
},
"WorkspaceId": "c7bffcd8-8156-466a-a88f-0785de2c8b13",
"ObjectId": "Sales Analytics",
"IsSuccess": true,
"RequestId": "e886d122-2c09-4189-e12a-ef998268b864",
"ActivityId": "9bb54a9d-b688-4028-958e-4d7d21ca903a",
"AppId": "c03530c0-db34-4b66-97c7-34dd2bd590af"
},
{
"Id": "aa002302-313d-4786-900e-e68a6064df1a",
"RecordType": 20,
"CreationTime": "2023-03-17T18:35:22Z",
"Operation": "InstallApp",
"UserType": 0,
"UserKey": "100HHH12F4412A",
"UserId": "ellis@contoso.com",
"ClientIP": "192.168.1.1",
"Activity": "InstallApp",
"ItemName": "Sales Reconciliations App",
"ObjectId": "Sales Reconciliations App",
"IsSuccess": true,
"RequestId": "7b3cc968-883f-7e13-081d-88b13f6cfbd8",
"ActivityId": "9bb54a9d-b688-4028-958e-4d7d21ca903a"
}
]
Ejemplo 5: Ver todas las actividades de un área
de trabajo durante un día
A veces, es posible que quiera investigar actividades relacionadas con un área de trabajo
específica. En este ejemplo se recuperan todas las actividades de todos los usuarios
durante un día. A continuación, filtra los resultados para que pueda centrarse en el
análisis de actividades de un área de trabajo.
El script declara dos variables:
$ActivityDate : la fecha en la que está interesado. El formato es AAAA-MM-DD. No
se puede solicitar una fecha anterior a 30 días antes de la fecha actual.

$WorkspaceName : el nombre del área de trabajo que le interesa.
Almacena los resultados en la variable $Results . A continuación, convierte los datos

JSON en un objeto para que se puedan analizar los resultados. A continuación, filtra los
resultados para recuperar cinco columnas específicas. Se cambia el nombre de los datos
CreationTime como ActivityDateTime. Los resultados se filtran por el nombre del área de
trabajo y, a continuación, se envían a la pantalla.
No hay ningún parámetro para el cmdlet Get-PowerBIActivityEvent que le permite

especificar un área de trabajo al comprobar el registro de actividad (en los ejemplos
anteriores de este artículo se usaban parámetros de PowerShell para establecer un
nombre de usuario, fecha o actividad específico). En este ejemplo, el script recupera
todos los datos y, a continuación, analiza la respuesta JSON para filtrar los resultados de
un área de trabajo específica.
Ｕ Precaución
Si se encuentra en una organización grande que tiene cientos o miles de

actividades al día, el filtrado de los resultados después de que se hayan recuperado
puede ser muy ineficaz. Tenga en cuenta que la operación Obtener eventos de
actividad está limitada a 200 solicitudes por hora.
Para evitar la limitación de API (cuando se supera el número de solicitudes que se

le permite realizar en un período de tiempo determinado), no recupere los datos
originales más de lo que necesita. Puede seguir trabajando con los resultados
filtrados sin ejecutar el script para recuperar los resultados de nuevo. En el caso de
las necesidades continuas, se recomienda extraer todos los datos una vez al día y, a
continuación, consultarlos muchas veces.
PowerShell

$ActivityDate = '2023-03-22'
$WorkspaceName = 'Sales Analytics'
#----------------------------------------------------------------------
#Run cmdlet to check activity events and store intermediate results:
$Events = Get-PowerBIActivityEvent `
-EndDateTime ($ActivityDate+'T23:59:59.999')
#Convert from JSON so we can parse the data:

$ConvertedResults = $Events | ConvertFrom-Json
#Obtain specific attributes and save to a PowerShell object:

$FilteredResults = $ConvertedResults `
|
Select-Object `
@{Name="ActivityDateTime";Expression={$PSItem.CreationTime}}, ` #alias
name
Activity, `
UserId, `
ArtifactName, `
WorkspaceName `
|
#Filter the results:
Where-Object {($PSItem.WorkspaceName -eq $WorkspaceName)}
#View the filtered results:

$FilteredResults
#Optional - Save back to JSON format:

#$FilteredResults = $FilteredResults | ConvertTo-Json -Depth 10
#$FilteredResults
Estos son los resultados filtrados, que incluyen un pequeño subconjunto de
propiedades. El formato es más fácil de leer para análisis ocasionales. Sin embargo, se
recomienda volver a convertirla en formato JSON si tiene previsto almacenar los
resultados.
７ Nota
Después de convertir los resultados JSON en un objeto de PowerShell, los valores
de hora se convierten en hora local. Los datos de auditoría originales siempre se
registran en hora universal coordinada (UTC), por lo que se recomienda que esté
acostumbrado a usar solo la hora UTC.
Resultados
ActivityDateTime : 4/25/2023 3:18:30 PM

Activity : ViewReport
UserId : jordan@contoso.com
ArtifactName : Gross Margin Analysis
WorkSpaceName : Sales Analytics
CreationTime : 4/25/2023 5:32:10 PM

Activity : ShareReport
UserId : ellis@contoso.com
ArtifactName : Call Center Stats
CreationTime : 4/25/2023 9:03:05 PM

Activity : ViewReport
UserId : morgan@contoso.com
ArtifactName : Call Center Stats
 Sugerencia
Puede usar esta técnica para filtrar los resultados por cualquier propiedad de los
resultados. Por ejemplo, puede usar un evento RequestId específico para analizar
solo un evento específico.
Ejemplo 6: Exportar todas las actividades de los

N días anteriores
A veces, es posible que desee exportar todos los datos de actividad a un archivo para
que pueda trabajar con los datos fuera de PowerShell. En este ejemplo se recuperan
todas las actividades de todos los usuarios durante 30 días. Exporta los datos a un
archivo JSON al día.
） Importante
Los datos del registro de actividad están disponibles durante un máximo de 30

días. Es importante que exporte y conserve los datos para poder realizar análisis
históricos. Si actualmente no exporta y almacena los datos del registro de actividad,
se recomienda encarecidamente priorizarlo.
El script recupera todas las actividades de una serie de días. Declara tres variables:
$NbrDaysDaysToExtract : cuántos días le interesa exportar. Realiza un bucle

trabajando hacia atrás desde el día anterior. El valor máximo permitido es 30 días
actual).
$ExportFileLocation : ruta de acceso de carpeta donde desea guardar los archivos.
La carpeta debe existir antes de ejecutar el script. No incluya un carácter de barra

diagonal inversa (\) al final de la ruta de acceso de la carpeta (porque se agrega
automáticamente en tiempo de ejecución). Se recomienda usar una carpeta
independiente para almacenar archivos de datos sin procesar.
$ExportFileName : el prefijo de cada nombre de archivo. Dado que se guarda un
archivo al día, el script agrega un sufijo para indicar los datos contenidos en el
archivo y la fecha y hora en que se recuperaron los datos. Por ejemplo, si ejecutó
un script a las 9:00 (UTC) el 25 de abril de 2023 para extraer datos de actividad
para el 23 de abril de 2023, el nombre de archivo sería: PBIActivityEvents-
20230423-202304250900. Aunque la estructura de carpetas en la que se almacena
es útil, cada nombre de archivo debe ser totalmente autodescriptivo.
Se recomienda extraer datos que son al menos un día antes del día actual. De este
modo, evita recuperar eventos de día parciales y puede estar seguro de que cada
archivo de exportación contiene las 24 horas completas de datos.
El script recopila hasta 30 días de datos hasta el día anterior. Las marcas de tiempo de
los eventos auditados siempre están en UTC. Le recomendamos que compile todos los
procesos de auditoría en función de la hora UTC en lugar de la hora local.
El script genera un archivo JSON al día. El sufijo del nombre de archivo incluye la marca
de tiempo (en formato UTC) de los datos extraídos. Si extrae el mismo día de datos más
de una vez, el sufijo en el nombre de archivo le ayuda a identificar el archivo más
reciente.
PowerShell

$NbrDaysDaysToExtract = 7
$ExportFileLocation = 'C:\Power-BI-Raw-Data\Activity-Log'
$ExportFileName = 'PBIActivityEvents'
#--------------------------------------------
#Start with yesterday for counting back to ensure full day results are
obtained:
[datetime]$DayUTC = (([datetime]::Today.ToUniversalTime()).Date).AddDays(-1)
#Suffix for file name so we know when it was written:

[string]$DateTimeFileWrittenUTCLabel =
([datetime]::Now.ToUniversalTime()).ToString("yyyyMMddHHmm")
#Loop through each of the days to be extracted (<Initilize> ; <Condition> ;

<Repeat>)
For($LoopNbr=0 ; $LoopNbr -lt $NbrDaysDaysToExtract ; $LoopNbr++)
{
[datetime]$DateToExtractUTC=$DayUTC.AddDays(-$LoopNbr).ToString("yyyy-
MM-dd")
[string]$DateToExtractLabel=$DateToExtractUTC.ToString("yyyy-MM-dd")
#Create full file name:

[string]$FullExportFileName = $ExportFileName `
+ '-' + ($DateToExtractLabel -replace '-', '') `
+ '-' + $DateTimeFileWrittenUTCLabel `
+ '.json'
#Obtain activity events and store intermediary results:

[psobject]$Events=Get-PowerBIActivityEvent `
-StartDateTime ($DateToExtractLabel+'T00:00:00.000') `
-EndDateTime ($DateToExtractLabel+'T23:59:59.999')
#Write one file per day:

$Events | Out-File "$ExportFileLocation\$FullExportFileName"
Write-Verbose "File written: $FullExportFileName" -Verbose

}
Write-Verbose "Extract of Power BI activity events is complete." -Verbose
Hay varias ventajas para usar el cmdlet Get-PowerBIActivityEvent de PowerShell en lugar

de la operación Obtener eventos de actividad de API de REST.
El cmdlet permite solicitar un día de actividad cada vez que realice una llamada
mediante el cmdlet. Mientras que cuando se comunica directamente con la API,
solo puede solicitar una hora por solicitud de API.
El cmdlet le gestiona los tokens de continuación. Si usa la API directamente, debe
comprobar el token de continuación para determinar si hay más resultados.
Algunas API deben usar tokens de paginación y continuación por motivos de
rendimiento cuando devuelven una gran cantidad de datos. Devuelven el primer
conjunto de registros y, a continuación, con un token de continuación, puede
realizar una llamada API posterior para recuperar el siguiente conjunto de
registros. Seguirá llamando a la API hasta que no se devuelva un token de
continuación. El uso del token de continuación es una manera de consolidar varias
solicitudes de API para que pueda consolidar un conjunto lógico de resultados.
Para obtener un ejemplo del uso de un token de continuación, consulte la REST
API de eventos de actividad.
El cmdlet controla las expiraciones del token de acceso de Azure Active Directory
(Azure AD). Después de autenticarse, el token de acceso expira después de una
hora (de forma predeterminada). En este caso, el cmdlet solicita automáticamente
un token de actualización. Si se comunica directamente con la API, debe solicitar
un token de actualización.
Para obtener más información, consulte Elegir API o cmdlets de PowerShell.
７ Nota
Se omite una respuesta de ejemplo porque es una salida similar a las respuestas
que se muestran en los ejemplos anteriores.
Pasos siguientes
Seguimiento de actividades de usuario en Power BI

Planificación de la implementación de Power BI: auditoría de nivel de inquilino
Hoja de ruta de adopción de Power BI: auditoría y supervisión
Información general sobre la migración
a Power BI
Los clientes adoptan cada vez más medidas para estandarizar Power BI con el fin de
impulsar una cultura de datos, lo que implica habilitar inteligencia empresarial con
características de autoservicio (SSBI) administrada, racionalizar la entrega de BI
empresarial y resolver presiones económicas. La finalidad de esta serie de artículos
sobre la migración a Power BI es proporcionarle instrucciones sobre cómo planear y
llevar a cabo una migración desde una herramienta de BI de terceros a Power BI.
Los artículos de la serie sobre la migración a Power BI incluyen los siguientes:
1. Información general sobre la migración a Power BI (este artículo)

2. Preparación para realizar la migración a Power BI
3. Recopilación de requisitos para la migración a Power BI (fase 1)
4. Planeamiento de la implementación para la migración a Power BI (fase 2)
5. Realización de una prueba de concepto para la migración a Power BI (fase 3)
6. Creación de contenido para la migración a Power BI (fase 4)
7. Implementación en Power BI (fase 5)
8. Más información sobre las migraciones de los clientes a Power BI
７ Nota
También se recomienda leer atentamente los artículos Hoja de ruta de adopción

de Power BI y Planeamiento de la implementación de Power BI.
Hay dos supuestos: su organización tiene actualmente una plataforma de BI heredada y

se ha tomado la decisión de migrar formalmente el contenido y los usuarios a Power BI.
La migración al servicio Power BI es el objetivo principal de esta serie. Es posible que se
apliquen consideraciones adicionales en el caso de los clientes de nubes nacionales,
además de lo que se describe en esta serie de artículos.
En el diagrama siguiente se muestran cuatro fases generales para implementar Power BI

en su organización.
Fase Descripción
Configuración y evaluación de Power BI. La primera fase implica el establecimiento de la

arquitectura inicial de Power BI. En este momento, se controlan la implementación
preliminar y el planeamiento de la gobernanza, así como evaluaciones de Power BI, como
el análisis de costos y beneficios, o la rentabilidad de la inversión.
Creación rápida de soluciones en Power BI. En la segunda fase, los autores de BI con
características de autoservicio pueden empezar a usar y evaluar Power BI en función de sus
necesidades, y se puede obtener valor de Power BI rápidamente. Las actividades de la
fase 2 conceden importancia a la agilidad y al valor empresarial rápido, que son
fundamentales para lograr la aceptación de la selección de una nueva herramienta de BI
como Power BI. Por esta razón, el diagrama muestra las actividades de la fase 2 en paralelo
con las actividades de migración de la fase 3.
Migración de recursos de BI de la plataforma heredada a Power BI. La tercera fase

aborda la migración a Power BI. Se trata del objetivo de esta serie de artículos sobre la
migración a Power BI. En la sección siguiente se describen cinco fases de migración
específicas.
Adopción, control y supervisión de Power BI. La fase final consta de actividades continuas
tales como el fomento de una cultura de datos, la comunicación y el aprendizaje. Estas
actividades tienen gran repercusión en una implementación eficaz de Power BI. Es
importante contar con directivas y procesos de gobernanza y seguridad adecuados para
su organización, además de auditorías y supervisiones que le permitan escalar, crecer y
mejorar continuamente.
） Importante
Una migración formal a Power BI casi siempre se produce en paralelo con el

desarrollo de una nueva solución de Power BI. Solución de Power BI es un término
genérico que engloba el uso de datos e informes. Un solo archivo de Power BI
Desktop (.pbix) puede contener un modelo de datos, un informe o ambos. Se
recomienda separar el modelo de datos de los informes con fines de reutilización
de datos, pero no es necesario.
El uso de Power BI para crear requisitos, mientras planea y lleva a cabo la migración
formal, le ayudará a ganar aceptación. Las fases simultáneas ofrecen a los autores
de contenido una experiencia práctica y real con Power BI.
Cinco fases de una migración a Power BI

La fase 3 del diagrama aborda la migración a Power BI. Durante esta fase, hay cinco
fases comunes.
Las fases que se muestran en el diagrama anterior son las siguientes:
Pasos previos a la migración

Fase 1: recopilación y priorización de requisitos
Fase 2: planeamiento de la implementación
Fase 3: realización de una prueba de concepto
Fase 4: creación y validación de contenido
Fase 5: implementación, soporte técnico y supervisión
Pasos previos a la migración

Los pasos previos a la migración incluyen acciones que puede plantearse antes de
comenzar un proyecto para migrar contenido de una plataforma de BI heredada a
Power BI. Normalmente se incluye el planeamiento inicial de la implementación de nivel
de inquilino. Para más información sobre estas actividades, consulte Preparación para
realizar la migración a Power BI.
Fase 1: recopilación y priorización de requisitos
El énfasis de la fase 1 radica en recopilar información y planear la migración de una sola
solución. Este proceso debe ser iterativo y tener como ámbito un esfuerzo de tamaño
razonable. La salida de la fase 1 incluye un inventario por orden de prioridad de los
informes y datos que se van a migrar. Se necesitan actividades adicionales en las fases 2
y 3 para calcular por completo el nivel de esfuerzo. Para más información sobre las
actividades de la fase 1, consulte Recopilación de requisitos para la migración a
Power BI.
Fase 2: planeamiento de la implementación

La fase 2 se centra en cómo se pueden cumplir los requisitos definidos en la fase 1 para
cada solución específica. La salida de la fase 2 incluye tantos detalles como sea posible
para guiar el proceso, aunque se trata de un proceso iterativo y no lineal. La creación de
una prueba de concepto (fase 3) puede producirse en paralelo con esta fase. Incluso
durante la creación de la solución (fase 4), puede que haya información adicional que
influya en las decisiones de planeamiento de la implementación. Este tipo de
planeamiento de implementación de la fase 2 se centra en el nivel de la solución, a la
vez que respeta las decisiones ya realizadas en el nivel de la organización. Para más
información sobre las actividades de la fase 2, consulte Planeamiento de la
implementación para la migración a Power BI.
Fase 3: realización de una prueba de concepto

El énfasis de la fase 3 se pone en abordar los factores desconocidos y mitigar los riesgos
cuanto antes. Una prueba de concepto (POC) técnica resulta útil para validar supuestos
y se puede realizar de forma iterativa junto con el planeamiento de la implementación
(fase 2). La salida de esta fase es una solución de Power BI de ámbito reducido. Tenga en
cuenta que no se pretende que la POC sea un trabajo descartable. Aunque es probable
que haya que realizar trabajo adicional en la fase 4 para que esté lista para producción.
En este sentido, en su organización, puede hacer referencia a esta actividad como un
prototipo, un piloto, un boceto, un inicio rápido o un producto mínimamente viable
(MVP). No siempre es necesario realizar una POC y se puede realizar de manera
informal. Para más información sobre las actividades de la fase 3, consulte Realización
de una prueba de concepto para la migración a Power BI.
Fase 4: creación y validación de contenido

En la fase 4 es donde se realiza el trabajo real para convertir la POC en una solución lista
para producción. La salida de esta fase es una solución de Power BI completa que se ha
validado en un entorno de desarrollo. Debe estar lista para implementación en la fase 5.
Para más información sobre las actividades de la fase 4, consulte Creación de contenido
para la migración a Power BI.
Fase 5: implementación, soporte técnico y supervisión

El objetivo principal de la fase 5 es implementar la nueva solución de Power BI en
producción. La salida de esta fase es una solución de producción que los usuarios
empresariales utilizan de forma activa. Cuando se usa una metodología ágil, conviene
tener algunas mejoras planeadas, que se entregarán en una futura iteración. Según su
nivel de comodidad con Power BI, como el uso de minimización de riesgos e
interrupción del usuario, puede optar por realizar una implementación por fases.
También puede implementar inicialmente en un grupo más pequeño de usuarios piloto.
El soporte técnico y la supervisión también son importantes en esta fase y de forma
continua. Para más información sobre las actividades de la fase 5, consulte Migración a
Power BI.
 Sugerencia
La mayoría de los conceptos descritos en esta serie de artículos sobre la migración

a Power BI se aplican también a un proyecto de implementación estándar de
Power BI.
Consideración de los motivos de la migración

Habilitar una cultura de datos productiva y de calidad es un objetivo principal de
muchas organizaciones. Power BI es una herramienta excelente para facilitar este
objetivo. Tres razones comunes por las que podría considerarse una migración a
Power BI se pueden resumir en lo siguiente:
Habilitar una inteligencia empresarial de autoservicio administrada incluyendo

características nuevas que aporten más capacidad a la comunidad de usuarios de
la inteligencia empresarial de autoservicio. Power BI hace que el acceso a la
información y la toma de decisiones estén disponibles más ampliamente, mientras
que se depende menos de aptitudes especializadas que pueden ser difíciles de
encontrar.
Racionalizar la entrega de inteligencia empresarial corporativa para cumplir
requisitos que no se abordan con las herramientas de BI existentes, al tiempo que
se disminuye el nivel de complejidad, se reduce el costo de propiedad y se
normalizan las diferentes herramientas de BI que están actualmente en uso.
Resolver presiones económicas para aumentar la productividad con menos
recursos, tiempo y personal.
Logro del éxito en la migración a Power BI

Cada migración es ligeramente diferente. Puede depender de la estructura organizativa,
las estrategias de datos, la madurez de administración de los datos y los objetivos de la
organización. Sin embargo, hay algunas prácticas que vemos constantemente cuando
nuestros clientes logran el éxito en la migración a Power BI.
Patrocinio ejecutivo: identifique un patrocinador ejecutivo al principio del proceso.

Esta persona debe ser alguien que impulse BI de forma activa en la organización y
que se dedique personalmente a lograr un resultado positivo de la migración. Lo
ideal es que el patrocinador ejecutivo tenga la autoridad y responsabilidad finales
en los resultados relacionados con Power BI. Para obtener más información,
consulta este artículo.
Aprendizaje, soporte técnico y comunicación: reconozca que es algo más que una
iniciativa tecnológica. Cualquier proyecto de inteligencia empresarial o de análisis
es también una iniciativa que involucra al personal, por lo que es conveniente
invertir desde el principio en la formación de los usuarios y el soporte técnico.
Además, cree un plan de comunicación que explique con transparencia a todas las
partes interesadas lo que sucede y el porqué, y que establezca expectativas
realistas. Asegúrese de incluir un bucle de comentarios en el plan de comunicación
para recopilar las aportaciones de las partes interesadas.
Logros rápidos: inicialmente, dé prioridad a los elementos más importantes que
tengan un valor empresarial tangible y sean apremiantes. En lugar de tratar
estrictamente de migrar siempre los informes exactamente como aparecen en la
plataforma de BI heredada, céntrese en la pregunta empresarial que el informe
trata de responder (incluida la acción que se va a realizar) al abordar el informe
rediseñado.
Modernización y mejoras: esté dispuesto a replantearse cómo se han hecho
siempre las cosas. Una migración puede brindar una oportunidad de lograr
mejoras. Por ejemplo, podría eliminar la preparación manual de los datos o
reubicar reglas de negocio que se limitaban a un único informe. Valore la
posibilidad de refactorizar, modernizar y consolidar las soluciones existentes
cuando el esfuerzo pueda justificarse. Esto puede incluir la consolidación de varios
informes en uno o la eliminación de elementos heredados que no se han usado
durante algún tiempo.
Aprendizaje continuo: esté preparado para usar un enfoque por fases mientras
aprende y se adapta continuamente. Trabaje en ciclos cortos e iterativos que
aporten valor rápidamente. Haga una práctica frecuente de completar pequeñas
POC para minimizar el riesgo de factores desconocidos, validar supuestos e
informarse sobre las nuevas características. Como Power BI es un servicio en la
nube que se actualiza mensualmente, es importante mantenerse al tanto de los
desarrollos y ajustar el rumbo cuando sea necesario.
Resistencia al cambio: entienda que tal vez haya distintos niveles de resistencia al
cambio; algunos usuarios se resistirán al aprendizaje de una nueva herramienta.
Además, algunos profesionales que han dedicado mucho tiempo y esfuerzo para
obtener experiencia con una herramienta de BI distinta pueden sentirse
amenazados por ser desplazados. Esté preparado, ya que pueden originarse
controversias internas, especialmente en organizaciones altamente
descentralizadas.
Restricciones: sea realista con los planes de migración, lo que incluye la
financiación, las estimaciones de tiempo, así como los roles y las responsabilidades
de todos los usuarios implicados.
Agradecimientos
Melissa Coates, Microsoft MVP de la plataforma de datos y propietaria de Coates Data
Strategies , es quien ha redactado esta serie de artículos. Entre los colaboradores y
revisores se incluyen Marc Reguera, Venkatesh Titte, Patrick Baumgartner, Tamer Farag,
Richard Tkachuk, Matthew Roche, Adam Saxton, Chris Webb, Mark Vaillancourt, Daniel
Rubiolo, David Iseminger y Peter Myers.
Pasos siguientes
En el siguiente artículo de esta serie sobre la migración a Power BI, conocerá los pasos
previos a la migración a Power BI.
Otros recursos útiles incluyen los siguientes:

Planeamiento de la implementación de Power BI
Notas del producto de la planeación de una implementación de Power BI
Enterprise
Migración de informes de SSRS a Power BI
Hay partners de Power BI experimentados a su disposición para ayudar a su
organización a tener éxito en el proceso de migración. Para ponerse en contacto con un
partner de Power BI, visite el portal de partners de Power BI .
Preparación para migrar a Power BI
En este artículo se indican las acciones que se pueden considerar antes de migrar a
Power BI.
７ Nota
Para obtener una explicación completa del gráfico anterior, vea Información
general sobre la migración de Power BI.
En los pasos previos a la migración se hace hincapié en la planeación inicial, que es una
preparación importante antes de pasar por las cinco fases de migración. La mayoría de
los pasos previos a la migración ocurren una vez, aunque en el caso de las
organizaciones de mayor tamaño algunas partes pueden ser iterativas para cada unidad
de negocio o departamento.
El resultado de los pasos previos a la migración incluye un modelo de gobernanza

inicial, una planeación de implementación inicial de alto nivel y un inventario de los
informes y los datos que se van a migrar. Se necesita información adicional de las
actividades de las fases 1, 2 y 3 para estimar en su totalidad el nivel de esfuerzo
necesario para migrar soluciones individuales.
 Sugerencia
La mayoría de los temas que se tratan en este artículo también se aplican a un

proyecto de implementación estándar de Power BI.
Creación de análisis y evaluación de costos y
beneficios
Algunas consideraciones fundamentales durante la evaluación inicial incluyen la
obtención de lo siguiente:
Claridad sobre el caso de negocio y la estrategia de BI para alcanzar un estado

futuro deseado concreto.
Claridad sobre qué significa el éxito y sobre cómo medir el progreso y el éxito de
la iniciativa de migración.
Estimaciones de costos y resultados de cálculos de rentabilidad de la inversión
(ROI).
Resultados correctos de varias iniciativas productivas de Power BI de menor
ámbito y nivel de complejidad.
Identificación de las partes interesadas y el

apoyo directivo
Algunas consideraciones para identificar a las partes interesadas incluyen lo siguiente:
Asegúrese de que el patrocinio ejecutivo está en vigor.

Garantizar la convergencia con las partes interesadas sobre el caso de negocio y la
estrategia de BI.
Incluir a representantes de todas las unidades de negocio, aunque la migración de
su contenido esté prevista para más adelante, a fin de comprender sus
motivaciones y preocupaciones.
Implicar a los expertos de Power BI en una fase temprana.
Crear, y seguir, un plan de comunicación con las partes interesadas.
 Sugerencia
Si se teme estar empezando a sobrecargar con información, probablemente esté

haciendo lo correcto.
Creación de un modelo de gobernanza inicial

Algunos puntos clave que se deben abordar al principio de una implementación de
Power BI incluyen:
Objetivos específicos para la adopción de Power BI y dónde encaja Power BI en la
estrategia general de BI de la organización.
Cómo se va a controlar el rol Administrador de Power BI, especialmente en
organizaciones descentralizadas.
Directivas relacionadas con la obtención de datos de confianza: uso de orígenes de
datos acreditados, solución de problemas de calidad de los datos y uso de
definiciones comunes y terminología coherentes.
Estrategia de seguridad y privacidad de los datos de orígenes de datos, modelos
de datos, informes y entrega de contenido a usuarios internos y externos.
Cómo se van a cumplir los requisitos de cumplimiento, normativos y de auditoría
internos y externos.
） Importante
El modelo de gobernanza más eficaz intenta equilibrar la capacitación del usuario

con el nivel de control necesario. Obtenga más información, lea sobre Disciplina en
el núcleo y Flexibilidad en el borde.
Elaboración de un plan de implementación

inicial
El plan de implementación inicial conlleva definir estándares, directivas y preferencias
para la implementación de Power BI de la organización.
Observe que la fase 2 se refiere al plan de implementación de nivel de solución. Las

actividades de la fase 2 deben respetar las decisiones de nivel de organización siempre
que sea posible.
Algunos puntos críticos que se deben abordar al principio de una implementación de

Power BI incluyen lo siguiente:
Decisiones de configuración de inquilinos de Power BI, que se deben documentar.

Decisiones de administración de áreas de trabajo, que se deben documentar.
Consideraciones y preferencias relacionadas con los datos y los métodos de
distribución de contenido, como aplicaciones, áreas de trabajo, uso compartido,
suscripciones e inserción de contenido.
Preferencias relacionadas con los modos de conjuntos de datos, como el uso del
modo de importación, el modo DirectQuery o la combinación de los dos modos en
un modelo compuesto.
Protección de datos y acceso.
Trabajo con conjuntos de datos compartidos para la reutilización.
Aplicación de certificación de datos para fomentar el uso de datos acreditados y
de confianza.
Uso de diferentes tipos de informes, incluidos informes de Power BI, informes de
Excel o informes paginados para diferentes casos de uso o unidades de negocio.
Cambios de los enfoques de administración para administrar elementos de BI
centralizados y elementos de BI administrados por la empresa.
Planes de aprendizaje para consumidores, modeladores de datos, autores de
informes y administradores.
Soporte para autores de contenido mediante plantillas de Power BI Desktop,
objetos visuales personalizados y estándares de diseño de informes
documentados.
Procedimientos y procesos para administrar los requisitos de los usuarios, como la
solicitud de nuevas licencias, la incorporación de nuevos orígenes de datos de
puerta de enlace, la obtención de permisos a orígenes de datos de puerta de
enlace, la solicitud de nuevas áreas de trabajo, los cambios de permisos de áreas
de trabajo y otros requisitos comunes que se pueden detectar de forma periódica.
） Importante
El plan de implementación es un proceso iterativo. Las decisiones de

implementación se perfeccionan y extienden muchas veces a medida que aumenta
la experiencia de la organización con Power BI y que este evoluciona. Las
decisiones tomadas a lo largo de este proceso se usan durante el plan de
implementación de nivel de solución descrito en la fase 2 del proceso de
migración.
Establecimiento de la arquitectura inicial

La arquitectura de la solución de BI evoluciona y madura con el tiempo. Las tareas de
configuración de Power BI que se deben abordar de inmediato incluyen:
Configuración de inquilinos de Power BI e integración con Azure Active Directory.

Definición de administradores de Power BI.
Adquisición y asignación de licencias de usuario iniciales.
Configuración y revisión de la configuración de inquilinos de Power BI.
Configuración de roles de áreas de trabajo y asignación de acceso a grupos de
seguridad y usuarios de Azure Active Directory.
Configuración de un clúster de puerta de enlace de datos inicial, con un plan para
actualizar con regularidad.
Adquisición de una licencia de capacidad Premium inicial (si procede).
Configuración de cargas de trabajo de capacidad Premium, con un plan para
administrar de manera continuada.
Definición de criterios de éxito de la migración

La primera tarea es comprender qué se considera éxito de la migración en una solución
individual. Estas son algunas de las preguntas que pueden formularse:
¿Cuáles son las motivaciones y los objetivos concretos de esta migración? Para
obtener más información, vea Información general sobre la migración de Power BI
(Consideración de los motivos de la migración). En este artículo se indican las
razones más habituales para migrar a Power BI. Sin duda, los objetivos deben
especificarse en el nivel de organización. Por lo demás, la migración de una
solución de BI heredada puede beneficiarse considerablemente de los ahorros de
costos, mientras que la migración de otra solución de BI heredada puede centrarse
en obtener ventajas de optimización de flujos de trabajo.
¿Cuál es la relación costo/beneficio esperada o ROI de esta migración? El tener
un reconocimiento claro de las expectativas relacionadas con el costo, el aumento
de capacidades, la menor complejidad o la mayor agilidad resulta útil para medir el
éxito. Puede proporcionar principios orientativos para ayudar a tomar decisiones
durante el proceso de migración.
¿Qué indicadores clave de rendimiento (KPI) se van a usar para medir el éxito?
En la siguiente lista se muestran algunos ejemplos de KPI:
Número de informes representados desde la plataforma de BI heredada, que se
reduce mes tras mes.
Número de informes representados desde Power BI, que aumenta mes tras mes.
Número de consumidores de informes de Power BI, que aumenta trimestre tras
trimestre.
Porcentaje de informes migrados a producción por fecha objetivo.
Reducción de costos en el apartado de costos de licencias año tras año.
 Sugerencia
El registro de actividad de Power BI se puede usar como origen para medir el

progreso de los KPI.
Preparación del inventario de informes

existentes
La preparación de un inventario de los informes existentes en la plataforma de BI
heredada es un paso crítico para entender lo que ya existe. El resultado de este paso es
un aporte para evaluar el nivel de esfuerzo de migración. Estas son algunas de las
actividades relacionadas con la preparación de un inventario:
1. Inventario de informes: compile una lista de informes y paneles que sean

candidatos para la migración.
2. Inventario de orígenes de datos: compile una lista de todos los orígenes de datos
a los que acceden los informes existentes. Debe incluir tanto orígenes de datos
empresariales como orígenes de datos de departamento y personales. Este
proceso puede destapar orígenes de datos desconocidos para el departamento de
TI, lo que a menudo se conoce como TI en la sombra.
3. Registro de auditoría: obtenga datos del registro de auditoría de la plataforma de
BI heredada para comprender los patrones de uso y ayudar a priorizar. La
información importante que se debe obtener del registro de auditoría incluye:
Número medio de veces que se ha ejecutado cada informe por semana, mes
o trimestre.
Número medio de consumidores por informe por semana, mes o trimestre.
Consumidores de cada informe, especialmente los informes que usan los
ejecutivos.
Fecha más reciente en que se ha ejecutado cada informe.
７ Nota
En muchos casos, el contenido no se migra a Power BI tal cual. La migración

presenta una oportunidad de rediseñar la arquitectura de datos o de mejorar la
entrega de informes. La compilación de un inventario de informes es fundamental
para entender lo que existe actualmente a fin de poder empezar a evaluar qué
refactorización debe producirse. En el resto de artículos de esta serie se indican las
posibles mejoras más detalladamente.
Estudio de las opciones de automatización

No es posible automatizar completamente un proceso de conversión de Power BI de un
extremo a otro.
La compilación del inventario existente de datos e informes es un posible candidato

para la automatización si se tiene una herramienta que pueda hacerlo automáticamente.
La medida en que se puede usar la automatización en algunas partes del proceso de
migración, como la compilación del inventario existente, depende de las herramientas
que se tengan.
Pasos siguientes
En el siguiente artículo de esta serie de migración de Power BI se proporciona
información sobre la fase 1, que se refiere a la recopilación y la priorización de los
requisitos al migrar a Power BI.
Otros recursos útiles incluyen:
Enterprise

Recopilación de requisitos para migrar a
Power BI
En este artículo se explica la fase 1, que se refiere a la recopilación y priorización de

requisitos al migrar a Power BI.
７ Nota
El énfasis de la fase 1 se pone en la recopilación de información y la planeación de una

solución individual que se va a migrar a Power BI.
El resultado de la fase 1 incluye los requisitos detallados a los que se ha dado prioridad.
Pero es necesario finalizar por completo las actividades adicionales de las fases 2 y 3
para estimar totalmente el nivel de esfuerzo.
） Importante
Las fases 1-5 representan actividades relacionadas con una solución concreta. Hay
decisiones y actividades en el nivel de organización o inquilino que afectan al
proceso en el nivel de solución. Algunas de esas actividades de planeación de nivel
superior se tratan en el artículo Información general sobre la migración de
Power BI. Cuando proceda, dé preferencia a las decisiones de nivel de organización
por eficacia y coherencia.
La hoja de ruta de adopción de Power BI describe estos tipos de consideraciones
estratégicas y tácticas. Hace énfasis en la adopción de la organización.
 Sugerencia

Compilación de requisitos
El inventario de los elementos de BI existentes, compilado en los pasos previos a la
migración, se convierte en la entrada de los requisitos de la nueva solución que se va a
crear en Power BI. La recopilación de requisitos consiste en comprender el estado actual,
así como los elementos que los usuarios quieren cambiar o refactorizar al rediseñar
informes en Power BI. Los requisitos detallados resultan útiles para el plan de
implementación de la solución de la fase 2, durante la creación de una prueba de
concepto en la fase 3 y al crear la solución lista para producción en la fase 4.
Recopilación de requisitos de informe

Compile información detallada y fácil de referenciar sobre los informes, como:
Propósito, público y acción esperada: identifique el propósito y el proceso

empresarial aplicable a cada informe, así como el público, el flujo de trabajo
analítico y la acción esperada que deben realizar los consumidores del informe.
Empleo del informe por parte de los consumidores: le recomendamos que se
reúna con los consumidores del informe existente para comprender exactamente
lo que hacen con él. Puede observar que ciertos elementos del informe se pueden
eliminar o mejorar en la nueva versión de Power BI. Este proceso conlleva una
inversión de tiempo adicional, pero es valioso para informes críticos o que se usan
con frecuencia.
Propietario y experto en la materia: identifique al propietario del informe y a los
expertos en la materia asociados al informe o al dominio de datos. Pueden
convertirse en los propietarios del nuevo informe de Power BI en el futuro. Incluya
cualquier requisito específico de administración de cambios (los requisitos suelen
diferir entre las soluciones administradas por TI y las administradas por el negocio),
así como las aprobaciones, que se van a necesitar cuando se realicen cambios en
adelante. Para obtener más información, consulta este artículo.
Método de entrega de contenido: aclare las expectativas de los consumidores del
informe en cuanto a la entrega de contenido. Puede ser una ejecución interactiva a
petición, insertada dentro de una aplicación personalizada, o una entrega según
una programación mediante una suscripción de correo electrónico. También puede
haber requisitos para desencadenar notificaciones de alerta.
Necesidades de interactividad: determine los requisitos de interactividad
necesarios y los deseables, como filtros, acciones de exploración en profundidad o
acciones de obtención de detalles.
Orígenes de datos: asegúrese de que se detectan todos los orígenes de datos
necesarios para el informe y de que se entienden las necesidades de latencia de
datos (actualización de datos). Identifique los requisitos de datos históricos,
tendencias e instantáneas de datos de cada informe, de modo que se puedan
alinear con los requisitos de datos. La documentación del origen de datos también
puede ser útil más adelante cuando se realice la validación de datos de un nuevo
informe con sus datos de origen.
Requisitos de seguridad: aclare los requisitos de seguridad (como los visores
permitidos, los editores permitidos y cualquier necesidad de seguridad de nivel de
fila), incluidas las excepciones a la seguridad normal de la organización.
Documente cualquier nivel de confidencialidad de datos, privacidad de datos o
necesidades regulatorias o de cumplimiento.
Cálculos, KPI y reglas de negocio: identifique y documente todos los cálculos, KPI
y reglas de negocio que estén definidos actualmente en el informe existente para
que se puedan alinear con los requisitos de datos.
Requisitos de uso, diseño y cosméticos: identifique las necesidades específicas de
uso, diseño y cosméticas relacionadas con las visualizaciones de datos, los
requisitos de agrupación y ordenación y la visibilidad condicional. Incluya cualquier
consideración específica relacionada con la entrega a dispositivos móviles.
Necesidades de impresión y exportación: determine si hay algún requisito
específico para imprimir, exportar o disponer de un diseño perfecto. Estas
necesidades influyen en qué tipo de informe va a ser más adecuado (como un
informe de Power BI, Excel o paginado). Tenga en cuenta que los consumidores de
los informes suelen dar mucha importancia al modo en que siempre han hecho las
cosas, así que no tenga miedo de cuestionar su forma de pensar. Asegúrese de
hablar de mejoras en lugar de cambios.
Riesgos o preocupaciones: determine si hay otros requisitos técnicos o
funcionales para los informes, así como cualquier riesgo o preocupación con
respecto a la información que se presenta en ellos.
Incidencias abiertas y elementos de trabajo pendiente: identifique el
mantenimiento futuro, los problemas conocidos o las solicitudes aplazadas para
agregarlos al trabajo pendiente en este momento.
 Sugerencia
Considere la posibilidad de clasificar los requisitos como requisitos que debe tener
o que sería agradable tener. A menudo los consumidores solicitan todo lo que
pueden necesitar por adelantado porque creen que puede ser su única
oportunidad de realizar solicitudes. Además, al abordar prioridades en varias
iteraciones, ponga el trabajo pendiente a disposición de las partes interesadas. Eso
ayuda a la comunicación, la toma de decisiones y el seguimiento de los
compromisos pendientes.
Recopilación de requisitos de datos

Compile información detallada relativa a los datos, como:
Consultas existentes: identifique si existen consultas de informe o procedimientos

almacenados existentes que pueda usar un modelo DirectQuery o un modelo
compuesto, o que se puedan convertir en un modelo de importación.
Tipos de orígenes de datos: compile los tipos de orígenes de datos que sean
necesarios, incluidos orígenes de datos centralizados (por ejemplo, un
almacenamiento de datos de negocio) y orígenes de datos no estándar (como
archivos planos o archivos de Excel que aumenten los orígenes de datos de
negocio con fines informativos). También es importante saber dónde se
encuentran los orígenes de datos a efectos de conectividad de la puerta de enlace
de datos.
Necesidades de estructura de datos y limpieza: determine la estructura de datos
de cada origen de datos necesario y en qué medida se necesitan actividades de
limpieza de datos.
Integración de datos: evalúe cómo se va a controlar la integración de datos
cuando haya varios orígenes de datos y cómo se pueden definir relaciones entre
cada tabla del modelo. Identifique elementos de datos específicos necesarios para
simplificar el modelo y reducir su tamaño.
Latencia de datos aceptable: determine las necesidades de latencia de datos de
cada origen de datos. Estas van a influir en las decisiones sobre qué modo de
almacenamiento de datos usar. También es importante conocer la frecuencia de
actualización de datos de las tablas del modelo de importación.
Volumen de datos y escalabilidad: evalúe las expectativas de volumen de datos,
que van a influir en las decisiones sobre la compatibilidad con modelos grandes y
el diseño de modelos DirectQuery o modelos compuestos. También es
fundamental conocer las consideraciones relacionadas con las necesidades de
datos históricos. En el caso de los conjuntos de datos de mayor tamaño, también
es necesario determinar la actualización incremental de datos.
Medidas, KPI y reglas de negocio: evalúe las necesidades de medidas, KPI y reglas
de negocio. Van a afectar a las decisiones sobre dónde aplicar la lógica: en el
conjunto de datos o en el proceso de integración de datos.
Datos maestros y catálogo de datos: considere si hay problemas en los datos
maestros que requieran atención. Determine si la integración con un catálogo de
datos empresariales es adecuada para mejorar la detectabilidad, el acceso a las
definiciones o la generación de una terminología coherente aceptada por la
organización.
Seguridad y privacidad de los datos: determine si hay alguna consideración de
seguridad o de privacidad de datos específica para los conjuntos de datos,
incluidos requisitos de seguridad de nivel de fila.
Incidencias abiertas y elementos de trabajo pendiente: agregue cualquier
problema conocido, defectos sabidos de calidad de los datos, mantenimiento
futuro o solicitudes aplazadas al trabajo pendiente en este momento.
） Importante
La reutilización de datos se puede lograr con conjuntos de datos compartidos, que

opcionalmente se pueden certificar para indicar confiabilidad y mejorar la
capacidad de detección. La reutilización de la preparación de datos se puede lograr
con flujos de datos para reducir la lógica repetitiva en varios conjuntos de datos.
Los flujos de datos también pueden reducir de forma considerable la carga sobre
los sistemas de origen, ya que los datos se recuperan con menos frecuencia: varios
conjuntos de datos pueden importar datos del flujo de datos.
Identificación de oportunidades de mejora

En la mayoría de las situaciones, se producen algunas modificaciones y mejoras. Es raro
que se produzca una migración directa uno a uno sin ninguna refactorización ni mejora.
Los tres tipos de mejoras que puede considerar incluyen:
Consolidación de informes: los informes similares se pueden consolidar mediante

técnicas como filtros, marcadores o personalización. Si tiene menos informes, cada
uno con mayor flexibilidad, esto puede mejorar considerablemente la experiencia
de los consumidores de los informes. Le recomendamos que optimice los
conjuntos de datos de Preguntas y respuestas (consultas en lenguaje natural) para
ofrecer una flexibilidad aún mayor a los consumidores de informes, permitiéndoles
crear sus propias visualizaciones.
Mejoras de eficacia: durante la recopilación de requisitos, a menudo se pueden
identificar mejoras. Por ejemplo, si los analistas compilan números manualmente o
si se puede simplificar un flujo de trabajo. Power Query puede desempeñar un
importante papel en el reemplazo de actividades manuales que se realizan
actualmente. Si los analistas de negocios se encuentran realizando las mismas
actividades para limpiar y preparar los datos de forma habitual, los pasos de
preparación de datos repetibles de Power Query pueden traducirse en un ahorro
de tiempo considerable y una reducción de errores.
Centralización del modelo de datos: un conjunto de datos certificado y acreditado
actúa como espina dorsal de un programa de BI autoservicio administrado. En este
caso, los datos se administran una vez y los analistas tienen flexibilidad para usar y
aumentar esos datos a fin de satisfacer sus necesidades de elaboración de
informes y análisis.
７ Nota
Para obtener más información sobre la centralización de modelos de datos, lea

sobre Disciplina en el núcleo y Flexibilidad en el borde.
Priorización y evaluación de la complejidad

En este punto, el inventario inicial está disponible y puede incluir requisitos específicos.
Al priorizar el conjunto inicial de elementos de BI listos para la migración, los informes y
los datos se deben considerar colectivamente, así como de forma independiente entre
sí.
Identifique los informes de alta prioridad, que pueden incluir informes que:
Aporten un valor considerable a la empresa.

Se ejecuten con frecuencia.
Sean necesarios para la alta dirección o los ejecutivos.
Impliquen un nivel de complejidad razonable (para mejorar las posibilidades de
éxito durante las iteraciones de migración iniciales).
Identifique los datos de alta prioridad, que pueden incluir datos que:
Contengan elementos de datos críticos.

Sean datos comunes de la organización que sirvan para muchos casos de uso.
Se puedan usar para crear un conjunto de datos compartido que los informes y
muchos autores de informes puedan reutilizar.
Impliquen un nivel de complejidad razonable (para mejorar las posibilidades de
éxito durante las iteraciones de migración iniciales).
Pasos siguientes
información sobre la fase 2, que se refiere a la planeación de la migración de una única
solución de Power BI.
Enterprise

para migrar a Power BI
En este artículo se explica la fase 2, que se refiere a la planeación de la migración de una

única solución de Power BI.
７ Nota
La fase 2 se centra en definir cómo se usan los requisitos establecidos en la fase 1 para
migrar una solución a Power BI.
El resultado de la fase 2 incluye tantas decisiones específicas como sea posible para
guiar el proceso de implementación.
La toma de decisiones de esta naturaleza es un proceso iterativo y no lineal. En los

pasos previos a la migración ya se ha realizado algún planeamiento. Pueden extraerse
lecciones de una prueba de concepto (que se describe en la fase 3) en paralelo al
planeamiento de la implementación. Incluso durante la creación de la solución (que se
describe en la fase 4) puede que surja información adicional que influya en las
decisiones de implementación.
） Importante
Las fases 1-5 representan actividades relacionadas con una solución concreta. Hay
decisiones y actividades en el nivel de organización o inquilino que afectan al
proceso en el nivel de solución. Algunas de esas actividades de planeación de nivel
superior se tratan en el artículo Información general sobre la migración de
Power BI. Cuando proceda, dé preferencia a las decisiones de nivel de organización
por eficacia y coherencia.
 Sugerencia
Los temas que se tratan en este artículo también se aplican a un proyecto de

implementación estándar de Power BI.
Selección del producto Power BI

Una de las primeras decisiones es elegir el producto Power BI. Se trata de una decisión
entre el servicio Power BI o Power BI Report Server. Una vez publicado el contenido, hay
muchas opciones adicionales disponibles, como la inserción, la entrega a dispositivos
móviles y las suscripciones de correo electrónico.
Para obtener más información sobre las consideraciones de la arquitectura, vea la

sección 3 de las Notas del producto sobre la implementación de Power BI Enterprise .
Ｕ Precaución
Si le tienta usar archivos de Power BI Desktop almacenados en un sistema de

archivos, sea consciente de que no es un enfoque óptimo. El uso del servicio
Power BI (o Power BI Report Server) tiene importantes ventajas para la seguridad, la
distribución de contenido y la colaboración. El servicio Power BI también permite
auditar y supervisar actividades.
Decisión sobre el enfoque de administración de

áreas de trabajo
Las áreas de trabajo son un concepto fundamental del servicio Power BI, con lo que la
administración de áreas de trabajo es un importante aspecto de la planeación. Las
preguntas que se deben formular incluyen las siguientes:
¿Es necesaria una nueva área de trabajo para esta solución nueva?
¿Se van a necesitar áreas de trabajo independientes para desarrollo, pruebas y
producción?
¿Se van a usar áreas de trabajo independientes para los datos y los informes, o
basta con una sola área de trabajo? Las áreas de trabajo independientes tienen
numerosas ventajas, especialmente para la protección de los conjuntos de datos.
En caso necesario se pueden administrar de forma independiente de los usuarios
que publican informes.
¿Cuáles son los requisitos de seguridad del área de trabajo? Esto influye en la
planeación de roles del área de trabajo. Si son consumidores de contenido los que
van a usar una aplicación, los permisos de la audiencia para la aplicación se
administran de forma independiente del área de trabajo. Los distintos permisos
para los visores de la aplicación proporcionan flexibilidad adicional a la hora de
cumplir los requisitos de seguridad de los consumidores de solo lectura de
informes o paneles.
¿Se pueden usar grupos existentes para proteger el nuevo contenido? Se admiten
grupos de Azure Active Directory y Microsoft 365. Si está en consonancia con los
procesos existentes, el uso de grupos facilita la administración de permisos más
que las asignaciones a usuarios individuales.
¿Hay alguna consideración de seguridad relacionada con los usuarios invitados
externos? Es posible que tenga que trabajar con el administrador de Azure Active
Directory y el administrador de Power BI para configurar el acceso de usuarios
invitados.
 Sugerencia
Le recomendamos que cree un área de trabajo para una actividad o un proyecto de

empresarial específicos. Es posible que se sienta tentado a empezar a estructurar
áreas de trabajo en función de la estructura de la organización (como un área de
trabajo por departamento), pero este enfoque suele acabar siendo demasiado
amplio.
Determinación de cómo se va a usar el

contenido
Resulta útil entender cómo prefieren ver los informes y paneles los consumidores de
una solución. Las preguntas que se deben formular incluyen las siguientes:
¿Es una aplicación de Power BI (que incluye informes y paneles de una sola área de
trabajo) la mejor manera de entregar contenido a los consumidores o basta el
acceso directo a un área de trabajo para los visores de contenido?
¿Se van a incrustar determinados informes y paneles en otra ubicación, como
Teams, SharePoint Online o un portal o sitio web seguro?
¿Los consumidores van a acceder al contenido mediante dispositivos móviles? Los
requisitos para la entrega de informes en dispositivos de pequeño formato
influyen en algunas decisiones de diseño de informes.
Decisión de si se puede crear otro contenido

Hay varias decisiones clave que se deben tomar en relación con la posibilidad de que los
consumidores creen contenido nuevo, como:
¿Se va a permitir a los consumidores crear informes nuevos a partir del conjunto
de datos publicado? Esta capacidad se puede habilitar mediante la asignación del
permiso de compilación para el conjunto de datos a un usuario.
Si los consumidores quieren personalizar un informe, ¿pueden guardar una copia y
personalizarla de acuerdo a sus necesidades?
Ｕ Precaución
Aunque la capacidad Guardar una copia es una característica cómoda, se debe usar
con precaución si el informe incluye determinados gráficos o mensajes de
encabezado y pie de página. Dado que los logotipos, los iconos y los mensajes
textuales suelen estar relacionados con los requisitos de personalización de marca
o el cumplimiento normativo, es importante controlar cuidadosamente cómo se
entregan y distribuyen. Si se usa Guardar una copia, pero el nuevo autor no
modifica los gráficos ni los mensajes de encabezado y pie de página originales,
puede producirse confusión en torno a quién ha elaborado el informe en realidad.
También se puede reducir el sentido de la personalización de marca.
Evaluación de las necesidades de capacidad

Premium
Hay capacidades adicionales disponibles cuando se almacena un área de trabajo en una
capacidad Premium. Estas son varias razones por las que las áreas de trabajo de la
capacidad Premium pueden ser ventajosas:
Los consumidores sin una licencia de Power BI Pro o Premium por usuario (PPU)
pueden acceder al contenido.
Compatibilidad con conjuntos de datos de gran tamaño.
Compatibilidad con actualizaciones de datos más frecuentes.
Compatibilidad con el uso del conjunto completo de características de flujos de
datos.
Características empresariales, lo que incluye canalizaciones de implementación y el
punto de conexión XMLA.
Determinación del método de adquisición de

datos
Los datos que se necesitan en un informe pueden influir en varias decisiones. Las
preguntas que se deben formular incluyen las siguientes:
¿Se puede usar un conjunto de datos compartido existente de Power BI o es

apropiado crear un nuevo conjunto de datos de Power BI para esta solución?
¿Es necesario ampliar un conjunto de datos compartido existente con datos o
medidas nuevos a fin de satisfacer necesidades adicionales?
¿Qué modo de almacenamiento de datos es el más adecuado? Las opciones
incluyen el modo de importación, DirectQuery, compuesto o de conexión
dinámica.
¿Deben usarse agregaciones para mejorar el rendimiento de las consultas?
¿Va a resultar útil crear un flujo de datos y puede servir como origen de varios
conjuntos de datos?
¿Se debe registrar un nuevo origen de datos de puerta de enlace?
Decisión de dónde almacenar el contenido

original
Además de planear el destino de implementación, también es importante planear
dónde se va a almacenar el contenido original (u origen), como:
Especifique una ubicación aprobada para almacenar los archivos originales de

Power BI Desktop (.pbix). Lo ideal es que esta ubicación solo esté disponible para
los usuarios que editan el contenido. Debe ser conforme con la configuración de la
seguridad en el servicio Power BI.
Use una ubicación para los archivos originales de Power BI Desktop que incluya
historial de versiones o control de código fuente. El control de versiones permite
que el autor del contenido revierta a una versión anterior del archivo, si fuera
necesario. OneDrive para uso profesional o educativo o SharePoint sirven bien a
este fin.
Especifique una ubicación aprobada para almacenar datos de origen no
centralizados, como archivos planos o archivos de Excel. Debe ser una ruta de
acceso que cualquiera de los autores de conjuntos de datos pueda alcanzar sin
errores y de la que se realice una copia de seguridad con regularidad.
Especifique una ubicación aprobada para el contenido exportado desde el servicio
Power BI. El objetivo es garantizar que la seguridad definida en el servicio Power BI
no se eluda accidentalmente.
） Importante
La especificación de una ubicación protegida para los archivos originales de

Power BI Desktop es especialmente importante si contienen datos importados.
Evaluación del nivel de esfuerzo

Una vez que hay suficiente información disponible de los requisitos (que se han descrito
en la fase 1) y el proceso de planeación de la implementación de la solución, es posible
evaluar el nivel de esfuerzo. Entonces es posible formular un plan de proyecto con
tareas, escala de tiempo y responsabilidad.
 Sugerencia
Los costos de mano de obra (salarios y tarifas) suelen estar entre los mayores
gastos de la mayoría de las organizaciones. Aunque puede ser difícil de estimar con
precisión, las mejoras de productividad tienen una excelente rentabilidad de la
inversión (ROI).
Pasos siguientes
En el siguiente artículo de esta serie de migración de Power BI se ofrece información
sobre la fase 3, que está relacionada con la elaboración de una prueba de concepto para
mitigar el riesgo y abordar los factores desconocidos cuanto antes al migrar a Power BI.
Enterprise

Realización de una prueba de concepto
para migrar a Power BI
En este artículo se explica la fase 3, que está relacionada con la elaboración de una
prueba de concepto (POC) para mitigar el riesgo y abordar los factores desconocidos
cuanto antes al migrar a Power BI.
７ Nota
La atención de la fase 3 se centra en abordar los factores desconocidos y mitigar los

riesgos cuanto antes. Una prueba de concepto técnica resulta útil para validar
suposiciones. Se puede realizar de forma iterativa a la vez que el plan de
implementación de la solución (explicado en la fase 2).
El resultado de esta fase es una solución de Power BI de ámbito limitado, que aborda las
preguntas abiertas iniciales y que está lista para el trabajo adicional de la fase 4, que
consiste en prepararla para producción.
） Importante
No se pretende que la prueba de concepto sea un trabajo descartable, sino que se

espera que sea una iteración temprana de la solución lista para producción. En la
organización, puede hacer referencia a esta actividad como un prototipo, un piloto,
un boceto, un inicio rápido o un producto mínimamente viable (MVP). No siempre
es necesario realizar una prueba de concepto, e incluso se podría hacer de manera
informal.
 Sugerencia

proyecto de implementación estándar de Power BI. A medida que la organización
gana experiencia con Power BI, se reduce la necesidad de llevar a cabo pruebas de
concepto. Pero debido a la rápida cadencia de versiones con Power BI y a la
incorporación continua de nuevas características, puede realizar pruebas de
concepto periódicas con fines de aprendizaje.
Establecimiento de los objetivos y el ámbito de

la prueba de concepto
Al realizar una prueba de concepto, céntrese en los siguientes objetivos:
Compruebe sus suposiciones sobre el funcionamiento de una característica.

Infórmese sobre las diferencias de funcionamiento entre Power BI y la plataforma
de BI heredada.
Valide el reconocimiento inicial de determinados requisitos con expertos en la
materia.
Cree un conjunto de datos pequeño con datos reales para comprender y detectar
cualquier problema con la estructura de datos, las relaciones, los tipos de datos o
los valores de datos.
Experimente con las expresiones de sintaxis DAX que usan los cálculos del modelo
y valídelas.
Pruebe la conectividad del origen de datos mediante una puerta de enlace (si va a
ser un origen de puerta de enlace).
Pruebe la actualización de datos mediante una puerta de enlace (si va a ser un
origen de puerta de enlace).
Compruebe las configuraciones de seguridad, incluida la seguridad de nivel de fila,
si procede.
Experimente con las decisiones cosméticas y de diseño.
Compruebe que toda la funcionalidad del servicio Power BI funciona según lo
previsto.
El ámbito de la prueba de concepto depende de cuáles sean los factores desconocidos

o de los objetivos que se deban validar con los compañeros. Para reducir la
complejidad, mantenga el ámbito de la prueba de concepto lo más restringido posible.
Lo más normal en una migración es que los requisitos sean conocidos porque haya una
solución existente desde la que empezar. Pero, en función de la cantidad de mejoras
que se vayan a realizar o de las capacidades existentes de Power BI, una prueba de
concepto sigue proporcionando un valor considerable. Además, la elaboración rápida
de un prototipo con los comentarios de los consumidores puede ser adecuada para
aclarar los requisitos rápidamente, especialmente si se realizan mejoras.
） Importante
Aunque una prueba de concepto solo incluya un subconjunto de datos, o

únicamente objetos visuales limitados, suele ser importante realizarla de principio a
fin. Es decir, desde el desarrollo en Power BI Desktop hasta la implementación en
un área de trabajo de desarrollo del servicio Power BI. Es la única manera de
cumplir los objetivos de la prueba de concepto en su totalidad. Esto se da
especialmente si el servicio Power BI debe proporcionar una funcionalidad crítica
que no se ha usado antes, como un conjunto de datos de DirectQuery mediante
inicio de sesión único. Durante la prueba de concepto, centre los esfuerzos en los
aspectos sobre los que no está seguro o que necesita comprobar con otros
usuarios.
Control de las diferencias en Power BI

Power BI puede usarse como herramienta basada en modelos o como herramienta
basada en informes. Una solución basada en modelos conlleva el desarrollo de un
modelo de datos, mientras que una solución basada en informes se conecta a un
modelo de datos ya implementado.
Debido a su extrema flexibilidad, hay algunos aspectos sobre Power BI que pueden ser
sustancialmente diferentes a la plataforma de BI heredada desde la que se está
migrando.
Consideración del rediseño de la arquitectura de datos

Si va a migrar desde una plataforma de BI heredada que tiene su propia capa semántica,
es probable que la creación de un conjunto de datos de importación sea una buena
opción. Power BI funciona mejor con un diseño de tabla de esquema de estrella. Por lo
tanto, si la capa semántica heredada no es un esquema de estrella, es posible que se
requiera cierto rediseño para beneficiarse totalmente de Power BI. El esforzarse en
definir una capa semántica que se ajuste a los principios de diseño de los esquemas de
estrella (incluidas las relaciones, las medidas usadas habitualmente y la terminología
organizativa descriptiva) constituye un excelente punto de partida para los autores de
informes autoservicio.
Si va a migrar desde una plataforma de BI heredada donde los informes hacen

referencia a orígenes de datos relacionales mediante consultas SQL o procedimientos
almacenados, y si tiene previsto usar Power BI en modo DirectQuery, es posible que
pueda lograr prácticamente una migración uno a uno del modelo de datos.
Ｕ Precaución
Si ve la creación de una gran cantidad de archivos de Power BI Desktop que

componen una sola tabla importada, normalmente es un indicador de que el
diseño no es óptimo. Si observa esta situación, investigue si el uso de conjuntos de
datos compartidos creados mediante un diseño de esquema de estrella podría
lograr un mejor resultado.
Decisión de cómo controlar conversiones de panel

En el sector de BI, un panel es una colección de objetos visuales que muestra métricas
clave en una sola página. Pero en Power BI un panel representa una característica de
visualización específica que solo se puede crear en el servicio Power BI. Al migrar un
panel desde una plataforma de BI heredada hay dos opciones:
1. El panel heredado se puede volver a crear como informe de Power BI. La mayoría
de los informes se crean con Power BI Desktop. Los informes paginados y los
informes de Excel también son opciones alternativas.
2. El panel heredado se puede volver a crear como panel de Power BI. Los paneles
son una característica de visualización del servicio Power BI. Los objetos visuales de
panel se suelen crear mediante el anclaje de objetos visuales de uno o más
informes, Preguntas y respuestas o Conclusiones rápidas.
 Sugerencia
Dado que los paneles son un tipo de contenido de Power BI, no use la palabra
panel en el nombre del informe o panel.
Enfoque en la imagen general al volver a crear objetos
visuales
Todas las herramientas de BI tienen sus puntos fuertes y sus áreas de enfoque. Por esta
razón, es posible que los objetos visuales de informe exactos de los que dependía en
una plataforma de BI heredada no tengan un equivalente próximo en Power BI.
Al volver a crear objetos visuales de informe, céntrese más en las preguntas de negocio
generales que el informe va a abordar. Eso elimina la presión de replicar el diseño de
cada objeto visual exactamente de la misma forma. A pesar de que los consumidores de
contenido aprecian la coherencia a la hora de usar informes migrados, es importante no
enredarse en interminables debates sobre pequeños detalles.
Pasos siguientes
información sobre la fase 4, que se refiere a la creación y validación de contenido al
migrar a Power BI.
Enterprise

Creación de contenido para la migración
a Power BI
En este artículo se describe la fase 4, que se refiere a la creación y validación de

contenido al realizar la migración a Power BI.
７ Nota
Para obtener una explicación completa del gráfico anterior, consulte el artículo de
información general sobre la migración a Power BI.
La fase 4 se centra en realizar el trabajo real para convertir la prueba de concepto (POC)
en una solución lista para producción.
La salida de esta fase es una solución de Power BI que se ha validado en un área de

trabajo de desarrollo y está lista para su implementación en producción.
 Sugerencia

Creación de la solución de producción

En este momento, la misma persona que realizó la POC puede llevar a cabo la
generación de la solución de Power BI lista para producción. También es posible que
otro usuario esté implicado. Si las escalas de tiempo no se ven comprometidas, es genial
que los usuarios que se vayan a encargar del desarrollo de Power BI en el futuro estén
involucrados. De este modo, pueden aprender activamente.
） Importante
Reutilice la mayor parte del trabajo de la POC que sea posible.
Desarrollo de un nuevo conjunto de datos de

importación
Puede optar por crear un nuevo conjunto de datos de importación cuando ya no haya
uno de Power BI existente que satisfaga sus necesidades, o si este no puede mejorarse
para ajustarse a estas necesidades.
Idealmente, desde el principio, considere la posibilidad de desacoplar el trabajo de

desarrollo para los datos y los informes. Desacoplar los datos y los informes facilitará la
separación del trabajo y los permisos cuando los responsables del modelado de datos y
los informes sean personas distintas. Permite un enfoque más escalable y fomenta la
reusabilidad de los datos.
Las actividades esenciales relacionadas con el desarrollo de un conjunto de datos de

importación incluyen lo siguiente:
Adquirir datos de uno o más orígenes de datos (que pueden ser un flujo de datos
de Power BI).
Dar forma a los datos, así como combinarlos y prepararlos.
Crear el modelo de conjunto de datos, incluidas las tablas de fechas.
Crear y comprobar relaciones de modelo.
Definir medidas.
Configurar seguridad de nivel de fila, en caso necesario.
Configurar sinónimos y optimizar Preguntas y respuestas.
Planear la escalabilidad, el rendimiento y la simultaneidad, lo que puede influir en
sus decisiones sobre los modos de almacenamiento de datos, como el uso de una
modelo compuesto o agregaciones.
 Sugerencia
Si dispone de varios entornos de desarrollo, pruebas y producción, considere la

posibilidad de parametrizar orígenes de datos. Esto hará que la implementación,
que se describe en la fase 5, sea mucho más fácil.
Desarrollo de informes y paneles nuevos
Las actividades esenciales relacionadas con el desarrollo de un informe o panel de
Power BI incluyen lo siguiente:
Decidir el uso de una conexión dinámica a un modelo de datos existente o crear

un modelo de datos nuevo.
Al crear un modelo de datos nuevo, decida el modo de almacenamiento de datos
para las tablas del modelo (Importación, DirectQuery o Compuesto).
Decidir cuál es la mejor herramienta de visualización de datos para cumplir los
requisitos: Power BI Desktop, el generador de informes paginados o Excel.
Decidir los mejores objetos visuales para indicarle al informe la historia que debe
contar y resolver las preguntas que el informe debe responder.
Garantizar que todos los objetos visuales presenten una terminología clara, concisa
y empresarial.
Abordar los requisitos de interactividad.
Al usar la conexión dinámica, agregar medidas de nivel de informe.
Crear un panel en el servicio Power BI, especialmente cuando los consumidores
quieran una forma sencilla de supervisar las métricas clave.
７ Nota
Muchas de estas decisiones se habrán realizado en fases anteriores de planeación o

en el POC técnico.
Validación de la solución
Hay cuatro aspectos principales en la validación de una solución de Power BI:
1. Precisión de los datos

2. Seguridad
3. Funcionalidad
4. Rendimiento
Validación de la precisión de los datos

Como esfuerzo único durante la migración, deberá asegurarse de que los datos del
informe nuevo coinciden con los que se muestran en el informe heredado. O bien, si hay
diferencias, ser capaz de explicar el por qué. Encontrar un error en la solución heredada
que queda resuelto en la solución nueva es más común de lo que podría pensar.
Como parte de los esfuerzos continuos de validación de datos, el informe nuevo

normalmente tendrá que comprobarse de forma cruzada con el sistema de origen
inicial. Idealmente, esta validación se produce de forma reiterativa cada vez que se
publica un cambio en un informe.
Validación de seguridad
Al validar la seguridad, hay dos aspectos principales que hay que tener en cuenta:
Permisos de datos
Acceso a conjuntos de datos, informes y paneles
En un conjunto de datos de importación, los permisos de datos se aplican mediante la

definición de seguridad de nivel de fila (RLS). También es posible que el sistema de
origen aplique permisos de datos al usar el modo de almacenamiento DirectQuery
(posiblemente con inicio de sesión único).
Las principales formas de conceder acceso al contenido de Power BI son las siguientes:
Roles de área de trabajo (para editores y visores de contenido).

Permisos de audiencia de aplicación aplicados a un conjunto empaquetado de
contenido del área de trabajo (para visores).
Compartir un informe o panel individual (para visores).
 Sugerencia
Se recomienda entrenar a los autores de contenido en cómo administrar la

seguridad de forma eficaz. También es importante tener una prueba, auditoría y
supervisión sólidas.
Validación de la funcionalidad
Es el momento de comprobar de nuevo los detalles del conjunto de datos, como los
nombres de campo, el formato, la ordenación y el comportamiento de resumen
predeterminado. También se deben comprobar las características de los informes
interactivos, como las segmentaciones de datos, las acciones de exploración en
profundidad y obtención de detalles, las expresiones, los botones o los marcadores.
Durante el proceso de desarrollo, la solución de Power BI debe publicarse en un área de
trabajo de desarrollo en el servicio Power BI de forma periódica. Compruebe que toda la
funcionalidad actúa según lo previsto en el servicio, como la representación de objetos
visuales personalizados. También es un buen momento para realizar más pruebas.
Pruebe la actualización programada, Preguntas y respuestas, y cómo los informes y
paneles se ven en un dispositivo móvil.
Validación del rendimiento

El rendimiento de la solución Power BI es un elemento importante para la experiencia
del consumidor. La mayoría de los informes deben presentar objetos visuales en menos
de diez segundos. Si tiene informes que tardan más tiempo en cargarse, páuselos y
reconsidere qué puede estar contribuyendo a estos retrasos. El rendimiento de los
informes debe evaluarse con regularidad en el servicio Power BI, además de en Power BI
Desktop.
Muchos de los problemas de rendimiento surgen del subestándar DAX (expresiones de

análisis de datos), de un diseño deficiente del conjunto de datos o de un diseño de
informe poco óptimo (por ejemplo, intentar representar demasiados objetos visuales en
una sola página). Las incidencias del entorno técnico, como la red, una puerta de enlace
de datos sobrecargada o la forma de configurar una capacidad Premium, también
pueden contribuir a generar incidencias de rendimiento. Para obtener más información,
vea la Guía de optimización para Power BI y Solución de problemas de rendimiento de
los informes en Power BI.
Documentación de la solución
Hay dos tipos principales de documentación que son útiles para una solución Power BI:
Documentación del conjunto de datos

Documentación del informe
La documentación se puede almacenar en cualquier lugar donde el público de destino

tenga un acceso más sencillo. Entre las opciones comunes se incluyen las siguientes:
En un sitio de SharePoint: puede existir un sitio de SharePoint para el Centro de

excelencia o un sitio de la comunidad interna de Power BI.
En una aplicación: las direcciones URL se pueden configurar al publicar una
aplicación de Power BI para dirigir al consumidor a más información.
En archivos individuales de Power BI Desktop: los elementos del modelo, como
las tablas y las columnas, pueden definir una descripción. Estas descripciones
aparecen como información sobre herramientas en el panel Campos al crear
informes.
 Sugerencia
Si crea un sitio con el fin de que sirva como centro para la documentación
relacionada con Power BI, valore la posibilidad de personalizar el menú Obtener
ayuda con la ubicación de su URL.
Creación de la documentación del conjunto de datos

La documentación del conjunto de datos está dirigida a los usuarios que van a
administrar este conjunto de datos en el futuro. Es útil incluir lo siguiente:
Decisiones de diseño adoptadas y los motivos.

Quién posee, mantiene y certifica los conjuntos de datos.
Requisitos de actualización de datos.
Reglas de negocios personalizadas definidas en los conjuntos de datos.
Seguridad específica del conjunto de datos o requisitos de privacidad de los datos.
Necesidades de mantenimiento futuras.
Incidencias abiertas conocidas o elementos de trabajo pendiente diferidos.
También puede optar por crear un registro de cambios que resuma los cambios más
importantes que se hayan producido en el conjunto de datos a lo largo del tiempo.
Creación de la documentación del informe

La documentación del informe, que se estructura normalmente como un tutorial
dirigido a los consumidores del informe, puede ayudar a los consumidores a obtener
más valor de los informes y paneles. A menudo un tutorial de vídeo breve sirve para
este propósito.
También puede optar por incluir documentación adicional del informe en una página
oculta del mismo. Podría incluir decisiones de diseño y un registro de cambios.
Pasos siguientes
información sobre la fase 5, que se refiere a la implementación, admisión y supervisión
de contenido al realizar la migración a Power BI.
Enterprise

Implementación en Power BI
En este artículo se describe la fase 5, que se refiere a la implementación, admisión y

supervisión de contenido al realizar la migración a Power BI.
７ Nota
Para obtener una explicación completa del gráfico anterior, consulte el artículo de
información general sobre la migración a Power BI.
El objetivo principal de la fase 5 es implementar la nueva solución de Power BI en

producción.
La salida de esta fase es una solución de producción lista para su uso en la empresa.
Cuando se trabaja con un método ágil, conviene tener algunas mejoras planeadas, que
se entregarán en una futura iteración. El soporte técnico y la supervisión también son
importantes en esta fase y de forma continua.
 Sugerencia
A excepción de la ejecución en paralelo y la retirada de los informes heredados,

que se describen a continuación, los temas que se tratan en este artículo se aplican
también a un proyecto de implementación estándar de Power BI.
Implementación en un entorno de prueba

En el caso de las soluciones administradas por TI o las que son críticas para la
productividad empresarial, generalmente hay un entorno de prueba. Un entorno de
prueba se encuentra entre el desarrollo y la producción, y no es necesario para todas las
soluciones Power BI. Un área de trabajo de prueba puede servir como ubicación estable,
separada del desarrollo, para que las pruebas de aceptación de usuario (UAT) se
efectúen antes de la versión para producción.
Si el contenido se ha publicado en un área de trabajo de capacidad Premium, las

canalizaciones de implementación pueden simplificar el proceso de implementación en
áreas de trabajo de desarrollo, prueba y producción. Como alternativa, la publicación
puede realizarse manualmente o con scripts de PowerShell .
Implementación en el área de trabajo de prueba

Las actividades clave durante una implementación en el área de trabajo de prueba
suelen incluir lo siguiente:
Cadenas de conexión y parámetros: ajuste las cadenas de conexión del conjunto

de datos si el origen de datos difiere entre el entorno de desarrollo y de prueba.
Se puede utilizar la parametrización para administrar de forma eficaz las cadenas
de conexión.
Contenido del área de trabajo: publique conjuntos de datos e informes en el área
de trabajo de prueba, y cree paneles.
Apéndice publique una aplicación mediante el contenido del área de trabajo de
prueba, si forma parte del proceso de UAT. Normalmente, los permisos de
aplicación se restringen a un número pequeño de personas implicadas en el
proceso de UAT.
Actualización de datos:programe la actualización de los conjuntos de datos de
importación durante el período en el que el proceso de UAT se lleva a cabo de
forma activa.
Seguridad: actualice o compruebe los roles del área de trabajo. El acceso a las
áreas de trabajo de prueba incluye un número reducido de personas que
participan en las pruebas de aceptación de usuario.
７ Nota
Para más información sobre las opciones de implementación en desarrollo, prueba

y producción, consulte la sección 9 del documento Notas del producto de la
planeación de una implementación de Power BI Enterprise .
Realización de pruebas de aceptación de usuario
Por lo general, el proceso de UAT implica a usuarios empresariales expertos en la
materia. Una vez comprobado, dan su aprobación con respecto a que el nuevo
contenido es preciso, cumple los requisitos y es posible su implementación para un
consumo más amplio por parte de otros usuarios.
El grado de formalidad de este proceso de UAT, incluidas las aprobaciones por escrito,
dependerá de sus prácticas de administración de cambios.
Implementación en el entorno de producción

Hay varias consideraciones sobre su implementación en el entorno de producción que
hay que tener en cuenta.
Realización de una implementación por fases

Si está tratando de minimizar el riesgo y la interrupción del usuario, o si hay otros
problemas, puede optar por realizar una implementación por fases. Es posible que la
primera implementación en producción implique un grupo más pequeño de usuarios
piloto. Con una prueba piloto, se pueden solicitar comentarios a los usuarios piloto de
forma activa.
Expanda los permisos en el área de trabajo de producción, o la aplicación, gradualmente

hasta que todos los usuarios de destino tengan permiso para la nueva solución de
Power BI.
 Sugerencia
Use el registro de actividad de Power BI para comprender cómo los consumidores

adoptan y usan la nueva solución de Power BI.
Control de componentes adicionales

Durante el proceso de implementación, puede que tenga que trabajar con los
administradores de Power BI a fin de abordar otros requisitos necesarios para admitir
toda la solución, por ejemplo:
Mantenimiento de la puerta de enlace: puede que se necesite el registro de

nuevos orígenes de datos en la puerta de enlace de datos.
Conectores y controladores de puerta de enlace: es posible que un nuevo origen
de datos de propiedad requiera la instalación de un nuevo controlador o un
conector personalizado en cada servidor del clúster de puerta de enlace.
Creación de una capacidad Premium: tal vez pueda usar una capacidad Premium
existente. También puede haber situaciones en las que esté justificado usar una
nueva capacidad Premium. Podría ser el caso cuando quiera separar
deliberadamente una carga de trabajo de departamento.
Configuración de un flujo de datos de Power BI: las actividades de preparación de
datos se pueden configurar de una vez en un flujo de datos de Power BI mediante
Power Query Online. Eso evita tener que replicar el trabajo de preparación de
datos en muchos archivos distintos de Power BI Desktop.
Registro de un nuevo objeto visual de la organización:el registro de objetos
visuales de la organización se puede realizar en el portal de administración en el
caso de objetos visuales personalizados que no se originaron en AppSource.
Establecimiento de contenido destacado: existe una opción de inquilino que
controla quién puede presentar contenido en la página principal del servicio
Power BI.
Establecimiento de etiquetas de confidencialidad: todas las etiquetas de
confidencialidad se integran con Microsoft Purview Information Protection.
Implementación en el área de trabajo de producción

Las actividades clave durante una implementación en el área de trabajo de producción
suelen incluir lo siguiente:
Administración de cambios: de ser necesario, obtenga la aprobación

correspondiente para realizar la implementación; asimismo, comunique dicha
implementación a la población de usuarios mediante sus prácticas estándar de
administración de cambios. Puede que haya una ventana de administración de
cambios aprobada durante la cual se permitan las implementaciones de
producción. Normalmente, se aplica al contenido administrado por TI y, con
mucha menos frecuencia, al contenido de autoservicio.
Plan de reversión: en el caso de una migración, la expectativa es que se trate de la
migración de una nueva solución por primera vez. Si ya existe contenido, conviene
tener un plan para efectuar una reversión a la versión anterior, en caso necesario.
Tener versiones anteriores de los archivos de Power BI Desktop (con el control de
versiones de SharePoint o OneDrive) funciona bien a tal efecto.
Cadenas de conexión y parámetros: ajuste las cadenas de conexión del conjunto
de datos si el origen de datos difiere entre el entorno de prueba y de producción.
Se puede usar la parametrización eficazmente a tal efecto.
Actualización de datos:programe la actualización del conjunto de datos para los
valores importados.
Contenido del área de trabajo: publique conjuntos de datos e informes en el área
de trabajo de producción, y cree paneles. Las canalizaciones de implementación
pueden simplificar el proceso de implementación en áreas de trabajo de
desarrollo, prueba y producción si el contenido se ha publicado en áreas de
trabajo de capacidad Premium.
Aplicación: si las aplicaciones forman parte de la estrategia de distribución de
contenido, publique una aplicación mediante el contenido del área de trabajo de
producción.
Seguridad: actualice y compruebe los roles de área de trabajo en función de su
estrategia de distribución de contenido y colaboración.
Configuración del conjunto de datos: actualice y compruebe la configuración de
cada conjunto de datos, incluido lo siguiente:
Aprobación (por ejemplo, de certificados o promocionados)
Credenciales del origen de datos o la conexión de puerta de enlace
Actualización programada
Preguntas y respuestas destacadas
Uso compartido de paneles e informes: actualice y compruebe la configuración
de cada informe y panel. Entre los valores más importantes se incluyen los
siguientes:
Descripción
Persona o grupo de contacto
Etiqueta de confidencialidad
Contenido destacado
Suscripciones: configure suscripciones de informe, si es necesario.
） Importante
Llegados a este punto, ha alcanzado un gran hito. Celebre su logro al completar la

migración.
Comunicación con los usuarios

Anuncie la nueva solución a los consumidores. Indíqueles dónde pueden encontrar el
contenido, así como documentación asociada, preguntas más frecuentes y tutoriales.
Para presentar el nuevo contenido, considere la posibilidad de hospedar una sesión de
tipo almuerzo y aprendizaje, o preparar algunos vídeos a petición.
Asegúrese de incluir instrucciones sobre cómo solicitar ayuda y cómo proporcionar
comentarios.
Realización de una retrospectiva

Valore la posibilidad de realizar una retrospectiva para examinar lo que ha ido bien en la
migración y lo que se puede hacer mejor en la próxima.
Ejecución en paralelo
En muchas situaciones, la nueva solución se ejecutará en paralelo con la heredada
durante un tiempo predeterminado. Entre las ventajas de la ejecución en paralelo se
incluyen las siguientes:
Reducción del riesgo, especialmente si los informes se consideran críticos.

Deja tiempo para que los usuarios se acostumbren a la nueva solución de
Power BI.
Permite que la información presentada en Power BI haga referencias cruzadas a los
informes heredados.
Retirada del informe heredado

En algún momento, los informes migrados a Power BI han de deshabilitarse en la
plataforma de BI heredada. La retirada de los informes heredados puede producirse
cuando:
El tiempo predeterminado para ejecutarse en paralelo (que debería haberse

comunicado a la población de usuarios) ha expirado. Normalmente es de entre 30
y 90 días.
Todos los usuarios del sistema heredado tienen acceso a la nueva solución de
Power BI.
Ya no se produce una actividad importante en el informe heredado.
No se ha producido ningún problema con la nueva solución de Power BI que
podría afectar a la productividad de los usuarios.
Supervisión de la solución
Los eventos del registro de actividad de Power Bi se pueden utilizar para comprender
los patrones de uso de la nueva solución (o del registro de ejecución en el caso de
contenido implementado en Power BI Report Server). El análisis del registro de actividad
puede ayudar a determinar si el uso real difiere de las expectativas. También puede
validar que la solución se admite adecuadamente.
Estas son algunas preguntas que pueden responderse revisando el registro de actividad:
¿Con qué frecuencia se ve el contenido?

¿Quién ve el contenido?
¿El contenido se ve normalmente a través de una aplicación o un área de trabajo?
¿La mayoría de los usuarios usan un explorador o una aplicación móvil?
¿Se usan suscripciones?
¿Se crean informes basados en esta solución?
¿Se actualiza con frecuencia el contenido?
¿Cómo se define la seguridad?
¿Se producen habitualmente problemas tales como errores de actualización de
datos?
¿Se producen actividades preocupantes (por ejemplo, una importante actividad de
exportación o numerosas participaciones en informes individuales) que pudieran
justificar el aprendizaje adicional?
） Importante
Asegúrese de que alguien revise periódicamente el registro de actividad. La simple

captura y almacenamiento del historial tiene valor a efectos de auditoría o
cumplimiento. Sin embargo, el verdadero valor se produce cuando se puede
realizar una acción proactiva.
Soporte técnico de la solución

Aunque la migración se haya completado, el período posterior a la migración resulta
fundamental para solucionar problemas y controlar las cuestiones de rendimiento. Con
el tiempo, es probable que la solución migrada sufra cambios a medida que
evolucionen las necesidades empresariales.
El soporte técnico tiende a prestarse de forma ligeramente diferente en función de

cómo se administre la inteligencia empresarial de autoservicio en toda la organización.
Los expertos en Power BI de todas las unidades de negocio suelen actuar como soporte
técnico de primera línea. Aunque se trata de un rol informal, es algo fundamental que se
debe fomentar.
Contar con un proceso de soporte técnico formal, con personal de TI capaz de atender
incidencias de soporte técnico, también resulta esencial para controlar las solicitudes
rutinarias orientadas al sistema y con fines de escalamiento.
７ Nota
Los diferentes tipos de soporte técnico interno y externo se describen en la hoja

de ruta de adopción de Power BI.
También se puede tener un Centro de excelencia (COE) que actúe como grupo de
asesores internos que prestan asistencia e imparten cursos sobre Power BI y determinan
su uso en la organización. Un COE puede ser responsable de mantener contenido útil
sobre Power BI en un portal interno.
Por último, debe quedar claro a los consumidores del contenido con quién deben
ponerse en contacto en caso de tener dudas al respecto, así como disponer de un
mecanismo para proporcionar comentarios sobre problemas o mejoras.
Para obtener más información sobre el soporte técnico de los usuarios, con especial
atención a la resolución de problemas, vea Hoja de ruta de adopción de Power BI:
soporte técnico para usuarios.
Pasos siguientes
En el artículo final de esta serie podrá aprender de los clientes cuándo realizar la
migración a Power BI.
Enterprise

Más información sobre las migraciones
de los clientes a Power BI
En este artículo, que concluye la serie sobre la migración a Power BI, se comparten
lecciones clave que han descubierto dos clientes que han realizado una correcta
migración a Power BI.
Empresa internacional de bienes de consumo

Una empresa internacional de bienes de consumo, que vende cientos de productos,
tomó la decisión en 2017 de adoptar una estrategia priorización de la nube. Uno de los
factores principales para seleccionar Power BI como su plataforma de inteligencia
empresarial (BI) es su profunda integración con Azure y Microsoft 365.
Realización de una migración por fases

En 2017, la empresa comenzó a usar Power BI. El objetivo inicial de la organización era
incorporar Power BI como una herramienta de BI adicional. La decisión proporcionó a
los autores de contenido, consumidores y TI tiempo para adaptarse a las nuevas formas
de ofrecer BI. También les permitió ganar experiencia en Power BI.
Durante la segunda mitad de 2018, se hizo un anuncio formal por el que se indicaba
que Power BI pasaba a ser la herramienta de BI aprobada para la organización. Y, por lo
tanto, todos los nuevos trabajos de desarrollo de BI debían realizarse en Power BI. La
disponibilidad de Power BI Premium fue un factor clave para tomar esta decisión. En
aquel momento, la organización desaconsejaba el uso de la plataforma de BI anterior y
empezó la planeación de la transición.
Hacia finales de 2019, la empresa comenzó a migrar el contenido existente de la

plataforma de BI heredada a Power BI. Algunos de los usuarios pioneros migraron
rápidamente su contenido. Esto ayudó a impulsar Power BI todavía más dentro de la
propia organización. Más adelante, se solicitó a los propietarios y autores de contenido
que comenzaran a realizar la migración completa a Power BI a finales de 2020. La
organización sigue enfrentándose a desafíos relacionados con las aptitudes, el tiempo y
la financiación, aunque ninguno de estos está relacionado con la plataforma tecnológica
propiamente dicha.
） Importante
Power BI ya tenía éxito y estaba afianzado en la organización antes de que se
pidiera a las unidades de negocio que acometieran un esfuerzo de migración
formal fuera de la plataforma de BI anterior.
Preparación para el manejo de respuestas distintas

En esta gran organización descentralizada, había diferentes niveles de receptividad y
disposición ante el cambio a Power BI. Más allá de las inquietudes relacionadas con el
tiempo y el presupuesto, parte del personal había realizado inversiones considerables en
el desarrollo de sus habilidades en la plataforma de BI anterior. Por lo tanto, el anuncio
sobre la estandarización de Power BI no fue bienvenida por todo el personal. Puesto
que cada unidad de negocio tiene su presupuesto, las unidades individuales podrían
cuestionar decisiones de este tipo. A medida que las decisiones sobre las herramientas
de TI se hicieron de forma centralizada, se produjeron algunos desafíos que tuvieron
que tratar el patrocinador ejecutivo y los líderes de BI.
） Importante
La comunicación con los equipos de liderazgo a lo largo de las unidades de

negocio fue fundamental para asegurarse de que comprendieran las ventajas
organizativas de alto nivel derivadas de la estandarización en Power BI. La
comunicación efectiva resultó todavía más esencial a medida que progresaba la
migración y se aproximaba la fecha de retirada de la plataforma de BI heredada.
Enfoque en una visión general más amplia

La empresa descubrió que, aunque algunos informes migrados podían replicar
cuidadosamente el diseño original, no todos los informes individuales podían replicarse
con exactitud en Power BI. En cualquier caso, es lo que se esperaba, dado que todas las
plataformas de BI son diferentes. Esto puso de manifiesto que era necesaria una
mentalidad de diseño diferente.
Se proporcionaron instrucciones a los autores de contenido: atención a la creación de

informes que se ajustaran a la finalidad del uso en Power BI, en lugar de intentar una
réplica exacta del informe heredado. Por este motivo, los expertos en la materia deben
estar disponibles activamente durante el proceso de migración para la consulta y la
validación. Se han realizado esfuerzos para tener en cuenta el propósito del diseño del
informe y mejorarlo cuando sea necesario.
） Importante
A veces, el mejor enfoque consiste en realizar mejoras durante la migración. En

otras ocasiones, la mejor opción es ofrecer el mismo valor exacto que antes, sin
mejoras significativas, para no poner en peligro la escala de tiempo de la
migración.
Evaluación de las prioridades con precaución

Se llevó a cabo un análisis de la plataforma de BI anterior para comprender
completamente su uso. La plataforma de BI anterior tenía miles de informes publicados,
de los cuales se había accedido aproximadamente a la mitad en el año anterior. Al
evaluar qué informes se consideraba que ofrecían un valor significativo a la
organización, la cifra anterior se recortaba de nuevo a la mitad. A esos informes se les
dio prioridad a la hora de la migración.
） Importante
Es muy fácil sobrestimar la importancia real del informe. En el caso de los informes
que no se usan con frecuencia, evalúe si se pueden retirar completamente. A veces,
lo más económico y más sencillo es no hacer nada.
Evaluación de la complejidad con precaución

De los primeros informes a los que se les dio prioridad, las estimaciones de tiempo se
compilaron en función de los niveles de esfuerzo estimado: sencillo, medio o complejo.
Aunque suene como un proceso relativamente sencillo, no espere que las estimaciones
de tiempo sean precisas en cada informe. Puede encontrarse con que una estimación
sea muy poco precisa. Por ejemplo, la compañía tenía un informe que consideró muy
complejo. Los consultores estimaron una conversión de 50 días. Sin embargo, el informe
rediseñado en Power BI se completó en aproximadamente 50 horas.
） Importante
Aunque las estimaciones de tiempo suelen ser necesarias para obtener la

financiación y las asignaciones de personal, probablemente son más valiosas en el
total agregado.
Decisión de cómo se controla la administración de
cambios
Con un volumen tan alto de recursos de BI, cambiar la administración de los informes de
propiedad empresarial suponía un desafío. Los informes administrados por TI se
manejaron según las prácticas estándar de administración de cambios. Sin embargo,
debido al gran volumen, producir un cambio para el contenido de propiedad
empresarial de forma centralizada no era posible.
） Importante
La responsabilidad adicional recae en las unidades de negocio cuando no es

práctico administrar los cambios desde un equipo central.
Creación de una comunidad interna

La empresa estableció un Centro de excelencia (COE) para proporcionar clases y
recursos internos de entrenamiento. El COE también actúa como un grupo de
consultoría interno que está preparado para ayudar a los autores de contenido con
incidencias técnicas, resolución de obstáculos e instrucciones de procedimientos
recomendados.
También existe una comunidad interna de Power BI que cuenta con más de
1600 miembros, lo que ha resultado un éxito masivo. La comunidad se administra en
Yammer. Los miembros pueden plantear preguntas de forma interna y recibir respuestas
que se ciñen a los procedimientos recomendados y se enmarcan dentro de las
restricciones de la organización. Este tipo de interacción entre usuarios reduce gran
parte de la carga de soporte técnico del COE. Sin embargo, el COE supervisa las
preguntas y respuestas, y participa en las conversaciones cuando es necesario.
Una extensión de la comunidad interna es la red de expertos más reciente de Power BI.
Incluye un pequeño número de campeones de Power BI preseleccionados de dentro de
la organización. Son profesionales de Power BI de las unidades de negocio muy
cualificados, campeones entusiastas y que quieren resolver de forma activa los desafíos
de la empresa. Se espera que los miembros de la red de expertos de Power BI cumplan
los procedimientos recomendados y las directrices que establece el COE, y ayuden a que
la comunidad interna de Power BI en sentido más amplio los entienda e implemente.
Aunque la red de expertos de Power BI colabora con el COE y puede recibir
entrenamiento dedicado, los expertos de Power BI funcionan independientemente del
COE. Los expertos de Power BI pueden definir los parámetros de su funcionamiento,
teniendo en cuenta que cuentan con otras responsabilidades y prioridades en su rol
oficial.
） Importante
Tenga un ámbito muy bien definido de lo que hace el COE, por ejemplo, adopción,
gobernanza, instrucciones, procedimientos recomendados, entrenamiento, soporte
técnico y quizás incluso desarrollo práctico. Aunque un COE es increíblemente
valioso, medir el retorno de la inversión puede resultar difícil.
Supervisión del progreso y el éxito de la migración

Los indicadores clave de rendimiento (KPI) se supervisan continuamente durante la
migración a Power BI. Ayudan a la empresa a comprender las tendencias de las métricas,
como el número de visitas a los informes, el número de informes activos y los usuarios
distintos al mes. El mayor uso de Power BI se mide junto con el menor uso de la
plataforma de BI anterior, con el objetivo de lograr una relación inversa. Los destinos se
actualizan cada mes para adaptarse a los cambios. Si el uso no se produce al ritmo
deseado, se identifican los cuellos de botella para que se puedan realizar las acciones
pertinentes.
） Importante
Cree un cuadro de mandos de migración con inteligencia empresarial procesable

para supervisar el éxito del trabajo de migración.
Empresa de transporte y logística de gran

tamaño
Una gran empresa de transporte y logística de Norteamérica está invirtiendo de forma
activa en la modernización de su infraestructura de datos y sistemas analíticos.
Habilitación de un período de crecimiento gradual

La compañía empezó a usar Power BI en 2018. A mediados de 2019, Power BI se
convirtió en la plataforma preferida para todos los casos de uso de BI nuevos.
Posteriormente, en 2020, la empresa se centró en la eliminación gradual de la
plataforma de BI existente y de una serie de soluciones de BI de ASP.NET desarrolladas
de forma personalizada.
） Importante
Power BI tenía muchos usuarios activos en la organización antes de comenzar la

eliminación gradual de la plataforma y las soluciones de BI heredadas.
Equilibrio de los grupos centralizados y distribuidos

En la empresa, hay dos tipos de equipos de BI: un equipo central de BI y grupos de
análisis distribuidos en toda la organización. El equipo central de BI tiene la
responsabilidad de la propiedad de Power BI como plataforma, pero no posee ningún
contenido. De esta manera, el equipo central de BI es un centro de habilitación técnica
que admite los grupos de análisis distribuidos.
Cada uno de los grupos de análisis está dedicado a una unidad de negocio específica o
a una función de servicios compartidos. Un grupo pequeño puede contener un solo
analista, mientras que un grupo de mayor tamaño puede tener de 10 a 15.
） Importante
Los grupos de análisis distribuidos constan de expertos en la materia que están

familiarizados con las necesidades del día a día de la empresa. Esta separación
permite que el equipo principal de BI se centre mayormente en el soporte técnico y
la habilitación de los servicios y herramientas de BI.
Enfoque en la reusabilidad del conjunto de datos

Confiar en soluciones de BI personalizadas de ASP.NET suponía una barrera para
desarrollar soluciones de BI nuevas. El conjunto de aptitudes necesario implicaba que el
número de autores de contenido de autoservicio era pequeño. Dado que Power BI es
una herramienta mucho más accesible, diseñada específicamente para BI de
autoservicio, se difunde rápidamente en toda la organización una vez que se ha lanzado.
La capacitación de los analistas de datos dentro de la empresa dio lugar a resultados

positivos inmediatos. Sin embargo, el enfoque inicial con el desarrollo de Power BI
estaba en la visualización. Aunque dio como resultado soluciones de BI valiosas, este
enfoque producía un gran número de archivos de Power BI Desktop, todos ellos con
una relación uno a uno entre el informe y su conjunto de datos. Dio como resultado
muchos conjuntos de datos y la duplicación de datos y lógica de negocios. Para reducir
la duplicación de datos, la lógica y el esfuerzo, la empresa facilitó el entrenamiento y
proporcionó soporte técnico a los autores de contenido.
） Importante
Incluya información sobre la importancia de la reusabilidad de los datos en los

esfuerzos de entrenamiento internos. Solucione los conceptos importantes tan
pronto como sea práctico.
Prueba de acceso a datos de varias maneras

La plataforma de almacenamiento de datos de la empresa es DB2. En función del diseño
actual del almacenamiento de datos, la compañía averiguó que los modelos
DirectQuery, en lugar de los modelos de importación, funcionaban mejor para sus
requisitos.
） Importante
Realice una prueba de concepto técnica para evaluar el modo de almacenamiento

del modelo que mejor funcione. Además, enseñe a los modeladores de datos los
modos de almacenamiento de los modelos y cómo pueden elegir un modo
adecuado para su proyecto.
Aprendizaje de los autores sobre las licencias Premium

Dado que era más fácil empezar a trabajar con Power BI (en comparación con su
plataforma de BI heredada), muchos de los usuarios pioneros eran personas que no
tenían una licencia para la herramienta de BI anterior. Tal como se esperaba, el número
de autores de contenido aumentó de forma considerable. Estos autores de contenido
querían compartir su contenido con otras personas, lo que daba como resultado una
necesidad continua de licencias de Power BI Pro adicionales.
La empresa realizó una gran inversión en áreas de trabajo Premium, especialmente para
distribuir contenido de Power BI a muchos usuarios con licencias de Power BI gratuitas.
El equipo de soporte técnico trabaja con autores de contenido para asegurarse de que
usan áreas de trabajo Premium cuando sea necesario. Evita la asignación innecesaria de
licencias de Power BI Pro cuando un usuario solo necesita consumir contenido.
） Importante
Suelen surgir preguntas acerca de las licencias. Prepárese para educar y ayudar a
los creadores de contenido a resolver las preguntas sobre las licencias. Compruebe
que las solicitudes de usuario para licencias de Power BI Pro están justificadas.
Descripción de las puertas de enlace de datos

En un primer momento, la empresa tenía muchas puertas de enlace personales. El uso
de un clúster de puerta de enlace de datos local desplaza los esfuerzos de
administración al equipo central de BI, lo que permite que la comunidad de autores de
contenido se centre en la generación de contenido. El equipo central de BI trabajó con
la comunidad de usuarios de Power BI interna para reducir el número de puertas de
enlace personales.
） Importante
Cuente con un plan para crear y administrar puertas de enlace de datos locales.
Decida quién tiene permiso para instalar y usar una puerta de enlace personal, y
aplíquela a las directivas de puerta de enlace.
Formalización del plan de soporte técnico

Dado que la adopción de Power BI aumentó en la organización, la empresa descubrió
que un enfoque de compatibilidad con varios niveles funcionaba bien:
Nivel 1; entre el equipo: los usuarios aprenden los unos de los otros a diario.
Nivel 2; comunidad de Power BI: las personas formulan preguntas de la
comunidad de equipos internos para que aprendan unos de otros y comuniquen
información importante.
Nivel 3; equipo central de BI y COE: las personas envían solicitudes de correo
electrónico para obtener ayuda. Las sesiones en horario de oficina se llevan a cabo
dos veces al día para debatir problemas de forma colectiva y compartir ideas.
） Importante
Aunque los dos primeros niveles son menos formales, son tan importantes como el
tercer nivel de soporte técnico. Los usuarios experimentados suelen confiar
principalmente en las personas que conocen, mientras que los usuarios más
recientes (o los que son el único analista de datos para una unidad de negocio o un
servicio compartido) suelen confiar más en el soporte técnico formal.
Inversión en entrenamiento y gobernanza

En el último año, la empresa mejoró sus ofertas de entrenamiento internas y ha
mejorado su programa de gobernanza de datos. El comité de gobernanza incluye
miembros clave de cada uno de los grupos de análisis distribuidos, además del COE.
Ahora hay seis cursos de Power BI internos en su catálogo. El curso Dashboard in a

Day (Panel en un día) sigue siendo un curso popular para principiantes. Para ayudar a
los usuarios a profundizar en sus conocimientos, ofrecen una serie de tres cursos de
Power BI y dos cursos de DAX.
Una de sus decisiones de gobernanza de datos más importante se relaciona con la

administración de las capacidades Premium. La empresa ha decidido alinear su
capacidad con áreas de análisis clave en unidades de negocio y servicios compartidos.
Por lo tanto, si existen ineficiencias, el impacto solo se percibe dentro de esa área y los
administradores de capacidad descentralizada cuentan con los conocimientos para
administrarla tal como consideren oportuno.
） Importante
Preste atención a cómo se usan las capacidades Premium y cómo se asignan las
áreas de trabajo.
Pasos siguientes
Enterprise
Dashboard in a Day

El objetivo de esta serie de artículos es proporcionar una hoja de ruta. La hoja de ruta
presenta una serie de consideraciones estratégicas y tácticas y elementos de acción que
conducen directamente a la adopción adecuada de Power BI y ayudan a crear una
cultura de los datos en la organización.
El progreso de la adopción y el fomento de una cultura de los datos van más allá de la
mera implementación de características tecnológicas. La tecnología puede ayudar a una
organización a conseguir el mayor impacto, pero una buena cultura de los datos abarca
una gran cantidad de consideraciones que afectan a personas, procesos y tecnología.
７ Nota
Cuando lea esta serie de artículos, se recomienda que también tenga en cuenta las
instrucciones de planeamiento de la implementación de Power BI. Una vez que
esté familiarizado con los conceptos de la hoja de ruta de adopción de Power BI,
considere la posibilidad de revisar los escenarios de uso. Comprender las diversas
formas en que se usa Power BI puede influir en las decisiones y estrategias
relacionadas con la implementación.
Esta serie de artículos se corresponde con el siguiente diagrama de la hoja de ruta de

adopción de Power BI:
Las áreas del diagrama anterior incluyen:
Ámbito Descripción
Cultural de los datos: la cultura de los datos se refiere a un conjunto de

comportamientos y normas de la organización que fomenta una cultura controlada por
los datos. La creación de una cultura de datos está estrechamente relacionada con la
adopción de Power BI, y a menudo es un aspecto clave de la transformación digital de
una organización.
Patrocinador ejecutivo: un patrocinador ejecutivo es alguien con credibilidad,

influencia y autoridad en toda la organización. Promueve la creación de una cultura de
los datos y la adopción de Power BI.
Propiedad y administración del contenido: hay tres estrategias principales para la

propiedad y la administración del contenido de inteligencia empresarial (BI): BI de
autoservicio dirigida por la empresa, BI de autoservicio administrada y BI empresarial.
Estas estrategias tienen una influencia considerable sobre la adopción, la gobernanza y
el modelo operativo del Centro de excelencia (COE).
Ámbito de entrega de contenido: hay cuatro estrategias principales para la entrega de

contenido: la BI personal, la BI de equipo, la BI de departamento y la BI empresarial.
Estas estrategias tienen una influencia considerable sobre la adopción, la gobernanza y
el modelo operativo del COE.
Centro de excelencia: un COE de Power BI es un equipo interno de expertos técnicos y

empresariales. Estos expertos ayudan de forma activa a otros usuarios que trabajan con
datos dentro de la organización. El COE constituye el núcleo de toda la comunidad para
el adelanto de los objetivos de adopción alineados con la visión de la cultura de los
datos.
Gobernanza: la gobernanza de los datos es un conjunto de directivas y procedimientos

que definen las formas en que una organización quiere que se usen los datos. Al
adoptar Power BI, el objetivo de la gobernanza es capacitar a la comunidad interna de
usuarios en la mayor medida posible, a la vez que satisfacer los requisitos y normativas
del sector, gubernamentales y contractuales.
Mentoría y capacitación de los usuarios: un objetivo fundamental de los esfuerzos de

adopción es permitir que los usuarios logren lo máximo posible dentro de los límites de
protección establecidos por las directivas y directrices de gobernanza. La mentoría de
los usuarios es una de las responsabilidades más importantes del COE. Tiene una
influencia directa sobre los esfuerzos de adopción.
Comunidad práctica: una comunidad práctica está formada por un grupo de personas
con un interés común que interactúan y se ayudan entre sí de forma voluntaria. Una
comunidad activa es un indicador de una buena cultura de los datos. Puede adelantar
considerablemente los esfuerzos de adopción.
Soporte técnico para usuarios: el soporte técnico para usuarios incluye métodos
organizados formal e informalmente para resolver problemas y responder a preguntas.
Los métodos de soporte técnico formales e informales son fundamentales para la
adopción.
Supervisión del sistema: la supervisión del sistema incluye las responsabilidades de

administración diarias que respaldan a los procesos internos, las herramientas y las
personas.
Las relaciones del diagrama mostrado anteriormente se pueden resumir en la siguiente

lista con viñetas:
La visión de la cultura de los datos de la organización va a influir mucho en las

estrategias que se siguen para la propiedad y la administración de contenido
empresarial y de autoservicio y el ámbito de entrega de contenido.
A su vez, estas estrategias van a tener un gran impacto en el modelo operativo del
Centro de excelencia y las decisiones de gobernanza.
Las directrices, las directivas y los procesos establecidos de gobernanza afectan a
los métodos de implementación empleados para la mentoría y la capacitación de
los usuarios, la comunidad prácticay el soporte técnico para usuarios.
Las decisiones de gobernanza dictan las actividades diarias de supervisión del
sistema (administración).
Todas las decisiones y acciones relacionadas con la cultura de los datos y la
adopción se logran más fácilmente con la orientación y el liderazgo de un
patrocinador ejecutivo.
En cada artículo individual de esta serie se habla de los temas clave asociados a los
elementos del diagrama. Se ofrecen consideraciones y posibles elementos de acción.
Cada artículo concluye con un conjunto de niveles de madurez para ayudar a evaluar el
estado actual a fin de poder decidir qué acción llevar a cabo a continuación.
Adopción de Power BI
Una correcta adopción de Power BI supone la creación de procesos, soporte técnico,
herramientas y datos eficaces y su integración en los patrones continuos de uso
normales de los creadores de contenido, los consumidores y las partes interesadas de la
organización.
） Importante
Esta serie de artículos de adopción se centra en la adopción organizativa. Vea el

artículo sobre los niveles de madurez de la adopción de Power BI para obtener
una introducción a los tres tipos de adopción: organizativa, de usuario y de
solución.
Un concepto erróneo común es que la adopción está principalmente relacionada con el

uso o el número de usuarios. No hay duda de que las estadísticas de uso son un factor
importante, Sin embargo, el uso no es el único factor. La adopción no solo se refiere al
uso de la tecnología de forma periódica, sino a utilizarla de forma eficaz. La eficacia es
mucho más difícil de definir y medir.
Siempre que sea posible, los esfuerzos de adopción deben alinearse entre plataformas
de análisis, servicios de BI y otros productos de Power Platform. Estos productos
incluyen Power Apps y Power Automate.
７ Nota
Los individuos, y la propia organización, están aprendiendo, cambiando y

mejorando continuamente. Eso significa que no existe un final propiamente dicho
para los esfuerzos relacionados con la adopción.
En los artículos restantes de esta serie de adopción de Power BI se tratan los siguientes
aspectos de la adopción.
Niveles de madurez de la adopción

Administración y propiedad del contenido
Gobernanza
Mentoría y capacitación
Comunidad práctica
Supervisión del sistema
Conclusión y recursos adicionales
） Importante
Es posible que se pregunte en qué se diferencia esta hoja de ruta de adopción de

Power BI del marco de adopción de Power BI . El marco de adopción se creó
principalmente como ayuda para los asociados de Microsoft. Es un conjunto ligero
de recursos para ayudar a los asociados a implementar soluciones de Power BI para
sus clientes.
Esta serie de adopción de Power BI es más actual. Está diseñada para orientar a
cualquier persona u organización que use, o considere la posibilidad de usar,
Power BI. Si busca mejorar la implementación de Power BI existente o planear una
nueva, esta hoja de ruta de adopción es un excelente punto de partida. En el marco
de adopción de Power BI va a encontrar una gran cantidad de información útil,
por lo que se recomienda revisarlo.
Audiencia de destino
La audiencia prevista de esta serie de artículos está interesada en uno o más de los
siguientes resultados.
Mejorar la capacidad de su organización para usar Power BI de forma eficaz.

Aumentar el nivel de madurez de su organización relacionado con la entrega de
Power BI.
Reconocer y superar los desafíos relacionados con la adopción a los que se
enfrenta al escalar Power BI.
Aumentar la rentabilidad de la inversión (ROI) de su organización en cuanto a
datos y análisis.
En primer lugar, esta serie de artículos va a ser útil para aquellos que trabajan en una
organización con una o más de las características siguientes.
Power BI se ha implementado con algunos éxitos.

Power BI tiene bolsas de adopción viral, pero no se gobierna con un fin en toda la
organización.
Power BI se ha implementado con una escala algo significativa, pero sigue siendo
necesario determinar:
Qué es eficaz y qué se debe mantener.
Qué se debe mejorar.
Cómo podrían ser más estratégicas las implementaciones futuras.
Se está considerando o planeando una implementación ampliada de Power BI.
En segundo lugar, esta serie de artículos es útil para:
Organizaciones que se encuentran en las primeras fases de una implementación

de Power BI.
Organizaciones que han tenido éxito en la adopción y ahora quieren evaluar su
nivel de madurez actual.
Suposiciones y ámbito
El protagonista principal de esta serie de artículos es la plataforma tecnológica Power BI,
con énfasis en el servicio Power BI.
Para beneficiarse totalmente de la información proporcionada en estos artículos, supone

una ventaja comprender al menos los conceptos fundamentales de Power BI.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre los niveles de madurez
de la adopción de Power BI. Se hace referencia a los niveles de madurez a lo largo de
toda la serie de artículos. Vea también el artículo de conclusión para obtener recursos
adicionales relacionados con la adopción.
Planeamiento de la implementación de Power BI

Enterprise
Hay asociados de Power BI experimentados a su disposición para ayudar a la

organización a lograr la adopción de Power BI. Para ponerse en contacto con un partner
de Power BI, visite el portal de partners de Power BI .
Agradecimientos
Melissa Coates, MVP de plataforma de datos y propietaria de Coates Data Strategies ,
ha redactado esta serie de artículos, junto con la colaboración de Matthew Roche. Entre
los revisores se incluyen Cory Moore, James Ward, Timothy Bindas, Greg Moir, Chuy
Varela, Daniel Rubiolo, Sanjay Raut y Peter Myers.
Niveles de madurez de la hoja de ruta
de adopción de Power BI
７ Nota
Este artículo forma parte de la serie de artículos sobre la hoja de ruta de adopción
de Power BI. Para obtener una introducción a la serie, vea Hoja de ruta de
adopción de Power BI.
Hay tres perspectivas interrelacionadas que se deben tener en cuenta al adoptar una
tecnología como Power BI.
Los tres tipos de adopción que se muestran en el diagrama anterior incluyen:
Tipo Descripción
Adopción de la organización: la adopción de la organización hace referencia a la eficacia

de la gobernanza de Power BI. También hace referencia a los procedimientos de
administración de datos que respaldan y facilitan los esfuerzos de inteligencia empresarial.
Adopción del usuario: la adopción del usuario es la capacidad de los consumidores y

creadores de aumentar sus conocimientos de forma continua. Tiene en cuenta si usan
Power BI de forma activa y eficaz.
Adopción de la solución: la adopción de la solución hace referencia al impacto y al valor

empresarial logrados para los requisitos individuales y las soluciones de Power BI.
Como indican las cuatro flechas del diagrama anterior, los tres tipos de adopción están
muy interrelacionados:
La adopción de la solución afecta a la adopción del usuario. Una solución bien

diseñada y bien gestionada, que podría ser muchas cosas, como un conjunto de
informes, una aplicación o un conjunto de datos, tiene un impacto y guía a los
usuarios en el uso óptimo de Power BI.
La adopción del usuario afecta a la adopción de la organización. Los patrones y
prácticas utilizados por los usuarios individuales influyen en las decisiones,
directivas y prácticas de la adopción de la organización.
La adopción de la organización influye en la adopción del usuario. Las prácticas
organizativas eficaces, como la orientación, la formación, la asistencia y la
comunidad, animan a los usuarios a hacer lo correcto en su flujo de trabajo diario.
La adopción del usuario afecta a la adopción de la solución. Una adopción del
usuario más sólida a causa del uso eficaz de Power BI por parte de usuarios
formados e informados contribuye a generar soluciones individuales más sólidas y
exitosas.
A continuación, se presentan los tres tipos de adopción de Power BI de forma más

detallada.
Niveles de madurez de la adopción de la

organización
La adopción de la organización mide el estado de las prácticas de administración de
datos y gobernanza de Power BI. Existen varios objetivos de adopción de la
organización:
Apoyar a la comunidad de forma eficaz.

Capacitar y facultar a los usuarios.
Supervisar la entrega de información a través de BI empresarial y BI de autoservicio
con ciclos de mejora continua.
Resulta útil pensar en la adopción de la organización desde la perspectiva de un modelo

de madurez. Para mantener la coherencia con el modelo de madurez de la adopción de
Power CAT y el modelo de madurez para Microsoft 365, esta hoja de ruta de adopción
de Power BI se ajusta a los cinco niveles del modelo de madurez y de capacidad , que
posteriormente se mejoraron con el modelo de madurez de administración de datos
(DMM) de ISACA (tenga en cuenta que DMM era un recurso de pago que se ha
retirado).
Las organizaciones tienen limitaciones de tiempo, financiación y personal. Por lo tanto,
deben ser selectivas a la hora de priorizar sus esfuerzos. Para sacar el máximo partido de
su inversión en Power BI, intente alcanzar, al menos, el nivel de madurez 300 o 400,
como se describe a continuación. Es habitual que las distintas unidades de negocio de la
organización evolucionen y maduren a velocidades diferentes, por lo que debe ser
consciente del estado de la organización, así como del progreso de las unidades de
negocio clave.
７ Nota
El recorrido para alcanzar la madurez de la adopción de la organización es largo. Se

necesita tiempo, esfuerzo y planificación para avanzar a los niveles superiores.
Nivel de madurez 100: inicial

El nivel 100 se conoce como inicial o realizado. Es el punto de partida para nuevas
inversiones relacionadas con los datos, no documentadas y sin disciplina de proceso.
Entre las características comunes del nivel de madurez 100, se incluyen las siguientes:
Existen focos de éxito y experimentación con Power BI en una o varias áreas de la

organización.
Conseguir logros rápidos ha sido una prioridad que ha traído consigo algunos
éxitos.
El crecimiento autónomo ha provocado una falta de estrategia coordinada o
enfoque de gobernanza.
Las prácticas no están documentadas y existe una dependencia importante del
conocimiento no escrito de grupo.
Existen pocos procesos formales en vigor para administrar los datos de forma
eficaz.
Existe un riesgo debido a la falta de conocimiento de cómo se usan los datos en la
organización.
Se reconoce la posibilidad de una inversión estratégica con Power BI, pero no
existe ninguna vía de progreso clara hacia una ejecución determinada y a nivel de
Nivel de madurez 200: recurrente

El nivel 200 se conoce como recurrente o administrado. En este punto de la curva de
madurez, se ha planificado y ejecutado la administración de datos. La administración de
datos se basa en procesos definidos, aunque es posible que estos procesos no se
apliquen de manera uniforme en toda la organización.
Algunos de los contenidos de Power BI han adquirido una importancia vital o se

usan de forma generalizada en la organización.
Se han intentado documentar y definir prácticas recurrentes. Sin embargo, los
esfuerzos son aislados, reactivos y ofrecen distintos niveles de éxito.
Existe una dependencia excesiva de las personas que tienen un buen criterio y
adoptan hábitos correctos que han aprendido por sí mismas.
Cada vez se adopta Power BI más y más naturalmente y genera valor. Sin embargo,
se produce de forma incontrolada.
Se adoptan recursos para crear una comunidad interna, como un canal de Teams o
un grupo de Yammer.
Se está llevando a cabo una planificación inicial para desarrollar una estrategia de
gobernanza de Power BI coherente.
Se reconoce que un centro de excelencia (COE) de Power BI puede proporcionar
valor.
Nivel de madurez 300: definido

El nivel 300 se conoce como definido. En este punto de la curva de madurez, se han
definido unos procesos de administración de datos estandarizados que se aplican de
forma coherente a través de los límites de la organización.
Se logra un éxito medible para el uso eficaz de Power BI.

Se ha avanzado en la normalización de las prácticas recurrentes, aunque puede
que sigan existiendo aspectos que no son óptimos debido a un crecimiento inicial
incontrolado.
Se ha definido un COE de Power BI, con ámbitos de responsabilidades y objetivos
claros.
La comunidad interna gana terreno con la participación de un número creciente de
usuarios.
Surgen expertos de Power BI en la comunidad.
Se realizan inversiones iniciales en formación, documentación y recursos.
Existe un modelo de gobernanza inicial.
Power BI tiene un patrocinador ejecutivo activo y comprometido.
Los roles y las responsabilidades de todos los implicados en la adopción de
Power BI están bien comprendidos.
Nivel de madurez 400: capaz
El nivel 400 se conoce como capaz o medido. En este punto de la curva de madurez, los
datos se administran bien a lo largo de todo su ciclo de vida.
Los esfuerzos de inteligencia empresarial proporcionan un valor significativo.

Power BI se usa de forma habitual en la organización para entregar contenido de
vital importancia.
Existe un modelo de gobernanza establecido y aceptado con la cooperación de
todas las unidades de negocio clave.
La comunidad de usuarios de Power BI usa de forma activa y accede con facilidad a
la formación, la documentación y los recursos.
Se han puesto en marcha procesos estandarizados para el control y la supervisión
del uso y las prácticas de Power BI.
En el COE de Power BI se encuentran representadas todas las unidades de negocio
clave.
Existe una red de expertos de Power BI que apoya a la comunidad interna. Los
expertos colaboran de forma activa con sus compañeros y el COE.
Nivel de madurez 500: eficaz

El nivel 500 se conoce como eficaz o perfeccionador, ya que en este punto de la curva de
madurez se pone énfasis en la automatización y la mejora continua.
El valor de las soluciones de Power BI predomina en la organización y se acepta

Power BI de forma generalizada.
En la organización se otorga un gran valor a los conjuntos de aptitudes de
Power BI y la dirección los reconoce.
La comunidad interna de Power BI es autosuficiente, con el apoyo del COE. La
comunidad no depende en exceso de las personas clave.
El COE revisa periódicamente los indicadores clave de rendimiento para medir el
éxito de los objetivos de implementación y adopción.
La mejora continua siempre es una prioridad.
El uso de la automatización añade valor, mejora la productividad o reduce el riesgo
de error.
７ Nota
Las características anteriores tienen una connotación general. Al considerar los
niveles de madurez y diseñar un plan, querrá tener en cuenta cada tema u objetivo
de forma independiente. En realidad, es probable que no sea posible alcanzar el
nivel de madurez 500 para todos los aspectos de la adopción de Power BI en toda
la organización. Por lo tanto, evalúe los niveles de madurez de forma
independiente, por objetivo. De este modo, puede dar prioridad a los esfuerzos
donde le proporcionen más valor. En los demás artículos de esta serie sobre la
adopción de Power BI se presentan los niveles de madurez por tema.
Las personas, y la propia organización, aprenden, cambian y mejoran de forma continua.

Por lo tanto, no existe un final propiamente dicho para los esfuerzos relacionados con la
adopción. Sin embargo, es habitual que el esfuerzo se reduzca a medida que se
alcancen niveles de madurez más altos.
A continuación, se presentan el segundo y el tercer tipo de adopción: adopción del

usuario y adopción de la solución.
７ Nota
Los demás artículos de esta serie se centran principalmente en la adopción de la

organización.
Fases de adopción del usuario

La adopción del usuario mide la capacidad de los consumidores de contenido y los
creadores de contenido de autoservicio para usar Power BI de forma activa y eficaz. Las
estadísticas de uso por sí solas no representan la adopción del usuario. La adopción del
usuario también hace referencia a los comportamientos y prácticas de los usuarios
individuales. El objetivo es garantizar una interacción correcta e integral con Power BI
por parte de los usuarios.
La adopción del usuario abarca cómo los consumidores ven el contenido y también
cómo los creadores de autoservicio generan contenido para que otros lo consuman.
La adopción del usuario se produce de forma individual, pero se mide y analiza en

conjunto. Los usuarios individuales avanzan por las cuatro fases de adopción del usuario
a su propio ritmo. Cuando una persona adopta una nueva tecnología, necesita tiempo
para dominarla. Algunos usuarios mostrarán predisposición, pero otros serán reacios a
aprender a usar otra herramienta, independientemente de las mejoras de productividad
prometidas. Avanzar por las fases de adopción del usuario implica tiempo y esfuerzo, así
como cambios de comportamiento para adaptarse a los objetivos de adopción de la
organización. La capacidad de la organización para respaldar el avance de los usuarios
por las fases de adopción tiene una correlación directa con la madurez de la adopción a
nivel de la organización.
Fase 1 de la adopción del usuario: reconocimiento

Entre las características comunes de la fase 1 de la adopción del usuario, se incluyen las
siguientes:
La persona ha oído hablar de o ha sido expuesta inicialmente a Power BI de alguna

manera.
Puede que una persona tenga acceso a Power BI, pero aún no lo use.
Fase 2 de la adopción del usuario: comprensión

siguientes:
La persona toma conciencia de las ventajas de Power BI para proporcionar valor

analítico y respaldar la toma de decisiones.
La persona muestra interés y empieza a usar Power BI.
Fase 3 de la adopción del usuario: impulso

siguientes:
La persona participa de forma activa en la adquisición de las habilidades de

Power BI a través de la formación oficial, el aprendizaje autónomo o la
experimentación.
La persona adquiere competencias básicas sobre los aspectos de Power BI
relacionados con su rol.
Fase 4 de la adopción del usuario: dominio

siguientes:
La persona usa Power BI de forma habitual.

La persona entiende cómo usar Power BI según la manera prevista y las
necesidades de su rol.
La persona modifica su comportamiento y sus actividades para adaptarse a los
procesos de gobernanza de la organización.
La disposición de una persona a respaldar los esfuerzos de cambio y los procesos
de la organización aumenta con el tiempo, y esa persona acaba convirtiéndose en
promotora de Power BI en la organización.
La persona hace el esfuerzo de mejorar sus aptitudes de forma continua y de
mantenerse al día en lo referente a las nuevas funcionalidades y características del
producto.
Es fácil infravalorar el esfuerzo que se realiza para avanzar de la fase 2 (comprensión) a

la fase 4 (dominio). Normalmente, se tarda más tiempo en avanzar de la fase 3 (impulso)
a la fase 4 (dominio).
） Importante
Cuando los usuarios alcanzan las fases de impulso y dominio, la organización debe
estar lista para ofrecerles apoyo. Puede plantearse algunos esfuerzos proactivos
para animar a los usuarios a avanzar por las fases. Para obtener más información,
consulte los artículos sobre la comunidad de prácticas y el soporte técnico del
usuario.
Fases de adopción de la solución

La adopción de la solución hace referencia a la medición del impacto de las soluciones
de Power BI individuales. También tiene en cuenta el nivel de valor que proporcionan las
soluciones. El ámbito para evaluar la adopción de la solución corresponde a un conjunto
de requisitos, como un conjunto de informes o una aplicación Power BI única.
Cuando una solución avanza a las fases 3 o 4, las expectativas para poner en práctica la
solución son mayores.
 Sugerencia
La importancia del ámbito en las expectativas de gobernanza se describe en el

artículo sobre el ámbito de entrega de contenido. Ese concepto está
estrechamente relacionado con este tema, pero en este artículo se aborda desde
un ángulo diferente. Tiene en cuenta el hecho de tener ya una solución en
funcionamiento y distribuida a muchos usuarios. Esto no equivale inmediatamente
a la fase 4 de la adopción de la solución, ya que el concepto de adopción de la
solución se centra en cuánto valor ofrece el contenido.
Fase 1 de la solución: exploración
Entre las características comunes de la fase 1 de la adopción de la solución, se incluyen
las siguientes:
La exploración y la experimentación son los enfoques principales para probar

nuevas ideas. La exploración de nuevas ideas puede producirse a través del
autoservicio informal de BI o a través de una prueba de concepto (POC) formal,
que tiene un ámbito específico. El objetivo es confirmar requisitos, validar
supuestos, abordar factores desconocidos y mitigar riesgos.
Un pequeño grupo de usuarios prueba la solución de prueba de concepto y
proporciona comentarios útiles.
La exploración y los comentarios iniciales pueden llevarse a cabo en Power BI
Desktop o Excel. El uso de Power BI es limitado.
Fase 2 de la solución: funcional

las siguientes:
La solución es funcional y cumple el conjunto básico de requisitos de usuario. Es

probable que haya planes para repetir mejoras y perfeccionamientos.
La solución se implementa en el servicio de Power BI.
Todos los componentes auxiliares necesarios están preparados, como las puertas
de enlace para permitir la actualización programada.
Los usuarios son conscientes de la solución y muestran interés en utilizarla. Es
posible que sea una versión preliminar limitada y que aún no esté lista para
avanzar a un área de trabajo de producción.
Fase 3 de la solución: valiosa

las siguientes:
Los usuarios de destino creen que la solución es valiosa y experimentan ventajas

tangibles.
La solución avanza a un área de trabajo de producción.
Se realizan validaciones y pruebas para garantizar la calidad de los datos, una
presentación precisa, accesibilidad y un rendimiento aceptable.
El contenido se aprueba, cuando corresponde.
Las métricas de uso de la solución se supervisan de forma activa.
Existen bucles de comentarios de usuarios para facilitar sugerencias y mejoras que
pueden contribuir al desarrollo de futuras versiones.
Se crea documentación de la solución para satisfacer las necesidades de los
consumidores de información (por ejemplo, los orígenes de datos usados o la
forma de calcular las métricas) y ayudar a los futuros creadores (por ejemplo,
documentar cualquier mantenimiento futuro o mejoras planificadas).
La propiedad y los expertos en la materia del contenido están claros.
Existe un tema y una personalización de marca para los informes en línea con las
directrices de gobernanza.
Fase 4 de la solución: esencial

las siguientes:
Los usuarios de destino usan la solución de forma activa y rutinaria. Además, la

solución se considera esencial para la toma de decisiones.
La solución se encuentra en un área de trabajo de producción, bien separada del
contenido de prueba y desarrollo. La administración de los cambios y las versiones
se controla con cuidado debido al impacto de los cambios.
Un subconjunto de usuarios proporciona comentarios de forma periódica para
garantizar que la solución sigue cumpliendo los requisitos.
Las expectativas en cuanto al éxito de la solución son claras y se miden.
Las expectativas en cuanto al soporte técnico de la solución son claras,
especialmente si hay contratos de nivel de servicio.
La solución se ajusta a las prácticas y directrices de gobernanza de la organización.
En su mayoría, se trata de contenido certificado debido a su vital importancia.
Pueden llevarse a cabo pruebas de aceptación de usuario formales para los nuevos
cambios, especialmente para el contenido administrado por TI.
Pasos siguientes
En el siguiente artículo de la serie sobre la hoja de ruta de adopción de Power BI,
obtendrá más información sobre la cultura de datos de la organización y su impacto en
los esfuerzos de adopción.
Hoja de ruta de adopción de Power BI:
cultura de datos
７ Nota
La creación de una cultura de datos está estrechamente relacionada con la adopción de

Power BI, y a menudo es un aspecto clave de la transformación digital de una
organización. El término cultura de datos se puede definir de maneras diferentes en
distintas organizaciones. En esta serie de artículos, se considera cultura de datos un
conjunto de comportamientos y normas en una organización. Esta fomenta una cultura
que regularmente realiza tomas de decisiones bien fundadas en datos:
Por parte de más partes interesadas en más áreas de la organización.

Basadas en el análisis, no en la opinión.
De una manera eficaz y eficiente basada en los procedimientos recomendados
aprobados por el centro de excelencia (COE).
Basadas en datos de confianza.
Que reducen la dependencia en el conocimiento tribal no documentado.
Que reducen la dependencia en las corazonadas y las decisiones instintivas.
） Importante
Piense en la cultura de datos como lo que se hace, no lo que se dice. La cultura de

datos no es un conjunto de reglas (la gobernanza cumple ese papel). Por lo tanto,
la cultura de datos es un concepto algo abstracto. Son los comportamientos y las
normas que se permiten, recompensan y fomentan, o los que no se permiten y
desaconsejan. Tenga en cuenta que una cultura de datos en buen estado motiva a
los empleados de todos los niveles de la organización a generar y distribuir
conocimientos prácticos.
Dentro de una organización, es probable que determinadas unidades de negocio o

equipos tengan sus propios comportamientos y normas para realizar las cosas. Las
formas específicas de lograr los objetivos de la cultura de datos pueden variar de unos
departamentos a otros. Lo importante es que todos coincidan con los objetivos de la
cultura de datos de la organización. Esta estructura se puede ver como una autonomía
alineada.
El siguiente diagrama circular muestra los aspectos interrelacionados que pueden influir
en una cultura de datos:
El diagrama representa las relaciones algo ambiguas entre los siguientes elementos:
La cultura de datos es el círculo externo. Todos los temas que contiene contribuyen
al estado de la cultura de datos.
La adopción en la organización (incluidos los aspectos de implementación de la
mentoría y la habilitación de los usuarios, el soporte técnico al usuario, la
comunidad práctica, la gobernanza y la supervisión del sistema) es el círculo
interno. Todos los temas contribuyen en gran parte a la cultura de datos.
El soporte ejecutivo y el Centro de excelencia impulsan el éxito de la adopción de
la organización.
El dominio, la democratización y la detección de los datos son aspectos de la
cultura de datos que están muy influenciados por la adopción en la organización.
La propiedad, la administración y el ámbito de entrega del contenido están
estrechamente relacionados con la democratización de los datos.
Los elementos del diagrama se describen en esta serie de artículos.
Visión de la cultura de datos

El concepto de cultura de datos puede ser difícil de definir y medir. Aunque es difícil
expresar la cultura de datos de una manera significativa, útil y medible, es importante
que comprenda bien la definición de lo que significa una cultura de datos correcta para
su organización. Esta visión de una cultura de datos correcta debe:
Tener origen en el nivel ejecutivo.

Coincidir con los objetivos de la organización.
Influir directamente en la estrategia de adopción.
Actuar como principios rectores de alto nivel para la aplicación de directivas y
directrices de gobernanza.
Los resultados de la cultura de datos no se exigen específicamente. Más bien, el estado

de la cultura de datos es el resultado de seguir las reglas de gobernanza a medida que
se aplican (o la falta de ellas). Los líderes de todos los niveles deben demostrar
activamente lo que es importante a través de sus acciones, incluida la forma en que
halagan, reconocen y recompensan a los miembros del personal que toman la iniciativa.
 Sugerencia
Si puede dar por hecho que sus esfuerzos para desarrollar una solución de datos
(como un conjunto de datos o un informe) se valorarán y apreciarán, es un
indicador excelente de que cuenta con una cultura de datos correcta. En ocasiones,
sin embargo, depende de lo que el administrador valore más.
La motivación inicial para establecer una cultura de datos a menudo proviene de un

problema o iniciativa empresarial estratégico concreto. Podría ser:
Un cambio reactivo, como responder a una nueva competencia ágil.

Un cambio proactivo, como iniciar una nueva línea de negocio o expandirse a
nuevos mercados para aprovechar una oportunidad totalmente nueva. Basarse en
los datos desde el principio puede ser relativamente fácil cuando hay menos
restricciones y complicaciones, en comparación con una organización establecida.
Controlada por cambios externos, como la presión para eliminar ineficiencias y
redundancias durante una caída económica.
En cualquiera de estas situaciones, a menudo hay un área específica donde se afianza la

cultura de datos. El área específica podría ser un ámbito de esfuerzo menor que toda la
organización, incluso si sigue siendo significativa. Después de realizar los cambios
necesarios en este ámbito más pequeño, se pueden replicar y adaptar de forma
incremental al resto de la organización.
Aunque la tecnología puede ayudar a avanzar en los objetivos de una cultura de datos,
la implementación de herramientas o características específicas no es el objetivo. Esta
serie de artículos cubre muchos temas que contribuyen a la adopción de una cultura de
datos correcta. En el resto de este artículo se abordan tres aspectos esenciales de la
cultura de datos: la detección de datos, la democratización de datos y la flexibilidad de
datos.
Detección de datos
Una cultura de datos correcta depende de los usuarios que trabajan con los datos
adecuados en sus actividades cotidianas. Para lograr este objetivo, los usuarios deben
buscar y acceder a orígenes de datos, informes y otros elementos.
La detección de datos es la capacidad de buscar y localizar eficazmente orígenes de

datos e informes pertinentes en toda la organización. Principalmente, la detección de
datos se centra en mejorar el conocimiento de que los datos existen, especialmente
cuando los datos se almacenan en sistemas de departamento. Una vez que un usuario
conoce la existencia de los datos, ese usuario puede pasar por el proceso estándar para
solicitar acceso a la información. Hoy en día, la tecnología ayuda mucho en la detección
de datos y permite ir mucho más allá que preguntando a los compañeros dónde se
pueden encontrar conjuntos de datos.
 Sugerencia
Es importante tener un proceso claro y sencillo para que los usuarios puedan
solicitar acceso a los datos. Saber que existe un conjunto de datos, pero no poder
acceder a él debido a las directrices y los procesos establecidos por el propietario
del dominio, puede ser frustrante para los usuarios. Puede obligarles a usar
soluciones alternativas ineficaces en lugar de solicitar acceso en los canales
adecuados.
La detección de datos contribuye a los esfuerzos de adopción y a la implementación de
prácticas de gobernanza mediante las siguientes acciones:
Fomentar el uso de orígenes de datos de alta calidad de confianza.

Animar a los usuarios a aprovechar las inversiones en recursos de datos existentes.
Promover el uso y el enriquecimiento de los elementos de Power BI que ya existen.
Ayudar a las personas a comprender quién posee y administra los conjuntos de
datos.
Establecer conexiones entre consumidores, creadores y propietarios.
En Power BI, el centro de datos y el uso de aprobaciones ayudan a promover la

detección de datos de conjuntos de datos compartidos. También animan a los creadores
de autoservicio a reutilizar y aumentar los conjuntos de datos.
Además, las soluciones de catálogo de datos son extremadamente valiosas para la

detección de datos. Pueden registrar etiquetas y descripciones de metadatos para
proporcionar un contexto y un significado más profundos. Por ejemplo, Azure Purview
puede examinar y catalogar un inquilino de Power BI entero.
Democratización de datos
La democratización de datos hace referencia a poner los datos en manos de más
usuarios responsables de resolver problemas empresariales. Se trata de permitirles
tomar decisiones relacionadas con los datos.
７ Nota
El concepto de democratización de los datos no implica una falta de seguridad ni

una falta de justificación basada en el rol de trabajo. Como parte de una cultura de
datos correcta, la democratización de los datos ayuda a reducir la TI en la sombra al
proporcionar conjuntos de datos que:
Están protegidos, controlados y bien administrados.

Satisfacen las necesidades empresariales de un modo rentable y oportuno.
La posición de su organización sobre la democratización de los datos tendrá un gran

impacto en los esfuerzos relacionados con la adopción y la gobernanza. Estos son
algunos ejemplos de decisiones de gobernanza de Power BI que pueden afectar a la
democratización de los datos:
¿Quién tiene permiso para instalar Power BI Desktop?

¿Quién puede tener licencias de Power BI Pro o Power BI Premium por usuario
(PPU)?
¿Cuál es el nivel deseado de habilitación de los usuarios de inteligencia
empresarial (BI) de autoservicio? ¿Cómo varía este nivel en función de la unidad de
negocio o el rol de trabajo?
¿Cuál es el equilibrio deseado entre el BI empresarial y el BI de autoservicio?
¿Hay una clara preferencia por algunos orígenes de datos? ¿Cuál es el uso
permitido de orígenes de datos no autorizados?
¿Quién puede administrar el contenido? ¿Esta decisión es diferente para los datos
y para los informes? ¿La decisión es diferente para los usuarios de BI empresariales
frente a los usuarios descentralizados que poseen y administran contenido de BI
de autoservicio?
¿Quién puede consumir contenido? ¿Esta decisión es diferente para asociados
externos, clientes y proveedores?
２ Advertencia
Si el acceso a los datos o la capacidad de realizar análisis se limita a un número

determinado de personas de la organización, suele ser una señal de advertencia, ya
que la capacidad de trabajar con datos es una característica clave de una cultura de
datos.
Flexibilidad de los datos

La flexibilidad de los datos hace referencia a la capacidad de interpretar, crear y
comunicar datos de forma precisa y eficaz.
Los esfuerzos de entrenamiento, como se describe en el artículo sobre mentoría y

habilitación de usuarios, a menudo se centran en cómo usar la propia tecnología. Las
aptitudes tecnológicas son importantes para generar soluciones de alta calidad, pero
también es importante tener en cuenta cómo avanzar intencionadamente en el dominio
de los datos en toda la organización. Dicho de otro modo, la adopción correcta requiere
mucho más que proporcionar el software y las licencias de Power BI a los usuarios.
La forma de mejorar la flexibilidad de los datos en su organización depende de muchos

factores, como los conjuntos de aptitudes de usuario actuales, la complejidad de los
datos y los tipos de análisis necesarios. Puede centrarse en estas actividades
relacionadas con el dominio de los datos:
Interpretación de gráficos y grafos.

Evaluación de la validez de los datos.
Realización de análisis de la causa principal.
Distinción entre correlación y causalidad.
Comprensión de cómo influyen el contexto y los valores atípicos en los resultados
que se presentan.
Uso de la narración para ayudar a los consumidores a comprender y actuar
rápidamente.
 Sugerencia
Si tiene dificultades para aprobar la cultura de datos o los esfuerzos de

gobernanza, puede ser útil centrarse en las ventajas tangibles que se pueden lograr
con la detección de datos ("buscar los datos"), la democratización de los datos
("usar los datos") o la flexibilidad de los datos ("comprender los datos"). También
puede ser útil centrarse en problemas específicos que se pueden resolver o mitigar
con los avances de la cultura de datos.
Normalmente, el primer paso es conseguir que las partes interesadas adecuadas

acepten el problema. Después, se trata de conseguir que las partes interesadas se
pongan de acuerdo en el enfoque estratégico de una solución, junto con los
detalles de la solución.
Consideraciones y acciones clave
Lista de comprobación: estas son algunas consideraciones y acciones clave que puede
realizar para reforzar la cultura de datos.
＂ Alinear los objetivos y la estrategia de la cultura de datos: preste especial atención

al tipo de cultura de datos que quiere cultivar. Lo ideal es que sea más desde una
posición de capacitación del usuario que desde una posición de ordeno y mando.
＂ Comprensión del estado actual: hable con las partes interesadas de las diferentes
unidades de negocio para saber qué procedimientos de análisis funcionan bien en
la actualidad y cuáles no para la toma de decisiones basadas en datos. Realice una
serie de talleres para conocer el estado actual y formular el estado futuro deseado.
＂ Comunicación con las partes interesadas: hable con las partes interesadas de TI, BI
o el COE para saber qué restricciones de gobernanza se deben tener en cuenta.
Estas charlas pueden ser una oportunidad para educar a los equipos en temas
como la seguridad y la infraestructura. También puede usar la oportunidad de
educarlos sobre lo que es realmente Power BI (y cómo incluye funcionalidades
eficaces de preparación y modelado de datos, además de ser una herramienta de
visualización).
＂ Comprobación del nivel de patrocinio: compruebe el nivel de patrocinio y apoyo
de la dirección que tiene para avanzar en los objetivos de la cultura de datos.
＂ Toma de decisiones significativas sobre la estrategia de BI: decida cuál debe ser el
equilibrio ideal entre la inteligencia empresarial de autoservicio dirigida por la
empresa, la inteligencia empresarial de autoservicio administrada y la inteligencia
empresarial corporativa para las principales unidades de negocio de la organización
(lo que se describe en el artículo sobre propiedad y administración de contenido).
Tenga en cuenta también cómo se relaciona la estrategia con la extensión del
contenido publicado para la inteligencia empresarial personal, de equipo, de
departamento y corporativa (lo que se describe en el artículo sobre ámbito de
entrega de contenido). Determine cómo afectan estas decisiones al plan de acción.
＂ Creación de un plan de acción: comience por crear un plan de acción para
elementos de acción inmediatos, a corto y a largo plazo. Identifique los grupos de
negocio y los problemas que representan "resultados rápidos" y pueden marcar
una diferencia notable.
＂ Creación de objetivos y métricas: determine cómo medirá la eficacia de las
iniciativas de cultura de datos. Cree KPI (indicadores clave de rendimiento) u OKR
(objetivos y resultados clave) para validar los resultados de los esfuerzos.
Niveles de madurez
Los siguientes niveles de madurez le ayudarán a evaluar el estado actual de la cultura de

datos.
Level Estado de la cultura de datos

Level Estado de la cultura de datos
100: Inicial El equipo de BI empresarial no puede mantenerse al día con las necesidades de la
empresa. Existe un trabajo pendiente significativo de solicitudes para el equipo de
BI empresarial.
Se llevan a cabo iniciativas de inteligencia empresarial de autoservicio, con algunos

logros, en varias áreas de la organización. Estas actividades se llevan a cabo de una
manera algo caótica, con pocos procesos formales y sin un plan estratégico.
Hay una falta de supervisión y visibilidad de las actividades de inteligencia

empresarial de autoservicio. Los éxitos o errores de las soluciones de BI no se
comprenden bien.
200: Varios equipos han tenido éxitos medibles con soluciones de BI de autoservicio.
Repetible Personas de la organización empiezan a prestar atención.
Se realizan inversiones para identificar el equilibrio idóneo entre la inteligencia

empresarial y la de autoservicio.
300: Se establecen objetivos específicos para avanzar en la cultura de datos. Estos

Definido objetivos se implementan de forma incremental.
Se comparten los aprendizajes de lo que funciona en unidades de negocio

individuales.
Las prácticas eficaces de inteligencia empresarial de autoservicio se replican

incremental e intencionadamente en más áreas de la organización.
400: Los objetivos de la cultura de datos para emplear una toma de decisiones
Competente informada están alineados con los objetivos de la organización. Cuentan con el
apoyo activo del patrocinio de la directiva, el COE y tienen un impacto directo en
las estrategias de adopción.
Existe una asociación productiva y en buen estado entre el patrocinio de la

directiva, el COE, las unidades de negocio y TI. Los equipos trabajan para lograr
objetivos compartidos.
Se reconoce y se premia a las personas que toman la iniciativa en la creación de

soluciones valiosas de inteligencia empresarial.
500: El valor empresarial de las soluciones de inteligencia empresarial se evalúa y mide

Eficiente periódicamente. Se usan KPI u OKR para realizar el seguimiento de los objetivos de
la cultural de datos y los resultados de los esfuerzos de BI.
Hay bucles de comentarios en vigor y fomentan mejoras en la cultura de datos en

curso.
La mejora continua de la adopción en la organización y por parte de los usuarios y

la adopción de soluciones es una de las principales prioridades.
Pasos siguientes
Puede obtener más información sobre la importancia del patrocinador ejecutivo en el
siguiente artículo de la serie sobre la hoja de ruta de adopción de Power BI.
patrocinio ejecutivo
７ Nota
Al planear el progreso de la cultura de los datos y el estado de la adopción de Power BI

en la organización, es fundamental contar con soporte ejecutivo. Un patrocinador
ejecutivo es vital, puesto que la adopción de Power BI es mucho más que un mero
proyecto tecnológico.
Aunque unos cuantos colaboradores individuales decididos pueden lograr algunos

éxitos, la organización estará en una posición considerablemente mejor si hay un líder
sénior comprometido, comprensivo, informado y disponible para ayudar en las
actividades siguientes.
La formulación de una visión estratégica y de las prioridades de BI y análisis.

El ejemplo mediante el uso activo de Power BI de forma coherente con la cultura
de los datos y los objetivos de adopción.
La asignación de personal y la priorización de recursos.
La aprobación de financiación (por ejemplo, licencias de Power BI).
La eliminación de barreras para habilitar la acción.
La comunicación de anuncios que son de importancia crítica, para ayudarles a
ganar tracción.
La toma de decisiones, especialmente decisiones de gobernanza de nivel
estratégico.
La resolución de conflictos (de problemas escalados que no puede resolver el
personal operativo o táctico).
El respaldo de las iniciativas de cambios organizativos (por ejemplo, la creación o
la ampliación del Centro de excelencia).
） Importante
El patrocinador ejecutivo ideal tiene suficiente credibilidad, influencia y autoridad

en toda la organización.
Identificación de un patrocinador ejecutivo
Hay varias maneras de identificar un patrocinador ejecutivo.
Patrón de arriba abajo

Un patrocinador ejecutivo puede ser seleccionado por un ejecutivo de más nivel. Por
ejemplo, el director ejecutivo (CEO) puede contratar a un director de datos (CDO) o
director de análisis (CAO) para impulsar los objetivos de la cultura de datos de la
organización o dirigir los esfuerzos de transformación digital. Luego, el CDO o CAO se
convierte en el candidato ideal para actuar como patrocinador ejecutivo de Power BI (o
análisis en general).
Este es otro ejemplo: el CEO puede capacitar a un ejecutivo existente, como el director
financiero (CFO), por su buen historial en la manipulación de datos y análisis de la
organización. Como nuevo patrocinador ejecutivo, el CFO podría dirigir los esfuerzos
para replicar el éxito del equipo financiero en otras áreas de la organización.
７ Nota
Tener un patrocinador ejecutivo de Power BI de nivel directivo es un indicador

excelente. Indica que la organización reconoce la importancia de los datos como
recurso estratégico y que está desarrollando su cultura de los datos en una
dirección positiva.
Patrón de abajo arriba

También puede surgir un candidato para el rol de patrocinador ejecutivo, debido al éxito
experimentado con la creación de soluciones de BI. Por ejemplo, una unidad de negocio
de la organización, como Finanzas, ha logrado un gran éxito integral con su uso de los
datos y el análisis. Básicamente, ha formado correctamente su propia cultura de datos a
pequeña escala. Entonces, un líder junior que no haya alcanzado el nivel ejecutivo (por
ejemplo, un director) puede convertirse en el patrocinador ejecutivo al compartir los
éxitos con otras unidades de negocio de la organización.
Es más probable que el enfoque de abajo arriba se plantee en organizaciones más

pequeñas. Puede deberse a que la rentabilidad de la inversión y el imperativo
estratégico de una cultura de datos (o una transformación digital) no es una prioridad
para los directivos de mayor nivel.
El éxito de un líder que usa el patrón de abajo arriba depende de su reconocimiento por
parte del equipo de alta dirección.
Con un enfoque de abajo arriba, es posible que el patrocinador pueda realizar algún
progreso, pero no tendrá autoridad formal sobre otras unidades de negocio. Sin una
autoridad clara, solo es cuestión de tiempo que se produzcan desafíos que superen su
nivel de autoridad. Por esta razón, el enfoque de arriba abajo tiene una mayor
probabilidad de éxito. Sin embargo, los éxitos iniciales con un enfoque de abajo arriba
pueden convencer a los directivos de aumentar su nivel de patrocinio, lo que puede
iniciar una competencia sana entre otras unidades de negocio en cuanto a la adopción
de BI.
Lista de comprobación: esta es una lista de consideraciones y acciones clave para

establecer o reforzar el apoyo ejecutivo para Power BI.
＂ Identifique a un patrocinador ejecutivo con amplia autoridad: encuentre a alguien

con la suficiente influencia y autoridad (en toda la organización) que comprenda el
valor y el impacto de la inteligencia empresarial. Es importante que el individuo
tenga interés en el éxito del análisis en la organización.
＂ Implique a su patrocinador ejecutivo: implique de forma coherente a su
patrocinador ejecutivo en todas las decisiones de gobernanza de nivel estratégico
que impliquen la administración de datos, la inteligencia empresarial y el análisis.
Implique también al patrocinador en todas las iniciativas de gobernanza de la
cultura de datos para garantizar la alineación y el consenso de los objetivos y las
prioridades.
＂ Establecer responsabilidades y expectativas: formalice la disposición con
responsabilidades documentadas para el rol de patrocinador ejecutivo. Asegúrese
de que no haya incertidumbre sobre las expectativas y los compromisos
temporales.
＂ Identifique un respaldo para el patrocinador: considere la posibilidad de nombrar
un patrocinador ejecutivo de respaldo. Este puede asistir a las reuniones en caso de
ausencia del patrocinador y tomar decisiones urgentes cuando sea necesario.
＂ Identifique a los defensores empresariales: encuentre defensores influyentes en
cada unidad de negocio. Determine cómo su cooperación y participación pueden
ayudarle a lograr sus objetivos. Considere la posibilidad de involucrar a defensores
de varios niveles en el organigrama.
Niveles de madurez
Los niveles de madurez siguientes le ayudarán a evaluar el estado actual del patrocinio
ejecutivo.
Level Estado del patrocinio ejecutivo de Power BI
100: Inicial Al menos un ejecutivo deber ser consciente de la importancia estratégica de

Power BI para el progreso de los objetivos de la cultura de los datos de la
organización. Sin embargo, no se ha identificado patrocinador de Power BI ni
responsable de la toma de decisiones de nivel ejecutivo.
200: Existe soporte ejecutivo informal para Power BI por medio de canales y relaciones
Repetible informales.
300: Se identifica un patrocinador ejecutivo. Las expectativas respecto al rol son claras.
Definido
400: Un patrocinador ejecutivo está bien establecido con alguien con autoridad
Competente suficiente en toda la organización.
Existe una asociación productiva y en buen estado entre el patrocinio de la

directiva, el COE, las unidades de negocio y TI. Los equipos trabajan para lograr los
objetivos de la cultura de datos compartidos.
500: El patrocinador ejecutivo está muy comprometido. Es un impulsor clave a la hora

Eficiente de fomentar la visión de la cultura de datos de la organización.
El patrocinador ejecutivo se implica en las mejoras de adopción continuas de la

organización. Los KPI (indicadores clave de rendimiento) o los OKR (objetivos y
resultados clave) se usan para realizar un seguimiento de los objetivos de la cultura
de datos y de los resultados de los esfuerzos de BI.
Pasos siguientes
Obtenga más información sobre la propiedad y la administración de contenido y su
efecto en la BI de autoservicio dirigida por la empresa, la BI de autoservicio
administrada y la BI empresarial en el siguiente artículo de la serie de la hoja de ruta de
propiedad y administración de
contenido
７ Nota
７ Nota
Los escenarios de uso de Planeamiento de implementación de Power BI exploran

muchos conceptos que se describen en este artículo. Los artículos sobre escenarios
de uso incluyen diagramas detallados que pueden resultar útiles para apoyar la
planeación y la toma de decisiones.
Hay tres estrategias principales para la propiedad y la administración del contenido de

inteligencia empresarial (BI): BI de autoservicio dirigida por la empresa, BI de
autoservicio administrada y BI empresarial. Para el objetivo de esta serie de artículos, el
término contenido se refiere a cualquier tipo de elemento de datos, como un informe o
un panel. Es sinónimo de solución.
La cultura de datos de la organización es la que determina por qué, cómo y por parte de
quién se implementa cada una de estas tres estrategias de propiedad del contenido.
Las áreas del diagrama anterior incluyen:

BI de autoservicio dirigida por la empresa: todo el contenido es propiedad de los

creadores y los expertos en la materia de una unidad de negocio y ellos son los que lo
administran. Esta estrategia de propiedad también se conoce como estrategia de BI
descentralizada o de abajo arriba.
BI de autoservicio administrada: los datos son propiedad de un equipo centralizado,

que es el que los administra, mientras que los usuarios empresariales asumen la
responsabilidad de los informes y paneles. Esta estrategia de propiedad también se
conoce como disciplina en el núcleo y flexibilidad en el borde.
BI empresarial: todo el contenido es propiedad de un equipo centralizado, como TI, BI

empresarial o el Centro de excelencia (COE), que son los que lo administran.
Es poco probable que una organización funcione con solo una estrategia de propiedad
y administración de contenido. Según la cultura de los datos, una estrategia puede ser
mucho más dominante que las demás. La elección de estrategia puede diferir entre una
solución y otra, o entre un equipo y otro. De hecho, un único equipo puede usar de
manera activa varias estrategias si es tanto consumidor de contenido de BI empresarial
como productor de su propio contenido de autoservicio. La estrategia que se debe
seguir depende de factores como:
Requisitos de una solución (por ejemplo, una colección de informes).

Aptitudes de los usuarios.
Compromiso continuo con el entrenamiento y el desarrollo de aptitudes.
Necesidad de flexibilidad.
Nivel de complejidad.
Prioridades y nivel de compromiso de la dirección.
La cultura de los datos de la organización, especialmente su postura con respecto a la

democratización de los datos, tiene una influencia considerable sobre la medida en que
se usan las tres estrategias de propiedad del contenido. Aunque hay patrones comunes
para el éxito, no hay un único enfoque adecuado para todos. El modelo de gobernanza
y el enfoque de la propiedad y la administración del contenido de cada organización
deben reflejar las diferencias en cuanto a orígenes de datos, aplicaciones y contexto
empresarial.
La forma en que se posee y se administra el contenido tiene un efecto considerable

sobre la gobernanza, la extensión de la mentoría y capacitación de los usuarios, las
necesidades de asistencia técnica de usuario y el modelo operativo del COE.
Como se explica en el artículo sobre gobernanza, el nivel de gobernanza y supervisión

depende de:
Quién posee y administra el contenido.
El ámbito de entrega del contenido.
El área de asunto de los datos y el nivel de confidencialidad.
La importancia de los datos.
En general:
El contenido de BI de autoservicio dirigida por la empresa está sujeto a los

controles de gobernanza y supervisión menos estrictos. A menudo incluye
soluciones de BI personal y BI para equipos.
El contenido de BI de autoservicio administrada está sujeto a controles de
gobernanza y supervisión moderadamente estrictos. Con frecuencia, incluye
soluciones de BI para equipos y BI para departamentos.
Las soluciones de BI para empresas están sujetas a controles de gobernanza y
supervisión más rigurosos.
Como se indica en el artículo sobre niveles de madurez de la adopción, la adopción de

la organización mide el estado de los procesos de administración de los datos y la
gobernanza. Las elecciones realizadas para la propiedad y la administración del
contenido afectan considerablemente a la forma en que se logra la adopción de la
organización.
Propiedad y administración
Hay muchos roles relacionados con la administración de datos. Los roles se pueden
definir de muchas maneras y se pueden malinterpretar fácilmente. En la tabla siguiente
se presentan posibles formas de definir conceptualmente estos roles:
Rol Descripción
Administrador Responsable de definir o administrar los niveles de calidad de datos aceptables,

de datos así como de la administración de datos maestros (MDM).
Experto en la Responsable de definir lo que significan los datos, para qué se usan, quién puede
materia (SME) acceder a ellos y cómo se presentan a otros usuarios. Colabora con el propietario
del dominio según sea necesario y ayuda a sus compañeros cuando estos usan
los datos.
Propietario Responsable de crear, mantener, publicar y proteger el acceso a los datos y a los
técnico elementos de informes.
Rol Descripción
Propietario Responsable de la toma de decisiones de nivel superior que colabora con los
del dominio equipos de gobernanza en las directivas, los procesos y los requisitos de
administración de los datos. Se ocupa de la toma de decisiones para definir los
usos adecuados e inadecuados de los datos. Participa en la junta de gobernanza
de datos, como se explica en el artículo sobre gobernanza.
La asignación de la propiedad de un dominio de datos tiende a ser más sencilla cuando

se administran sistemas de origen transaccionales. En las soluciones de BI se integran
datos de varias áreas de dominio que, luego, se transforman y se enriquecen. En el caso
de las soluciones analíticas de bajada, el tema de la propiedad se vuelve más complejo.
７ Nota
Sepa quién es el responsable de administrar los elementos de datos. Es

fundamental garantizar una buena experiencia para los consumidores de
contenido. En concreto, la claridad sobre la propiedad resulta útil para:
Saber con quién ponerse en contacto para hacer preguntas.

Comentarios.
Solicitudes de mejora.
Solicitudes de soporte técnico.
En el servicio Power BI, los propietarios de contenido pueden establecer la

propiedad lista de contactos de muchos tipos de elementos. La lista de contactos
también se usa en flujos de trabajo de seguridad. Por ejemplo, cuando se envía una
dirección URL a un usuario para que abra una aplicación, pero este no tiene
permiso, se le presenta una opción para realizar una solicitud de acceso.
Directrices para el éxito con la propiedad:
Defina cómo se usa la terminología de propiedad y administración en la

organización, incluidas las expectativas de estos roles.
Establezca contactos para cada área de trabajo y para elementos individuales para
comunicar la propiedad y/o las responsabilidades de soporte técnico.
Especifique entre dos y cuatro administradores de áreas de trabajo y realice una
auditoría periódica de estos (por ejemplo, dos veces al año). Es posible que los
administradores de áreas de trabajo sean directamente responsables de
administrar el contenido de un área de trabajo, o bien que esas tareas se asignen a
compañeros que realicen el trabajo práctico. En cualquier caso, los administradores
de áreas de trabajo deben poder ponerse en contacto fácilmente con los
propietarios de un contenido específico.
Incluya personalización de marca coherente en los informes para indicar quién ha
elaborado el contenido y con quién hay que ponerse en contacto para obtener
ayuda. Una pequeña imagen o etiqueta de texto en el pie de página del informe es
útil, especialmente si se exporta del servicio Power BI. Una plantilla estándar, como
se explica en el artículo sobre mentoría y capacitación de los usuarios, puede
fomentar y simplificar el uso coherente de la personalización de marca.
Use las revisiones de procedimientos recomendados del COE, que se tratan en el
artículo sobre el COE.
En el resto de este artículo se habla de las consideraciones relacionadas con las tres
estrategias de administración y propiedad del contenido.
BI de autoservicio dirigida por la empresa

En la BI de autoservicio dirigida por la empresa todo el contenido es propiedad de los
creadores y los expertos en la materia y ellos son los que lo administran. Dado que la
responsabilidad se mantiene dentro de una unidad de negocio, esta estrategia se suele
describir como un enfoque de abajo arriba o descentralizado. BI de autoservicio dirigida
por la empresa suele ser una buena estrategia para soluciones de BI personal y BI para
equipos.
） Importante
El concepto de BI de autoservicio dirigida por la empresa no equivale a TI en la

sombra. En ambos escenarios, los usuarios empresariales crean, poseen y
administran el contenido de BI. Pero la TI en la sombra implica que la unidad de
negocio está evitando a TI y, por tanto, la solución no está autorizada. Con las
soluciones de BI de autoservicio dirigida por la empresa, la unidad de negocio tiene
plena autoridad para crear y administrar el contenido. Los recursos y el soporte
técnico del COE están a disposición de los creadores de contenido de autoservicio.
Además se espera que la unidad de negocio cumpla todas las directivas y
directrices de gobernanza de datos establecidas.
La BI de autoservicio dirigida por la empresa es más adecuada si:
La administración de datos descentralizada es conforme con la cultura de los datos

de la organización y la organización está preparada para respaldar estos esfuerzos.
La exploración de datos y la libertad de innovar tienen una prioridad alta.
La unidad de negocio quiere tener la máxima implicación y conservar el máximo
nivel de control.
La unidad de negocio tiene personal cualificado capaz de prestar soporte a las
soluciones a lo largo de todo su ciclo de vida, y totalmente comprometido con
ello. Abarca todos los tipos de elementos de Power BI, incluidos los datos (flujos
de datos y conjuntos de datos), los objetos visuales (informes y paneles) y las
aplicaciones.
La flexibilidad de responder a las condiciones empresariales cambiantes y de
reaccionar rápidamente supera a la necesidad de una gobernanza y supervisión
más estrictas.
Directrices para el éxito con la BI de autoservicio dirigida por la empresa:
Enseñe a los creadores a usar las mismas técnicas que usaría TI, como los
conjuntos de datos compartidos y los flujos de datos. Un menor número de
conjuntos de datos duplicados reduce el mantenimiento, mejora la coherencia y
disminuye el riesgo.
Céntrese en proporcionar mentoría, entrenamiento, recursos y documentación
(como se describe en el artículo sobre mentoría y capacitación de los usuarios). La
importancia de estos esfuerzos no se puede pasar por alto. Esté preparado para
que los niveles de aptitudes de los creadores de contenido de autoservicio varíen
considerablemente. También es habitual que una solución ofrezca un valor
empresarial excelente, pero que se haya creado de forma que no se escale ni tenga
un buen desempeño con el tiempo (a medida que aumentan los volúmenes de
datos históricos). Resulta muy útil que el COE esté disponible para ayudar cuando
se planteen estas situaciones.
Proporcione instrucciones sobre la mejor manera de usar las aprobaciones. La
aprobación promocionada es para el contenido generado por los creadores de
autoservicio. Considere la posibilidad de reservar el uso de la aprobación
certificada para el contenido de BI empresarial y el contenido de BI de autoservicio
administrada (que se explican a continuación).
Analice el registro de actividad para detectar situaciones en las que el COE podría
ponerse en contacto proactivamente con los propietarios de autoservicio para
ofrecer información útil. Resulta especialmente útil cuando se detecta un patrón de
uso poco adecuado. Por ejemplo, la actividad de registro podría revelar un uso
excesivo del uso compartido de elementos individuales cuando los roles de una
aplicación o un área de trabajo pueden ser una mejor opción. Los datos del
registro de actividad permiten al COE ofrecer soporte técnico y consejos a las
unidades de negocio. A su vez, esta información puede ayudar a aumentar la
calidad de las soluciones, al tiempo que permite a la empresa conservar la
propiedad total y el control de su contenido.
BI de autoservicio administrada
La BI de autoservicio administrada es un enfoque mixto. Los datos son propiedad de un
equipo centralizado (como TI, BI empresarial o el COE) que los administra, mientras que
la responsabilidad de los informes y paneles pertenece a los creadores y expertos en la
materia de las unidades de negocio. BI de autoservicio administrada suele ser una
buena estrategia para las soluciones de BI para equipos y BI para departamentos.
Este enfoque se suele denominar disciplina en el núcleo y flexibilidad en el borde . Esto se

debe a que es un único equipo con un nivel adecuado de disciplina y rigor el que
mantiene la arquitectura de datos. Las unidades de negocio tienen la flexibilidad de
crear informes y paneles basados en datos centralizados. Este enfoque permite a los
creadores de informes ser mucho más eficaces, ya que pueden permanecer centrados
en ofrecer valor a partir de sus objetos visuales y análisis de datos.
La BI de autoservicio administrada es más adecuada si:
La administración de datos centralizada es conforme con la cultura de los datos de

la organización.
La organización tiene un equipo de expertos en BI que administran la arquitectura
de datos.
Tiene sentido la reutilización de datos por parte de muchos creadores de informes
de autoservicio entre límites de la organización.
Los creadores de informes de autoservicio deben generar contenido a un ritmo
más rápido de lo que lo hace el equipo centralizado.
Diferentes personas son responsables de controlar la preparación de datos, el
modelado de datos y la creación de informes.
Directrices para el éxito con la BI de autoservicio:
Enseñe a los usuarios a separar el desarrollo de modelos e informes. Pueden usar

conexiones dinámicas para crear informes basados en conjuntos de datos
existentes. Cuando el conjunto de datos se desacopla del informe, promueve la
reutilización de datos por parte de muchos informes y muchos autores. También
facilita la separación de tareas.
Use flujos de datos para centralizar la lógica de preparación de datos y para
compartir tablas de datos usados habitualmente (como fecha, cliente, producto o
ventas) con muchos creadores de conjuntos de datos. Perfeccione el flujo de datos
tanto como sea posible, con nombres de columna descriptivos y tipos de datos
correctos para reducir el esfuerzo de bajada de los autores de conjuntos de datos,
que consumen el flujo de datos como un origen. Los flujos de datos son una
manera eficaz de reducir el tiempo que conlleva la preparación de datos y de
mejorar la coherencia de los datos entre conjuntos de datos. El uso de flujos de
datos también reduce el número de actualizaciones de datos en los sistemas de
origen y permite que haya menos usuarios que necesiten acceso directo a los
sistemas de origen.
Si los creadores de autoservicio necesitan aumentar un conjunto de datos
existente con datos de departamento, edúquelos para que usen conexiones de
DirectQuery para conjuntos de datos de Power BI y Azure Analysis Services. Esta
característica permite un equilibrio ideal de la capacitación de autoservicio, al
tiempo que se aprovecha la inversión en recursos de datos que se administran de
forma centralizada.
Use la aprobación certificada para conjuntos de datos y flujos de datos a fin de
ayudar a los creadores de contenido a identificar orígenes de datos de confianza.
Incluya personalización de marca coherente en todos los informes para indicar
quién ha elaborado el contenido y con quién hay que ponerse en contacto para
obtener ayuda. La personalización de marca es especialmente útil para distinguir el
contenido generado por creadores de autoservicio. Una pequeña imagen o
etiqueta de texto en el pie de página del informe es útil si se exporta desde el
servicio Power BI.
Considere la posibilidad de implementar áreas de trabajo independientes para
almacenar datos e informes. Este enfoque ofrece una mayor claridad sobre quién
es responsable del contenido. También permite asignaciones de roles de área de
trabajo más restrictivas. De este modo, los creadores de informes solo pueden
publicar contenido en su área de trabajo de informes; además, los permisos de
conjunto de datos de lectura y compilación permiten a los creadores crear nuevos
informes con seguridad de nivel de fila (RLS) en vigor, cuando proceda.
Use las API de REST de Power BI para compilar un inventario de elementos de
Power BI. Analice la proporción entre conjuntos de datos e informes para evaluar
el alcance de la reutilización de conjuntos de datos.
BI empresarial
BI para empresas usa un enfoque centralizado en el que todo el contenido es propiedad
de un equipo centralizado que lo administra. Este equipo suele ser TI, BI empresarial o el
COE.
La BI empresarial es más adecuada si:
La centralización de la administración de contenido en un único equipo es

conforme con la cultura de los datos de la organización.
La organización tiene experiencia en BI para administrar todos los elementos de BI
de un extremo a otro.
Las necesidades de contenido de los consumidores están bien definidas y no es
necesario personalizar ni explorar los datos más allá de la solución de informes
que se entrega.
La propiedad del contenido y el acceso directo a los datos se deben limitar a un
número reducido de personas.
Los datos son altamente confidenciales o están sujetos a requisitos normativos.
Directrices para el éxito con la BI empresarial:
Implemente un proceso riguroso para usar la aprobación certificada para

conjuntos de datos, informes y aplicaciones. No es necesario certificar todo el
contenido de BI empresarial, pero sí buena parte, probablemente. El contenido
certificado debe indicar que se ha validado la calidad de los datos. El contenido
certificado también debe seguir las reglas de administración de cambios, contar
con soporte formal y estar totalmente documentado. Dado que el contenido
certificado ha superado rigurosos estándares, las expectativas de confiabilidad son
mayores.
Incluya personalización de marca coherente en todos los informes de BI
empresarial para indicar quién ha elaborado el contenido y con quién hay que
ponerse en contacto para obtener ayuda. Una pequeña imagen o etiqueta de texto
en el pie de página del informe es útil si se exporta desde el servicio Power BI.
Si usa la personalización de marca de informe específica para indicar contenido de
BI empresarial, tenga cuidado con la funcionalidad guardar una copia, que
permitiría a un usuario descargar una copia de un informe y personalizarla.
Aunque esta funcionalidad es una excelente manera de crear puentes entre la BI
empresarial y la BI de autoservicio administrada, diluye el valor de la
personalización de marca. Una solución menos problemática es proporcionar un
archivo de plantilla de Power BI Desktop independiente para los autores de
autoservicio. La plantilla define un punto de partida para la creación de informes
con una conexión dinámica a un conjunto de datos existente y no incluye
personalización de marca. El archivo de plantilla se puede compartir como un
vínculo dentro de una aplicación de Power BI o desde el sitio de la comunidad.
Transferencias de propiedad
A veces puede ser necesario transferir la propiedad de una solución determinada a otro
equipo. Se puede producir una transferencia de propiedad de una unidad de negocio a
un equipo centralizado si:
Un número considerable de personas usan una solución dirigida por la empresa, o

esta ahora admite decisiones empresariales críticas. En estos casos es un equipo
con procesos en vigor para implementar mayores niveles de gobernanza y soporte
técnico el que debe administrar la solución.
Una solución dirigida por la empresa es una candidata para usarse de forma
mucho más amplia en la organización, por lo que debe administrarla un equipo
que pueda establecer la seguridad e implementar el contenido de forma amplia en
Una unidad de negocio ya no tiene la experiencia, el presupuesto ni el tiempo
disponible para seguir administrando el contenido.
El tamaño o la complejidad de una solución ha aumentado hasta un punto en el
que se requiere una arquitectura de datos o un rediseño diferentes.
Hay una prueba de concepto lista para ponerse en marcha.
El COE debe tener procedimientos bien documentados para identificar si una solución
es candidata para la transferencia de propiedad. Resulta muy útil si el personal del
departamento de soporte técnico sabe qué buscar también. El contar con un patrón
personalizado para que los creadores de autoservicio compilen y desarrollen una
solución, y la entreguen en determinadas circunstancias, es un indicador de una cultura
de los datos productiva y correcta. Una transferencia de propiedad simple se puede
realizar durante el horario de oficina del COE; una transferencia más compleja puede
significar un proyecto pequeño administrado por el COE.
７ Nota
Existe la posibilidad de que el nuevo propietario tenga que realizar alguna

refactorización antes de poder asumir la propiedad completa. Es más probable que
la refactorización se produzca con los aspectos menos visibles de la preparación de
datos, el modelado de datos y los cálculos. Si hay pasos manuales u orígenes de
archivos planos, es el momento ideal para aplicar esas mejoras. Es posible que
también sea necesario cambiar la personalización de marca de los informes y
paneles, por ejemplo, si hay un pie de página que indica el contacto del informe o
una etiqueta de texto que indica que el contenido está certificado.
También es posible que un equipo centralizado transfiera la propiedad a una unidad de

negocio. Esto podría suceder si:
El equipo con conocimientos de dominio está mejor equipado para poseer y

administrar el contenido en el futuro.
El equipo centralizado ha creado la solución para una unidad de negocio que no
tiene las aptitudes necesarias para crearla desde cero, pero que puede mantenerla
y ampliarla en el futuro.
 Sugerencia
No olvide reconocer y recompensar el trabajo del creador original, especialmente si

las transferencias de propiedad son habituales.
Lista de comprobación: es una lista de consideraciones y acciones clave que puede

llevar a cabo para reforzar el enfoque de la propiedad y la administración de contenido.
＂ Obtención de una comprensión completa de lo que ocurre en la actualidad:

asegúrese de comprender profundamente cómo se produce la propiedad y la
administración del contenido en toda la organización. Reconozca que es probable
que no haya un enfoque adecuado para todos para su aplicación uniforme en toda
la organización. Revise los escenarios de uso de Planeamiento de implementación
de Power BI para comprender cómo se puede usar Power BI de diversas maneras.
＂ Realización de debates: determine qué funciona bien actualmente, qué no funciona
bien y cuál es el equilibrio deseado entre las tres estrategias de propiedad. Si es
necesario, programe conversaciones con personas concretas de varios equipos.
Desarrolle un plan para pasar del estado actual al deseado.
＂ Realización de una valoración: si el equipo de BI empresarial tiene desafíos
relacionados con la programación y las prioridades, realice una valoración para
determinar si se puede establecer una estrategia de BI de autoservicio administrada
para capacitar a más creadores de contenido en la organización. La BI de
autoservicio administrada puede ser muy eficaz a escala global.
＂ Clarificación de la terminología: aclare los términos usados en la organización para
propietario, administrador de datos y experto en la materia.
＂ Asignación de roles y responsabilidades claros: asegúrese de que los roles y
responsabilidades de los propietarios, administradores y expertos en la materia
están documentados y que todos los implicados los comprenden. Incluya al
personal de respaldo.
＂ Garantía de la participación de la comunidad: asegúrese de que todos los
propietarios de contenido, tanto de la empresa como de TI, forman parte de la
comunidad práctica.
＂ Creación de instrucciones de usuario para propietarios y contactos en Power BI:
determine cómo usará la característica de contactos en Power BI. Hable con los
creadores de contenido sobre cómo se debe usar y por qué es importante.
＂ Creación de un proceso para controlar las transferencias de propiedad: si las
transferencias de propiedad se producen de manera periódica, cree un proceso
para cómo funcionará.
＂ Soporte para los creadores de contenido avanzado: determine la estrategia de uso
de herramientas externas para las funciones de creación avanzadas y para una
mayor productividad.
Niveles de madurez
Los siguientes niveles de madurez le ayudarán a evaluar el estado actual de la

propiedad y la administración del contenido.
Level Estado de la propiedad y administración del contenido de Power BI
100: Inicial Los creadores de contenido de autoservicio poseen y administran contenido de

forma no controlada, sin una estrategia específica.
Existe una alta proporción de conjuntos de datos con los informes. Cuando
muchos conjuntos de datos solo admiten un informe, indica oportunidades para
mejorar la reutilización de los datos, mejorar la confiabilidad, reducir el
mantenimiento y el número de conjuntos de datos duplicados.
Las discrepancias entre distintos informes son habituales, lo que provoca

desconfianza en el contenido generado por otros.
200: Se ha aplicado un plan sobre qué estrategia de propiedad y administración del

Repetible contenido usar y en qué circunstancias.
Se han dado los primeros pasos para mejorar los niveles de coherencia y
confiabilidad de los esfuerzos de BI de autoservicio.
Hay instrucciones disponibles para la comunidad de usuarios que incluyen

expectativas del contenido de autoservicio frente al empresarial.
Los roles y las responsabilidades son claros y todos los implicados los
comprenden.
Level Estado de la propiedad y administración del contenido de Power BI
300: La BI de autoservicio administrada es una prioridad y un área de inversión para

Definido avanzar aún más en la cultura de los datos. La prioridad es dotar a los creadores de
informes de la flexibilidad que necesitan al usar orígenes de datos bien
administrados, seguros y de confianza.
La personalización de marca de los informes se usa de forma coherente para

indicar quién ha elaborado el contenido.
Existe un programa de mentoría para formar a los creadores de contenido de

autoservicio sobre cómo aplicar procedimientos recomendados y tomar buenas
decisiones.
400: Hay criterios definidos para alinear los requisitos de gobernanza con el contenido
Competente de autoservicio frente a empresarial.
Hay un plan en vigor sobre cómo solicitar y controlar las transferencias de

propiedad.
La BI de autoservicio administrada, y las técnicas para la reutilización de datos, se

usan normalmente y se comprenden bien.
500: Pasos proactivos para comunicarse con los usuarios cuando se detectan
Eficiente actividades sospechosas en el registro de actividad. La educación y la información
se proporcionan para realizar mejoras graduales o reducir el riesgo.
Creadores de contenido altamente cualificados usan herramientas de terceros para

mejorar la productividad y la eficacia.
Pasos siguientes
Puede obtener más información sobre el ámbito de la entrega de contenido en el
Ámbito de entrega de contenido
７ Nota
Los cuatro ámbitos de entrega que se describen en este artículo incluyen la inteligencia
empresarial personal, la inteligencia empresarial de equipo, la inteligencia empresarial
de departamento y la inteligencia empresarial corporativa. Como aclaración, centrarse
en el ámbito de una solución de BI entregada se refiere al número de personas que
pueden ver la solución, aunque el impacto es mucho mayor que eso. El ámbito influye
en gran medida en los procedimientos recomendados para la distribución de contenido,
el uso compartido, la seguridad y la protección de la información. El ámbito tiene una
correlación directa con el nivel de gobernanza (por ejemplo, los requisitos de
administración de cambios, el soporte técnico o la documentación), la extensión de la
mentoría y la habilitación de usuarios y las necesidades de soporte técnico del usuario.
También influye en las decisiones de licencias de usuario.
El artículo de administración y propiedad de contenido relacionado aborda temas

similares. Mientras que el enfoque de ese artículo estaba en el creador de contenido, el
enfoque de este artículo se centra en el uso del contenido de destino. Deben tenerse en
cuenta ambos aspectos interrelacionados para tomar decisiones de gobernanza y del
modelo operativo del Centro de excelencia (COE).
） Importante
No todos los datos y soluciones son iguales. Prepárese para aplicar diferentes
niveles de administración y gobernanza de datos a distintos equipos y a diversos
tipos de contenido. Las reglas estandarizadas son más fáciles de mantener, pero la
flexibilidad o la personalización suelen ser necesarias para aplicar el nivel adecuado
de supervisión en determinadas circunstancias. El patrocinador ejecutivo puede
resultar muy valioso para alcanzar el consenso entre los grupos de partes
interesadas cuando surgen situaciones difíciles.
El diagrama siguiente se centra en el número de consumidores de destino que
consumirán el contenido.
Los cuatro ámbitos de entrega de contenido que se muestran en el diagrama anterior

incluyen:
BI personal: las soluciones de BI personales están, como su nombre indica,

diseñadas para el uso del creador. Compartir contenido con otros usuarios no es
un objetivo. Por lo tanto, la BI personal tiene el menor número de consumidores
de destino.
BI para equipos: colabora y comparte contenido con un número de compañeros
relativamente pequeño que trabajan juntos.
BI de departamento: proporciona contenido a un gran número de consumidores,
que pueden pertenecer a un departamento o a una unidad de negocio.
BI empresarial: proporciona contenido ampliamente en toda la organización al
mayor número de consumidores de destino. El contenido empresarial se
administra con mayor frecuencia por un equipo centralizado y está sujeto a
requisitos de gobernanza adicionales.
Compare los cuatro ámbitos anteriores de entrega de contenido con el diagrama
siguiente, que tiene una relación inversa con respecto al número de creadores de
contenido.
Los cuatro ámbitos de los creadores de contenido que se muestran en el diagrama

anterior incluyen:
BI personal: representa el mayor número de creadores porque cualquier usuario

puede trabajar con datos mediante métodos de BI de autoservicio dirigidos por la
empresa. Aunque se pueden usar métodos de BI de autoservicio administrados, es
menos común con la BI personal.
BI para equipos: los compañeros de un equipo colaboran y comparten contenido
entre sí mediante patrones de la BI de autoservicio dirigidos por la empresa. Tiene
el segundo mayor número de creadores de la organización. Los patrones de BI de
autoservicio administrados también pueden empezar a surgir a medida que
evolucionan los niveles de aptitud.
BI de departamento: implica una cantidad más pequeña de creadores. Es probable
que sean usuarios avanzados que usan herramientas sofisticadas para crear
soluciones sofisticadas. Las prácticas de BI de autoservicio administradas son muy
comunes y muy recomendables.
BI empresarial: implica al menor número de creadores de contenido, ya que
normalmente solo incluye desarrolladores profesionales de BI que trabajan en el
equipo de BI, el COE o de TI.
En el artículo Administración y propiedad del contenido, se presentaron los conceptos

de BI de autoservicio dirigido por la empresa, BI de autoservicio administrado y BI
empresarial. La alineación más común entre la propiedad y el ámbito de entrega es:
Propiedad de BI de autoservicio dirigida por la empresa: normalmente se

implementan como soluciones de BI personales y para equipos.
Propiedad administrada de BI de autoservicio: se puede implementar como
soluciones de BI personales, de equipo o de departamento.
Propiedad de BI empresarial: se implementa como soluciones empresariales con
ámbito de BI.
Algunas organizaciones también equiparan el contenido de autoservicio con el soporte

técnico basado en la comunidad. Se da el caso cuando los creadores y propietarios de
contenido de autoservicio son responsables de proporcionar asistencia para el
contenido que publican. En el artículo de soporte técnico del usuario se describen varios
niveles informales y formales para el soporte técnico.
７ Nota
El término uso compartido se puede interpretar de dos maneras: a menudo se usa

de una manera general relacionada con el uso compartido de contenido con
compañeros, que podría implementarse de varias maneras. También puede hacer
referencia a una característica específica de Power BI, que es una implementación
específica en la que a un usuario o grupo se le concede acceso de solo lectura a un
único elemento. En este artículo, el término uso compartido se usa de forma general
para describir el uso compartido de contenido con los compañeros. Cuando se
pretenda hacer referencia a la característica de uso compartido por elemento, en
este artículo se especificará claramente dicha característica.
BI personal
La inteligencia empresarial personal trata sobre permitir que un individuo obtenga valor
analítico. También se trata de permitirles realizar tareas empresariales de forma más
eficaz mediante el uso personal eficiente de datos, información y análisis. Podría
aplicarse a cualquier tipo de trabajador de la información de la organización, no solo a
los analistas de datos y desarrolladores.
Compartir contenido con otros usuarios no es el objetivo. El contenido personal puede
residir en Power BI Desktop o en un área de trabajo personal del servicio de Power BI. Se
permite el uso del área de trabajo personal con la licencia de Power BI gratuita.
Características de la BI personal:
La intención principal del creador es la exploración y el análisis de datos, en lugar

de la entrega de informes.
El contenido está pensado para que lo analice y consuma una persona: el creador.
El contenido puede ser una prueba de concepto exploratoria que puede o no
evolucionar en un proyecto.
Directrices para el éxito con la BI personal:
Piense en las soluciones de BI personales como espacios aislados analíticos que

tienen poca gobernanza formal y supervisión por parte del equipo de gobernanza
o el COE. Sin embargo, sigue siendo adecuado informar a los creadores de
contenido de que se siguen aplicando ciertas directrices generales de gobernanza
al contenido personal. Entre las preguntas válidas que se deben hacer se incluyen:
¿Puede el creador exportar informes personales y enviarlos por correo electrónico
a otros usuarios? ¿Puede el creador almacenar informes personales en un portátil
o dispositivo que no es de la organización? ¿Cuáles son las limitaciones o los
requisitos para el contenido que contiene datos confidenciales?
Consulte las técnicas descritas para la BI de autoservicio dirigido por la empresa y
la BI de autoservicio administrado en el artículo sobre Propiedad y administración
de contenido. Son técnicas muy importantes que ayudan a los creadores de
contenido a crear soluciones de BI eficaces y personales.
Analice los datos del registro de actividad para detectar situaciones en las que
parece que las soluciones de BI personales se han expandido más allá del uso
previsto original. Normalmente se descubren detectando una cantidad significativa
de contenido compartido desde un área de trabajo personal.
 Sugerencia
Consulte el artículo niveles de madurez de la adopción para obtener más

información sobre cómo progresan los usuarios a lo largo de las fases de adopción.
Consulte el artículo supervisión del sistema para obtener información sobre el
seguimiento de uso mediante el registro de actividad.
BI para equipos
La inteligencia empresarial de equipo se centra en un equipo de personas que trabajan
juntas y que tienen la tarea de resolver problemas estrechamente relacionados usando
los mismos datos. La colaboración y el uso compartido de contenido entre sí en un área
de trabajo suele ser el objetivo principal. Debido a este estilo de trabajo, los miembros
del equipo normalmente tendrán una licencia de Power BI Pro o Power BI Premium por
usuario (PPU).
El contenido suele compartirse entre el equipo de forma más informal en comparación

con la BI de departamento o empresarial. Por ejemplo, el área de trabajo suele ser
suficiente para consumir contenido dentro de un equipo pequeño. No requiere la
formalidad de publicar el área de trabajo para distribuirla como una aplicación. No hay
un número específico de usuarios que determine cuándo la entrega basada en equipo
se considera demasiado informal; cada equipo debe encontrar el número correcto que
funcione para ellos.
Características de BI para equipos:
El contenido se crea, administra y visualiza dentro de un grupo de compañeros

que trabajan juntos.
La colaboración y la administración conjunta del contenido es la mayor prioridad.
Los visualizadores de informes pueden entregar informes formalmente
(especialmente los administradores del equipo), pero suele ser una prioridad
secundaria.
Los informes no siempre son muy sofisticados ni atractivos; la funcionalidad y el
acceso a la información es lo que más importa.
Directrices para el éxito con la BI para equipos:
Asegúrese de que el Centro de excelencia (COE) está preparado para respaldar los
esfuerzos de los creadores de autoservicio que publican contenido para su equipo.
Tome decisiones lógicas sobre cómo se controlará la administración del área de
trabajo. El área de trabajo es un lugar para organizar el contenido relacionado, el
límite de los permisos y el ámbito de las aplicaciones. Puede ser tentador empezar
con un área de trabajo por equipo, pero es posible que no sea lo suficientemente
flexible como para satisfacer todas las necesidades.
la BI de autoservicio administrado en el artículo propiedad y administración de
contenido. Son técnicas muy relevantes que ayudan a los creadores de contenido a
crear soluciones de BI para equipos eficaces y eficientes.
BI de departamento
El contenido se entrega a los miembros de un departamento o unidad de negocio. La
distribución de contenido a un mayor número de consumidores es una prioridad de la
inteligencia empresarial de departamento.
Normalmente hay un número mucho mayor de consumidores que son visualizadores de

contenido (en comparación con el número mucho menor de creadores de contenido).
Por lo tanto, se puede usar una combinación de licencias de Power BI Pro, Premium por
usuario o Capacidad Premium.
Características de la entrega de la BI de departamento:
Algunos creadores de contenido suelen publicar contenido para que los consuman
sus compañeros.
La entrega formal de informes y aplicaciones es una prioridad alta para garantizar
que los consumidores tengan la mejor experiencia.
Se realiza un esfuerzo adicional para ofrecer informes más sofisticados y pulidos.
También se espera que se sigan los procedimientos recomendados para la
preparación de datos y el modelado de datos de mayor calidad.
Las necesidades de administración de cambios y administración del ciclo de vida
de las aplicaciones (ALM) comienzan a surgir para garantizar la estabilidad de la
versión y una experiencia coherente para los consumidores.
Directrices para que la entrega de la BI de departamento se realice correctamente:
Asegúrese de que el COE está preparado para respaldar los esfuerzos de los
creadores de autoservicio. Los creadores que publican contenido usado en su
departamento o unidad de negocio pueden surgir como candidatos para
convertirse en campeones, o pueden convertirse en candidatos para unirse al COE
como miembros asociados.
Tome decisiones lógicas sobre cómo se controlará la administración del área de
trabajo. El área de trabajo es un lugar para organizar el contenido relacionado, el
límite de los permisos y el ámbito de las aplicaciones. Es probable que se necesiten
varias áreas de trabajo para satisfacer todas las necesidades de un departamento o
unidad de negocio de gran tamaño.
Planee cómo las aplicaciones de Power BI distribuirán contenido a la empresa. Las
aplicaciones pueden proporcionar una experiencia de usuario significativamente
mejor para consumir contenido. En muchos casos, a los consumidores de
contenido se les pueden conceder permisos para ver contenido solo mediante la
aplicación, reservando la administración de permisos del área de trabajo solo para
creadores y revisores de contenido. El uso de grupos de audiencia de aplicaciones
permite mezclar y combinar contenido y audiencia de destino de forma flexible.
Tenga claro qué validaciones de calidad de datos se han producido. Según
aumenta la importancia y el nivel de confidencialidad, también crecen las
expectativas de confiabilidad.
Asegúrese de que el entrenamiento, la mentoría y la documentación adecuados
estén disponibles para dar soporte a los creadores de contenido. Los
procedimientos recomendados para la preparación de datos, el modelado de
datos y la presentación de datos darán lugar a soluciones de mejor calidad.
Proporcione instrucciones sobre la mejor manera de usar la aprobación
promocionada y cuándo se puede permitir la aprobación certificada de las
soluciones de BI de departamento.
Asegúrese de que el propietario está identificado en todo el contenido de
departamento. La claridad sobre la propiedad del contenido es útil, incluido quién
es la persona con la que se debe contactar si se tienen preguntas, comentarios,
solicitudes de mejora o solicitudes de soporte técnico. En el servicio Power BI, los
propietarios de contenido pueden establecer la propiedad de la lista de contactos
para muchos tipos de elementos (como los informes y paneles). La lista de
contactos también se usa en flujos de trabajo de seguridad. Por ejemplo, cuando
se envía una dirección URL a un usuario para que abra una aplicación, pero este no
tiene permiso, se le presentará una opción para realizar una solicitud de acceso.
Considere la posibilidad de usar canalizaciones de implementación junto con áreas
de trabajo independientes. Las canalizaciones de implementación pueden admitir
entornos de desarrollo, prueba y producción que proporcionan más estabilidad a
los consumidores.
Considere la posibilidad de aplicar el uso de etiquetas de confidencialidad para
implementar la protección de la información en todo el contenido.
Incluya una personalización de marca coherente en los informes que coincida con
los colores y el estilo de los departamentos. También puede indicar quién produjo
el contenido. Para obtener más información, vea el artículo Propiedad y
administración de contenido. Una pequeña imagen o etiqueta de texto en el pie
de página del informe es útil si se exporta desde el servicio Power BI. Un archivo de
plantilla estándar de Power BI Desktop puede fomentar y simplificar el uso
coherente de la personalización de marca. Para obtener más información, consulte
el artículo Mentoría y habilitación del usuario.
la BI de autoservicio administrado en el artículo propiedad y administración de
contenido. Son técnicas muy relevantes que ayudan a los creadores de contenido a
crear soluciones de BI para departamentos eficaces y eficientes.
BI empresarial
El contenido de la inteligencia empresarial corporativa suele administrarlo un equipo
centralizado y está sujeto a requisitos de gobernanza adicionales. El contenido se
entrega ampliamente en toda la organización.
La BI empresarial suele tener un número significativamente mayor de consumidores en

comparación al número de creadores de contenido. Por lo tanto, se puede usar una
combinación de licencias de Power BI Pro, Premium por usuario o Capacidad Premium.
Características de entrega de la BI empresarial:
Un equipo centralizado de expertos en BI administra el contenido de un extremo a

otro y lo publica para que lo consuman otros usuarios.
La entrega formal de informes y aplicaciones es una prioridad alta para garantizar
que los consumidores tengan la mejor experiencia.
El contenido es muy confidencial, está sujeto a requisitos normativos o se
considera extremadamente crítico.
Los conjuntos de datos y flujos de datos de nivel empresarial publicados se
pueden usar como origen para creadores de autoservicio, lo que crea una cadena
de dependencias con los datos de origen.
La estabilidad y la experiencia coherente de los consumidores son muy
importantes. Normalmente se usa la administración del ciclo de vida de las
aplicaciones, como las canalizaciones de implementación y las técnicas de
DevOps . Los procesos de administración de cambios de revisión y aprobación
antes de la implementación se usan normalmente con el contenido de BI
empresarial, por ejemplo, por parte de un comité de revisión o un grupo similar.
Existen procesos para recopilar requisitos, priorizar esfuerzos y planear nuevos
proyectos o mejoras del contenido existente.
Pueden existir integraciones con otros servicios de administración y arquitectura
de datos a nivel empresarial, posiblemente con otros servicios de Azure y
productos de Power Platform.
Directrices para el éxito con la entrega de BI empresarial:
Las técnicas de gobernanza y supervisión descritas en el artículo Gobernanza son

importantes para administrar una solución de BI empresarial. Las técnicas incluyen
principalmente la administración de cambios y la administración del ciclo de vida
de las aplicaciones.
Planee cómo usar de forma eficaz las licencias Premium por usuario o de
Capacidad Premium para cada área de trabajo. Alinee la estrategia de
administración del área de trabajo, como por ejemplo de qué modo se organizarán
y protegerán las áreas de trabajo o cuáles son las estrategias de licencias
planeadas.
Planee cómo las aplicaciones de Power BI distribuirán contenido de BI empresarial.
Las aplicaciones pueden proporcionar una experiencia de usuario
significativamente mejor para consumir contenido. Alinee la estrategia de
distribución de aplicaciones con la estrategia de administración de áreas de
trabajo.
Considere la posibilidad de aplicar el uso de etiquetas de confidencialidad para
implementar la protección de la información en todo el contenido.
Implemente un proceso riguroso para usar la aprobación certificada de informes y
aplicaciones de BI empresarial. Los conjuntos de datos y los flujos de datos
también se pueden certificar cuando se espera que los creadores de autoservicio
compilen soluciones basadas en ellos. No es necesario certificar todo el contenido
de BI empresarial, pero sí buena parte, probablemente.
Haga que sea una práctica común anunciar cuándo se producirán los cambios.
Para obtener más información, consulte el artículo Comunidad práctica para
obtener una descripción de los tipos de comunicación.
Incluya una personalización de marca coherente en los informes que coincida con
los colores y el estilo de los departamentos. También puede indicar quién produjo
el contenido. Para obtener más información, vea el artículo Propiedad y
administración de contenido. Una pequeña imagen o etiqueta de texto en el pie
de página del informe es útil si se exporta desde el servicio Power BI. Un archivo de
plantilla estándar de Power BI Desktop puede fomentar y simplificar el uso
coherente de la personalización de marca. Para obtener más información, consulte
el artículo Mentoría y habilitación del usuario.
Use la vista de linaje para entender la dependencias, realizar análisis de impacto y
comunicarse con los propietarios de contenido de nivel inferior cuando se
produzcan cambios.
Consulte las técnicas descritas para BI empresarial en el artículo Propiedad y
administración de contenido. Son técnicas muy relevantes que ayudan a los
creadores de contenido a crear soluciones eficaces y eficientes para BI para la
empresa.
Consulte las técnicas descritas en el artículo supervisión del sistema para la
auditoría, la gobernanza y la supervisión del contenido de la BI empresarial.

Lista de comprobación: consideraciones y acciones clave que puede realizar para
reforzar el enfoque de entrega de contenido.
＂ Coincidencia de objetivos para entrega de contenido: asegúrese de que las

directrices, la documentación y otros recursos coincidan con los objetivos
estratégicos definidos para la adopción de Power BI.
＂ Aclaración de los ámbitos para la entrega de contenido en su organización:
determine a quién se aplica cada ámbito y cómo este se alinea con las decisiones
de gobernanza. Asegúrese de que las decisiones y las directrices sean coherentes
con el modo en que se controla la propiedad y administración de contenido.
＂ Consideración de excepciones: prepárese para controlar situaciones en las que un
equipo más pequeño quiera publicar contenido para un público de toda la
empresa.
¿Será necesario que el contenido sea propiedad y lo administre un equipo
centralizado? Para obtener más información, consulte el artículo sobre Propiedad
y administración del contenido, que describe un concepto interrelacionado con
el ámbito de entrega de contenido.
¿Habrá un proceso de aprobación? La gobernanza puede ser más complicada
cuando el ámbito de entrega de contenido es más amplio que el propietario del
contenido. Por ejemplo, cuando se distribuye una aplicación que es propiedad
de un equipo de ventas de división a toda la organización.
＂ Creación de documentación útil: asegúrese de tener suficiente documentación de
aprendizaje y soporte técnico para que los creadores de contenido comprendan
cuándo es adecuado usar áreas de trabajo, aplicaciones o uso compartido por
elemento (acceso directo o vínculo) .
＂ Creación de una estrategia de licencias asegúrese de que tiene una estrategia
específica para controlar las consideraciones de las licencias de usuario de Power BI
Pro, Premium por usuario y Capacidad Premium. Cree un proceso para saber cómo
se pueden asignar las áreas de trabajo a cada tipo de licencia y los requisitos
previos necesarios para el tipo de contenido que se puede asignar a Premium.
Niveles de madurez
Los niveles de madurez siguientes le ayudarán a evaluar el estado actual de la entrega

de contenido.
Level Estado de la entrega de contenido de Power BI

Level Estado de la entrega de contenido de Power BI
100: Inicial Los creadores de autoservicio publican el contenido para los consumidores de
forma no supervisada, sin una estrategia específica.
200: Existen demostraciones de buenas prácticas. Pero las buenas prácticas dependen
Repetible demasiado de los conocimientos, las aptitudes y los hábitos del creador del
contenido.
300: Se han definido y comunicado directrices claras para describir qué puede y no
Definido puede ocurrir dentro de cada ámbito de entrega. Estas directrices las siguen
algunos grupos de la organización, pero no todos.
400: Hay criterios definidos para alinear los requisitos de gobernanza con el contenido
Competente de autoservicio frente al empresarial.
La mayoría o todos los grupos de la organización siguen las directrices para el

ámbito de entrega de contenido.
Se han establecido requisitos de administración de cambios para aprobar los

cambios críticos en el contenido que se distribuye a un público de mayor tamaño.
Se han anunciado cambios y siguen un plan de comunicación. Los creadores de

contenido son conscientes de los efectos descendentes en su contenido. Los
consumidores saben cuándo se cambian los informes y las aplicaciones.
500: Pasos proactivos para comunicarse con los usuarios cuando se detectan
Eficiente actividades sospechosas en el registro de actividad. La educación y la información
se proporcionan para realizar mejoras graduales o reducir el riesgo.
El valor empresarial que se logra para las soluciones implementadas se evalúa

periódicamente.
Pasos siguientes
Puede obtener más información sobre el Centro de excelencia (COE) en el artículo
siguiente de la serie sobre la hoja de ruta de adopción de Power BI.
７ Nota
Un Centro de excelencia (COE) de Power BI es un equipo interno formado por expertos

técnicos y empresariales. El equipo ayuda activamente a otros usuarios de la
organización que trabajan con datos. El COE constituye el núcleo de toda la comunidad
para avanzar en los objetivos de adopción, que coinciden con la visión de la cultura de
datos.
Los COE también se denominan centro de competencia de la inteligencia empresarial (BI)

, centro de capacidades o centro de experiencia. Algunas organizaciones usan el término
escuadrón. Muchas organizaciones realizan las responsabilidades del COE dentro de su
equipo de BI o equipo de análisis.
７ Nota
Se recomienda tener un equipo de COE reconocido formalmente en el gráfico

organizativo, pero no es esencial. Lo más importante es que los roles y
responsabilidades del COE se identifiquen, prioricen y asignen. Es habitual que un
equipo centralizado de inteligencia empresarial o análisis asuma muchas de las
responsabilidades del COE. Algunas responsabilidades también puede asumirlas el
equipo de TI. Para simplificar, en esta serie de artículos, el término COE hace
referencia a un grupo específico de personas, aunque puede implementarlo de
forma diferente. También es muy común implementar el COE con un ámbito más
amplio que Power BI por sí solo: por ejemplo, un COE de Power Platform o un COE
de análisis.
Objetivos de un COE
Los objetivos de un COE incluyen:
Promover una cultura impulsada por datos.
Promover la adopción de Power BI.
Apoyar, formar, guiar y educar a los usuarios internos para mejorar sus aptitudes y
nivel de autosuficiencia.
Coordinar los esfuerzos y difundir el conocimiento en toda la organización.
Crear coherencia y transparencia para la comunidad de usuarios, lo que reduce la
fricción y los puntos débiles relacionados con la búsqueda de datos y contenido
de análisis importantes.
Maximizar las ventajas de la BI de autoservicio a la vez que se reducen los riesgos.
Reducir la deuda técnica al ayudar a tomar buenas decisiones que aumenten la
coherencia y resulten en menos ineficiencias.
） Importante
Uno de los aspectos más eficaces de un COE es la información entre

departamentos sobre cómo la organización usa Power BI. Esta información puede
revelar qué prácticas funcionan bien y cuáles no, lo que puede facilitar un enfoque
ascendente para la gobernanza. Un objetivo principal del COE es aprender qué
prácticas funcionan bien, compartir ese conocimiento de forma más amplia y
replicar los procedimientos recomendados en toda la organización.
Ámbito de las responsabilidades del COE

El ámbito de las responsabilidades del COE puede variar significativamente entre
organizaciones. En cierto modo, un COE puede considerarse un servicio de consultoría
porque sus miembros habitualmente proporcionan consejos expertos a otros usuarios.
En distintos grados, la mayoría de los COE también supervisan el trabajo práctico.
Entre las responsabilidades comunes del COE, se incluyen las siguientes:
Mentoría de la comunidad interna de Power BI. Para obtener más información,

consulte el artículo Comunidad práctica.
Producción, selección y promoción de materiales de entrenamiento. Para obtener
más información, consulte el artículo Mentoría y habilitación del usuario.
Creación de documentación y recursos para fomentar el uso coherente de
estándares y procedimientos recomendados. Para obtener más información,
consulte el artículo Mentoría y habilitación del usuario.
Aplicación, comunicación y asistencia con las directrices de gobernanza. Para
obtener más información, consulte el artículo Gobernanza.
Gestión y asistencia con la supervisión y administración del sistema. Para obtener
más información, consulte el artículo Supervisión del sistema.
Respuesta a problemas de soporte técnico que se han escalado desde el
departamento de soporte técnico. Para obtener más información, consulte el
artículo Soporte técnico para usuarios.
Desarrollo de soluciones o pruebas de concepto.
Establecimiento y mantenimiento de la plataforma de BI y la arquitectura de datos.
Dotación de un personal para un COE

Las personas que son buenas candidatas como miembros del COE tienden a ser las que:
Comprenden la visión de análisis de la organización.

Quieren mejorar continuamente los procedimientos de análisis de la organización.
Tienen un profundo interés y experiencia en Power BI.
Están interesados en que se utilice Power BI de forma efectiva y se adopte
correctamente en toda la organización.
Toman la iniciativa a la hora de aprender, adaptarse y crecer continuamente.
Comparten fácilmente sus conocimientos con otros usuarios.
Están interesados en los procesos repetibles, la normalización y la gobernanza
centrados en la habilitación del usuario.
Se centran en la colaboración con otros usuarios.
Se sienten cómodos trabajando con rapidez.
Tienen un interés inherente en participar y ayudar a otros.
Pueden convertir eficazmente las necesidades empresariales en soluciones.
Se comunican bien con compañeros técnicos y empresariales.
 Sugerencia
Si hay creadores de Power BI en su organización que traspasan constantemente los

límites de lo que se puede hacer, podrían ser excelentes candidatos para
convertirse en campeones reconocidos o quizás incluso en miembros del COE.
Al contratar personal para el COE, es importante tener una combinación de aptitudes

analíticas, aptitudes técnicas y aptitudes empresariales complementarias.
Roles y responsabilidades
A continuación, se enumeran roles muy generalizados dentro de un COE. Es habitual
que varias personas tengan roles que se superponen, lo que resulta útil desde una
perspectiva de sustitución del personal y entrenamiento cruzado. También es habitual
que la misma persona desempeñe varios roles. Por ejemplo, la mayoría de los miembros
del COE también sirven como asesores o mentores.
Rol Descripción
Líder del Administra las operaciones cotidianas del COE. Interactúa con el patrocinador
COE ejecutivo y otros equipos de la organización, como la junta de gobernanza de datos,
según sea necesario. Para obtener más información sobre los roles y
responsabilidades adicionales, consulte el artículo Gobernanza.
Asesor Entrena y forma a otros usuarios en las aptitudes de BI durante el horario de trabajo
(involucración de la comunidad), las revisiones de procedimientos recomendados o
los proyectos de desarrollo conjuntos. Supervisa y participa en el canal de discusión
de la comunidad interna. Interactúa y asiste a la red de campeones.
Formador Desarrolla, mantiene y entrega materiales de entrenamiento, documentación y

recursos internos.
Analista de Experto en la materia específica del campo. Actúa como intermediario entre el COE
datos y la unidad de negocio. Creador de contenido para la unidad de negocio. Ayuda con
la certificación de contenido. Trabaja en proyectos de desarrollo conjuntos y
pruebas de concepto.
Modelador Crea y administra conjuntos de datos y flujos de datos compartidos para asistir a los
de datos creadores de contenido de autoservicio.
Creador de Crea y publica informes y paneles.

informes
Ingeniero Planea la implementación y arquitectura de Power BI, incluida la integración con los
de datos servicios de Azure y otras plataformas de datos. Publica los recursos de datos que se
usan ampliamente en toda la organización.
Asistencia Ayuda con la resolución de discrepancias de datos y problemas de soporte técnico

técnica de del departamento de soporte técnico.
usuario
Como se mencionó anteriormente, el ámbito de las responsabilidades de los COE puede

variar significativamente entre organizaciones. Por lo tanto, los roles de los miembros
del COE también pueden variar.
Estructura de un COE
La estructura seleccionada para el COE puede variar entre organizaciones. También es
posible que existan varias estructuras dentro de una sola organización grande. Esto es
especialmente cierto cuando se han producido adquisiciones o existen subsidiarias.
７ Nota
Los términos siguientes pueden diferir de los definidos para su organización,

especialmente el significado de federado, que tiende a tener muchos significados
diferentes relacionados con la TI.
COE centralizado
Un COE centralizado se compone de un único equipo de servicios compartidos.
Ventajas:
Hay un solo punto de responsabilidad para un único equipo que administra los
estándares, los procedimientos recomendados y las entregas de un extremo a otro.
El COE es un grupo desde la perspectiva de un gráfico organizativo.
Es fácil empezar con este enfoque y, con el tiempo, evolucionar al modelo
unificado o federado.
Inconvenientes:
Los equipos centralizados pueden tener tendencias autoritarias que favorecen

decisiones universales que no siempre funcionan bien en todas las unidades de
negocio.
Puede haber una tendencia a preferir las aptitudes de Ti por encima de las
aptitudes empresariales.
Debido a su naturaleza centralizada, puede ser más difícil que los miembros del
COE comprendan lo suficiente las necesidades de todas las unidades de negocio.
COE unificado
Un COE unificado es un único equipo de servicios compartidos centralizado que se ha
ampliado para incluir miembros del equipo adicionales. Los miembros adicionales del
equipo se dedican a asistir un área funcional o unidad de negocio específicas.
Ventajas:
Hay un solo punto de responsabilidad para un único equipo que incluye la

participación multidisciplinaria de los miembros adicionales del equipo del COE.
Los miembros adicionales del equipo de COE se asignan a varias áreas de la
empresa.
El COE es un grupo desde la perspectiva de un gráfico organizativo.
El COE entiende las necesidades de las unidades de negocio más profundamente
debido a que cuenta con miembros dedicados con experiencia en el campo.
Inconvenientes:
Los miembros adicionales del equipo de COE, que están dedicados a una unidad
de negocio específica, tienen responsabilidades de un gráfico organizativo
diferente al de las personas a las que sirven directamente dentro de la unidad de
negocio. Esto puede provocar complicaciones, diferencias en las prioridades o
requerir la participación del patrocinador ejecutivo. Preferiblemente, el
patrocinador ejecutivo debería tener un ámbito de autoridad que incluya el COE y
todas las unidades de negocio implicadas para ayudar a resolver conflictos.
COE federado
Un COE federado consta de un equipo de servicios compartidos y de miembros
asociados de cada área funcional o unidad de negocio principal. Los equipos federados
trabajan de forma coordinada aunque sus miembros pertenezcan a diferentes unidades
de negocio. Normalmente, los miembros asociados se centran principalmente en las
actividades de desarrollo para asistir a su unidad de negocio, mientras que el personal
de servicios compartidos asiste a toda la comunidad.
Ventajas:
Los miembros asociados del COE representan su área funcional específica y tienen
experiencia en el campo, de modo que su participación es multidisciplinaria.
Hay un equilibrio entre la representación centralizada y descentralizada en los
miembros principales y asociados del COE.
Cuando existen situaciones de propiedad de datos distribuidos (como podría ser el
caso cuando las unidades de negocio asumen la responsabilidad directa de las
actividades de administración de datos), este modelo es efectivo.
Inconvenientes:
Dado que los miembros principales y asociados están repartidos por toda la
organización, el enfoque del COE federado requiere un liderazgo sólido, una
comunicación excelente, una administración firme de los proyectos y expectativas
muy claras.
Existe un mayor riesgo de encontrar prioridades contrapuestas debido a la
estructura federada.
Este enfoque suele implicar a personal a tiempo parcial o responsabilidades en
gráficos organizativos de línea punteada que pueden introducir presiones de
tiempo contrapuestas.
 Sugerencia
Algunas organizaciones tienen éxito mediante un programa de rotación. Implica

que los miembros federados del COE se unan al COE durante un período de
tiempo, como seis meses. Este tipo de programa permite a los miembros federados
aprender procedimientos recomendados y comprender más profundamente cómo
y por qué se hacen las cosas. Aunque el miembro federado todavía se centra en su
unidad de negocio específica, obtiene un conocimiento más profundo de los
desafíos de la organización. Esta comprensión más profunda da lugar a una
asociación más productiva a lo largo del tiempo.
COE descentralizado
Las unidades de negocio administran de forma independiente los COE descentralizados.
Ventajas:
Existe una cultura de datos especializada que se centra en la unidad de negocio, lo

que facilita el aprendizaje rápido y la adaptación.
Las directivas y prácticas se adaptan a cada unidad de negocio.
La agilidad, la flexibilidad y las prioridades se centran en la unidad de negocio
individual.
Inconvenientes:
Existe el riesgo de que los COE descentralizados funcionen de forma aislada. Como
resultado, es posible que no compartan los procedimientos recomendados y las
lecciones aprendidas fuera de su unidad de negocio.
La colaboración con un equipo centralizado puede ser informal o incoherente.
Las directivas incoherentes se crean y aplican entre unidades de negocio.
Es difícil escalar un modelo descentralizado.
Puede que sea necesaria una reformulación para hacer que las directivas de toda la
organización coincidan con uno o más COE descentralizados.
Las unidades de negocio más grandes con fondos significativos pueden tener más
recursos disponibles, lo que puede no cumplir los objetivos de optimización de
costos desde una perspectiva general de la organización.
） Importante
Un COE muy centralizado tiende a ser más autoritario, mientras que los COE
altamente descentralizados tienden a estar más aislados. Cada organización tendrá
que sopesar las ventajas y desventajas que se les aplican para determinar la mejor
opción. Para la mayoría de las organizaciones, el enfoque más eficaz tiende a ser el
unificado o federado, que une toda la organización.
Financiación del COE

El COE puede obtener su presupuesto operativo de varias maneras:
Centro de costos.
Centro de beneficios con presupuestos de proyectos.
Una combinación de centro de costos y centro de beneficios.
Cuando el COE funciona como un centro de costos, absorbe los costos operativos. Por
lo general, implica contar con un presupuesto anual aprobado. A veces, esto se
denomina modelo de interacción de imposición.
Cuando el COE funciona como centro de beneficios (al menos una parte de su
presupuesto), podría aceptar proyectos a lo largo del año en función de la financiación
del resto de unidades de negocio. A veces, esto se denomina modelo de interacción de
atracción.
La financiación es importante porque afecta a la forma en que el COE se comunica y se

involucra con la comunidad interna. A medida que el COE experimenta cada vez más
éxitos, es posible que reciban más solicitudes de ayuda de las unidades de negocio. Esto
sucede especialmente a medida que crece el conocimiento en toda la organización.
 Sugerencia
La elección del modelo de financiación puede determinar cómo el COE aumenta

activamente su influencia y capacidad de ayuda. El modelo de financiación también
puede tener un gran impacto en dónde reside la autoridad y cómo funciona la
toma de decisiones. Además, afecta a los tipos de servicios que puede ofrecer un
COE, como los proyectos de desarrollo conjuntos o las revisiones de
procedimientos recomendados. Para obtener más información, consulte el artículo
Mentoría y habilitación del usuario.
Algunas organizaciones cubren los costos operativos del COE («Center of Excelence»)
con contracargos a las unidades de negocio en función de las métricas de uso de
Power BI. Para la capacidad compartida de Power BI, esto puede basarse en el número
de usuarios activos. Para la capacidad Premium, los contracargos pueden asignarse en
función de qué unidades de negocio usan dicha capacidad. Idealmente, los
contracargos deben correlacionarse directamente con el valor empresarial obtenido.
Lista de comprobación: Consideraciones y acciones clave que puede realizar para

establecer o mejorar su COE de Power BI.
＂ Defina el ámbito de las responsabilidades del COE: asegúrese de que tiene claro
qué actividades puede admitir el COE. Una vez definido el ámbito de
responsabilidades, identifique las aptitudes y competencias necesarias para cumplir
esas responsabilidades.
＂ Identifique deficiencias en la capacidad para desempeñar su labor: analice si el
COE tiene los sistemas y la infraestructura necesarios para cumplir sus objetivos y
ámbito de responsabilidades.
＂ Determine la mejor estructura de COE: identifique qué estructura de COE es más
adecuada (centralizada, unificada, federada o descentralizada). Compruebe que el
personal, los roles y las responsabilidades y las relaciones adecuadas del gráfico
organizativo (informes de RR. HH.) son correctos.
＂ Planee el crecimiento futuro: Si va a empezar con un COE centralizado o
descentralizado, considere cómo va a escalar el COE con el tiempo con el enfoque
unificado o federado. Planee las acciones que pueda realizar ahora que facilitarán el
crecimiento futuro.
＂ Identifique los clientes: Identifique los clientes internos y los clientes externos a los
que asistirá el COE. Decida cómo el COE interactuará en general con esos clientes,
ya sea un modelo de imposición, un modelo de atracción o ambos.
＂ Compruebe el modelo de financiación para el COE: Decida si el COE es
simplemente un centro de costos con un presupuesto operativo, si funcionará
parcialmente como centro de beneficios o si se requerirán contracargos a otras
unidades de negocio.
＂ Cree un plan de comunicación: Cree una estrategia de comunicaciones para
informar a la comunidad de Power BI sobre los servicios que ofrece el COE y cómo
pueden interactuar con el COE.
＂ Cree objetivos y métricas: determine cómo medirá la eficacia del COE. Cree KPI
(indicadores clave de rendimiento) u OKR (objetivos y resultados clave) para validar
que el COE proporciona valor de forma coherente a la comunidad de usuarios.
Niveles de madurez
Los siguientes niveles de madurez le ayudarán a evaluar el estado actual del COE.
Level Estado del Centro de excelencia de Power BI
100: Inicial Existen uno o varios COE, o las actividades se realizan dentro del equipo de BI o de
TI. No están claros los objetivos específicos ni las expectativas de las
responsabilidades.
Las solicitudes de ayuda del COE se gestionan de forma no planeada.
200: El COE está establecido con estatutos específicos para orientar, guiar y educar a los
Repetible usuarios de autoservicio. El COE busca maximizar las ventajas de la BI de
autoservicio a la vez que se reducen los riesgos.
Los objetivos, el ámbito de las responsabilidades, el personal, la estructura y el

modelo de financiación se han establecido para el COE.
300: El COE funciona con la participación activa de todas las unidades de negocio en un
Definido modo unificado o federado.
400: Los objetivos del COE coinciden con los objetivos de la organización y se revisan
Competente periódicamente.
El COE es conocido en toda la organización y demuestra constantemente su valor

a la comunidad interna de usuarios.
500: Las revisiones periódicas de KPI o OKR evalúan la eficacia del COE de una manera
Eficiente medible.
La agilidad y la implementación de mejoras continuas a partir de las lecciones

aprendidas (como el escalado horizontal de los métodos que funcionan) son
prioridades principales para el COE.
Pasos siguientes
Puede obtener más información sobre la implementación de directrices, directivas y
procedimientos de gobernanza en el siguiente artículo de la serie de hoja de ruta de
Además, considere leer la información sobre el recorrido y la experiencia de Microsoft
en el impulso de culturas de datos. En este artículo se describe la importancia de la
disciplina en el núcleo y la flexibilidad en el borde. También expone los puntos de vista y
las experiencias de Microsoft sobre la importancia de establecer un COE.
Gobernanza
７ Nota
La gobernanza de datos es un tema amplio y complejo. En este artículo se presentan

conceptos y consideraciones clave. Se identifican las acciones importantes que se deben
realizar al adoptar Power BI, pero no es una referencia completa para la gobernanza de
datos.
Tal y como define el Data Governance Institute , la gobernanza de datos es "un sistema
de derechos y responsabilidades de decisión para los procesos relacionados con la
información, que se ejecuta según los modelos acordados que describen quién puede
realizar qué acciones, con qué información y cuándo, en qué circunstancias y mediante
qué métodos".
El término gobernanza de datos es un nombre poco apropiado. El enfoque principal para

la gobernanza no está en los propios datos. El enfoque es controlar lo que hacen los
usuarios con los datos. Dicho de otro modo: el verdadero objetivo es regir el
comportamiento de las personas para garantizar que los datos de la organización estén
bien administrados.
Cuando se centra en el autoservicio de inteligencia empresarial, el objetivo principal de

la gobernanza es conseguir el equilibrio adecuado de los siguientes elementos:
Capacitación del usuario: permita a la comunidad de usuarios internos ser

productivos y eficientes, dentro de los límites de protección necesarios.
Cumplimiento normativo: cumplir las regulaciones del sector, gubernamentales y
contractuales de la organización.
Requisitos internos: cumplir los requisitos internos de la organización.
El equilibrio óptimo entre control y capacitación variará en función de las

organizaciones. También es probable que difieran entre las diferentes unidades de
negocio dentro de una organización. Con una plataforma como Power BI, tendrá más
éxito cuando ponga tanto énfasis en la capacitación del usuario como en aclarar su uso
práctico dentro de los límites de protección establecidos.
 Sugerencia
Piense en la gobernanza como un conjunto de directrices establecidas y directivas

formalizadas. Todas las directivas y directrices de gobernanza deben coincidir con
la cultura de datos de la organización y los objetivos de adopción. La gobernanza
se ejecuta diariamente mediante las actividades de supervisión del sistema
(administración).
Estrategia de gobernanza
Al considerar utilizar la gobernanza de datos en cualquier organización, el mejor lugar
para empezar es definir una estrategia de gobernanza. Al centrarse primero en los
objetivos estratégicos de la gobernanza de datos, la estrategia puede informar de todas
las decisiones detalladas al implementar procesos y directivas de gobernanza. A su vez,
la estrategia de gobernanza se definirá mediante la cultura de datos de la organización.
Las decisiones de gobernanza se implementan con directrices, directivas y procesos

documentados. Los objetivos para la gobernanza de una plataforma de BI como
Power BI incluyen:
Capacitar a todos los usuarios de la organización para que usen datos y tomen
decisiones dentro de los límites definidos.
Mejorar la experiencia del usuario proporcionando instrucciones claras y
transparentes (con mínima fricción) sobre qué acciones se permiten, por qué y
cómo.
Asegurarse de que el uso de datos es adecuado para las necesidades de la
empresa.
Asegurarse de que las responsabilidades de propiedad y administración del
contenido son claras. Para obtener más información, vea el artículo Propiedad y
administración de contenido.
Mejorar la coherencia y la normalización del trabajo con datos mediante los límites
de la organización.
Reducir el riesgo de pérdida de datos y el uso indebido de los datos. Para obtener
más información, consulte el artículo protección de la información y prevención de
pérdida de datos.
Cumplir los requisitos normativos, del sector e internos para el uso adecuado de
los datos.
 Sugerencia
Una estrategia de gobernanza de datos bien ejecutada facilita que más usuarios
trabajen con datos. Cuando se aborda la gobernanza desde la perspectiva de la
capacitación del usuario, es más probable que los usuarios sigan los procesos
documentados. En consecuencia, los usuarios también se convierten en un
asociado de confianza.
Factores de éxito de la gobernanza

La gobernanza no es bien recibida cuando se establece mediante órdenes verticales que
se centran más en el control que en la capacitación. La gobernanza de Power BI tiene
más éxito cuando:
Se usa el modelo de gobernanza más ligero que logre los objetivos necesarios.
La gobernanza se aborda de forma iterativa y no interfiere significativamente con
la productividad.
Siempre que sea práctico, se usa un enfoque ascendente para formular directrices
de gobernanza. El centro de excelencia (COE) o el equipo de gobernanza de datos
observa comportamientos correctos que se producen dentro de una unidad
empresarial. A continuación, el COE realiza acciones para escalar horizontalmente a
otras áreas de la organización.
Las decisiones de gobernanza se definen de forma coexistida a partir de las
contribuciones de diferentes unidades de negocio antes de aplicarlas. Aunque hay
ocasiones en las que se necesita una directiva específica (especialmente en
sectores muy regulados), las órdenes deben ser la excepción en lugar de la regla.
Las necesidades de gobernanza están equilibradas con la flexibilidad y la
capacidad de ser productivas.
Los requisitos de gobernanza se pueden cumplir como parte del flujo de trabajo
normal de los usuarios, lo que facilita a los usuarios hacer lo correcto de manera
correcta y sencilla.
La respuesta a las nuevas solicitudes de datos no es "no" de forma
predeterminada, sino "sí y" con reglas claras, sencillas y transparentes sobre qué
requisitos de gobernanza corresponden al acceso de datos, al uso y al uso
compartido.
Los usuarios que necesitan acceso a los datos tienen incentivos para hacerlo
mediante canales normales, cumpliendo con los requisitos de gobernanza en lugar
de eludirlos.
Las decisiones de gobernanza, las directivas y los requisitos que deben seguir los
usuarios coinciden con los objetivos de la cultura de datos de la organización, así
como con otras iniciativas de gobernanza de datos existentes.
Las decisiones que afectan a lo que los usuarios pueden (y no pueden) hacer no las
toma únicamente un administrador del sistema.
Introducción de la gobernanza en la
organización
Hay tres métodos de control de tiempo principales que las organizaciones deben seguir
al introducir la gobernanza de Power BI en una organización.
Los métodos del diagrama anterior incluyen:
Método Estrategia seguida
Introducir Power BI primero y después la gobernanza: se pone Power BI a disposición

de los usuarios en la organización como nueva herramienta BI con características de
autoservicio. A continuación, en algún momento en el futuro, se inicia el esfuerzo de
gobernanza. Este método prioriza la agilidad.
Planear completamente la gobernanza y después implementar Power BI: se planea

de forma extensiva la gobernanza antes de permitir a los usuarios que empiecen a usar
Power BI. Este método prioriza el control y la estabilidad.
Planear de forma iterativa la gobernanza con implementaciones de Power BI en

fases: al principio, se planea ligeramente la gobernanza. A continuación, se implementa
Power BI de forma iterativa en fases mientras se producen mejoras de gobernanza
iterativas. Este método da igual prioridad a la agilidad y la gobernanza.
Elija el método 1 cuando ya se use Power BI en escenarios de autoservicio y esté listo

para trabajar de forma más eficaz.
Elija el método 2 cuando su organización ya tenga un enfoque bien establecido de
gobernanza que se pueda expandir fácilmente para incluir Power BI.
Elija el método 3 cuando desee tener un equilibrio de agilidad de control. Este enfoque
equilibrado es la mejor opción para la mayoría de las organizaciones y la mayoría de los
escenarios.
Método 1: Implementación de Power BI en primer lugar

El método 1 prioriza la agilidad y la velocidad. Permite a los usuarios empezar a crear
soluciones rápidamente. Este método se produce cuando se pone Power BI a
disposición de los usuarios en la organización como nueva herramienta BI con
características de autoservicio. Se logran resultados rápidos y algunos éxitos. En algún
momento del futuro, se inicia el esfuerzo de gobernanza, normalmente para llevar el
orden a un nivel inaceptable de caos, ya que los usuarios de autoservicio no han
recibido instrucciones suficientes.
Ventajas:
Lo más rápido para empezar

Los usuarios habilidosos pueden realizar las acciones rápidamente
Se logran buenos resultados rápidamente
Inconvenientes:
Requiere mayor esfuerzo para establecer la gobernanza una vez que se usa
Power BI con frecuencia en toda la organización
Los usuarios de autoservicio pueden oponerse cuando se les pida que cambien lo
que han estado haciendo
Los usuarios de autoservicio necesitan averiguar las cosas por sí mismos y usar su
mejor criterio
Consulte otras posibles desventajas en la sección Desafíos de gobernanza a

continuación.
Método 2: Planeamiento de gobernanza en profundidad

en primer lugar
El método 2 prioriza el control y la estabilidad. Se encuentra en el extremo opuesto del
espectro del método 1. El método 2 implica planear de forma extensa la gobernanza
antes de implementar Power BI. Es más probable que esta situación se produzca cuando
la implementación de Power BI está dirigida por TI. También es probable que se
produzca cuando la organización opera en un sector altamente regulado o cuando
existe una junta de gobernanza de datos que impone requisitos previos y requisitos
importantes.
Ventajas:
Más preparado para cumplir los requisitos normativos

Más preparado para dar soporte a la comunidad de usuarios
Inconvenientes:
Favorece el uso de BI empresarial más que el BI de autoservicio

Tarda más en permitir que los usuarios empiecen a obtener valor y a mejorar la
toma de decisiones
Fomenta hábitos deficientes y soluciones alternativas cuando hay un retraso
significativo al permitir el uso de datos para la toma de decisiones
Método 3: Gobernanza iterativa con implementaciones

El método 3 busca un equilibrio entre agilidad y gobernanza. Es un escenario ideal que
realiza el planeamiento suficiente por adelantado. Las mejoras de gobernanza frecuentes
y continuas se producen de forma iterativa con el tiempo junto con proyectos de
desarrollo de Power BI que proporcionan valor.
Ventajas:
Da la misma prioridad a la gobernanza y la productividad de los usuarios

Resalta la mentalidad de aprendizaje sobre la marcha
Fomenta las versiones iterativas para grupos de usuarios en fases
Inconvenientes:
Requiere un alto nivel de comunicación para tener éxito con prácticas de

gobernanza ágiles
Requiere una materia adicional para mantener actualizada la documentación y la
formación
La introducción de nuevas directivas y directrices de gobernanza con demasiada
frecuencia provoca un cierto nivel de interrupción del usuario
Para obtener más información sobre el planeamiento por adelantado, consulte el

artículo Preparación para migrar a Power BI.
Desafíos de gobernanza
Si su organización ha implementado Power BI sin un enfoque de gobernanza ni una
dirección estratégica (como se describió anteriormente en el método 1), podría haber
numerosos desafíos que requieren atención. Según el enfoque que haya adoptado y su
estado actual, algunos de los desafíos siguientes pueden ser aplicables a su
organización.
Desafíos de la estrategia
Falta de una estrategia de gobernanza de datos cohesiva que se alinee con la
estrategia empresarial
Falta de soporte ejecutivo para la regulación de datos, como un recurso
estratégico
Planificación de adopción insuficiente para avanzar en la adopción y el nivel de
madurez de BI y el análisis
Desafíos de las personas

Falta de prioridades alineadas entre equipos centralizados y unidades
empresariales
Falta de personas identificadas con conocimientos y entusiasmo suficientes en
todas las unidades empresariales para avanzar en los objetivos de adopción de la
organización
Falta de conocimiento de los procedimientos recomendados de autoservicio
Oposición a seguir las directivas y directrices de gobernanza recién introducidas
Esfuerzo duplicado invertido entre unidades empresariales
Falta de rendición de cuentas, responsabilidades y roles claros
Desafíos del proceso

Falta de procesos claramente definidos que da lugar a caos e incoherencias
Falta de normalización o repetibilidad
Capacidad insuficiente para comunicar y compartir las lecciones aprendidas
Falta de documentación y dependencia excesiva de los conocimientos tribales
Incapacidad de cumplir los requisitos de seguridad y privacidad
Desafíos de administración de datos y calidad de los

datos
Expansión de datos e informes
Datos inexactos, incompletos u obsoletos
Falta de confianza en los datos, especialmente para el contenido de autoservicio
Informes incoherentes generados sin validación de datos
Datos valiosos no utilizados o difíciles de acceder
Conjuntos de datos fragmentados, aislados y duplicados
Falta de catálogo, inventario, glosario o linaje de datos
Propiedad y administración de datos poco claras
Desafíos de conocimientos de aptitudes y datos

Distintos niveles de aptitud para interpretar, crear y comunicarse con los datos de
forma eficaz
Distintos niveles de conjuntos de aptitudes técnicas y brechas en las aptitudes
Falta de capacidad para administrar con confianza la diversidad y el volumen de
datos
Infravalorar el nivel de complejidad del desarrollo y la administración de soluciones
de BI a lo largo de todo su ciclo de vida
Breves períodos de tiempo con transferencias continuas y rotación de personal
Hacer frente a la velocidad de cambio de los servicios en la nube
 Sugerencia
Identificar los desafíos actuales, así como sus puntos fuertes, es esencial para
realizar un planeamiento adecuado de la gobernanza. No hay una única solución
sencilla a los desafíos enumerados anteriormente. Cada organización debe
encontrar el equilibrio y el enfoque adecuados que resuelvan los desafíos más
importantes para ellos. Los desafíos presentados anteriormente le ayudarán a
identificar cómo pueden afectar a su organización, de modo que pueda empezar a
pensar en la solución adecuada para sus circunstancias.
Planeamiento de la gobernanza
Algunas organizaciones han implementado Power BI sin un enfoque de gobernanza o
una dirección estratégica clara (como se ha descrito anteriormente en el método 1). En
este caso, el esfuerzo para comenzar la planificación de la gobernanza puede ser
abrumador.
Si actualmente no existe un cuerpo de gobernanza formal en su organización, el foco de

los esfuerzos de planeamiento e implementación de gobernanza será más amplio. Sin
embargo, si existe una junta de gobernanza de datos en la organización, su enfoque es
principalmente integrarlos con las prácticas existentes y personalizarlos para adaptarlos
a los objetivos de BI de autoservicio y BI empresarial.
） Importante
La gobernanza es una gran tarea y nunca está terminada del todo. La priorización e
iteración de las mejoras hará que el ámbito sea más fácil de administrar. Si realiza
un seguimiento de su progreso y sus logros cada semana y cada mes, se
sorprenderá con el impacto que puede llegar a tener a medida que progresa. Los
niveles de madurez al final de cada artículo de esta serie pueden ayudarle a
evaluar dónde está actualmente.
A continuación se describen algunas posibles actividades de planeamiento y resultados

de gobernanza que pueden resultar valiosos.
Estrategia
Actividades clave:
Evaluar el estado actual de la cultura de datos, la adopción y las prácticas de BI

Realizar una serie de sesiones de recopilación de información para definir el estado
futuro deseado, la visión estratégica, las prioridades y los objetivos de la cultura de
datos, la adopción y las prácticas de BI. Asegúrese de incluir los objetivos de
adopción de Power BI como se sugiere en la serie sobre el entorno de adopción de
Power BI . Son un enfoque útil si aún no tiene un método estructurado para la
recopilación de información.
Validar el foco y el ámbito del programa de gobernanza
Identificar las iniciativas ascendentes en curso
Identificar los puntos débiles, los problemas y los riesgos inmediatos
Instruir al equipo de dirección en la gobernanza y garantizar que el soporte
ejecutivo sea suficiente para mantener y hacer crecer el programa
Aclarar cómo Power BI se ajusta a la estrategia general de datos y análisis de la
organización
Evaluar factores internos, como la preparación de la organización, los niveles de
madurez y los desafíos clave
Evaluar factores externos como el riesgo, la exposición y los requisitos legales y
normativos, incluidas las diferencias regionales
Resultados clave:
Caso empresarial con análisis de costos y beneficios

Objetivos de gobernanza, enfoque y prioridades aprobados que estén en línea con
los objetivos empresariales de alto nivel
Planes para objetivos y prioridades a corto plazo. Estos genera resultados rápidos
Planes de objetivos y prioridades a largo plazo y diferidos
Criterios de éxito e indicadores clave de rendimiento (KPI) medibles
Riesgos conocidos documentados con un plan de mitigación
Planes para el cumplimiento de los requisitos normativos, gubernamentales,
contractuales y del sector que afectan a BI y al análisis de la organización
Plan de financiación
Personas
Actividades clave:
Establecer una junta de gobernanza e identificar las partes interesadas clave

Determinar el foco, el ámbito y el conjunto de responsabilidades de la junta de
gobernanza
Establecimiento de un COE
Determinar el foco, el ámbito y el conjunto de responsabilidades del COE
Definir los roles y las responsabilidades
Confirmar quién tiene autoridad para la toma de decisiones, la aprobación y el
veto
Resultados clave:
Estatutos de la junta de gobernanza

Estatutos del COE
Plan de personal
Matriz de responsabilidad y toma de decisiones
Plan de comunicación
Plan de administración de incidencias
Directivas y procesos.
Actividades clave:
Analizar los puntos débiles inmediatos, los problemas, los riesgos y las áreas para
mejorar la experiencia del usuario
Dar prioridad a las directivas de datos que se abordarán por orden de importancia
Identificar los procesos existentes que funcionan bien y se pueden formalizar
Determinar cómo se socializarán las nuevas directivas de datos
Decidir en qué medida las directivas de datos pueden diferir o personalizarse para
distintos grupos
Resultados clave:
Proceso de definición, aprobación, comunicación y mantenimiento de las directivas

de datos y la documentación
Plan para la solicitud de excepciones y salidas válidas de las directivas
documentadas
Administración de proyectos
La implementación del programa de gobernanza debe planearse y administrarse como
una serie de proyectos.
Actividades clave:
Establecer una escala de tiempo con prioridades e hitos

Identificar las iniciativas y dependencias relacionadas
Identificar y coordinarse con las iniciativas ascendentes existentes
Crear un plan de proyecto iterativo que se alinee con la priorización de alto nivel
Obtener la aprobación y la financiación del presupuesto
Establecer una manera tangible de realizar un seguimiento del progreso
Resultados clave:
Plan de proyecto con iteraciones, dependencias y secuenciación

Cadencia de retrospectivas centrada en las mejoras continuas
） Importante
El ámbito de las actividades enumeradas anteriormente que será útil asumir variará
considerablemente entre organizaciones. Si su organización no tiene procesos y
flujos de trabajo existentes para crear estos tipos de resultados, consulte las guías
del sector que se encuentran en el artículo Conclusión de la hoja de ruta para
obtener algunos recursos útiles.
Directivas de gobernanza
Criterios de decisión
Todas las decisiones de gobernanza deben estar alineadas con los objetivos
establecidos para la adopción de la organización. Una vez que la estrategia esté clara, se
tendrán que tomar decisiones de gobernanza más tácticas que afecten a las actividades
cotidianas de la comunidad de usuarios de autoservicio. Estos tipos de decisiones
tácticas se correlacionan directamente con las directivas de datos que se crean.
La forma en que se toman decisiones de gobernanza depende de:
¿Quién posee y administra el contenido de BI? En el artículo Administración y

propiedad del contenido, se presentaron tres tipos de estrategias: BI de
autoservicio dirigido por la empresa, BI de autoservicio administrado y BI
empresarial. Quién posee y administra el contenido tiene un impacto significativo
en los requisitos de gobernanza.
¿Cuál es el ámbito de entrega del contenido de BI? En el artículo Ámbito de
entrega de contenido se presentaron cuatro ámbitos para la entrega de contenido:
BI personal, BI de equipo, BI de departamento y BI empresarial. El ámbito de
entrega tiene un impacto considerable en los requisitos de gobernanza.
¿Cuál es el área de interés de los datos? Los propios datos, incluido su nivel de
confidencialidad, son un factor importante. Algunos dominios de datos requieren
controles más estrictos de forma inherente. Por ejemplo, la información de
identificación personal (PII) o los datos regulados por normativas deben estar
sujetos a requisitos de gobernanza más estrictos que los datos menos
confidenciales.
¿Se consideran críticos los datos o la solución de BI? Si no puede tomar una
decisión fundamentada fácilmente sin estos datos, está trabajando con elementos
de datos críticos. Algunos informes y aplicaciones pueden considerarse críticos
porque cumplen un conjunto de criterios predefinidos. Por ejemplo, si el contenido
se entrega a los ejecutivos. Los criterios predefinidos para lo que se considera
crítico ayudan a todos a tener expectativas claras. Los datos críticos suelen estar
sujetos a requisitos de gobernanza más estrictos.
 Sugerencia
Las distintas combinaciones de los cuatro criterios anteriores darán lugar a distintos
requisitos de gobernanza para el contenido de Power BI.
Decisiones clave de la gobernanza de Power BI

A medida que explore sus metas y objetivos y tome decisiones de gobernanza de datos
más tácticas como se ha descrito anteriormente, será importante determinar cuáles son
las prioridades más altas. Decidir dónde centrar los esfuerzos puede ser complicado.
En la siguiente lista se incluyen los elementos que puede optar por priorizar al introducir
la gobernanza para Power BI.
Recomendaciones y requisitos para la administración y propiedad del contenido

Recomendaciones y requisitos del ámbito de entrega del contenido
Recomendaciones y requisitos para la distribución y el uso compartido de
contenido con compañeros de trabajo, así como para usuarios externos como
clientes, asociados o proveedores
Cómo se permite a los usuarios trabajar con datos regulados y datos altamente
confidenciales
Uso permitido de orígenes de datos no verificados que so desconocidos para TI
Cuando se mantienen de forma manual, se permiten los orígenes de datos, como
Excel o archivos planos
Cómo administrar áreas de trabajo de forma eficaz
Quién puede ser un administrador de Power BI
Requisitos de seguridad, privacidad y protección de datos y acciones permitidas
para conjuntos de datos asignados a cada etiqueta de confidencialidad
Uso permitido o fomentado de puertas de enlace personales
Uso permitido o fomentado de la compra de autoservicio de licencias de usuario
Requisitos para quién puede certificar los conjuntos de datos, así como requisitos
que deben cumplirse
Administración del ciclo de vida de las aplicaciones para administrar el contenido
durante todo su ciclo de vida, incluidas las fases de desarrollo, prueba y
producción
Requisitos adicionales aplicables al contenido crítico, como las comprobaciones de
calidad de los datos y la documentación
Requisitos para usar datos maestros estandarizados y definiciones de datos
comunes para mejorar la coherencia entre conjuntos de datos e informes
Recomendaciones y requisitos para el uso de herramientas externas por creadores
de contenido avanzado
Si no toma decisiones de gobernanza y las comunica bien, los usuarios usarán su propio
criterio sobre cómo deben funcionar las cosas, lo que a menudo da lugar a enfoques
incoherentes en las tareas comunes.
Aunque no todas las decisiones de gobernanza deben tomarse por adelantado, es

importante que identifique las áreas de mayor riesgo en su organización. Después,
implemente gradualmente las directivas y los procesos de gobernanza que tengan
mayor impacto.
Directivas de datos
Una directiva de datos es un documento que define lo que los usuarios pueden y no
pueden hacer. Puede llamarlo por otro nombre, pero el objetivo sigue siendo el mismo:
cuando se toman decisiones, como las que se han analizado en la sección anterior, la
comunidad de usuarios las documenta para su uso y referencia.
Una directiva de datos debe ser lo más corta posible. De este modo, es fácil que los
usuarios entiendan lo que se les pide.
Una directiva de datos debe incluir:
Nombre, propósito, descripción y detalles de la directiva

Responsabilidades específicas
Ámbito de la directiva (en toda la organización o específico del departamento)
Público al que se dirige la directiva
Propietario, aprobador y persona de contacto de la directiva
Cómo solicitar una excepción
Cómo se auditará y aplicará la directiva
Requisitos legales o normativos que cumple la directiva
Referencias a definiciones de terminología
Referencias a las directrices o directivas relacionadas
Fecha de vigencia, última fecha de revisión y registro de cambios
７ Nota
Busque o vincule las directivas de datos desde el portal centralizado.
Estos son tres ejemplos comunes de directivas de datos que puede optar por priorizar:
Directiva Descripción
Directiva de Especifica cuándo se requiere un propietario para un conjunto de datos y cuáles

propiedad son las responsabilidades del propietario, por ejemplo: ayudar a compañeros que
de datos ven el contenido, mantener la confidencialidad y seguridad adecuadas y garantizar
el cumplimiento.
Directiva de Especifica el proceso que se sigue para certificar un conjunto de datos. Los
certificación requisitos pueden incluir actividades como: validación de la precisión de datos,
de datos revisión del origen de datos y linaje, revisión técnica del modelo de datos, revisión
(aprobación) de seguridad y revisión de documentación.
Directiva Descripción
Directiva de Especifica las actividades permitidas y no permitidas por clasificación (nivel de

clasificación confidencialidad). Debe especificar actividades como: uso compartido permitido
y protección con usuarios externos (con o sin acuerdo de confidencialidad), requisitos de
de datos cifrado y capacidad para descargar el conjunto de datos. A veces, también se
denomina directiva de control de datos o directiva de uso de datos. Para más
información, consulte el artículo Protección de la información para Power BI.
Ｕ Precaución
Tener una gran cantidad de documentación puede dar lugar a una falsa sensación
de que todo está bajo control, lo que puede conducir a la autocomplacencia. El
nivel de compromiso que el COE tiene con la comunidad de usuarios es una
manera de mejorar las posibilidades de que se sigan las directrices y las directivas
de gobernanza. Las actividades de auditoría y supervisión también son importantes.
Ámbito de las directivas

Las decisiones de gobernanza rara vez serán universales para toda la organización.
Cuando sea práctico, es aconsejable empezar con directivas estandarizadas y, a
continuación, implementar excepciones según sea necesario. Tener una estrategia
claramente definida sobre cómo se controlarán las directivas para los equipos
centralizados y descentralizados hará que sea mucho más fácil determinar cómo
controlar las excepciones.
Ventajas de las directivas para toda la organización:
Mucho más fáciles de administrar y mantener

Mayor coherencia
Abarcan más casos de uso
Menos directivas en general
Inconvenientes de las directivas para toda la organización:
Inflexible
Menos autonomía y capacitación
Ventajas de las directivas de departamento:
Las expectativas son más claras cuando se adaptan a un grupo específico

Personalizables y flexibles
Inconvenientes de las directivas de departamento:
Más trabajo que administrar

Más directivas que están en silos
Posibilidad de que la información sea conflictiva
Difícil de escalar de forma más amplia en toda la organización
 Sugerencia
Encontrar el equilibrio adecuado entre la normalización y la personalización para

admitir BI de autoservicio en toda la organización puede ser un desafío. Sin
embargo, al empezar con las directivas de la organización y observar con atención
las excepciones, puede realizar un progreso significativo rápidamente.
Personal y responsabilidad
La estructura organizativa para la gobernanza de datos varía significativamente entre
organizaciones. En organizaciones más grandes puede haber una oficina de gobernanza
de datos con personal dedicado. Algunas organizaciones tienen un comité de
gobernanza de datos, un consejo o un comité directivo con miembros asignados
procedentes de diferentes unidades de negocio. En función de la extensión del cuerpo
de gobernanza de datos dentro de la organización, puede haber un equipo ejecutivo
independiente de un equipo funcional de personas.
） Importante
Independientemente de cómo se estructure el cuerpo de gobernanza, es

importante que haya una persona o grupo con suficiente influencia sobre las
decisiones de gobernanza de datos. Esta persona debe tener autoridad para aplicar
esas decisiones considerando los límites de la organización.
Comprobaciones y balances
La responsabilidad de gobernanza está relacionada con las comprobaciones y los
balances.
Empezando por la parte inferior, los niveles del diagrama anterior incluyen:
Level Descripción
Operativo - Unidades empresariales: el nivel 1 es la base de un sistema bien regulado,

que incluye a las personas dentro de las unidades empresariales que realizan su trabajo.
Los creadores de BI de autoservicio tienen una gran responsabilidad relacionada con la
creación, publicación, uso compartido, seguridad y calidad de los datos. Los
consumidores de BI de autoservicio también tienen responsabilidades relacionadas con el
uso adecuado de los datos.
Táctico. Equipos de soporte: el nivel 2 incluye varios grupos que dan asistencia a los
esfuerzos de los usuarios de las unidades de negocio. Los equipos de soporte incluyen el
COE, el BI empresarial y la oficina de gobernanza de datos, así como otros equipos
auxiliares. Los equipos auxiliares pueden incluir el departamento de TI, seguridad, RR. HH.
y legal. También se incluye una placa de control de cambios aquí.
Táctico - Auditoría y cumplimiento: el nivel 3 incluye los equipos de auditoría interna,

administración de riesgos y cumplimiento. Estos equipos proporcionan instrucciones para
los niveles 1 y 2. También garantizan el cumplimiento cuando es necesario.
Estratégico. Patrocinador ejecutivo y comité directivo: el nivel más alto incluye la

supervisión a nivel ejecutivo de la estrategia y las prioridades. Este nivel controla los
problemas escalados que no se pudieron resolver en niveles inferiores. Por lo tanto, es
importante contar con personas con autoridad suficiente para poder tomar decisiones
cuando sea necesario.
） Importante
Todos los usuarios tienen la responsabilidad de cumplir las directivas para
garantizar que los datos de la organización están seguros, protegidos y bien
administrados como un recurso organizativo. A veces, este concepto se denomina
todas las personas son administradores de datos. Para que esto sea una realidad,
comience con los usuarios de las unidades empresariales (nivel 1 descrito
anteriormente) como base.
Una vez tenga una idea sobre su estrategia de gobernanza, se deben definir roles y
responsabilidades para establecer expectativas claras.
La estructura del equipo de gobernanza, los roles (incluida la terminología) y las

responsabilidades varían ampliamente entre las organizaciones. Los roles muy
generalizados se describen en la siguiente tabla. En algunos casos, la misma persona
puede cumplir varios roles. Por ejemplo, el director de datos (CDO) también puede ser
el patrocinador ejecutivo.
Rol Descripción
Director de Define la estrategia para el uso de datos como recursos empresariales.

datos o director Supervisa las directivas y directrices de gobernanza de toda la empresa.
de análisis
Junta de Comité directivo con miembros de cada unidad de negocio que, como
gobernanza de propietarios de dominios, están capacitados para tomar decisiones sobre la
datos gobernanza empresarial. Toman decisiones en nombre de su unidad de
negocio y teniendo en cuenta los intereses de la organización. Proporciona
aprobaciones, decisiones, prioridades e indicaciones al equipo de gobernanza
de datos empresariales y a los comités de trabajo.
Equipo de Crea directivas estándares y procesos de gobernanza. Supervisa toda la

gobernanza de empresa y optimiza la integridad de los datos, la confiabilidad, la privacidad y
datos la facilidad de uso. Colabora con el COE para proporcionar formación sobre la
gobernanza, soporte técnico y orientación a propietarios de datos y creadores
de contenido.
Comités de Equipos temporales o permanentes que se centran en temas de gobernanza

trabajo de individuales, como la seguridad o la calidad de los datos.
gobernanza de
datos
Junta de control Coordina los requisitos, los procesos, las aprobaciones y la programación de
de cambios los procesos de administración de versiones con el objetivo de reducir el
riesgo y minimizar el impacto de los cambios en las aplicaciones críticas.
Rol Descripción
Oficina de Administra los proyectos de gobernanza individuales y el programa de

administración gobernanza de datos en curso.
de proyectos
Patrocinador Promueve la adopción y el uso correcto de Power BI. Garantiza activamente

ejecutivo de que las decisiones de Power BI estén alineadas de forma coherente con los
Power BI objetivos empresariales, los principios rectores y las directivas de acuerdo con
los límites de la organización. Para obtener más información, consulte el
artículo Patrocinio ejecutivo.
Centro de Impulsa a la comunidad de creadores y consumidores a promover el uso eficaz

excelencia de Power BI para la toma de decisiones. Proporciona coordinación entre
departamentos de Power BI para mejorar las prácticas, aumentar la coherencia
y reducir las ineficiencias. Para obtener más información, consulte el artículo
Centro de excelencia.
Campeones de Un subconjunto de creadores de contenido que se encuentran en las unidades

Power BI de negocio y ayudan a avanzar en la adopción de Power BI. Contribuyen al
crecimiento de la cultura de datos al promover el uso de procedimientos
recomendados y ayudar activamente a sus compañeros. Para obtener más
información, consulte el artículo Comunidad práctica.
Administradores Responsabilidades diarias de supervisión del sistema para respaldar los

de Power BI procesos internos, las herramientas y las personas. Controlan la supervisión, la
auditoría y la administración. Para obtener más información, consulte el
artículo Supervisión del sistema.
Tecnología de la Proporcionan asistencia ocasional a los administradores de Power BI con

información servicios relacionados, como Azure Active Directory, Microsoft 365, Teams,
SharePoint o OneDrive.
Administración Revisa y evalúa los riesgos de seguridad y el uso compartido de datos. Define
de riesgos estándares y directivas de datos éticos. Comunica los requisitos legales y
normativos.
Auditoría Auditoría del cumplimiento de los requisitos normativos e internos.

interna
Administrador Colabora con el comité de gobernanza o el COE para asegurarse de que los
de datos datos de la organización tienen niveles de calidad aceptables.
Todos los Se adhiere a las directivas para garantizar que los datos están seguros,
creadores y protegidos y bien administrados como un recurso organizativo.
consumidores
de BI
 Sugerencia
Asigne un nombre a una copia de seguridad para cada persona que tenga roles
clave, por ejemplo, a los miembros de la junta de gobernanza de datos. En su
ausencia, la persona que le sustituya puede asistir a las reuniones y tomar
decisiones sensibles al tiempo cuando sea necesario.
Lista de comprobación: consideraciones y acciones clave que puede tener en cuenta

para establecer o reforzar las iniciativas de gobernanza.
＂ Alinear los objetivos y los principios rectores: confirme que los objetivos de alto
nivel y los principios rectores de los objetivos de referencia cultural de datos están
claramente documentados y comunicados. Asegúrese de que existe alineación para
las nuevas directrices o directivas de gobernanza.
＂ Comprender lo que está ocurriendo: asegúrese de que tiene un conocimiento
profundo de cómo Power BI se usa actualmente para BI de autoservicio y BI
empresarial. Documente las oportunidades para realizar mejoras. Además,
documente los puntos fuertes y los procedimientos recomendados que serían útiles
para escalar horizontalmente en términos más amplios.
＂ Priorizar nuevas directrices y directivas de gobernanza: para priorizar qué nuevas
directrices o directivas crear, seleccione un punto débil importante, una necesidad
de prioridad alta o un riesgo conocido para un dominio de datos. Debe tener una
ventaja significativa y se debe poder lograr con un nivel de esfuerzo factible. Al
implementar las primeras directrices de gobernanza, elija algo que sea probable
que los usuarios admitan porque el cambio tiene un impacto bajo, o porque están
lo suficientemente motivados como para realizar un cambio.
＂ Crear una programación para revisar las directivas: determine la cadencia de la
frecuencia con la que se vuelven a evaluar las directivas de datos. Vuelve a evaluar y
ajustar cuando cambien las necesidades.
＂ Decidir cómo controlar excepciones: determine cómo se controlarán los conflictos,
los problemas y las solicitudes de excepciones de las directivas documentadas.
＂ Comprender los recursos de datos existentes:confirme que comprende qué
recursos de datos críticos existen. Cree un inventario de propiedad y linaje, si es
necesario. Tenga en cuenta que no puede gobernar lo que no conoce.
＂ Verificar el patrocinio ejecutivo: confirme que tiene soporte técnico y suficiente
atención por parte de su patrocinador ejecutivo, así como de los líderes de la
unidad empresarial.
＂ Preparar un plan de acción: incluya los siguientes elementos clave:
Prioridades iniciales: seleccione un único dominio de datos o una unidad
empresarial.
Escala de tiempo: trabaje en iteraciones el tiempo suficiente para lograr un
progreso significativo, pero lo suficientemente corto como para ajustarse
periódicamente.
Resultados rápidos: céntrese en el progreso tangible, táctico e incremental.
Métricas de éxito: cree métricas medibles para evaluar el progreso.
Niveles de madurez
Los siguientes niveles de madurez le ayudarán a evaluar el estado actual de las

iniciativas de gobernanza.
Level Estado de la gobernanza de Power BI
100: Inicial Debido a la falta de planeamiento de la gobernanza, las prácticas de buena

administración de datos y de gobernanza informales que se están llevando a cabo
dependen en exceso del criterio y el nivel de experiencia de las personas.
Se depende significativamente del conocimiento no documentado.
200: Algunas áreas de la organización han realizado un esfuerzo significativo para

Repetible estandarizar, mejorar y documentar sus prácticas de administración y gobernanza
de datos.
Existe un enfoque de gobernanza inicial. Se está realizando un progreso

incremental.
300: Una estrategia de gobernanza completa con enfoque, objetivos y prioridades se

Definido promulga y se comunica ampliamente.
Se implementan directivas y directrices de gobernanza específicas para las

principales prioridades (puntos débiles u oportunidades). Son seguidos de forma
activa y coherente por los usuarios.
Los roles y responsabilidades están claramente definidos y documentados.

Level Estado de la gobernanza de Power BI
400: Todas las prioridades de gobernanza de Power BI coinciden con los objetivos
Competente empresariales y de la organización. Los objetivos se vuelven a evaluar
periódicamente.
Los procesos existen para personalizar directivas para unidades empresariales

descentralizadas o para controlar excepciones válidas a las directivas de
gobernanza estándar.
Está claro dónde encaja Power BI en la estrategia general de BI de la organización.
El registro de actividad de Power BI y los datos de API se analizan de forma activa

para supervisar y auditar las actividades de Power BI. Se toman medidas proactivas
en función de los datos.
500: Las revisiones periódicas de KPI o OKR evalúan los objetivos de gobernanza
Efficient medibles. El progreso continuo iterativo es una prioridad.
La agilidad y la implementación de mejoras continuas a partir de las lecciones

aprendidas (como el escalado horizontal de los métodos que funcionan) son
prioridades principales para el COE.
El registro de actividad de Power BI y los datos de la API se utilizan de manera

activa para informar de los esfuerzos de adopción y gobernanza y mejorarlos.
Pasos siguientes
Puede obtener más información sobre la capacitación y la habilitación de usuarios en el
orientación y habilitación de usuarios
７ Nota
Un objetivo fundamental para los esfuerzos de adopción es permitir que los usuarios
logren todo lo que puedan dentro de los límites de protección establecidos por las
directivas y directrices de gobernanza. Por esta razón, el acto de orientar a los usuarios
es una de las responsabilidades más importantes del Centro de excelencia (COE) e
influye directamente en cómo se produce la adopción de usuarios. Para obtener más
información sobre la adopción de usuarios, consulte el artículo Niveles de madurez de la
Mentoría de aptitudes
La orientación y la ayuda a los usuarios de la comunidad de Power BI es más eficaz y se
puede realizar de diversas formas:
Office Hours
Proyectos de desarrollo conjunto
Revisiones de procedimientos recomendados
Soporte extendido
Office Hours
Las horas de trabajo son una forma de compromisos continuos de la comunidad
administrados por el COE. Como su nombre indica, las horas de trabajo son horas de
disponibilidad programadas periódicamente en las que los miembros de la comunidad
pueden interactuar con expertos del COE para recibir asistencia con una sobrecarga
mínima del proceso. Dado que las horas de trabajo están basadas en grupos, Power BI y
otros miembros de la comunidad también pueden contribuir para ayudar a resolver un
problema si un tema está en su área de especialización.
Las horas de trabajo son una actividad muy popular y productiva en muchas
organizaciones. Algunas organizaciones se refieren a ellas como horas de contribución o
incluso con un nombre divertido, como "horas de producir". El objetivo principal suele
ser obtener respuestas a las preguntas, solucionar problemas y eliminar los
bloqueadores. Las horas de trabajo también se pueden usar como una plataforma para
que la comunidad de usuarios comparta ideas, sugerencias e incluso quejas.
El COE publica los horarios de las horas de trabajo normales en las que uno o varios
miembros del COE están disponibles. Idealmente, las horas de trabajo se mantienen de
forma periódica y frecuente. Por ejemplo, podrían ser todos los martes y jueves.
Considere la posibilidad de ofrecer diferentes franjas horarias o de rotación si tiene
personal en todo el mundo.
 Sugerencia
Una opción es establecer horas de trabajo específicas cada semana. Pero las
personas podrían presentarse o no, por lo que esto puede acabar siendo ineficaz.
Como alternativa, considere la posibilidad de aprovechar Microsoft Bookings
para programar las horas de trabajo. Muestra los bloques de tiempo en los que
está disponible cada experto del COE; la integración con Outlook garantiza que la
disponibilidad esté actualizada.
Las horas de trabajo representan un enfoque de habilitación de los usuarios excelente

por los siguientes motivos:
Los creadores de contenido y el COE colaboran activamente para responder

preguntas y resolver problemas juntos.
El trabajo real se realiza mientras se aprende y se resuelven problemas.
Otros usuarios pueden observar, aprender y participar.
Los grupos individuales pueden dirigirse a una sala para grupos para resolver un
problema específico.
Las horas de trabajo también benefician al COE porque:
Son una excelente manera de que el COE identifique a personas con aptitudes
específicas que no conocía previamente.
El COE puede saber qué les está presentando dificultades a las personas de la
organización. Ayuda a informar sobre si se pueden necesitar recursos,
documentación o formación adicional.
 Sugerencia
Es habitual que surjan algunos problemas complicados durante las horas de trabajo
que no se pueden resolver rápidamente, como conseguir que funcione un cálculo
DAX complejo. Establezca expectativas claras sobre lo que se espera que se realice
en las horas de trabajo, y si hay algún compromiso de seguimiento.
Proyectos de desarrollo conjunto

Una manera en que el COE puede proporcionar servicios de mentoría es durante un
proyecto de desarrollo conjunto. Un proyecto de desarrollo conjunto es una forma de
asistencia que ofrece el COE, donde un usuario o una unidad de negocio aprovecha la
experiencia técnica del COE para resolver problemas empresariales con los datos. El
desarrollo conjunto implica que las partes interesadas de la unidad de negocio y el COE
trabajen en colaboración para crear una solución de BI con características de
autoservicio de alta calidad que las partes interesadas del negocio no podrían ofrecer de
forma independiente.
El objetivo del desarrollo conjunto es ayudar a la unidad de negocio a desarrollar

experiencia a lo largo del tiempo y, al mismo tiempo, proporcionar valor. Por ejemplo, el
equipo de ventas tiene una necesidad urgente de desarrollar un nuevo conjunto de
informes de comisiones, pero todavía no tiene los conocimientos necesarios para
completarlo por sí solo.
Un proyecto de desarrollo conjunto forma una asociación entre la unidad de negocio y

el COE. En este acuerdo, la unidad de negocio está totalmente invertida, profundamente
implicada y asume la propiedad del proyecto.
El tiempo de participación del COE se reduce con el tiempo hasta que la unidad de
negocio adquiere experiencia y se vuelve autosuficiente.
La participación activa que se muestra en el diagrama anterior cambia con el tiempo de
la siguiente manera:
Unidad de negocio: inicialmente, corresponde a un 50 %; después, aumenta hasta

el 75 %, y por último se sitúa entre el 98 % y el 100 %.
COE: inicialmente, corresponde a un 50 %; después, disminuye hasta el 25 %, y por
último se sitúa entre el 0 % y el 2 %.
Lo ideal es que el período para la reducción gradual de la participación se identifique

por adelantado en el proyecto. De este modo, tanto la unidad de negocio como el COE
pueden planear suficientemente la escala de tiempo y las necesidades de personal.
Los proyectos de desarrollo conjunto pueden ofrecer importantes ventajas a corto y

largo plazo. A corto plazo, la participación del COE a menudo puede dar lugar a una
solución mejor diseñada y de mejor rendimiento que sigue los procedimientos
recomendados y se ajusta a los estándares de la organización. A largo plazo, el
desarrollo conjunto ayuda a aumentar el conocimiento y las funcionalidades de las
partes interesadas de la empresa, lo que las hace más autosuficientes y más seguras
para ofrecer soluciones de BI de autoservicio de calidad en el futuro.
） Importante
Básicamente, un proyecto de desarrollo conjunto ayuda a los usuarios menos

experimentados a aprender cuál es la forma correcta de hacer las cosas. Reduce el
riesgo de que más adelante sea necesario refactorizar y aumenta la capacidad de
que una solución se escale y crezca con el tiempo.
Revisiones de procedimientos recomendados

El COE también puede ofrecer revisiones de procedimientos recomendados. Una revisión
de procedimientos recomendados puede ser muy útil para los creadores de contenido
que quieran validar su trabajo. También se conocen como servicios de consultoría,
tiempo de consultas internas o revisiones técnicas.
Durante una revisión, un experto del COE evalúa el contenido de autoservicio de

Power BI desarrollado por un miembro de la comunidad e identifica las áreas de riesgo
o las oportunidades de mejora. En la siguiente lista con viñetas se presentan algunos
ejemplos de cuándo podría ser beneficiosa una revisión de procedimientos
recomendados:
El equipo de ventas tiene una aplicación que pretende distribuir a miles de

usuarios en toda la organización. Puesto que la aplicación representa contenido de
alta prioridad distribuido a un público grande, les gustaría que se certificase. El
proceso estándar para certificar contenido incluye una revisión de procedimientos
recomendados.
Al equipo financiero le gustaría asignar un área de trabajo a la capacidad Premium.
Se requiere una revisión del contenido del área de trabajo para asegurarse de que
se han seguido unas prácticas de desarrollo sólidas. Este tipo de revisión es común
cuando la capacidad se comparte entre varias unidades de negocio. (Es posible
que no sea necesaria una revisión si la capacidad se asigna a una única unidad de
negocio).
El equipo de operaciones está creando una nueva solución que esperan que se
utilice habitualmente. Les gustaría solicitar una revisión de procedimientos
recomendados antes de pasar a las pruebas de aceptación del usuario (UAT) o
antes de enviar una solicitud a la junta de control de cambios.
Una revisión de procedimientos recomendados suele centrarse en el diseño del

conjunto de datos, aunque la revisión puede abarcar todos los tipos de elementos de
Power BI (flujos de datos, conjuntos de datos, informes o aplicaciones).
Antes de implementar el contenido en el servicio Power BI, una revisión de

procedimientos recomendados puede comprobar que:
Los orígenes de datos usados son adecuados y el plegado de consultas se invoca

siempre que sea posible.
Las opciones de modo de conectividad y modo de almacenamiento (por ejemplo,
los marcos de modelo de importación, conexión dinámica, DirectQuery o
compuesto) son adecuadas.
La ubicación de los orígenes de datos, como los archivos planos, y los archivos de
Power BI Desktop originales son adecuados (preferiblemente se almacenan en una
ubicación de copia de seguridad con control de versiones y seguridad adecuada,
como archivos de Teams o una biblioteca compartida de SharePoint).
Los pasos de preparación de datos son limpios, ordenados y eficaces.
Los conjuntos de datos están bien diseñados, son limpios y comprensibles (es muy
recomendable usar un diseño de esquema de estrella).
Las relaciones están correctamente configuradas.
Los cálculos DAX usan prácticas de codificación eficaces (especialmente si el
modelo de datos es grande).
El tamaño del conjunto de datos está dentro de un límite razonable y se aplican
técnicas de reducción de datos.
La seguridad de nivel de fila (RLS) aplica correctamente los permisos de datos.
Los datos son precisos y se han validado según los orígenes autoritativos.
Se usan definiciones y terminología comunes aprobadas.
Se siguen buenos procedimientos de visualización de datos , incluidos aquellos
que permitan la accesibilidad.
Una vez implementado el contenido en el servicio Power BI, la revisión de

procedimientos recomendados no tiene por qué estar completada todavía. En la
finalización del resto de la revisión también se pueden incluir los siguientes elementos:
El área de trabajo de destino es adecuada para el contenido.

Los roles de seguridad del área de trabajo son adecuados para el contenido.
El resto de los permisos (permisos de público de aplicación, permiso de
compilación, uso de la característica de uso compartido de elementos individuales)
están configurados correcta y adecuadamente.
Los contactos están identificados y correctamente correlacionados con los
propietarios del contenido.
Las etiquetas de confidencialidad están correctamente asignadas.
La aprobación del elemento de Power BI (certificada o promocionada) es
adecuada.
La actualización de datos está configurada correctamente, las notificaciones de
error incluyen a los usuarios adecuados y usan la puerta de enlace de datos
adecuada en modo estándar (si procede).
Se siguen todas las reglas de procedimientos recomendados y, preferiblemente,
se automatizan a través de una herramienta de la comunidad denominada
Analizador de procedimientos recomendados para lograr la máxima eficacia y
productividad.
Soporte extendido
De vez en cuando, el COE puede implicarse con problemas complejos que se han
escalado desde el servicio de asistencia. Para obtener más información, consulte el
artículo de soporte técnico para usuarios.
７ Nota
Ofrecer servicios de mentoría puede ser un cambio cultural para su organización.

Podría pasar que los usuarios no suelen pedir ayuda con una herramienta como
Excel, así que ¿por qué iban a hacerlo con Power BI? La respuesta radica en el
hecho de que Power BI es una herramienta muy eficaz, que proporciona
capacidades de preparación de datos y modelado de datos, además de la
visualización de datos. La complejidad de la herramienta implica de forma
inherente que hay una curva de aprendizaje significativa para llegar a dominarla.
Tener la capacidad de ayudar y habilitar a los usuarios puede mejorar
significativamente sus aptitudes y aumentar la calidad de sus soluciones, ya que
también reduce los riesgos.
Portal centralizado
Un único portal centralizado, o centro, es donde la comunidad de usuarios puede
encontrar lo siguiente:
Acceso al foro de preguntas y respuestas de la comunidad.

Anuncios de interés para la comunidad, como nuevas características y
actualizaciones del plan de lanzamiento.
Programaciones y vínculos de registro para horas de trabajo, sesiones de almuerzo
y aprendizaje, sesiones de aprendizaje y reuniones de grupos de usuarios.
Anuncios de cambios clave en conjuntos de datos y registro de cambios (si
procede).
Cómo solicitar ayuda o soporte técnico.
Materiales de aprendizaje.
Documentación, materiales de incorporación y preguntas más frecuentes (P+F).
Guía de gobernanza y enfoques recomendados por el COE.
Plantillas.
Grabaciones de sesiones de uso compartido de conocimientos.
Puntos de entrada para acceder a procesos administrados, como la adquisición de
licencias, las solicitudes de acceso y la configuración de puertas de enlace.
 Sugerencia
En general, solo entre el 10 % y el 20 % de la comunidad no podrán buscar

activamente información educativa y de aprendizaje. Estos tipos de usuarios
pueden evolucionar de forma natural para convertirse en expertos en Power BI.
Normalmente, todos los demás intentan realizar el trabajo lo más rápido posible
porque necesitan su tiempo, enfoque y energía para otra tarea. Por lo tanto, es
importante hacer que a los usuarios de la comunidad les sea fácil encontrar la
información.
El objetivo es dirigir de forma coherente a los usuarios de la comunidad al portal

centralizado para encontrar la información. Por tanto, le corresponde al COE asegurarse
de que la información que necesitan los usuarios está disponible en el portal
centralizado. Mantener actualizado el portal requiere disciplina cuando todo el mundo
está ocupado.
En organizaciones más grandes, puede ser difícil implementar un único portal
centralizado. Cuando la consolidación en un único portal no resulte práctica, un centro
que funcione de forma centralizada puede actuar como agregador, con vínculos a las
otras ubicaciones.
） Importante
Aunque es importante ahorrar tiempo en la búsqueda de información, el objetivo

de un portal centralizado va más allá. Se trata de hacer que la información esté
disponible fácilmente para ayudar a que la comunidad de usuarios haga lo
correcto. Deben poder encontrar la información durante un día normal de trabajo,
de la manera más sencilla posible. Hasta que sea más fácil completar una tarea
dentro de los límites de protección establecidos por el COE y el equipo de
gobernanza de datos, algunos usuarios seguirán haciéndolo eludiendo las
directivas que se establezcan. La ruta recomendada debe ser la que ofrezca menor
resistencia. Tener un portal centralizado puede ayudar a lograr este objetivo.
Lleva algún tiempo conseguir que los usuarios de la comunidad piensen en el portal
centralizado como su primera opción natural para buscar información. Es necesario un
redireccionamiento coherente al portal para cambiar los hábitos. El envío de un vínculo
a una ubicación de documento original en el portal genera mejores hábitos que, por
ejemplo, incluir la respuesta en una respuesta de correo electrónico. Es el mismo desafío
que se describe en el artículo de soporte técnico para usuarios.
Cursos
Un factor clave para habilitar correctamente a los usuarios de una comunidad de
Power BI es el aprendizaje. Es importante que estén disponibles los recursos de
aprendizaje adecuados y se puedan detectar fácilmente. Aunque algunos usuarios
muestran mucho entusiasmo por Power BI y buscarán información e investigarán las
cosas por sí mismos, esto no es así para la mayoría de la comunidad de usuarios.
Asegurarse de que los usuarios de la comunidad tienen acceso a los recursos de

aprendizaje que necesitan para conseguir buenos resultados no significa que necesite
desarrollar su propio material de aprendizaje. El desarrollo de material de aprendizaje
suele ser contraproducente debido a la naturaleza en constante evolución del producto.
Afortunadamente, hay una gran cantidad de recursos de aprendizaje disponibles en la
comunidad mundial. Un conjunto seleccionado de vínculos puede contribuir
considerablemente a ayudar a los usuarios a organizar y centrar sus esfuerzos de
aprendizaje, especialmente para el aprendizaje de herramientas, que se centra en la
tecnología. El COE debe validar todos los vínculos externos para que sean precisos y
confiables. Es una oportunidad clave para que el COE agregue valor, ya que las partes
interesadas del COE se encuentran en una posición ideal para comprender las
necesidades de aprendizaje de la comunidad y para identificar y localizar orígenes de
confianza de materiales de aprendizaje de calidad.
Encontrará la mayor rentabilidad de la inversión con la creación de materiales de

aprendizaje personalizados para procesos específicos de la organización, a la vez que se
basa en el contenido generado por otros para todo lo demás. También resulta útil tener
una clase de aprendizaje corta que se centre principalmente en temas como, por
ejemplo, cómo buscar documentación, obtener ayuda e interactuar con la comunidad.
 Sugerencia
Uno de los objetivos del aprendizaje es ayudar a los usuarios a aprender nuevas
aptitudes y, al mismo tiempo, ayudarles a evitar malos hábitos. Puede ser un acto
de equilibrio. Por ejemplo, no quiere sobrecargar a los usuarios agregando mucha
complejidad a una clase de nivel principiante para los creadores de informes. Pero
es una gran inversión hacer que los creadores de contenido más reciente conozcan
cosas que, de lo contrario, podrían tardar un tiempo en averiguar. Un ejemplo ideal
es enseñar la capacidad de usar una conexión dinámica para informar desde un
conjunto de datos existente. Al enseñar este concepto en el primer punto lógico,
puede evitar que un creador con menos experiencia piense que siempre necesita
un conjunto de datos para cada informe (y fomentar el buen hábito de volver a
usar los conjuntos de datos existentes en los informes).
Algunas organizaciones más grandes experimentan una rotación y transferencias

continuas de empleados. Este cambio frecuente provoca una mayor necesidad de un
conjunto repetible de recursos de aprendizaje.
Recursos y enfoques de aprendizaje

Hay muchos enfoques de aprendizaje porque los usuarios aprenden de maneras
diferentes. Si puede supervisar y medir el uso de los materiales de aprendizaje,
aprenderá con el tiempo qué funciona mejor. Es posible que parte del aprendizaje se
entregue de forma más formal, como el que se realiza en el aula con laboratorios
prácticos. Otros tipos de aprendizaje son menos formales, como por ejemplo:
Presentaciones de sesiones de almuerzo y aprendizaje

Vídeos de instrucciones cortos destinados a un objetivo específico
Conjunto mantenido de recursos en línea
Presentaciones de grupos de usuarios internos
Desafíos de una hora, una semana o un mes
Eventos de estilo hackatón
Las ventajas de fomentar el uso compartido de conocimientos entre compañeros se

describen en el artículo Comunidad práctica.
 Sugerencia
Siempre que sea práctico, el aprendizaje debe correlacionarse con la creación de

algo significativo y realista. Pero los datos de demostración simples tienen valor
durante un curso de aprendizaje. Permiten que un aprendiz se centre en cómo usar
la tecnología en lugar de en los propios datos. Después de completar las sesiones
de introducción, considere la posibilidad de ofrecer un tipo de sesión en la que los
participantes lleven sus propios datos. Estos tipos de sesiones animan al alumno a
aplicar sus nuevas aptitudes técnicas a un problema empresarial real. Intente incluir
varios moderadores del COE durante este tipo de sesión de seguimiento para que
las preguntas se puedan responder rápidamente.
Entre los tipos de usuarios a los que puede dirigirse para el aprendizaje, se incluyen los
siguientes:
Consumidores de contenido
Creadores de informes
Creadores de datos (conjuntos de datos y flujos de datos)
Propietarios de contenido, expertos en la materia y administradores de áreas de
trabajo
Miembros asociados del COE y red de expertos
Administradores de Power BI
） Importante
Cada tipo de usuario representa un público diferente que tiene diferentes

necesidades de aprendizaje. El COE deberá identificar la mejor manera de satisfacer
las necesidades de cada audiencia. Por ejemplo, una audiencia podría pensar que
una clase estándar de introducción de Power BI Desktop es abrumadora, mientras
que otra querrá información más compleja y detallada. Si tiene una gran variedad
de creadores de contenido de Power BI, considere la posibilidad de crear roles y
adaptar la experiencia a una medida que sea práctica.
La finalización del aprendizaje puede ser un indicador principal del éxito con la
adopción del usuario. Algunas organizaciones conceden distintivos, como una cinta azul
o una cinta negra a medida que los usuarios progresan por los programas de
aprendizaje.
Considere cómo quiere controlar a los usuarios en varias fases de la adopción del
usuario. El aprendizaje para incorporar nuevos usuarios (a veces denominado día de
aprendizaje cero) y para los usuarios con menos experiencia es muy diferente al
aprendizaje para los usuarios con más experiencia.
La forma en que el COE invierte su tiempo en la creación y la conservación de materiales

de aprendizaje cambiará con el tiempo a medida que crezcan la adopción y la madurez.
Con el tiempo, es posible que algunos miembros de la comunidad quieran ejecutar su
propio conjunto personalizado de clases de aprendizaje dentro de su unidad de negocio
funcional.
Orígenes del contenido de aprendizaje de Power BI de

confianza
Un conjunto seleccionado de recursos en línea es valioso para ayudar a los miembros de
la comunidad a centrarse y dirigir sus esfuerzos en lo que realmente importa. Entre los
recursos de aprendizaje disponibles públicamente que pueden resultar útiles se incluyen
los siguientes:
Aprendizaje de Microsoft Learn para Power BI

Cursos de Power BI y materiales de aprendizaje "de un día"
Aprendizaje de LinkedIn
Aprendizaje y talleres virtuales
Considere la posibilidad de usar Microsoft Viva Learning , que está integrado en

Microsoft Teams. Incluye contenido de orígenes como Microsoft Learn y LinkedIn
Learning . También se puede incluir contenido personalizado creado por su
organización.
Además del contenido de Microsoft y el contenido personalizado que cree su

organización, puede optar por proporcionar a la comunidad de usuarios un conjunto
seleccionado de vínculos recomendados a orígenes en línea de confianza. Hay una
amplia gama de vídeos, blogs y artículos creados por la comunidad mundial. La
comunidad está formada por expertos en Power BI, profesionales más valiosos (MVP) de
Microsoft y aficionados. Proporcionar una ruta de aprendizaje de calidad que
contenga recursos específicos, de confianza, actuales y de alta calidad proporcionará el
máximo valor a la comunidad de usuarios.
Si realiza la inversión para crear recursos de aprendizaje personalizados, considere la
posibilidad de crear contenido corto y dirigido que se centre en resolver un problema
específico. De esta manera se facilita la búsqueda y el consumo del aprendizaje.
También es más fácil de mantener y actualizar con el tiempo.
 Sugerencia
El menú Ayuda y soporte técnico del servicio Power BI es personalizable. Cuando

la ubicación centralizada para la documentación de aprendizaje esté operativa,
actualice la configuración del inquilino en el portal de administración con el
vínculo. Después, se podrá acceder al vínculo desde el menú cuando los usuarios
seleccionen la opción Obtener ayuda. Además, asegúrese de instruir a los usuarios
sobre la pestaña de la cinta de opciones Ayuda de Power BI Desktop. Esta incluye
vínculos a aprendizaje guiado, vídeos de aprendizaje, documentación y mucho más.
Documentación
La documentación concisa y bien escrita puede ser una ayuda importante para los
usuarios que intentan ser más productivos. La cantidad de documentación que necesite
y cómo se entrega dependerá de cómo se administre Power BI en su organización. Para
obtener más información, vea el artículo Propiedad y administración de contenido.
Ciertos aspectos de Power BI suelen administrarse a través de un equipo centralizado,

como el COE. En estos casos, son útiles los siguientes tipos de documentación:
Procedimiento para solicitar una licencia de Power BI (y si hay requisitos para la

aprobación del administrador)
Cómo solicitar una nueva capacidad Premium
Cómo solicitar una nueva área de trabajo
Cómo solicitar que se agregue un área de trabajo a una capacidad Premium
Cómo solicitar acceso a un origen de datos de puerta de enlace
Cómo solicitar la instalación de software
 Sugerencia
Para determinadas actividades que se repiten constantemente, considere la

posibilidad de automatizarlas mediante Power Apps y Power Automate. En este
caso, la documentación también incluirá el procedimiento para acceder y usar la
funcionalidad Power Platform.
Otros aspectos de Power BI se pueden administrar por medio de usuarios de
autoservicio, equipos descentralizados o un equipo centralizado. Los siguientes tipos de
documentación pueden diferir en función de quién posee y administra el contenido:
Cómo solicitar un nuevo informe

Cómo solicitar una mejora del informe
Cómo solicitar acceso a un conjunto de datos
Cómo solicitar una mejora del conjunto de datos
 Sugerencia
Como se ha descrito anteriormente en este artículo, al planear un portal

centralizado planee cómo controlar situaciones en las que es necesario personalizar
las instrucciones o las directivas de gobernanza para una o varias unidades de
negocio.
También se habrán tomado algunas decisiones de gobernanza que deberán

documentarse, como por ejemplo:
Cómo solicitar la certificación del contenido

Cuáles son las ubicaciones de almacenamiento de archivos aprobadas
Cuáles son los requisitos de retención y purga de datos
Cuáles son los requisitos para controlar los datos confidenciales y la información
de identificación personal (PII)
La documentación debe guardarse en el portal centralizado, que es una ubicación en la

que se pueden realizar búsquedas y donde, preferiblemente, los usuarios ya trabajan.
Tanto Teams como SharePoint funcionan muy bien. La creación de documentación en
páginas wiki o documentos también puede funcionar bien, siempre que el contenido
esté organizado y sea fácil de encontrar. Los documentos más cortos que se centran en
un tema suelen ser más fáciles de consumir que los documentos largos y más
completos.
） Importante
Una de las piezas de documentación más útiles que puede publicar para la
comunidad es una descripción de la configuración del inquilino y las pertenencias
a grupos necesarias para cada configuración de inquilino. Los usuarios leen las
características y la funcionalidad en línea y, a veces, descubren que no es adecuada
para ellos. Si pueden buscar rápidamente la configuración de inquilino de su
organización, esto evita que se sientan frustrados e intenten encontrar soluciones
alternativas. Una documentación eficaz puede reducir el número de vales del
servicio de asistencia enviados. También puede reducir el número de personas a las
que es necesario asignar el rol de administrador de Power BI (que podrían tener
este rol únicamente con el fin de ver la configuración).
Con el tiempo, puede optar por permitir que la comunidad mantenga parte de la
documentación si está dispuesto a participar. En este caso, puede que quiera introducir
un proceso de aprobación para los cambios.
Cuando vea que hay preguntas que se repiten en el foro de preguntas y respuestas
(como se describe en el artículo de soporte técnico para usuarios), durante las horas de
trabajo o durante las sesiones de almuerzo y aprendizaje, es un indicador excelente de
que puede ser adecuada la creación de nueva documentación. Cuando ya hay
documentación, permite a los compañeros hacer referencia a ella cuando sea necesario.
Contribuye a la habilitación del usuario y a la creación de una comunidad autosuficiente.
 Sugerencia
Al crear documentación personalizada o materiales de aprendizaje, haga referencia

a sitios de Microsoft existentes mediante vínculos, siempre que sea posible. Dado
que Power BI está en un estado continuo de evolución, con el tiempo irá
reduciendo el nivel de mantenimiento de documentación necesario.
Plantillas
Una plantilla de Power BI es un archivo .pbit. Se puede proporcionar como punto de
partida para los creadores de contenido. Es lo mismo que un archivo .pbix, que puede
contener consultas, un modelo de datos y un informe, pero con una excepción: el
archivo de plantilla no contiene ningún dato. Por lo tanto, es un archivo más pequeño
que se puede compartir con la comunidad y no presenta el riesgo de compartir datos
de forma inapropiada.
Proporcionar archivos de plantilla de Power BI a la comunidad es una excelente manera

de:
Promover la coherencia.
Reducir la curva de aprendizaje.
Mostrar buenos ejemplos y procedimientos recomendados.
Aumentar la eficacia.
Los archivos de plantilla de Power BI pueden mejorar la eficacia y ayudar a los usuarios a
aprender durante un día normal de trabajo. Estos son algunos ejemplos de cómo los
archivos de plantilla resultan útiles:
Los informes pueden usar ejemplos de procedimientos de visualización

recomendados.
Los informes pueden incorporar estándares de diseño y personalización de marca
de la organización.
Los conjuntos de datos pueden incluir la estructura de las tablas usadas
habitualmente, como una tabla de fechas.
Se pueden incluir cálculos DAX útiles, como un cálculo año a año.
Se pueden incluir parámetros comunes, como una cadena de conexión de origen
de datos.
Se puede incluir un ejemplo de documentación de informe o conjunto de datos.
７ Nota
Proporcionar plantillas no solo ahorra tiempo a los creadores de contenido, sino

que también les ayuda a moverse rápidamente más allá de una página en blanco
en una solución vacía.
Lista de comprobación: consideraciones y acciones clave que puede realizar para

establecer o mejorar la mentoría y la habilitación de usuarios.
＂ Tenga en cuenta los servicios de mentoría que el COE puede admitir: decida qué
tipos de servicios de mentoría puede ofrecer el COE. Entre los tipos se pueden
incluir horas de oficina, proyectos de desarrollo conjunto y revisiones de
procedimientos recomendados.
＂ Informe con regularidad sobre los servicios de mentoría: decida cómo va a
comunicar y a anunciar los servicios de mentoría, (por ejemplo, las horas de oficina)
a la comunidad de usuarios.
＂ Establezca un horario de oficina regular: lo ideal es establecer horas de oficina al
menos una vez a la semana (en función de la demanda de los usuarios, así como de
las restricciones de personal y programación).
＂ Decida cuáles serán las expectativas para las horas de oficina: determine cuál es el
ámbito de los temas permitidos o los tipos de problemas que los usuarios pueden
presentar en horas de oficina. Asimismo, determine cómo funcionará la cola de
solicitudes de horas de oficina, independientemente de que haya que presentar
información por adelantado o de que quepa esperar un seguimiento posterior.
＂ Cree un portal centralizado: asegúrese de tener una ubicación centralizada con
amplia compatibilidad donde los usuarios puedan encontrar fácilmente el material
de aprendizaje, la documentación y los recursos de Power BI. El portal centralizado
también debe proporcionar vínculos a otros recursos de la comunidad, como el
foro de preguntas y respuestas y cómo encontrar ayuda.
＂ Cree documentación y recursos: en el portal centralizado, se crea y se compila
documentación útil. Identifique y promueva entre 3 y 5 recursos principales que le
serán más útiles a la comunidad de usuarios.
＂ Actualice periódicamente la documentación y los recursos: asegúrese de que el
contenido se revise y se actualice periódicamente. El objetivo es asegurarse de que
la información disponible en el portal sea actual y de confianza.
＂ Compile una lista de recursos de aprendizaje de confianza reconocidos:
identifique recursos de aprendizaje destinados a las necesidades e intereses de
aprendizaje de la comunidad de usuarios. Publique la lista en el portal centralizado
y cree una programación para revisar y validar la lista.
＂ Plantéese si el aprendizaje interno personalizado puede ser útil: identifique si los
cursos de formación personalizados, desarrollados internamente, pueden ser útiles
y si vale la pena invertir tiempo en ellos. Invierta en la creación de contenido
específico de la organización.
＂ Cree objetivos y métricas: determine cómo medirá la eficacia del programa de
mentoría. Cree indicadores clave de rendimiento (KPI) u objetivos y resultados clave
(OKR) para validar si los esfuerzos de mentoría del COE refuerzan la comunidad y su
capacidad de proporcionar BI con características de autoservicio.
Niveles de madurez
Los niveles de madurez siguientes le ayudarán a evaluar el estado actual de su mentoría

y habilitación de usuarios.
Level Estado de mentoría y habilitación de usuarios de Power BI

Level Estado de mentoría y habilitación de usuarios de Power BI
100: Inicial Existen algunos recursos y documentación. Sin embargo, están en silos y son
incoherentes.
Pocos usuarios conocen o aprovechan los recursos disponibles.
200: Existe un portal centralizado con una biblioteca de documentación y recursos de

Repetible gran ayuda.
En el portal centralizado, hay disponible una lista mantenida de vínculos y recursos

de aprendizaje.
Las horas de oficina están disponibles para que la comunidad de usuarios pueda
obtener ayuda del COE.
300: El portal centralizado es el centro principal para que los miembros de la

Definido comunidad busquen formación, documentación y recursos. Normalmente, los
expertos y los miembros de la comunidad consultan los recursos cuando ofrecen
asistencia y aprenden unos de otros.
El programa de mentoría de aptitudes del COE está en vigor para ayudar a los
usuarios de la comunidad de varias maneras.
400: Durante las horas de oficina, la participación de todas las unidades de negocio de
Competente la organización es constante y activa.
Las unidades de negocio solicitan regularmente las revisiones de procedimientos

recomendados del COE.
El COE y los miembros de las unidades de negocio ejecutan repetidamente con

éxito los proyectos de desarrollo conjunto.
500: El COE actualiza y mejora continuamente la formación, la documentación y los

Eficiente recursos para garantizar que la comunidad tenga información actual y confiable.
El valor empresarial medible y tangible se obtiene del programa de mentoría

mediante los KPI o los OKR.
Pasos siguientes
Puede obtener más información sobre la comunidad práctica en el siguiente artículo de
la serie sobre la hoja de ruta de adopción de Power BI.
Comunidad práctica
７ Nota
Una comunidad práctica es un grupo de personas con un interés común que interactúa y
se ayuda entre sí de forma voluntaria. Utilizar Power BI para generar análisis eficaces es
un interés común que puede reunir a personas en una organización.
En el diagrama siguiente se proporciona información general de una comunidad interna.
En el diagrama anterior se muestra lo siguiente:
La comunidad práctica incluye a todos los usuarios interesados en Power BI.

El Centro de excelencia (COE) constituye el núcleo de la comunidad. Supervisa
toda la comunidad e interactúa más estrechamente con los campeones.
Los creadores de contenido de autoservicio y los expertos en la materia (SME)
producen, publican y admiten contenido que usan sus compañeros, que son
consumidores.
Los consumidores de contenido ven el contenido generado por creadores de
autoservicio y desarrolladores de BI empresariales.
Los campeones son un subconjunto de los creadores de contenido de
autoservicio. Los campeones están en una posición excelente para respaldar a sus
creadores de contenido en la generación de soluciones de Power BI eficaces.
El grupo de campeones es el más pequeño entre creadores y expertos en la materia. Los

creadores de contenido de autoservicio y los expertos en la materia representan un
mayor número de personas. Los consumidores de contenido representan el mayor
número de personas.
７ Nota
Todas las referencias a la comunidad de Power BI en esta serie de artículos de

adopción hacen referencia a usuarios internos, a menos que se indique
explícitamente lo contrario. Hay una comunidad activa y dinámica en todo el
mundo de escritores y presentadores que producen una gran cantidad de
conocimientos sobre Power BI. Sin embargo, los usuarios internos son el objetivo
de este artículo.
Para obtener información sobre temas relacionados, incluidos los recursos, la

documentación y el entrenamiento proporcionados para la comunidad de Power BI,
consulte el artículo Mentoría y habilitación de usuarios.
Red de campeones
Una parte importante de la comunidad práctica es sus campeones. Un campeón es un
creador de contenido de Power BI de contenido que trabaja en una unidad de negocio
que interactúa con el COE. Sus compañeros reconocen a los campeones como sus
expertos de Power BI de confianza. Los campeones crean y comparten continuamente
sus conocimientos aunque esa no sea una parte oficial de su rol de trabajo. Los
campeones de Power BI influyen y ayudan a sus compañeros de muchas maneras, como
con el desarrollo de soluciones, el aprendizaje, la mejora de aptitudes, la solución de
problemas y las últimas novedades.
Los campeones surgen como líderes de la comunidad práctica que:

Tienen un interés profundo en Power BI que utilizan de forma eficaz y han
adoptado correctamente en toda la organización.
Poseen importantes aptitudes de Power BI además de conocimientos de dominio
para su unidad de negocio funcional.
Tienen un interés inherente en participar y ayudar a otros.
Son los primeros usuarios y muestran entusiasmo por la experimentación y el
aprendizaje.
Pueden traducir eficazmente las necesidades empresariales en soluciones.
Se comunican bien con sus compañeros.
 Sugerencia
Para agregar un elemento de diversión, algunas organizaciones hacen referencia a

su red de campeones como embajadores, Jedis, ninjas o exploradores. Microsoft
tiene una comunidad interna denominada Campeones de BI.
A menudo, no se pide directamente a las personas que se conviertan en campeones.

Normalmente, el COE identifica a los campeones y los reconoce por las actividades que
ya están realizando, como responder con frecuencia a preguntas en un canal de
discusión interno o participar en sesiones de almuerzo y aprendizaje.
Los distintos enfoques serán más eficaces para las distintas organizaciones y cada
organización encontrará lo que mejor les funcione a medida que aumente su nivel de
madurez.
） Importante
Es muy posible que alguien esté asumiendo el rol de campeón sin saberlo o sin un
reconocimiento formal. El COE siempre debe estar atento para detectar a nuevos
campeones. Los miembros del COE deben supervisar activamente el canal de
discusión para ver quién es útil. Deben fomentar y apoyar deliberadamente a
posibles candidatos y, cuando sea necesario, invitarlos a una red local para que
reconocerlos formalmente.
Uso compartido de conocimiento

El objetivo principal de una comunidad práctica es facilitar el uso compartido de
conocimiento entre compañeros y en toda la organización. Hay muchas maneras de
compartir conocimientos. Puede suceder durante un día normal de trabajo. O bien,
podría ser durante una actividad más estructurada, como por ejemplo:
Actividad Descripción
Canal de Un foro de preguntas y respuestas donde cualquier persona de la comunidad

discusión puede publicar y ver mensajes. A menudo se usa para obtener ayuda y publicar
anuncios. Para obtener más información, vea el artículo Soporte técnico para
usuarios.
Sesiones de Sesiones programadas periódicamente en las que alguien realiza una breve
almuerzo y presentación sobre algo que ha aprendido o una solución que ha creado. El
aprendizaje objetivo es implicar a una variedad de presentadores, ya que escuchar de primera
mano lo que han logrado los compañeros puede ser muy eficaz.
Horas de Horas programadas periódicamente en las que los expertos del COE están
oficina con el disponibles para que la comunidad pueda interactuar con ellos. Los usuarios de la
COE comunidad pueden recibir asistencia con un proceso sencillo. Para obtener más
información, consulte el artículo Mentoría y habilitación del usuario.
Entradas de Entradas de blog cortas, que suelen tratar temas de ayuda técnicos.
blog internas
o
publicaciones
en la wiki
Grupo de Un subconjunto de la comunidad que decide reunirse como grupo de forma

usuarios programada periódicamente. A menudo, los miembros del grupo de usuarios se
internos de turnan para realizar presentaciones para compartir conocimientos y mejorar sus
Power BI habilidades de presentación.
Club de Un subconjunto de la comunidad selecciona un libro para leer según una

libros programación. Analizan lo que han aprendido y comparten sus opiniones entre sí.
Conferencias Una conferencia interna anual o semestral en la que se ofrecen una serie de
o eventos sesiones centradas en Power BI.
internos de
Power BI
 Sugerencia
Invitar a un presentador externo puede reducir el nivel de esfuerzo y aportar un

nuevo punto de vista para el aprendizaje y el uso compartido de conocimientos.
Incentivos
Se realiza mucho esfuerzo en la formación y el mantenimiento de una comunidad de
éxito. Es ventajoso para todos capacitar y recompensar a los usuarios que trabajan en
beneficio de la comunidad.
Recompensas para los miembros de la comunidad
Los incentivos que toda la comunidad (incluidos los campeones) encuentran
especialmente gratificantes pueden incluir:
Concursos con una pequeña tarjeta de obsequio o tiempo libre: por ejemplo,
podría realizar un evento de optimización del rendimiento, donde el ganador sería
la persona que consiguiera reducir más el tamaño de su modelo de datos.
Clasificación basada en puntos de ayuda: cada vez que la persona participa en
una sesión de preguntas y respuestas, obtiene un cambio de posición en una tabla
de clasificación. Este tipo de gamificación promueve la competición sana y la
emoción. Al participar en más conversaciones, el participante aprende y crece
personalmente, además de ayudar a sus compañeros.
Comunicación de liderazgo: cuando alguien muestre mucha dedicación y vaya
más allá, póngase en contacto con su gerente de modo que su líder, que puede
que no sea activo en la comunidad de Power BI, vea el valor que proporcionan los
miembros de su personal.
 Sugerencia
Los distintos tipos de incentivos atraerán a distintos tipos de personas. Algunos

miembros de la comunidad estarán muy motivados por los cumplidos y los
comentarios. A algunos los inspirará la gamificación y la diversión. Otros valorarán
mucho la oportunidad de mejorar su nivel de conocimiento.
Recompensas de los campeones

Los incentivos que los campeones pueden encontrar especialmente gratificantes
pueden incluir:
Acceso más directo al COE: la capacidad de tener conexiones en el COE es valiosa.

Se muestra en el diagrama mostrado anteriormente en este artículo.
Campeón del mes: agradezca públicamente a uno de sus campeones por algo
destacado que hizo durante el mes anterior. Puede ser una costumbre divertida al
principio de cada sesión de almuerzo y aprendizaje.
Área de discusión privada de expertos: un área privada para que los miembros
compartan ideas y aprendan unos de otros suele ser muy valiosa.
Información y entrenamiento especializados o profundos: se suele apreciar el
acceso a información adicional para ayudar a los campeones a desarrollar sus
conjuntos de aptitudes (así como a ayudar a sus compañeros). Podría incluir clases
de aprendizaje avanzado o conferencias.
Plan de comunicación
La comunicación con la comunidad se produce a través de varios tipos de canales de
comunicación. Los canales de comunicación comunes incluyen:
Canal de discusión interno o foro.

Canal de anuncios.
Boletín de la organización.
Los objetivos de comunicación más críticos incluyen garantizar que los miembros de la
comunidad sepan:
Que el COE existe.

Cómo obtener ayuda y soporte técnico.
Dónde encontrar recursos y documentación.
Dónde encontrar las directrices de gobernanza.
Cómo compartir sugerencias e ideas.
 Sugerencia
Considere la posibilidad de requerir un cuestionario de Power BI simple a los

usuarios antes de asignarles una licencia de Power BI. Denominarlo cuestionario no
es del todo correcto ya que no se centra en ninguna aptitud de Power BI. En su
lugar, es una breve serie de preguntas para comprobar que el usuario sabe dónde
encontrar ayuda y recursos. Los prepara para el éxito. También es una excelente
oportunidad para que los usuarios conozcan las directivas de gobernanza o los
acuerdos de privacidad y protección de datos necesarios. Para obtener más
información, consulte el artículo Supervisión del sistema.
Tipos de comunicación
Por lo general, hay cuatro tipos de comunicación para los que se debe planear:
Las nuevas comunicaciones de empleados se pueden dirigir a nuevos empleados

(y contratistas). Son una excelente oportunidad para proporcionar materiales de
incorporación a los nuevos empleados y que empiecen a trabajar con Power BI.
Puede incluir artículos sobre temas como la instalación de Power BI Desktop, cómo
solicitar una licencia y dónde encontrar materiales de entrenamiento
introductorios. También puede incluir directrices generales de gobernanza de
datos que todos los usuarios deben tener en cuenta.
Las comunicaciones de incorporación se pueden dirigir a los empleados que
acaban de adquirir una licencia de Power BI o han empezado a relacionarse con la
comunidad de Power BI. Presenta una excelente oportunidad de proporcionar los
mismos materiales que se proporcionan en las comunicaciones para los
empleados nuevos (como se mencionó anteriormente).
Las comunicaciones en curso pueden incluir anuncios y actualizaciones periódicas
dirigidos a todos los usuarios de Power BI o a subconjuntos de usuarios. Puede
incluir el anuncio de cambios planeados para el contenido clave de la
organización. Por ejemplo, los cambios que se van a publicar para un conjunto de
datos compartido crítico que se usa en gran medida en toda la organización.
También puede incluir el anuncio de nuevas características desde el blog de
Microsoft Power BI y las actualizaciones del plan de lanzamiento de
Microsoft Power BI . Para obtener más información sobre la planeación de
cambios, consulte el artículo Supervisión del sistema. Es más probable que los
anuncios de características reciban la atención del lector si el mensaje incluye
contexto significativo sobre por qué es importante. (Aunque el uso de fuentes RSS
puede ser una técnica útil, con el ritmo frecuente de cambio, puede resultar
ruidosa e ignorarse).
Las comunicaciones situacionales se pueden dirigir a usuarios o grupos
específicos en función de una aparición específica detectada al supervisar la
plataforma. Por ejemplo, quizás observe una cantidad significativa de uso
compartido desde el área de trabajo personal de un usuario determinado, por lo
que decide enviarle información sobre las ventajas de las áreas de trabajo y las
aplicaciones.
 Sugerencia
La comunicación directa con la comunidad de usuarios es importante. No olvide

incluir también opciones de comunicación bidireccional para asegurarse de que la
comunidad de usuarios tiene la oportunidad de proporcionar comentarios.
Recursos de la comunidad
Los recursos de la comunidad interna, como la documentación, las plantillas y el
entrenamiento, son fundamentales para el éxito de la adopción. Para obtener más
información sobre recursos, consulte el artículo Mentoría y habilitación del usuario.

Lista de comprobación: consideraciones y acciones clave que puede realizar para la
comunidad de prácticas.
Inicie, crezca y mantenga su red de campeones:
＂ Aclare los objetivos: aclare sus objetivos específicos para desarrollar una red de
campeones. Asegurarse de que estos objetivos coinciden con la estrategia general
de Power BI y de que su patrocinador ejecutivo está de acuerdo.
＂ Cree un plan para la red de campeones: Aunque algunos aspectos de la red de
campeones siempre estarán dirigidos de forma informal, determine hasta qué
punto el COE colaborará y apoyará los esfuerzos de los campeones en todas las
unidades de negocio individuales. Tenga en cuenta cuántos puestos son ideales
para cada área de negocio funcional. Normalmente, entre 1 y 2 campeones por
área funcionan bien, pero puede variar en función del tamaño del equipo, las
necesidades de la comunidad de autoservicio y cómo se estructura el COE.
＂ Decida el nivel de compromiso de los campeones: decida qué nivel de
compromiso y tiempo previsto será necesario para los campeones de Power BI.
Tenga en cuenta si la inversión de tiempo variará considerablemente de persona a
persona y equipo a equipo debido a diferentes responsabilidades. Planee
comunicar claramente las expectativas a las personas que están interesadas en
participar. Obtener la aprobación del administrador cuando corresponda.
＂ Determine cómo identificar a los campeones: determine cómo responderá a las
solicitudes para convertirse en campeones y cómo los buscará el COE. Decidir si va
a animar abiertamente a los empleados interesados a que se identifiquen como
campeones y pidan más información (menos común). O bien, si el COE observará
sus esfuerzos y enviará una invitación privada (más común).
＂ Determine cómo se administrarán los miembros de la red de campeones: Una
excelente opción para administrar quiénes son los campeones es con un grupo de
seguridad. Considere:
Cómo se comunicará con la red de campeones (por ejemplo, en un canal de
Teams, un grupo de Yammer o una lista de distribución de correo electrónico).
Cómo se comunicará y colaborará la red de campeones directamente entre sí (en
toda la organización).
Si es adecuado crear un foro de discusión privado y exclusivo para campeones y
miembros del COE.
＂ Planee recursos para campeones: asegúrese de que los miembros de la red de
campeones tienen los recursos que necesitan, entre los que se incluyen:
Acceso directo a los miembros del COE.
Influencia en las directivas de datos que se implementan (por ejemplo, los
requisitos de una directiva de certificación de conjunto de datos).
Influencia en la creación de procedimientos recomendados e instrucciones (por
ejemplo, recomendaciones para acceder a un sistema de origen específico).
＂ Implique a los campeones: Implique activamente a determinados campeones
como miembros asociados del COE. Para obtener más información sobre la
federación del COE, consulte el artículo Centro de excelencia.
＂ Cree un bucle de comentarios para campeones: asegúrese de que los miembros
de la red de campeones puedan proporcionar fácilmente información o enviar
sugerencias al COE.
＂ Proporcione reconocimiento e incentivos a los campeones de forma rutinaria: no
solo es una motivación eficaz, sino que el acto de compartir ejemplos de esfuerzos
correctos puede motivar e inspirar a otros.
Mejore el uso compartido de conocimientos:
＂ Identifique actividades de uso compartido de conocimientos: determine qué tipo

de actividades para el uso compartido de conocimiento encajan bien con la cultura
de datos de la organización. Asegurarse de que todas las actividades planeadas de
uso compartido de conocimiento sean compatibles y sostenibles.
＂ Confirme los roles y las responsabilidades: compruebe quién asumirá la
responsabilidad de coordinar todas las actividades de uso compartido del
conocimiento.
Introduzca incentivos:
＂ Identifique incentivos para campeones: tenga en cuenta qué tipo de incentivos

podría ofrecer a los miembros de la red de campeones.
＂ Identifique incentivos para los miembros de la comunidad: considere el tipo de
incentivos que podría ofrecer a su comunidad interna más amplia.
Mejore las comunicaciones:
＂ Establezca métodos de comunicación: evalúe qué métodos de comunicación

encajan bien con la cultura de datos de la organización. Configurar distintas
maneras de comunicarse, incluida la retención del historial y la búsqueda.
＂ Identifique responsabilidades: determine quién será responsable de los distintos
tipos de comunicación, cómo y cuándo.
Niveles de madurez
comunidad práctica.
Level Estado de la comunidad de Power BI
100: Inicial Algunos creadores de contenido de autoservicio están haciendo un gran trabajo
en toda la organización. Sin embargo, no se reconocen sus esfuerzos.
Los esfuerzos para compartir el conocimiento de forma intencionada por toda la

organización son poco frecuentes y no estructurados.
La comunicación es incoherente, sin un plan claramente establecido.
200: Se identifica el primer conjunto de campeones.

Repetible
Se identifican los objetivos de una red de campeones.
Las prácticas de uso compartido de conocimientos están tomando fuerza.
300: El uso compartido de conocimientos en varias formas es algo normal y habitual. El

Definido uso compartido de información se produce con frecuencia y de forma
intencionada.
Los objetivos para la comunicación transparente con la comunidad de usuarios se

definen.
400: Se identifican los campeones para todas las unidades de negocio. Respaldan
Competente activamente a sus compañeros en sus esfuerzos de autoservicio.
Los incentivos para reconocer y recompensar los esfuerzos de uso compartido de

conocimientos son una ocurrencia común.
La comunicación regular y frecuente se produce en base a un plan de

comunicación predefinido.
500: Existen bucles de comentarios bidireccionales entre la red de campeones y el COE.

Eficiente
Hay indicadores clave de rendimiento que miden la participación y la satisfacción
de la comunidad.
Existe automatización cuando esta agrega valor directo a la experiencia del usuario
(por ejemplo, el acceso automático a la comunidad).
Pasos siguientes
Puede obtener más información sobre el soporte técnico del usuario en el siguiente
artículo de la serie sobre la hoja de ruta de adopción de Power BI.
soporte técnico para usuarios
７ Nota
En este artículo se habla del soporte técnico para usuarios. El artículo se centra
principalmente en la resolución de problemas.
En las primeras secciones de este artículo se habla de los aspectos del soporte técnico
para usuarios que se controlan internamente dentro de la organización. Los temas
finales se centran en los recursos externos disponibles.
Para obtener una descripción de temas relacionados, como la mentoría de aptitudes, el

entrenamiento, la documentación y la asistencia para el desarrollo en colaboración que
se proporcionan a la comunidad interna de usuarios de Power BI, vea el artículo
Mentoría y capacitación de los usuarios. La eficacia de esas actividades puede reducir
considerablemente el volumen de solicitudes de soporte técnico para usuarios formales
y mejorar la experiencia del usuario en general.
Tipos de soporte técnico para usuarios

Si un usuario tiene un problema, ¿sabe cuáles son sus opciones para resolverlo?
En el diagrama siguiente se muestran algunos tipos habituales de soporte técnico para

usuarios que las organizaciones emplean correctamente:
Los seis tipos de soporte técnico para usuarios que se muestran en el diagrama anterior
incluyen:
Tipo Descripción
El soporte técnico dentro del equipo (interno) es muy informal. El soporte técnico tiene
lugar cuando los miembros del equipo aprenden unos de otros en el curso natural de su
trabajo.
El soporte técnico de la comunidad interna (interno) se puede organizar de manera

informal, formal o ambas. Tiene lugar cuando los compañeros interactúan entre sí por
medio de canales internos de la comunidad.
El soporte técnico del servicio de asistencia (interno) gestiona las solicitudes de soporte
técnico formales y los problemas.
El soporte extendido (interno) consiste en la gestión de problemas complejos escalados

por el servicio de asistencia.
El soporte técnico de Microsoft (externo) incluye soporte para usuarios con licencia y
administradores. También incluye documentación de Power BI general.
El soporte técnico de la comunidad (externo) incluye a la comunidad internacional de

expertos de Power BI, los Microsoft MVP y entusiastas que participan en foros y publican
contenido.
En algunas organizaciones, el soporte técnico dentro del equipo y de la comunidad

interna son más relevantes para la BI de autoservicio (el contenido es propiedad de
creadores y propietarios de unidades de negocio descentralizadas, que además lo
administran). Por el contrario, el soporte técnico del servicio de asistencia y el extendido
están reservados para problemas técnicos y BI empresarial (el contenido es propiedad
de un equipo de inteligencia empresarial centralizado o el Centro de excelencia, que
además lo administra). En algunas organizaciones, los cuatro tipos de soporte técnico
pueden ser relevantes para cualquier tipo de contenido.
 Sugerencia
Para más información sobre los conceptos de BI empresarial, BI de autoservicio

administrado y BI de autoservicio dirigido por la empresa, consulte el artículo
Propiedad y administración del contenido.
En este artículo se describen más detalladamente cada uno de los cuatro tipos de
soporte técnico interno para usuarios presentados anteriormente.
Soporte técnico dentro del equipo

El soporte técnico dentro del equipo se refiere a cuando los miembros del equipo
aprenden unos de otros y se ayudan entre sí durante su trabajo diario. Las personas que
emergen como campeones de Power BI suelen asumir este tipo de rol de soporte
técnico informal de manera voluntaria porque tienen un deseo intrínseco de ayudar.
Aunque es un modo de soporte técnico informal, no debe infravalorarse. Algunas
estimaciones indican que un gran porcentaje del aprendizaje en el trabajo es entre
pares, lo que resulta especialmente útil para los analistas que crean soluciones de
Power BI específicas de dominio.
７ Nota
El soporte técnico dentro del equipo no funciona bien en el caso de aquellos

usuarios que son los únicos analistas de datos dentro de un departamento.
Tampoco es eficaz en el de aquellos que aún no tienen muchas conexiones en su
organización. Si no hay ningún compañero cercano del que depender, cobran
importancia otros tipos de soporte técnico, como se explica en este artículo.
Soporte técnico de la comunidad interna

La ayuda de los miembros de la comunidad suele adoptar la forma de mensajes en un
canal o foro de debate establecido específicamente para la comunidad de práctica de
Power BI. Por ejemplo, alguien publica un mensaje contando que tiene problemas para
que un cálculo DAX funcione. A continuación, recibe una respuesta de alguien de la
organización con sugerencias o vínculos.
 Sugerencia
El objetivo de una comunidad de Power BI interna es ser autosuficiente, lo que

puede dar lugar a una reducción de los costos y las demandas de soporte técnico
formal. También puede facilitar la BI de autoservicio administrada a una mayor
escala frente a un enfoque de BI puramente centralizado. Pero siempre va a ser
necesario supervisar, administrar y formar a la comunidad interna. Estas son dos
recomendaciones concretas:
Asegúrese de formar a varios expertos en los temas más difíciles, como las
expresiones de análisis de datos (DAX) y el lenguaje de fórmulas M de
Power Query. Cuando alguien se convierte en un experto reconocido, puede
sentirse sobrecargado por las muchas solicitudes de ayuda.
Un mayor número de miembros de la comunidad puede responder
rápidamente a determinados tipos de preguntas (por ejemplo, visualizaciones
de informes), mientras que un número menor de miembros responderá a
otras (por ejemplo, DAX complejo). Es importante que el COE dé a la
comunidad la oportunidad de responder, pero que también esté dispuesto a
gestionar con prontitud las preguntas no respondidas. Si los usuarios
preguntan repetidamente y no reciben una respuesta, eso lastra
considerablemente el crecimiento de la comunidad. En ese caso, si un usuario
no recibe respuesta a sus preguntas, es probable que se vaya y nunca vuelva.
Un canal de debate de la comunidad interna se suele establecer como canal de Teams o

grupo de Yammer. La tecnología elegida debe reflejar dónde trabajan ya los usuarios, de
modo que las actividades tengan lugar dentro de su flujo de trabajo natural.
Una ventaja de un canal de debate interno es que las respuestas pueden llegar de
personas que el solicitante original no ha conocido. En organizaciones grandes, una
comunidad de práctica reúne a la gente en torno a un interés común. Puede ofrecer
diversas perspectivas para obtener ayuda y aprender en general.
El uso de un canal de debate comunitario interno permite que el Centro de excelencia

(COE) supervise el tipo de preguntas que hacen los usuarios. Es una manera de que
pueda entender los problemas que experimentan los usuarios (normalmente
relacionados con la creación de contenido, pero también con el consumo de este).
La supervisión del canal de debate también puede destapar a otros expertos de

Power BI y posibles campeones anteriormente desconocidos para el COE.
） Importante
Se recomienda identificar permanentemente a campeones de Power BI emergentes

e interactuar con ellos para asegurarse de que están preparados para ofrecer
soporte a sus compañeros. Como se indica en el artículo sobre la comunidad
práctica, el COE debe supervisar activamente el canal de debate para ver quién está
siendo de ayuda. El COE debe animar y apoyar deliberadamente a los miembros de
la comunidad. Cuando corresponda, invítelos a la red de campeones.
Otra ventaja fundamental de un canal de debate es que permite las búsquedas, lo que
deja que otras personas descubran la información. Sin embargo, el que los usuarios
hagan preguntas en un foro abierto en lugar de mediante mensajes privados o el correo
electrónico supone un cambio de hábitos. Debe tener en cuenta que algunas personas
no se sienten cómodas haciendo preguntas de forma tan pública. Reconocer
abiertamente lo que no saben, puede resultar embarazoso. Esta reticencia puede
disminuir con el tiempo gracias a la promoción de un canal de debate útil, alentador y
amable.
 Sugerencia
Puede sentirse tentado a crear un bot para gestionar algunas de las preguntas más
habituales y sencillas de la comunidad. Un bot puede servir para preguntas no
complicadas, por ejemplo, "¿Cómo solicito una licencia de Power BI?" o "¿Cómo
solicito un área de trabajo?". Antes de usar este método, piense si hay suficientes
preguntas rutinarias y predecibles como para mejorar la experiencia del usuario, en
lugar de empeorarla. A menudo, las preguntas más frecuentes bien creadas
funcionan mejor y son más rápidas de desarrollar y más fáciles de mantener.
Servicio de asistencia
El servicio de asistencia suele funcionar como un servicio compartido, administrado por
el departamento de TI. Entre los usuarios que probablemente dependan de un canal de
soporte técnico más formal se incluyen aquellos que son:
Menos experimentadas con Power BI.

Más nuevas en la organización.
Reacias a publicar un mensaje en la comunidad de debate interna.
Faltas de conexiones y compañeros dentro de la organización.
También hay determinados problemas técnicos que no se pueden resolver por completo
sin la intervención de TI, como las solicitudes de instalación y actualización de software
cuando las máquinas están administradas por TI.
Normalmente, el ocupado personal del servicio de asistencia se dedica al soporte de

varias tecnologías. Por esta razón, los tipos de problemas más fáciles de gestionar son
los que tienen una resolución clara y se pueden documentar en una base de
conocimiento. Por ejemplo, requisitos previos o requisitos de instalación de software
para obtener una licencia.
Algunas organizaciones solicitan al servicio de asistencia que gestione solo problemas

muy sencillos de reparación de averías. En otras organizaciones, el servicio de asistencia
interviene en todo lo que es repetible., como nuevas solicitudes de áreas de trabajo, la
administración de orígenes de datos de puerta de enlace o la solicitud de nuevas
capacidades Premium.
） Importante
Las decisiones de gobernanza de Power BI afectan directamente al volumen de
solicitudes del servicio de asistencia. Por ejemplo, si decide limitar los permisos de
creación de áreas de trabajo en la configuración de inquilinos, eso hará que los
usuarios envíen vales del servicio de asistencia. Aunque es una decisión legítima,
debe estar preparado para satisfacer las solicitudes muy rápidamente. Responda a
este tipo de solicitud en un plazo de 1 a 4 horas, si es posible. Si se retrasa
demasiado tiempo, los usuarios utilizarán lo que ya tienen o encontrarán la manera
de eludir sus requisitos. Este escenario puede que no sea el más idóneo. La
prontitud es fundamental para determinadas solicitudes del servicio de asistencia.
Tenga en cuenta que la automatización mediante Power Apps y Power Automate
puede ayudar a aumentar la eficiencia de algunos procesos.
Con el tiempo, a medida que el personal del servicio de asistencia amplía la base de
conocimiento y gana experiencia con Power BI, las aptitudes de solución de problemas
ganan eficacia. El mejor empleado del servicio de asistencia es aquel que comprende
bien lo que los usuarios necesitan lograr con Power BI.
 Sugerencia
Los problemas puramente técnicos, por ejemplo, un error de actualización de

datos o la necesidad de agregar un nuevo usuario a un origen de datos de puerta
de enlace, suelen tener respuestas sencillas asociadas a un contrato de nivel de
servicio. Por ejemplo, puede haber un contrato para responder a problemas de
bloqueo en un plazo de una hora y resolverlos en ocho horas. Por lo general, es
más difícil definir contratos de nivel de servicio (SLA) para solucionar problemas,
como discrepancias de datos.
Soporte extendido
Dado que el COE tiene un profundo conocimiento de cómo se usa Power BI en la
organización, es una excelente opción para el soporte extendido en caso de un
problema complejo. La participación del COE en el proceso de soporte técnico debe
seguir una ruta de escalado.
La administración de solicitudes como una mera ruta de escalado desde el servicio de

asistencia es difícil de aplicar, ya que los miembros del COE suelen ser conocidos de los
usuarios empresariales. Para fomentar el hábito de pasar por los canales adecuados, los
miembros del COE deben redirigir a los usuarios para que envíen un vale del servicio de
asistencia. Eso también mejora la calidad de los datos para analizar solicitudes del
servicio de asistencia.
Soporte técnico de Microsoft
Además de los enfoques internos de soporte técnico para usuarios que se tratan en este
artículo, hay valiosas opciones de soporte técnico externo disponibles directamente
para los usuarios y administradores de Power BI que no deben pasarse por alto.
Documentación de Microsoft
Consulte los problemas de alta prioridad del sitio de soporte técnico de Power BI que
afectan de forma generalizada a todos los clientes. Los administradores de
Microsoft 365 globales tienen acceso a detalles adicionales de problemas de soporte
técnico en el portal de Microsoft 365.
Supervise la cuenta de Twitter de Microsoft 365 . Microsoft publica puntualmente

información y actualizaciones sobre las interrupciones de todos los servicios de
Microsoft 365.
Vea la documentación de Power BI completa. Se trata de un recurso acreditado que

puede ayudar a solucionar problemas y a buscar información. Puede priorizar los
resultados del sitio de documentación de Power BI. Por ejemplo, escriba una solicitud de
búsqueda orientada al sitio en el motor de búsqueda web, como power bi dataset
site:learn.microsoft.com .
Soporte técnico para usuarios finales de Power BI Pro y

Premium por usuario
Los usuarios con una licencia de Power BI Pro o Premium por usuario pueden enviar
incidencias de soporte técnico a Microsoft .
 Sugerencia
Deje claro a la comunidad de usuarios interna si prefiere que los problemas

técnicos se notifiquen al servicio de asistencia interno. Si el servicio de asistencia
está preparado para gestionar la carga de trabajo, el contar con un área interna
centralizada para recopilar problemas de los usuarios puede proporcionar una
experiencia de usuario superior frente a que cada usuario intente resolver los
problemas por sí mismo. Tener visibilidad y analizar problemas de soporte técnico
también es útil para el COE.
Soporte técnico para administradores

Hay varias opciones de soporte técnico disponibles para administradores globales y de
Power BI.
En el caso de los clientes que tienen un contrato de Soporte técnico unificado de

Microsoft , considere la posibilidad de conceder acceso al servicio de asistencia y a los
miembros del COE a Microsoft Services Hub . Una ventaja del centro de servicios de
Microsoft es que los miembros del servicio de asistencia y del COE pueden configurarse
para enviar y ver solicitudes de soporte técnico.
Soporte técnico de la comunidad internacional

Además de los enfoques internos de soporte técnico para usuarios tratados en este
artículo y de las opciones de soporte técnico de Microsoft analizadas anteriormente,
puede aprovechar la comunidad internacional de Power BI.
La comunidad mundial es útil cuando una pregunta puede ser entendida fácilmente por
alguien que no esté cerca del problema, y cuando no se trata de datos confidenciales o
procesos internos delicados.
Foros de la comunidad disponibles públicamente

Hay varios foros públicos de la comunidad de Power BI en los que los usuarios
pueden publicar problemas y recibir respuestas de cualquier usuario de Power BI del
mundo. Obtener respuestas de cualquier persona, en cualquier lugar, puede ser muy
poderoso y sumamente útil. Sin embargo, como es el caso de cualquier foro público, es
importante validar los consejos y la información publicados en el foro. Es posible que el
consejo publicado en Internet no sea adecuado para su situación.
Áreas de debate disponibles públicamente

Es muy común ver a personas publicando preguntas técnicas de Power BI en
plataformas como Twitter. Un vistazo rápido al hashtag #PowerBI revela una dinámica
comunidad global de entusiastas de Power BI. Encontrará debates, anuncios de
publicaciones y usuarios que se ayudan mutuamente. El hashtag #PowerBIHelp se usa
a veces, aunque con menos frecuencia.
Documentación de la comunidad
La comunidad internacional de Power BI es dinámica. Todos los días se publican gran
cantidad de entradas de blog, artículos, seminarios web y vídeos de Power BI. Si confía
en la información de la comunidad para solucionar problemas, esté atento a lo
siguiente:
Cómo de reciente es la información. Intente comprobar cuándo se publicó o se

actualizó por última vez.
Si la situación y el contexto de la solución encontrada en línea se ajusta realmente
a sus circunstancias.
La credibilidad de la información que se presenta. Confíe en blogs y sitios de
confianza.
Lista de comprobación: a continuación se exponen las consideraciones y medidas clave

que puede adoptar para ayudar a los usuarios.
Mejore el apoyo dentro del equipo:
＂ Proporcione reconocimiento y estímulo: ofrezca incentivos a los campeones de

Power BI, como se explica en el artículo sobre la comunidad de práctica.
＂ Recompense el esfuerzo: reconozca y alabe los esfuerzos significativos básicos
cuando vea que se producen.
＂ Cree funciones formales: si los esfuerzos informales dentro del equipo no son
suficientes, considere la posibilidad de formalizar las funciones que desea
desempeñar en este ámbito. Incluya las contribuciones y responsabilidades
esperadas en la descripción del trabajo de RR. HH. cuando corresponda.
Mejore el apoyo interno de la comunidad:
＂ Fomente la formulación de preguntas continuamente: anime a los usuarios a

hacer preguntas en el canal de debate de la comunidad designado. A medida que
el hábito se consolida, se normalizará su uso como primera opción. Con el tiempo,
evolucionará para ser más autosuficiente.
＂ Supervise activamente el área de debate: asegúrese de que los miembros del COE
adecuados supervisen activamente este canal de debate. Pueden responder si una
pregunta sigue sin respuesta, mejorar las respuestas o realizar correcciones cuando
sea necesario. También pueden publicar vínculos a información adicional para dar a
conocer los recursos existentes. Aunque el objetivo de la comunidad es ser
autosuficiente, todavía requiere recursos dedicados para su supervisión y
formación.
＂ Comunique las opciones disponibles: asegúrese de que la población de usuarios
sepa que existe el área de apoyo interno de la comunidad. Podría incluir la
visualización destacada de vínculos. Puede incluir un vínculo en las comunicaciones
habituales a la comunidad de usuarios. También puede personalizar los vínculos del
menú de ayuda del servicio Power BI para dirigir a los usuarios a los recursos
internos.
＂ Configure la automatización: asegúrese de que todos los usuarios con licencia
Gratis, Power BI Pro y Premium por usuario tengan acceso automáticamente al
canal de debate de la comunidad. Es posible automatizar la configuración de
licencias mediante licencias basadas en grupos.
Mejore el apoyo interno del servicio de asistencia:
＂ Determine las responsabilidades del servicio de asistencia: decida el ámbito inicial

de los temas de Power BI que va a gestionar el servicio de asistencia.
＂ Evalúe el nivel de preparación: determine si el servicio de asistencia está preparado
para gestionar el soporte técnico de Power BI. Identifique si existen lagunas de
preparación que deben abordarse.
＂ Organice entrenamiento adicional: realice sesiones de transferencia de
conocimientos o sesiones de entrenamiento para preparar al personal del servicio
de asistencia.
＂ Actualice la base de conocimiento del servicio de asistencia: incluya preguntas y
respuestas conocidas de Power BI en una base de conocimiento en la que se
puedan hacer búsquedas. Asegúrese de que alguien sea responsable de las
actualizaciones periódicas de la base de conocimiento para reflejar las
características nuevas y mejoradas con el tiempo.
＂ Configure un sistema de seguimiento de vales: asegúrese de que haya un buen
sistema para realizar un seguimiento de las solicitudes enviadas al servicio de
asistencia.
＂ Decida si alguien estará de guardia para cualquier problema relacionado con
Power BI: si procede, asegúrese de que las expectativas de soporte técnico 24/7
sean claras.
＂ Determine qué Acuerdos de Nivel de Servicio existirán: cuando exista un Acuerdo
de Nivel de Servicio (SLA) específico, asegúrese de que las expectativas de
respuesta y resolución se comuniquen y documenten de forma clara.
＂ Prepárese para actuar rápidamente: esté listo para abordar problemas comunes
específicos con extrema rapidez. Una respuesta de soporte técnico lenta puede
llevar a que los usuarios busquen soluciones alternativas.
Mejore su soporte extendido del COE interno:

＂ Determine cómo funcionará el soporte técnico escalonado: decida cuál va a ser la
ruta de escalado de las solicitudes que el servicio de asistencia no pueda gestionar
directamente. Asegúrese de que el COE (o personal equivalente) esté preparado
para intervenir cuando sea necesario. Defina claramente dónde terminan las
responsabilidades del servicio de asistencia y dónde comienzan las
responsabilidades de soporte extendido del COE.
＂ Promueva la colaboración entre el COE y los administradores del sistema:
asegúrese de que los miembros del COE tengan una ruta de escalado directa para
llegar a los administradores globales de Microsoft 365 y Azure. Es fundamental
contar con un canal de comunicación cuando surja un problema generalizado que
se sale del ámbito de Power BI.
＂ Cree un bucle de comentarios desde el COE hasta el servicio de asistencia:
cuando el COE conozca la nueva información, se debe actualizar la base de
conocimiento de TI. El objetivo es que el personal del servicio de asistencia
principal esté siempre mejor preparado para gestionar más problemas en el futuro.
＂ Cree un bucle de comentarios desde el servicio de asistencia hasta el COE: si el
personal de soporte técnico observa redundancias o ineficiencias, pueden
comunicarlas al COE, quien puede optar por mejorar la base de conocimiento o
intervenir (especialmente si están relacionadas con la gobernanza o la seguridad).
Niveles de madurez
Los siguientes niveles de madurez le ayudarán a evaluar el estado actual del soporte
técnico para usuarios de Power BI.
Level Estado del soporte técnico para usuarios de Power BI
100: Inicial Las unidades de negocio individuales encuentran maneras eficaces de ayudarse
mutuamente. Sin embargo, las tácticas y prácticas están aisladas y no se aplican de
forma sistemática.
Existe un canal de debate interno. Sin embargo, no se supervisa continuamente.

Por lo tanto, la experiencia del usuario es incoherente.
Level Estado del soporte técnico para usuarios de Power BI
200: El COE fomenta activamente el apoyo dentro del equipo y el crecimiento de la red
Repetible de campeones.
El canal de debate interno gana adeptos. Se conoce como el lugar por excelencia
para preguntas y debates sobre Power BI.
El servicio de asistencia gestiona un pequeño número de los problemas de soporte

técnico más comunes de Power BI.
300: El canal de debate interno ahora es popular y, en gran medida, autosuficiente. Los
Definido miembros del COE supervisan y administran activamente el canal de debate para
asegurarse de que las preguntas se responden de forma rápida y correcta.
Hay un sistema de seguimiento del servicio de asistencia para supervisar la

frecuencia de soporte técnico, los temas de respuesta y las prioridades.
El COE proporciona soporte extendido adecuado cuando es necesario.
400: El servicio de asistencia está totalmente entrenado y preparado para gestionar un

Competente número más amplio de problemas conocidos y esperados de soporte técnico de
Power BI.
Hay Acuerdos de Nivel de Servicio (SLA) en vigor para definir las expectativas de
soporte técnico del servicio de asistencia, incluido el soporte extendido. Las
expectativas se documentan y se comunican para que sean claras para todos los
implicados.
500: Existen bucles de comentarios bidireccionales entre el servicio de asistencia y el

Efficient COE.
Los indicadores clave de rendimiento miden la satisfacción y los métodos de

soporte técnico.
Existe automatización para que el servicio de asistencia reaccione más rápido y

reduzca los errores (por ejemplo, uso de API y scripts).
Pasos siguientes
Obtenga información sobre las actividades de supervisión y administración del sistema
en el siguiente artículo de la serie de la hoja de ruta de adopción de Power BI.
supervisión del sistema
７ Nota
La supervisión del sistema, también conocida como administración de Power BI, consiste
en actividades administrativas cotidianas continuas. Se refiere específicamente a lo
siguiente:
Gobernanza: aplican directivas y directrices de gobernanza para permitir una de BI

de autoservicio y una instancia de BI empresarial.
Capacitación del usuario: facilita y permite los procesos y sistemas internos que
capacitan a la comunidad interna de usuarios en la medida de lo posible, a la vez
que cumplen los reglamentos y los requisitos de la organización.
Adopción: permite una adopción más amplia de Power BI dentro de la
organización con procedimientos eficaces de gobernanza y administración de
datos.
） Importante
Los objetivos de la cultura de los datos de la organización proporcionan una

dirección para las decisiones de gobernanza que, a su vez, dictan cómo se realizan
las actividades de administración de Power BI y por parte de quién.
La supervisión del sistema es un tema amplio y profundo. El objetivo de este artículo es

presentar algunas de las consideraciones y acciones más importantes para ayudarle a
alcanzar los objetivos de adopción de la organización.
Administradores de Power BI
El rol de administrador de Power BI es un rol definido en Microsoft 365, que delega un
subconjunto de actividades de administración específicas de Power BI. Los
administradores de Microsoft 365 globales son administradores de Power BI de forma
implícita. Los administradores de Power Platform también son administradores de Power
BI implícitamente (sin embargo, los administradores de Power BI no tienen el mismo rol
en otras aplicaciones de Power Platform).
Una decisión clave de gobernanza es a quién asignar como administrador de Power BI.
Se trata de un rol centralizado que afecta a todo el inquilino de Power BI. Lo ideal es
que haya entre 2 y 4 personas en la organización que sepan administrar el servicio
Power BI. Los administradores deberían operar en estrecha coordinación con el Centro
de excelencia (COE).
Rol con privilegios elevados

El rol de administrador de Power BI se considera un rol con privilegios elevados por lo
siguiente:
Experiencia de usuario: las opciones de configuración administradas por un

administrador de Power BI tienen un impacto considerable en las capacidades y la
experiencia de los usuarios (se describen en la sección Configuración de inquilinos
a continuación).
Acceso de seguridad total: los administradores de Power BI pueden actualizar los
permisos de acceso para las áreas de trabajo del inquilino. El resultado es que un
administrador puede conceder permiso para ver o descargar datos e informes
cuando lo considere adecuado (esto se explica en la sección Configuración de
inquilinos a continuación).
Metadtos: los administradores de Power BI pueden ver todos los metadatos de un
inquilino, incluidas todas las actividades de usuario que se producen en el servicio
Power BI (esto se explica en la sección Auditoría y supervisión a continuación).
） Importante
Tener demasiados administradores de Power BI es un riesgo. Aumenta la

probabilidad de una administración del inquilino no aprobada, no deseada o
incoherente.
Los tipos de actividades que un administrador va a realizar cada día varían entre
organizaciones. Lo que es importante y a lo que se da prioridad en la cultura de los
datos va a influir en gran medida en lo que hace un administrador para permitir la BI de
autoservicio dirigida por la empresa, la BI de autoservicio administrada y la BI
empresarial. Para obtener más información, vea el artículo Propiedad y administración
de contenido.
 Sugerencia
El mejor tipo de persona para asignar como administrador de Power BI es el que

tiene suficientes conocimientos sobre Power BI para comprender lo que los
usuarios de autoservicio necesitan lograr. Con esta comprensión, el administrador
puede equilibrar la capacitación y la gobernanza de los usuarios.
Hay varios tipos de administradores Power BI. En la siguiente tabla se describen los roles
que se usan con más frecuencia de forma habitual.
Rol Ámbito Descripción
Administrador Inquilino Administra la configuración de inquilinos y otros aspectos del

de Power BI de Power servicio Power BI. Todas las referencias generales a administrador en
BI este artículo se refieren a este tipo de administrador.
Administrador Una Administra áreas de trabajo, cargas de trabajo y supervisa el estado

de capacidad capacidad de una capacidad Premium.
de Power BI
Premium
Administrador Una Administra la configuración, las credenciales y las asignaciones de

de puerta de puerta de usuarios del origen de datos de puerta de enlace. También puede
enlace de enlace controlar las actualizaciones de software de puerta de enlace (o
Power BI colaborar con el equipo de infraestructura en las actualizaciones).
Administrador Un área Administra la configuración y el acceso del área de trabajo.

de área de de
trabajo de trabajo
Power BI
El ecosistema Power BI es muy amplio y profundo. Hay muchas maneras de integrar el

servicio Power BI con otros sistemas y plataformas. De vez en cuando es necesario
trabajar con otros administradores de sistemas y profesionales de TI, como:
Administrador de Microsoft 365 global

Administrador de Azure Active Directory (Azure AD)
Administrador de Teams
Administrador de OneDrive
Administrador de SharePoint
Administrador de base de datos
Administrador de licencias y facturación
Administrador de Intune
Equipo de soporte técnico de escritorio
Equipo de infraestructura
Equipo de redes
Equipo de seguridad y cumplimiento
En el resto de este artículo se habla de las actividades más comunes que lleva a cabo un
administrador de Power BI. El artículo se centra en aquellas actividades que es
importante llevar a cabo de forma eficaz al adoptar un enfoque estratégico para la
adopción de Power BI en la organización.
Administración de servicios
La supervisión del servicio Power BI es un aspecto crucial para garantizar que todos los
usuarios tengan una buena experiencia con Power BI.
Configuración de inquilinos
La administración adecuada de la configuración de inquilinos en el servicio Power BI es
fundamental. La configuración de inquilinos es la principal forma de controlar qué
capacidades de Power BI están habilitadas y para qué grupos de usuarios de la
organización.
Es esencial que la configuración de inquilinos sea conforme a las directrices y directivas

de gobernanza, y también a la forma en que el COE toma decisiones. El hecho de que
un administrador de Power BI decida de manera independiente qué opciones de
configuración habilitar o deshabilitar, es un indicador claro de una oportunidad de
mejorar los procesos de gobernanza.
） Importante
La modificación de la configuración de inquilinos debe pasar por un proceso de

control de cambios con un mecanismo de aprobación. Debe documentar todos los
cambios, registrar quién ha realizado el cambio, cuándo y por qué.
Dado que los creadores y consumidores de contenido pueden leer fácilmente en línea
sobre las características disponibles en Power BI, puede resultar frustrante que las
capacidades no funcionen según lo previsto. Eso puede traducirse en usuarios
insatisfechos y una adopción de la organización, de los usuarios y de soluciones menos
eficaz.
Esta es una lista de preguntas comunes realizadas por usuarios confusos y frustrados:
¿Por qué no puedo crear un área de trabajo?

¿Por qué no puedo exportar datos?
¿Por qué no funciona mi objeto visual personalizado?
¿Por qué no puedo certificar un conjunto de datos?
Ｕ Precaución
Un administrador puede detectar situaciones que no son ideales, como demasiadas

exportaciones de datos en el registro de actividad. No caiga en el error de
deshabilitar completamente la característica. La prohibición de características lleva
a la frustración de los usuarios y a la adopción de soluciones alternativas. Antes de
deshabilitar una opción de configuración, averigüe por qué los usuarios confían en
determinadas técnicas. Quizás sea necesario rediseñar una solución, o puede que la
educación y el entrenamiento adicionales de los usuarios mitiguen los problemas.
Conclusión: el uso compartido de conocimientos es una forma eficaz de
gobernanza.
Dado que no hay ningún rol de lector para ver la configuración de inquilinos, puede ser
un desafío en organizaciones de mayor tamaño. Considere la posibilidad de publicar un
documento en el portal centralizado que describa la configuración de inquilinos, como
se explica en el artículo Mentoría y capacitación de los usuarios.
Las actividades siguientes se aplican al revisar y validar cada configuración de inquilino:
Configuración de inquilino:
Habilitado, o
Disabled
Configuración de inquilino aplicable a:
Toda la organización, o
Limitada a grupos de seguridad específicos:
¿Ya existe un grupo de seguridad adecuado?, o
¿Es necesario crear un nuevo grupo de seguridad?
Portal de administración
Como se indica en el artículo sobre niveles de madurez de la adopción de Power BI, la
adopción de la organización se refiere a la eficacia de los procedimientos de
gobernanza y administración de datos de Power BI para permitir y habilitar la BI
empresarial y la BI de autoservicio. La administración activa de todas las áreas del
servicio Power BI (además de la configuración de inquilinos) de acuerdo con los
objetivos de adopción influye directamente en la garantía de que todos los usuarios
tengan una buena experiencia con Power BI.
Otras responsabilidades para administrar el servicio Power BI incluyen lo siguiente:
Administración de áreas de trabajo y acceso

Configuración de capacidad Premium y Premium por usuario
Códigos para insertar
Objetos visuales de la organización
Conexiones de Azure
Personalización de marca
Contenido destacado
Además de estos vínculos de documentación, vea las notas del producto sobre el
planeamiento de una implementación empresarial de Power BI , donde se describen
consideraciones adicionales para la administración de Power BI.
Máquinas y dispositivos de usuario

La administración de máquinas y dispositivos de usuario suele ser responsabilidad del
departamento de TI. La adopción de Power BI depende directamente de que los
creadores y los consumidores de contenido tengan instaladas y configuradas
correctamente las aplicaciones que necesitan.
Las siguientes instalaciones de software están disponibles para los creadores de

contenido:
Software Audiencia
Power BI Creadores de contenido que desarrollan modelos de datos e informes

Desktop interactivos para su implementación en el servicio Power BI.
Power BI Creadores de contenido que desarrollan modelos de datos e informes

Desktop interactivos para su implementación en Power BI Report Server.
optimizado
para Report
Server
Generador de Creadores de contenido que desarrollan informes paginados para su

informes de implementación en el servicio Power BI o en Power BI Report Server.
Power BI
Software Audiencia
Aplicación Creadores de contenido o consumidores que interactúan con el contenido que se

Power BI ha publicado en el servicio Power BI o Power BI Report Server mediante iOS,
Mobile Android o Windows 10.
Puerta de Creadores de contenido que publican conjuntos de datos en el servicio Power BI

enlace de y administran la actualización de datos programada (consulte la sección
datos local Arquitectura y administración de la puerta de enlace de este artículo para
(modo obtener más información).
personal)
Herramientas Los creadores de contenido avanzados pueden usar opcionalmente herramientas

de terceros de terceros para la administración avanzada de modelos de datos.
） Importante
No todo el software que se indica es necesario para todos los creadores de

contenido. Power BI Desktop es el requisito más común y el punto de partida en
caso de duda.
Todos los creadores de contenido que colaboran con otros deberían utilizar la misma
versión de software, especialmente Power BI Desktop, que se actualiza mensualmente.
Lo ideal es que las actualizaciones de software estén disponibles desde Microsoft Store
o se instalen mediante un proceso de TI automatizado. De este modo, los usuarios no
tienen que realizar ninguna acción específica para obtener actualizaciones.
Dado que se publican nuevas capacidades continuamente, las actualizaciones de

software deben lanzarse con prontitud. De este modo, los usuarios pueden aprovechar
las nuevas capacidades y su experiencia está alineada con la documentación. También es
importante tener en cuenta el canal de actualización. Proporciona características nuevas
(y actualizadas) de aplicaciones Office, como Excel y Word, de forma periódica.
Otros elementos comunes que es posible que deban instalarse en las máquinas de los
usuarios incluyen:
Controladores para permitir la conectividad de datos, por ejemplo, el Motor de

base de datos de Oracle, HANA o Microsoft Access
El proveedor Analizar en Excel
Herramientas externas. Por ejemplo, Tabular Editor, DAX Studio o ALM Toolkit.
Conectores de origen de datos personalizados
Además de las instalaciones de software, en las máquinas de los usuarios se puede

administrar:
Configuración de directiva de grupo: por ejemplo, la directiva de grupo puede
especificar el uso permitido de objetos visuales personalizados en Power BI
Desktop. El objetivo es una experiencia de usuario coherente en Power BI Desktop
y el servicio Power BI. El objetivo es evitar la frustración del usuario (si se les
permitió crear contenido en Power BI Desktop que no se puede mostrar en el
servicio Power BI).
Configuración de registro: por ejemplo, puede elegir deshabilitar el formulario de
inicio de sesión de Power BI Desktop o ajustar el rendimiento del Editor de
consultas.
 Sugerencia
La administración eficaz del software, los controladores y la configuración puede

suponer una gran diferencia en la experiencia del usuario, lo que puede traducirse
en una mayor adopción de los usuarios y satisfacción, así como en menores costos
de asistencia técnica de usuario.
Architecture
Arquitectura de datos
La Arquitectura de datos se refiere a los principios, los procedimientos y las
metodologías que rigen y definen qué datos se recopilan y cómo se ingieren,
almacenan, administran, integran, modelan y usan.
Hay muchas decisiones de arquitectura de datos que tomar. Es habitual que el COE
participe en el diseño y el planeamiento de la arquitectura de datos. Es normal que los
administradores también se impliquen, especialmente si administran bases de datos o
infraestructura de Azure.
） Importante
Las decisiones de arquitectura de datos tienen un impacto considerable en la

adopción de Power BI, la satisfacción de los usuarios y las tasas de éxito de
proyectos individuales.
Algunas consideraciones de arquitectura de datos que afectan a la adopción de

Power BI incluyen:
¿Dónde encaja Power BI en la totalidad de la arquitectura de datos de la
organización? Y, ¿hay otros componentes existentes, como un almacenamiento de
datos empresarial (EDW) o un lago de datos, que sea importante tener en cuenta
en los planes?
¿Power BI se usa de un extremo a otro para la preparación de datos, el modelado
de datos y la presentación de datos? O bien, ¿Power BI usa solo algunas de esas
capacidades?
¿Se siguen los patrones de BI de autoservicio administrados para encontrar el
mejor equilibrio entre la reutilización de datos y la flexibilidad del creador del
informe?
¿Dónde van a consumir los usuarios el contenido? Por lo general, las tres formas
principales de entregar contenido son: el servicio Power BI, Power BI Report Server
e insertado en aplicaciones personalizadas. En las notas del producto sobre el
planeamiento de una implementación empresarial de Power BI se incluye una
sección sobre las opciones de arquitectura de Power BI en la que se explica cuándo
considerar cada una de estas tres opciones principales. Además,
Microsoft Teams es una alternativa cómoda al servicio Power BI, especialmente
para los usuarios que pasan mucho tiempo en Teams.
¿Quién es responsable de administrar y mantener la arquitectura de datos? ¿Es un
equipo centralizado o descentralizado? ¿Cómo está representado el COE en este
equipo? ¿Se requieren determinados conjuntos de aptitudes?
¿Cuáles son los orígenes de datos más importantes? ¿Qué tipo de datos se
adquirirán?
¿Qué opciones de modo de conectividad y modo de almacenamiento (por
ejemplo, los marcos de modelo de importación, conexión dinámica, DirectQuery o
compuesto) son las más adecuadas para los casos de uso?
¿Hasta qué punto se fomenta la reutilización de datos mediante conjuntos de
datos compartidos?
¿Hasta qué punto se fomenta la reutilización de la lógica de preparación de datos
y la preparación de datos avanzada mediante flujos de datos?
Durante el proceso de familiarización con Power BI, muchos administradores de

sistemas dan por hecho que se trata de una herramienta de consulta muy parecida a
SQL Server Reporting Services (SSRS). Sin embargo, en comparación, la gama de
capacidades de Power BI es enorme. Por lo tanto, es importante que los administradores
conozcan las capacidades de Power BI antes de tomar decisiones arquitectónicas.
 Sugerencia
Adopte el buen hábito de realizar una prueba de concepto (POC) técnica para
probar las suposiciones e ideas. Algunas organizaciones también las llaman
microproyectos cuando el objetivo es entregar una pequeña unidad de trabajo. El
objetivo de una POC es abordar lo desconocido y reducir el riesgo en la fase más
temprana posible. Una POC no tiene que ser un trabajo desechable, pero debe
tener un ámbito reducido. Las revisiones de procedimientos recomendados, como
se explica en el artículo Mentoría y capacitación de los usuarios, son otra manera
útil de ayudar a los creadores de contenido con decisiones arquitectónicas
importantes.
Administración de capacidad Premium

Power BI Premium incluye características y capacidades para ofrecer soluciones de BI
a gran escala. Las suscripciones Premium se pueden adquirir por capacidad o por
usuario con Premium por usuario (PPU). Esta sección se centra principalmente en la
capacidad Premium, que requiere supervisión administrativa adicional.
Power BI Premium puede desempeñar un papel importante en la estrategia de BI.

Algunas de las principales razones para invertir en Premium incluyen:
Distribución ilimitada de contenido a grandes cantidades de solo lectura (el

consumo de contenido con una licencia gratuita de Power BI está disponible solo
en la capacidad Premium, no en PPU).
Canalizaciones de implementación para administrar la publicación de contenido en
áreas de trabajo de desarrollo, pruebas y producción. Se recomiendan
encarecidamente para que el contenido crítico mejore la estabilidad de la versión.
Informes paginados para la entrega de informes de formato complejo y píxeles
perfectos. Este tipo de informe permite a los creadores de contenido satisfacer
otros tipos de requisitos de entrega de información.
Punto de conexión XMLA, que es un protocolo estándar del sector para
administrar y publicar un conjunto de datos, o consultar el conjunto de datos
desde cualquier herramienta compatible con XMLA.
Mayores límites de tamaño de modelos, incluida compatibilidad con conjuntos de
datos grandes.
Actualizaciones de datos más frecuentes.
Almacenamiento de datos en un área geográfica determinada (Multi-Geo solo está
disponible por capacidad).
Esta lista no incluye todo. Para obtener una lista completa de características Premium,
vea Preguntas más frecuentes sobre Power BI Premium.
Administración de la capacidad Premium

La supervisión del estado de la capacidad de Power BI Premium es una actividad
continua para los administradores. Por definición, la capacidad Premium incluye un nivel
fijo de recursos del sistema. Equivale a los límites de memoria y CPU que se deben
administrar para lograr un rendimiento óptimo.
Ｕ Precaución
La falta de administración y la superación de los límites de la capacidad Premium

pueden dar lugar a desafíos de rendimiento y de experiencia de los usuarios.
Ambos desafíos, si no se administran correctamente, pueden contribuir al impacto
negativo en los esfuerzos de adopción.
Sugerencias para administrar la capacidad Premium:
Cree un conjunto específico de criterios para el contenido que se va a publicar en

la capacidad Premium. Esto es especialmente relevante si varias unidades de
negocio usan una sola capacidad, ya que existe la posibilidad de interrumpir a
otros usuarios si la capacidad no se administra bien. Para obtener una lista de
elementos que se pueden incluir en la revisión de procedimientos recomendados
(por ejemplo, tamaño razonable del conjunto de datos y cálculos eficaces), vea el
artículo Mentoría y capacitación de los usuarios.
Use periódicamente la aplicación de supervisión Premium para comprender el uso
de recursos y los patrones de la capacidad Premium. Lo más importante es buscar
patrones coherentes de sobreutilización que contribuyan a las interrupciones del
usuario. Un análisis de patrones de uso también debe visibilizar si la capacidad
está infrautilizada, lo que indica que se podría obtener más valor de la inversión.
Establezca la configuración de inquilinos de modo que Power BI le avise si la
capacidad Premium se sobrecarga o si se produce una interrupción o un
incidente.
Escalado automático
La escalabilidad automática es una funcionalidad de Power BI Premium. Su objetivo es
manejar los aumentos ocasionales o inesperados en los niveles de uso de Premium. La
escalabilidad automática puede responder a estos aumentos si incrementa
automáticamente los recursos de CPU para permitir el aumento de la carga de trabajo.
El escalado vertical automatizado reduce el riesgo de desafíos de rendimiento y

experiencia de los usuarios a cambio de un impacto financiero. Si la capacidad Premium
no está bien administrada, la escalabilidad automática puede desencadenarse con más
frecuencia de lo esperado. En este caso, la aplicación de supervisión Premium puede
ayudarle a determinar los problemas subyacentes y a planificar la capacidad.
Administración descentralizada de la capacidad Premium
Los administradores de capacidad son responsables de asignar áreas de trabajo a una

capacidad específica.
Tenga en cuenta que los administradores de áreas de trabajo también pueden asignar
un área de trabajo a PPU si el administrador del área de trabajo posee una licencia PPU.
Pero eso exigiría que todos los demás usuarios del área de trabajo también tuvieran una
licencia PPU.
Es posible configurar varias capacidades para facilitar la administración descentralizada

por parte de diferentes unidades de negocio. La descentralización de la administración
de determinados aspectos de Power BI es una excelente manera de equilibrar la agilidad
y el control.
Este es un ejemplo que describe una manera de administrar la capacidad Premium.
Compre un nodo de capacidad P3 en Microsoft 365. Incluye 32 núcleos virtuales.

Use 16 núcleos para crear la primera capacidad. Lo usará el equipo de ventas.
Use 8 núcleos para crear la segunda capacidad. Lo usará el equipo de operaciones.
Use los 8 núcleos restantes a fin de crear la tercera capacidad. Admitirá el uso
general.
Este ejemplo tiene varias ventajas.
Se pueden configurar administradores de capacidad independientes para cada

capacidad. Por lo tanto, facilita situaciones de administración descentralizadas.
Si una capacidad no está bien administrada, el efecto se limita a esa capacidad. Las
demás capacidades no se ven afectadas.
Sin embargo, el ejemplo también tiene desventajas.
Los límites por capacidad son inferiores. El tamaño máximo de memoria permitido
para los conjuntos de datos no es el tamaño de nodo de capacidad P3 completo.
En su lugar, es el tamaño de capacidad asignado donde se hospeda el conjunto de
datos.
Es más probable que una de las capacidades más pequeñas se deba escalar
verticalmente en algún momento.
Hay más capacidades para administrar en el inquilino de Power BI.
Arquitectura y administración de la puerta de enlace
La puerta de enlace de datos facilita la transferencia segura y eficaz de datos entre
orígenes de datos de la organización y el servicio Power BI. Se necesita una puerta de
enlace de datos para la conectividad de datos con servicios en la nube o locales cuando
un origen de datos presenta alguna de estas características:
Ubicado dentro del centro de datos de la empresa.

Configurado detrás de un firewall.
Dentro de una red virtual.
Dentro de una máquina virtual.
Hay tres tipos de puertas de enlace.
La puerta de enlace de datos local (modo estándar) es un servicio de puerta de

enlace que admite conexiones con orígenes de datos registrados para su uso por
parte de muchos usuarios. Las instalaciones y actualizaciones de software de la
puerta de enlace se instalan en una máquina administrada por el cliente.
La puerta de enlace de datos local (modo personal) es un servicio de puerta de
enlace que solo admite la actualización de datos. Este modo de puerta de enlace
normalmente se instala en el equipo del creador de contenido. Solo admite el uso
por parte de un usuario. No admite conexiones dinámicas ni conexiones
DirectQuery.
La puerta de enlace de datos de red virtual es un servicio administrado por
Microsoft que admite la conectividad por parte de muchos usuarios. En concreto,
admite la conectividad con conjuntos de datos y flujos de datos almacenados en
áreas de trabajo asignadas a la capacidad Premium o Premium por usuario.
 Sugerencia
La decisión de quién puede instalar software de puerta de enlace es una decisión

de gobernanza. Para la mayoría de las organizaciones, se debe animar
encarecidamente el uso de la puerta de enlace de datos en modo estándar o una
puerta de enlace de datos de red virtual. Son mucho más escalables, administrables
y auditables que las puertas de enlace de datos en modo personal.
Administración descentralizada de la puerta de enlace

La puerta de enlace de datos local (modo estándar) y la puerta de enlace de datos de
red virtual admiten tipos de orígenes de datos específicos que se pueden registrar, junto
con detalles de conexión y modo de almacenamiento de las credenciales. Los usuarios
pueden tener permiso para usar el origen de datos de puerta de enlace para que
puedan programar una actualización o ejecutar consultas de DirectQuery.
Determinados aspectos de la administración de la puerta de enlace se pueden llevar a

cabo de forma eficaz de manera descentralizada para equilibrar la agilidad y el control.
Por ejemplo, el grupo de operaciones puede tener una puerta de enlace dedicada a su
equipo de creadores de contenido de autoservicio y propietarios de datos.
La administración descentralizada de la puerta de enlace funciona mejor cuando se trata

de un esfuerzo conjunto, como se muestra a continuación.
Administrada por los propietarios de datos descentralizados:
Información de conectividad y niveles de privacidad del origen de datos

departamental.
Credenciales almacenadas del origen de datos departamental (incluida la
responsabilidad de actualizar los cambios de contraseña rutinarios).
Usuarios del origen de datos departamental a los que se permite usar cada origen
de datos.
Administrada por propietarios de datos centralizados (incluye orígenes de datos

ampliamente usados en la organización; la administración está centralizada para evitar
orígenes de datos duplicados):
Información de conectividad y niveles de privacidad del origen de datos

centralizado.
Credenciales almacenadas del origen de datos centralizado (incluida la
responsabilidad de actualizar los cambios de contraseña rutinarios).
Usuarios del origen de datos centralizado a los que se permite usar cada origen de
datos.
Administrada por TI:
Actualizaciones de software de la puerta de enlace (las actualizaciones de la puerta

de enlace se suelen publicar mensualmente).
Instalación de controladores y conectores personalizados (los mismos que se han
instalado en las máquinas de usuario).
Administración de clústeres de puerta de enlace (número de máquinas del clúster
de puerta de enlace para alta disponibilidad, recuperación ante desastres y para
eliminar un único punto de error, lo que puede provocar interrupciones
importantes de los usuarios).
Administración del servidor (por ejemplo, sistema operativo, RAM, CPU o
conectividad de red).
Administración y copia de seguridad de claves de cifrado de puerta de enlace.
Supervisión de los registros de puerta de enlace para evaluar cuándo es necesario
escalar vertical u horizontalmente.
Alertas de tiempo de inactividad o recursos bajos persistentes en la máquina de
puerta de enlace.
 Sugerencia
Permitir que un equipo descentralizado administre determinados aspectos de la

puerta de enlace significa que este puede moverse más rápido. La desventaja de la
administración descentralizada de puertas de enlace significa la ejecución de más
servidores de puertas de enlace para que cada uno se pueda dedicar a un área
específica de la organización. Si es TI el que controla por completo la
administración de la puerta de enlace, es imperativo contar con un buen proceso
para controlar rápidamente las solicitudes para agregar orígenes de datos y aplicar
actualizaciones de usuario.
Licencias de usuario
Cada usuario del servicio Power BI necesita una licencia comercial integrada con una
identidad de Azure AD. La licencia de usuario puede ser Gratis, Power BI Pro o Power BI
Premium por usuario.
Una licencia de usuario se obtiene por medio de una suscripción que autoriza un
número determinado de licencias con una fecha de inicio y finalización.
Existen dos enfoques para la obtención de suscripciones.
Centralizada: el administrador de facturación de Microsoft 365 adquiere una

suscripción de Power BI Pro o Premium por usuario . Es la manera más común de
administrar suscripciones y asignar licencias.
Descentralizada: los departamentos individuales compran una suscripción
mediante compra autoservicio.
Compra autoservicio
Una decisión de gobernanza importante está relacionada con la medida en que se
permite o se fomenta la compra autoservicio.
La compra autoservicio es útil para:

Organizaciones de mayor tamaño con unidades de negocio descentralizadas que
tienen autoridad de compra y quieren controlar el pago directamente con una
tarjeta de crédito.
Organizaciones que pretenden facilitar lo más posible la compra de suscripciones
mediante un compromiso mensual.
Considere la posibilidad de deshabilitar la compra autoservicio si:
Hay procesos de adquisición centralizados en vigor para cumplir requisitos

reglamentarios, de seguridad y de gobernanza.
Se obtienen precios con descuento por medio de un Contrato Enterprise (EA).
Hay procesos existentes en vigor para controlar los contracargos dentro de la
empresa.
Hay procesos existentes en vigor para controlar las asignaciones de licencias
basadas en grupos.
Son necesarios requisitos previos para obtener una licencia, como un requisito de
directiva de aprobación, justificación, entrenamiento o gobernanza.
Existe una necesidad válida, como un requisito normativo, de controlar el acceso al
servicio Power BI de forma muy estrecha.
Evaluaciones de licencias de usuario

Otra decisión de gobernanza importante es si se permiten las pruebas de licencia de
usuario. De manera predeterminada, las pruebas están habilitadas. Esto significa que
cuando se comparte contenido con un compañero, si el destinatario no tiene una
licencia de Power BI Pro o Premium por usuario, se le pide que inicie una prueba para
ver el contenido (si este no reside en la capacidad Premium). La experiencia de prueba
es una gran comodidad y permite a los usuarios continuar con su flujo de trabajo
normal.
Por lo general, no se recomienda deshabilitar las pruebas. Puede animar a los usuarios a
aplicar soluciones alternativas, quizás exportando datos o trabajando con herramientas
y procesos no admitidos.
Considere la posibilidad de deshabilitar las pruebas solo si:
Hay problemas de costo graves que harían improbable que se concedieran

licencias completas al final del período de prueba.
Son necesarios requisitos previos para obtener una licencia (como un requisito de
directiva de aprobación, justificación, entrenamiento o gobernanza). No es
suficiente cumplir este requisito durante el período de prueba.
Existe una necesidad válida, como un requisito normativo, de controlar el acceso al
servicio Power BI de forma muy estrecha.
 Sugerencia
No establezca demasiadas barreras para obtener una licencia de Power BI. Los
usuarios que tienen que hacer un trabajo van a encontrar una manera, y eso puede
conllevar soluciones alternativas que no son ideales. Por ejemplo, sin una licencia
para usar el servicio Power BI, los usuarios pueden depender demasiado del uso
compartido de archivos en un sistema de archivos o por correo electrónico, cuando
hay disponibles métodos mucho mejores.
Administración de costos
La administración y la optimización del costo de los servicios en la nube, como Power BI,
es una actividad importante. Estas son algunas actividades que puede que quiera tener
en cuenta.
Analice quién usa y, más concretamente, no usa, las licencias asignadas de

Power BI y realice los ajustes necesarios. El uso de Power BI se analiza mediante el
registro de actividad.
Analice la rentabilidad de la capacidad Premium o Premium por usuario. Además
de las características adicionales, realice un análisis de costos y ventajas para
determinar si las licencias Premium son más rentables cuando hay un gran número
de consumidores. La distribución de contenido ilimitada solo está disponible con
capacidad Premium, no con licencias PPU.
Supervise y administre cuidadosamente la capacidad Premium. El reconocimiento
de los patrones de uso a lo largo del tiempo le permitirá predecir cuándo comprar
capacidad adicional. Por ejemplo, puede optar por escalar verticalmente una sola
capacidad de P1 a P2, o escalar horizontalmente de una capacidad P1 a dos
capacidades P1.
Si hay picos ocasionales en el nivel de uso, se recomienda utilizar la escalabilidad
automática con Power BI Premium para garantizar una experiencia del usuario
ininterrumpida. La escalabilidad automática escalará verticalmente los recursos de
capacidad durante 24 horas y luego los devolverá a los niveles normales (siempre
que no haya actividad sostenida). Administre el costo de la escalabilidad
automática mediante la restricción del número máximo de núcleos virtuales, o con
límites de gasto establecidos en Azure (ya que la escalabilidad automática se
admite en el servicio Azure Power BI Embedded). Debido al modelo de precios, la
escalabilidad automática es más adecuada para controlar los aumentos
ocasionales no planeados de uso.
En el caso de los orígenes de datos de Azure, colóquelos en la misma región que
el inquilino de Power BI siempre que sea posible. Evitará incurrir en cargos de
salida de Azure . Los cargos de salida de datos son mínimos, pero, a gran escala,
pueden sumar costos considerables no planeados.
Seguridad, protección de la información y

prevención de pérdida de datos
La seguridad, la protección de la información y la prevención de pérdida de datos (DLP)
son responsabilidades conjuntas entre todos los creadores de contenido, consumidores
y administradores. No es tarea pequeña, porque hay información confidencial en todas
partes: datos personales, datos de clientes o datos creados por clientes, información de
salud protegida, propiedad intelectual e información propiedad de una organización,
por nombrar algunos. La normativa gubernamental, del sector y contractual puede tener
un gran impacto en las directrices y directivas de gobernanza que se crean relacionadas
con la seguridad.
Las Notas del producto sobre la seguridad de Power BI son un recurso excelente para
comprender la variedad de consideraciones, incluidos aspectos que Microsoft
administra. En esta sección se presentan varios temas que los clientes son responsables
de administrar.
Responsabilidades del usuario

Algunas organizaciones piden a los usuarios de Power BI que acepten una confirmación
de usuario autoservicio. Se trata de un documento que explica las responsabilidades y
expectativas del usuario para proteger los datos de la organización.
Una manera de automatizar su implementación es con una directiva de condiciones de

uso de Azure AD. El usuario debe aceptar la directiva para poder visitar el servicio
Power BI por primera vez. También puede requerir que se confirme periódicamente,
como una renovación anual.
Seguridad de los datos

En un modelo de responsabilidad compartida en la nube, la protección de datos
siempre es responsabilidad del cliente. Con una plataforma de BI de autoservicio, los
creadores de contenido de autoservicio tienen la responsabilidad de proteger
correctamente el contenido que se comparte con colegas.
El COE debe proporcionar documentación y entrenamiento cuando sea pertinente para

ayudar a los creadores de contenido con procedimientos recomendados (especialmente
situaciones para tratar con datos ultra confidenciales).
Los administradores pueden ser de ayuda si siguen los procedimientos recomendados

ellos mismos. Además, también pueden avisar cuando observan problemas que podrían
detectarse al administrar áreas de trabajo,auditar las actividades de los usuarios o
administrar credenciales de puerta de enlace y usuarios. También hay varias
configuraciones de inquilinos que normalmente están restringidas, excepto para
algunos usuarios (por ejemplo, la capacidad de publicar en la web o de publicar
aplicaciones en toda la organización).
Usuarios invitados externos

Los usuarios externos (como asociados, clientes, proveedores y consultores) son muy
habituales en algunas organizaciones y muy poco frecuentes en otras. La forma de
controlar a los usuarios externos es una decisión de gobernanza.
El acceso de los usuarios externos se controla mediante laconfiguración de inquilinos

del servicio Power BI y algunos parámetros de Azure AD. Para obtener más detalles
sobre las consideraciones de los usuarios externos, revise las notas del producto
Distribución del contenido de Power BI a usuarios invitados externos con Azure AD B2B.
Protección de la información y prevención de pérdida de

datos
Power BI admite capacidades para la protección de la información y la prevención de la
pérdida de datos (DLP) de las siguientes maneras.
Information Protection:Microsoft Purview Information Protection (anteriormente

conocido como Microsoft Information Protection) incluye funcionalidades para
detectar, clasificar y proteger datos. Un principio clave es que los datos se pueden
proteger mejor una vez clasificados. El bloque de creación clave para clasificar los
datos es etiquetas de confidencialidad. Para más información, consulte el artículo
Protección de la información para la planificación de Power BI.
Prevención de pérdida de datos para Power BI: Prevención de pérdida de datos
de Microsoft Purview (anteriormente conocido como prevención de pérdida de
datos Office 365) admite directivas DLP para Power BI. Mediante el uso de
etiquetas de confidencialidad o tipos de información confidencial, las directivas
DLP para Power BI ayudan a una organización a localizar conjuntos de datos
confidenciales. Para más información, consulte Prevención de pérdida de datos
para la planificación de Power BI.
Microsoft Defender for Cloud Apps:Microsoft Defender for Cloud Apps
(anteriormente conocido como Microsoft Cloud App Security) admite directivas
que ayudan a proteger los datos, incluidos los controles en tiempo real cuando los
usuarios interactúan con el servicio Power BI. Para más información, consulte
Planificación de Defender for Cloud Apps para Power BI.
Residencia de datos
En las organizaciones con requisitos de almacenamiento de datos en una región
geográfica, se puede configurar la capacidad Premium (no PPU) para una región
específica distinta de la región del inquilino principal de Power BI.
Claves de cifrado
Microsoft controla el cifrado de datos en reposo en centros de datos de Microsoft con
cifrado transparente de servidor y rotación automática de certificados. En el caso de los
clientes con requisitos normativos de administrar la clave de cifrado Premium por sí
mismos, la capacidad Premium se puede configurar para el empleo de Azure Key Vault.
El uso de claves administradas por el cliente, también conocidas como Bring Your Own
Key o BYOK, es una precaución para asegurarse de que, en caso de error humano por
parte de un operador del servicio, no se puedan exponer los datos del cliente.
Tenga en cuenta que Premium por usuario (PPU) solo admite BYOK cuando está
habilitado para todo el inquilino de Power BI.
Hay una gran cantidad de metadatos disponibles para comprender lo que sucede
dentro del inquilino de Power BI. El principal origen de información es el registro de
actividad de Power BI,que captura información sobre muchos tipos diferentes de
actividades que realizan los usuarios.
También hay una serie de API REST que proporcionan información adicional sobre áreas
de trabajo, aplicaciones, conjuntos de datos, etc. De especial interés para los
administradores son las API de administrador. Estas API proporcionan un medio de
extraer metadatos de todo el inquilino. El módulo de administración de Power BI es un
conjunto de comandos de PowerShell que facilitan la obtención de metadatos en lugar
de trabajar directamente con las API. Pero hay mucha más información disponible
directamente desde las API.
También hay disponible información uso y rendimiento a largo plazo de las áreas de
trabajo respaldadas por la capacidad Premium. Los administradores pueden analizar la
actividad, el rendimiento y el comportamiento del conjunto de datos. Esta capacidad
está integrada en Azure Log Analytics.
Auditoría
La auditoría de los datos es valiosa para comunicar los objetivos de adopción y realizar
un seguimiento de ellos, lo que ayuda al COE a ser más eficaz, a concebir ideas para
documentación o nuevo entrenamiento de utilidad, así como para la elaboración de
informes relacionados con la gobernanza.
En la tabla siguiente se presentan algunas ideas sobre lo que se puede hacer con la
información disponible en el registro de actividad de Power BI y las API:
Categoría de datos de auditoría Tipo de preguntas
Patrones de uso y adopción ¿Cuál es el contenido más usado y por parte de quién?
¿Cuántos usuarios activos hay?
¿Las vistas de informe tienen tendencia al alza o a la

baja?
¿Hay contenido infrautilizado o abandonado?
¿Los usuarios usan con más frecuencia aplicaciones

móviles o exploradores?
¿Cuándo se publica o actualiza el contenido y quién lo

hace?
Categoría de datos de auditoría Tipo de preguntas
Gobernanza, seguridad y ¿Cuándo se actualizan los roles de área de trabajo y

cumplimiento quién lo hace?
¿Cuántos usuarios externos acceden al contenido?
¿Quién ha agregado o actualizado una etiqueta de

confidencialidad?
¿Cuándo cambia una configuración de inquilino y quién

la modifica?
¿Qué porcentaje de vistas de informe se basa en

conjuntos de datos certificados?
¿Qué porcentaje de conjuntos de datos admite más de

un informe?
¿Con qué frecuencia se descarga el contenido y quién lo

hace?
¿Quién ha generado un código para insertar para

publicar en la web?
Informes y análisis de arquitectura ¿Cuántas áreas de trabajo hay por tipo?
¿Cuántos informes hay por tipo?
¿Cuándo se crea o actualiza una puerta de enlace o un

origen de datos?
Oportunidades de educación de ¿Quién ha iniciado una prueba de Power BI?

usuarios y entrenamiento
¿Quién está haciendo demasiado uso compartido desde
su área de trabajo personal?
¿Quién está publicando muchos conjuntos de datos

nuevos?
¿Quién está exportando mucho?
Al pensar en las necesidades para crear informes de auditoría, tenga en cuenta lo

siguiente:
¿Qué significa éxito?

¿Qué comportamientos quiere fomentar?
¿Qué quiere que empiecen a hacer los usuarios?
¿Qué quiere que dejen de hacer los usuarios?
） Importante
Los archivos de datos sin procesar que contienen los datos de auditoría deben
almacenarse en una ubicación muy segura, preferiblemente una que sea inmutable
(que no permita modificaciones ni eliminaciones). El almacenamiento inmutable
permite a los auditores confiar en estos datos. Un servicio como Azure Data Lake
Storage Gen2 es una alternativa flexible y de bajo costo para este fin.
Supervisión
Microsoft Defender for Cloud Apps es un agente de seguridad de acceso a la nube
(CASB) que permite a los administradores realizar actividades como las siguientes:
Auditar, supervisar y generar alertas basadas en actividades

Creación de directivas de prevención de pérdida de datos
Detectar comportamientos inusuales y sesiones de riesgo
Limitar las actividades realizadas por las aplicaciones (con el control de
aplicaciones de acceso condicional de Azure AD)
Con Defender for Cloud Apps hay disponibles algunas funciones de supervisión y
protección de Power BI muy eficaces. Por ejemplo, puede:
Prohibir que todos los usuarios (o algunos) descarguen un archivo del servicio
Power BI cuando se asigne una etiqueta de confidencialidad específica.
Recibir una alerta cada vez que se actualice una configuración de inquilino en el
servicio Power BI (por ejemplo, si se detecta una actividad administrativa).
Detectar comportamientos sospechosos o inusuales, como descargas masivas de
archivos o un número inusual de operaciones de uso compartido en el servicio
Power BI.
Buscar en el registro de actividad actividades específicas relacionadas con el
contenido con una etiqueta de confidencialidad concreta asignada, como las
exportaciones desde el servicio Power BI.
Recibir una notificación cuando tengan lugar sesiones de riesgo, como cuando la
misma cuenta de usuario se conecta desde distintas áreas geográficas en un
período de tiempo corto.
Determinar si alguien de fuera de un grupo de seguridad predefinido ve contenido
específico en el servicio Power BI.
Ｕ Precaución
Las licencias, el costo y los permisos administrativos de Defender for Cloud Apps se
administran de manera independiente a Power BI. Puede crear un administrador
específico de la aplicación con permisos con ámbito para supervisar solo el
servicio Power BI.
Planeación de los cambios

Cada mes se publican nuevas características y funcionalidad de Power BI. Para ser
eficaces, los implicados en la supervisión del sistema deben estar al día.
El blog de Power BI es el mejor lugar para que los clientes estén al tanto de los
anuncios y las nuevas versiones.
En el plan de versiones de Power BI los clientes pueden encontrar la hoja de ruta

pública de las características futuras y las fechas estimadas. A veces, un próximo cambio
es tan importante que resulta útil empezar a planearlo con bastante antelación. El ciclo
de planeación va por semestres: abril-septiembre y octubre-marzo.
） Importante
Es difícil sobrestimar la importancia de mantenerse al día. Llevar unos meses de

retraso con respecto a los anuncios puede dificultar la administración correcta del
servicio Power BI y el soporte a la población de usuarios de manera eficaz.
Lista de comprobación: a continuación se exponen las consideraciones y medidas clave

que puede adoptar para supervisar el sistema.
Mejorar la supervisión del sistema:
＂ Compruebe quién puede ser administrador de Power BI: en el caso de que se le

haya concedido el rol de administrador de Power BI a varias personas, reduzca el
número si es posible.
＂ Utilice PIM para administradores ocasionales: si tiene personas que
ocasionalmente necesitan derechos de administrador de Power BI, considere la
posibilidad de implementar Privileged Identity Management (PIM) de Azure AD.
Está diseñado para asignar permisos de rol Just-In-Time que expiran pasadas unas
horas.
＂ Administradores de entrenamiento: compruebe el estado del entrenamiento
cruzado y la documentación en vigor para controlar las responsabilidades de
administración de Power BI. Asegúrese de que una persona de copia de seguridad
esté entrenada para que las necesidades se puedan satisfacer oportunamente, de
forma coherente.
Mejorar la administración del servicio Power BI:
＂ Revisar la configuración de inquilino: revise todas las configuraciones de inquilino

para asegurarse de que están alineadas con los objetivos de la cultura de los datos
y las directrices y directivas de gobernanza. Compruebe qué grupos hay asignados
en cada configuración.
＂ Documentar la configuración de inquilino: cree documentación de la
configuración de inquilino de la comunidad de Power BI interna y publíquela en el
portal centralizado. Incluya qué grupos tendría que solicitar un usuario para poder
usar una característica.
＂ Personalizar los vínculos de Obtener ayuda: cuando se establezcan recursos de
usuario, como se explica en el artículo Mentoría y capacitación de los usuarios,
actualice la configuración de inquilino para personalizar los vínculos de la opción de
menú Obtener ayuda. Eso dirige a los usuarios a la documentación, la comunidad y
la ayuda.
Mejorar la administración de equipos y dispositivos de usuario:
＂ Crear un proceso de incorporación consistente: revise el proceso para el control

de la incorporación de nuevos creadores de contenido. Determine si las nuevas
solicitudes de software, como Power BI Desktop, y licencias de usuario
(Power BI Pro o Premium por usuario) se pueden administrar conjuntamente. Eso
puede simplificar la incorporación, ya que los nuevos creadores de contenido no
siempre van a saber qué pedir.
＂ Controlar las actualizaciones de los equipos de los usuarios: asegúrese de que
haya un proceso automatizado para instalar y actualizar el software, los
controladores y la configuración con el fin de asegurarse de que todos los usuarios
tengan la misma versión.
Planificación de arquitectura de datos:
＂ Evalúe el aspecto de la arquitectura de datos de un extremo a otro y asegúrese de

que tiene claro lo siguiente:
Cómo usan Power BI actualmente las distintas unidades de negocio de la
organización frente a cómo quiere se use. Determine si hay alguna brecha.
Si hay algún riesgo que se deba abordar.
Si hay situaciones de alto mantenimiento que se deban abordar.
Los orígenes de datos que son importantes para los usuarios de Power BI y
cómo se documentan y detectan.
＂ Revise las puertas de enlace de datos existentes y averigüe qué puertas de enlace
se usan en toda la organización. Compruebe que los administradores de puertas de
enlace y los usuarios están configurados correctamente. Compruebe quién presta
soporte a cada puerta de enlace y que haya un proceso de confianza en vigor para
mantener actualizados los servidores de puertas de enlace.
＂ Verifique el uso de puertas de enlace personales: compruebe el número de
puertas de enlace personales que están en uso y quién las utiliza. Si se hace un uso
considerable, tome medidas para avanzar hacia el uso de la puerta de enlace de
modo estándar.
Mejorar la administración de licencias de usuario:
＂ Revise el proceso para solicitar una licencia de usuario: aclare cuál es el proceso,
incluidos los requisitos previos, para que los usuarios obtengan una licencia.
Determine si hay mejoras que se deben realizar en el proceso.
＂ Determine cómo controlar la compra de licencias de autoservicio: aclare si la
compra de licencias de autoservicio está habilitada. Actualice la configuración si no
coinciden con las intenciones de cómo se pueden comprar las licencias.
＂ Confirme cómo se controlan las pruebas de usuario: compruebe que las
evaluaciones de licencias de usuario están habilitadas o deshabilitadas. Tenga en
cuenta que todas las evaluaciones de usuario son Premium por usuario. Se aplican
a los usuarios con licencia gratuita que se suscriben a una prueba, así como a los
usuarios de Power BI Pro que se suscriben a una prueba de Premium por usuario.
Mejora de la administración de costos:
＂ Determine cuáles son los objetivos de administración de costos y cómo equilibrar

el costo, las características, los patrones de uso y el uso eficaz de los recursos.
Programe un proceso rutinario para evaluar los costos, al menos anualmente.
＂ Obtenga datos de registro de actividad: asegúrese de que tiene acceso a los datos
del registro de actividad para ayudar con el análisis de costos. Se puede usar para
comprender quién está, o no, utilizando la licencia asignada a ellos.
Mejora de la seguridad y protección de datos:
＂ Aclare exactamente cuáles son las expectativas para la protección de datos:

asegúrese de que las expectativas de protección de datos, como el uso de etiquetas
de confidencialidad, se documentan y se comunican a los usuarios.
＂ Determine cómo controlar usuarios externos: comprenda y documente las
directivas organizativas para compartir contenido de Power BI con usuarios
externos. Asegúrese de que la configuración del servicio Power BI admita las
directivas para usuarios externos.
＂ Configure la supervisión: investigue el uso de Microsoft Defender for Cloud Apps
para supervisar el comportamiento y las actividades de los usuarios en el servicio
Power BI.
Mejorar la auditoría y la supervisión:
＂ Recupere y almacene datos del registro de actividad: comience a recuperar datos

del registro de actividad de Power BI si no está compilando actualmente los datos
sin procesar. La manera más fácil de empezar es usar el cmdlet Get-
PowerBIActivityEvent de PowerShell incluido en el módulo de administración de
Power BI. Recupere y almacene los datos sin procesar sin filtrar ni aplicar formato
para asegurarse de que todos los elementos de datos estén disponibles para su
análisis futuro. Un sistema de archivos o lago de datos es una ubicación ideal para
almacenar los archivos JSON.
＂ Incluya datos de autoría adicionales:con el tiempo, determine qué datos de
auditoría adicionales serían útiles para complementar los datos del registro de
actividad.
Niveles de madurez

supervisión del sistema de Power BI.
Level Estado de supervisión del sistema de Power BI
100: Inicial La configuración de inquilinos la establecen independientemente uno o más

administradores según su propio criterio.
Las necesidades de la arquitectura, como las puertas de enlace y las capacidades,

se satisfacen según sea necesario. Sin embargo, no hay un plan estratégico.
No se usan registros de actividad de Power BI, o se usan de forma selectiva con

fines tácticos.
200: La configuración de inquilinos se alinea a propósito con las directivas y las

Repetible directrices de gobernanza establecidas. Todas las configuraciones de inquilino se
revisan periódicamente.
Se selecciona un pequeño número de administradores específicos. Todos los

administradores tienen una buena comprensión de lo que los usuarios intentan
lograr en Power BI, por lo que están en una buena posición para servir de apoyo a
los usuarios.
Existe un proceso bien definido para que los usuarios soliciten licencias y software.
Los formularios de solicitud son fáciles de encontrar para los usuarios. Se
especifica la configuración de compra de autoservicio.
Las etiquetas de confidencialidad se configuran en Microsoft 365. Sin embargo, el

uso de etiquetas sigue siendo incoherente. Los usuarios no comprenden bien las
ventajas de la protección de datos.
300: La configuración de inquilinos está totalmente documentada en el portal

Definido centralizado para referencia de los usuarios, incluido cómo solicitar acceso a los
grupos correctos.
Existe entrenamiento cruzado y documentación para que los administradores

garanticen la continuidad, la estabilidad y la consistencia.
Las etiquetas de confidencialidad se asignan al contenido de forma coherente. Los

usuarios comprenden las ventajas de usar etiquetas de confidencialidad para la
protección de datos.
Hay un proceso automatizado para exportar el registro de actividad de Power BI y

los datos de API a una ubicación segura para la creación de informes y la auditoría.
400: Los administradores trabajan estrechamente con el COE y los equipos de

Competente gobernanza para proporcionar supervisión de Power BI. Se logra correctamente un
equilibrio entre la capacitación y la gobernanza de los usuarios.
La administración descentralizada de la arquitectura de datos (como las puertas de

enlace o la administración de capacidades) se controla eficazmente para equilibrar
la agilidad y el control.
Hay directivas automatizadas configuradas y supervisadas de manera activa en

Microsoft Defender for Cloud Apps para la prevención de la pérdida de datos.
El registro de actividad de Power BI y los datos de API se analizan de forma activa

para supervisar y auditar las actividades de Power BI. Se toman medidas proactivas
en función de los datos.
500: Los administradores de Power BI trabajan estrechamente con el COE para

Efficient mantenerse al día. Las entradas de blog y los planes de lanzamiento del equipo de
productos de Power BI se revisan con frecuencia para planificar los próximos
cambios.
Se realiza un análisis de administración de costos periódico para garantizar que las

necesidades de los usuarios se satisfagan de forma rentable.
El registro de actividad de Power BI y los datos de la API se utilizan de manera

activa para informar de los esfuerzos de adopción y gobernanza y mejorarlos.
Pasos siguientes
Para obtener más información sobre la supervisión del sistema y la administración de
Power BI, consulte los siguientes recursos.
Administrar Power BI: parte 1

Administrar Power BI: parte 2
Administrador en un día de entrenamiento: día 1
Administrador en un día de entrenamiento: día 2
Notas del producto sobre la seguridad de Power BI
Notas del producto sobre los usuarios invitados externos
Enterprise
Marco de adopción de Power BI
En el siguiente artículo de la serie de la hoja de ruta de adopción de Power BI, para

terminar, obtenga información sobre los recursos relacionados con la adopción que
pueden ser de utilidad.
Conclusión de la hoja de ruta de
adopción de Power BI
７ Nota
En este artículo se concluye la serie de adopción de Power BI. Las consideraciones

estratégicas y tácticas y los elementos de acción presentados en esta serie le ayudarán
en sus esfuerzos de adopción de Power BI y de creación de una cultura de datos
productiva en su organización.
En esta serie se han abordado los siguientes aspectos de la adopción de Power BI.
Introducción a la adopción
Niveles de madurez de la adopción
Administración y propiedad del contenido
Gobernanza
Mentoría y capacitación
Comunidad práctica
El resto de este artículo incluye acciones sugeridas que deben realizarse a continuación.
También incluye otros recursos relacionados con la adopción que pueden ser útiles.
Acciones que deben realizarse a continuación

Puede ser abrumador decidir dónde empezar. La siguiente serie de pasos proporciona
un proceso que le ayudará a abordar las acciones que deben realizarse a continuación.
1. Aprenda: en primer lugar, lea esta serie de artículos de principio a fin. Familiarícese
con las consideraciones estratégicas y tácticas y los elementos de acción que
conducen directamente a la adopción correcta de Power BI. Le ayudarán a crear
una cultura de datos en su organización. Analice los conceptos con sus
compañeros.
2. Evalúe el estado actual: en cada área de la hoja de ruta de adopción, evalúe el
estado actual. Documente sus hallazgos. Su objetivo es tener bien claro sobre
dónde está ahora para que pueda tomar decisiones informadas sobre lo que debe
hacer a continuación.
3. Aclare la estrategia: asegúrese de que está claro cuáles son los objetivos de su
organización para adoptar Power BI. Confirme que los objetivos de adopción de
Power BI se alinean con los objetivos estratégicos más amplios de su organización
para el uso de datos, análisis e inteligencia empresarial en general. Céntrese en lo
que es su estrategia inmediata para los próximos 3-12 meses.
4. Identifique el estado futuro: en cada área de la hoja de ruta, identifique las
diferencias entre lo que quiere que suceda (su estado futuro) y lo que está
sucediendo (su estado actual). Céntrese en los próximos 3-12 meses para
identificar el estado futuro deseado.
5. Personalice los niveles de madurez: con la información que tiene sobre su
estrategia y su estado futuro, personalice los niveles de madurez para cada área de
la hoja de ruta. Actualice o elimine la descripción de cada nivel de madurez para
que sean realistas, en función de sus objetivos y estrategia. Su estado actual, las
prioridades, el personal y la financiación influirán en el tiempo y el esfuerzo que
tardará en avanzar a los niveles de madurez superiores.
6. Priorice: aclare qué es lo más importante que se ha de lograr en los próximos 3-12
meses. Por ejemplo, puede identificar elementos específicos de habilitación de
usuarios o reducción de riesgos que son una prioridad más alta que otros
elementos. Determine qué avances en los niveles de madurez debe priorizar
primero.
7. Defina objetivos medibles: cree KPI (indicadores clave de rendimiento) u OKR
(objetivos y resultados clave) para definir objetivos específicos. Asegúrese de que
los objetivos son medibles y factibles. Confirme que cada objetivo se alinea con su
estrategia y el estado futuro deseado.
8. Cree elementos de acción: agregue elementos de acción específicos al plan del
proyecto. Los elementos de acción identificarán quién hará qué y cuándo. Incluya
elementos de corto, medio y largo plazo (trabajo pendiente) en el plan del
proyecto para facilitar el seguimiento y el cambio de prioridades.
9. Realice un seguimiento de elementos de acción: use su software de planeación
de proyectos preferido para realizar un seguimiento del progreso continuo e
incremental de los elementos de acción. Resuma el progreso y el estado cada
trimestre para el patrocinador ejecutivo.
10. Ajuste: a medida que la nueva información esté disponible y a medida que
cambien las prioridades, vuelva a evaluar y ajuste su enfoque. Vuelva a examinar la
estrategia, los objetivos y los elementos de acción una vez por trimestre, para
asegurarse de que se centra en las acciones correctas.
11. Celebre: pause regularmente para apreciar su progreso. Celebre sus victorias.
Premie y reconozca a las personas que toman la iniciativa y ayudan a lograr sus
objetivos. Fomente relaciones saludables entre TI y las diferentes áreas de la
empresa.
12. Repita: continúe aprendiendo, experimentando y ajustando a medida que avance
con la implementación de Power BI. Use bucles de comentarios para aprender
continuamente de todos los usuarios de la organización. Asegúrese de que la
mejora continua y gradual sea una prioridad.
Algunos puntos clave importantes están implícitos en las sugerencias anteriores.
Céntrese en el período más cercano: aunque es importante tener presente la

visión general, le recomendamos que se centre principalmente en el próximo
trimestre, el próximo semestre y el próximo año. Es más fácil evaluar, planear y
actuar cuando se centra a corto plazo.
El progreso será incremental: los cambios que se producen cada día, cada semana
y cada mes se suman a lo largo del tiempo. Es fácil desanimarse y sentir una falta
de progreso cuando se trabaja en una gran iniciativa de adopción que tarda
tiempo. Si realiza un seguimiento del progreso incremental, le sorprenderá cuánto
puede lograr durante el transcurso de un año.
Se producirán cambios continuamente: prepárese para reconsiderar las
decisiones que tome, quizá cada trimestre. Es más fácil hacer frente al cambio
continuo cuando se espera que el plan cambie.
Todo se correlaciona conjuntamente: a medida que avanza por cada uno de los
pasos enumerados anteriormente, es importante que todo esté correlacionado con
los objetivos estratégicos de alto nivel de la organización, hasta los elementos de
acción más detallados. De este modo, sabrá que está trabajando en las cosas
correctas.
Planeación de la implementación de Power BI

La implementación correcta de Power BI en toda la organización requiere una reflexión y
una planificación deliberadas. La serie de artículos de Planeamiento de implementación
de Power BI, que es un trabajo en curso, está pensado para complementar la hoja de
ruta de adopción de Power BI. Incluirá consideraciones clave, acciones, criterios de toma
de decisiones, recomendaciones y describirá los patrones de implementación para los
escenarios de uso comunes más importantes.
Marco de adopción de Power BI

El marco de adopción de Power BI describe los aspectos adicionales de cómo adoptar
Power BI en más detalle. La intención original del marco era admitir a los asociados de
Microsoft con un conjunto ligero de recursos para su uso al ayudar a sus clientes a
implementar y adoptar Power BI.
El marco puede aumentar esta serie de la hoja de ruta de adopción de Power BI. La serie
de la hoja de ruta se centra en el por qué y el qué de la adopción de Power BI, más que
en el cómo.
７ Nota
Cuando esté finalizada, la serie de Planeamiento de implementación de Power BI

(descrita en la sección anterior) reemplazará al marco de adopción de Power BI.
Notas del producto de la implementación

empresarial
Las notas del producto Planificación de una implementación empresarial de Power BI
proporcionan información general completa para implementadores de Power BI. Su
objetivo principal es conocer las opciones, las consideraciones clave, las decisiones y los
procedimientos recomendados. Debido a la gran cantidad de contenido, las distintas
secciones de las notas del producto se dirigirán a los administradores, los profesionales
de TI y los autores de autoservicio.
Las notas del producto profundizan en el qué y el cómo de la adopción de Power BI, con
un enfoque centrado en la tecnología. Cuando haya terminado de leer la serie de
artículos sobre la adopción de Power BI, las notas del producto le proporcionarán
información adicional para ayudarle a poner en marcha sus planes.
７ Nota
Las notas del producto de Implementación empresarial dejarán de actualizarse.

Cuando esté finalizada, la serie de Planeamiento de implementación de Power BI
(descrita en la sección anterior) reemplazará las notas del producto de
Implementación empresarial.
Considere leer la información sobre el recorrido y la experiencia de Microsoft en el
impulso de culturas de datos. En este artículo se describe la importancia de dos
términos: la disciplina en el núcleo y la flexibilidad en el borde. También se exponen los
puntos de vista y la experiencia de Microsoft sobre la importancia de establecer un COE.
Adopción de Power Platform

El equipo de Power Platform cuenta con un excelente conjunto de contenido
relacionado con la adopción. Su objetivos principales son Power Apps, Power Automate
y Power Virtual Agents. Muchas de las ideas que se presentan en este contenido
también se pueden aplicar a Power BI.
El Modelo de madurez de la adopción de Power CAT , publicado por el equipo de

Power CAT, describe patrones repetibles para una adopción correcta de Power Platform.
El kit de inicio del Centro de excelencia (CoE) es una colección de componentes y

herramientas que le ayudarán a desarrollar una estrategia para adoptar y admitir
Microsoft Power Platform.
Las prácticas recomendadas de adopción de Power Platform incluyen un conjunto útil

de documentación y procedimientos recomendados para ayudarle a alinear las
estrategias empresariales y técnicas.
El marco de adopción de Power Platform es un proyecto controlado por la comunidad

con excelentes recursos para la adopción de servicios de Power Platform a escala.
Microsoft 365 y adopción de Azure

También puede encontrar instrucciones útiles relacionadas con la adopción publicadas
por otros equipos de tecnología de Microsoft.
El Modelo de madurez para Microsoft 365 proporciona información y recursos

para usar funcionalidades de forma más completa y eficaz.
Microsoft Learn tiene una ruta de aprendizaje para usar el marco de adopción de
servicio de Microsoft para impulsar la adopción de su empresa.
La Plataforma de adopción de la nube de Microsoft para Azure es una colección de
documentación, instrucciones de implementación, procedimientos recomendados
y herramientas para acelerar el recorrido de adopción de la nube.
Puede encontrar una amplia variedad de guías de adopción para tecnologías
individuales en línea. Algunos ejemplos incluyen:
Guía de adopción de Microsoft Teams .

Guía de adopción de seguridad y cumplimiento de Microsoft .
Recursos de adopción de SharePoint .
Guía del sector

El Libro de conocimientos de administración de datos (DMBOK2) es un libro que se
puede adquirir en DAMA International. Contiene una gran cantidad de información
sobre la maduración de las prácticas de administración de datos.
７ Nota
Los recursos adicionales proporcionados en este artículo no son necesarios para

aprovechar las instrucciones proporcionadas en esta serie de adopción de Power BI.
Son recursos de confianza que puede utilizar si quiere continuar su recorrido.
Comunidad de partners
organización a tener éxito con Power BI. Para ponerse en contacto con un partner de
Power BI, visite el portal de partners de Power BI .
Planeamiento de la implementación de
Power BI
Artículo • 17/04/2023
En este vídeo, Matthew presenta la serie de artículos sobre el planeamiento de la

implementación de Power BI.
https://www.microsoft.com/es-es/videoplayer/embed/RWUWA9?
postJsllMsg=true&autoCaptions=es-es
La implementación correcta de Power BI en toda la organización requiere una reflexión y

un planeamiento deliberados. La serie sobre la planificación de la implementación de
Power BI está pensada para ayudarle a completar la implementación de Power BI. En sus
artículos se incluyen consideraciones clave, acciones, criterios para la toma de
decisiones, recomendaciones y se describen los patrones de implementación para los
escenarios de uso comunes más importantes.
Ámbito
Al implementar Power BI, hay muchas áreas temáticas que se deben tener en cuenta. Las
siguientes áreas temáticas forman parte de la serie de planificación de la
implementación de Power BI:
Estrategia de BI
Necesidades y oportunidades del usuario
Herramientas de creación y máquinas de usuario
Configuración del inquilino
Suscripciones, licencias y pruebas
Supervisión del servicio Power BI
Áreas de trabajo
Administración de datos
Distribución y uso compartido del contenido
Administración e implementación de cambios
Seguridad
Protección de la información y prevención de pérdida de datos
Power BI Premium
Puertas de enlace
Integración con otros servicios
Seguimiento de la adopción
Escalado y crecimiento
７ Nota
La serie es un trabajo en curso. Con el tiempo se publicarán gradualmente artículos

nuevos y actualizados.
Escenarios de uso
La serie incluye escenarios de uso que muestran diferentes formas en que los creadores
y consumidores pueden implementar y usar Power BI:
Colaboración y entrega de contenido

BI con características de autoservicio
Implementación y administración de contenido
En tiempo real
Inserción e híbrido
Propósito
Al finalizar, la serie:
Complementará la hoja de ruta de adopción de Power BI, que describe las

consideraciones para la adopción satisfactoria de Power BI y una cultura de datos
correcta. Las instrucciones relacionadas con el planeamiento de la implementación
de Power BI que se correlacionan con los objetivos de la hoja de ruta de adopción
se agregarán a esta serie.
Reemplazan las notas del producto Planificación de una implementación
empresarial de Power BI , que estaban diseñadas para describir diversos factores
técnicos al implementar Power BI. El contenido pertinente de las notas del
producto se combinará en esta serie, en un formato nuevo más reconocible y
práctico.
Reemplazará el marco de adopción de Power BI (junto con la hoja de ruta de
adopción de Power BI), que es un conjunto ligero de recursos (vídeos y
diapositivas de presentación) diseñados para ayudar a los asociados de Microsoft a
implementar las soluciones de Power BI para sus clientes. Los elementos de acción
pertinentes del marco de adopción se combinarán en esta serie.
Recomendaciones
Si quiere prepararse para el éxito, le recomendamos que siga estos pasos:
1. Lea la hoja de ruta de adopción de Power BI completa y familiarícese con cada uno
de los temas. Evalúe el estado actual de la adopción de Power BI y obtenga
claridad sobre los objetivos de la cultura de datos de su organización.
2. Explore los artículos relacionados con el planeamiento de la implementación de
Power BI que le resulten pertinentes. Empiece con los escenarios de uso de
Power BI, que indican cómo se puede utilizar Power BI de diversas maneras.
Asegúrese de comprender qué escenarios de uso se aplican en la organización y
quién los usa. Además, tenga en cuenta cómo estos escenarios de uso pueden
influir en las estrategias de implementación que decida.
3. Lea los artículos de cada una de las áreas temáticas que se enumeran
anteriormente. Puede optar por realizar inicialmente una revisión amplia del
contenido de arriba a abajo. O bien, puede optar por empezar con áreas temáticas
que sean más prioritarias. Revise cuidadosamente las decisiones y acciones clave
que se incluyen para cada tema (al final de cada sección). Se recomienda usarlas
como punto de partida para crear y personalizar el plan.
4. Cuando sea necesario, consulte la documentación de Power BI para obtener
información detallada sobre temas específicos.
Audiencia de destino
Es posible que el público al que está dirigida esta serie de artículos esté interesado en
obtener los resultados siguientes:
Identificar las áreas que se pueden mejorar o fortalecer la implementación de

Power BI
Aumentar su capacidad de administrar y ofrecer contenido de Power BI de manera
eficaz y segura
Planear la implementación de Power BI dentro de su organización
Aumentar la rentabilidad de la inversión (ROI) de la organización en Power BI
Esta serie resulta útil para las organizaciones que se encuentran en las primeras fases de
una implementación de Power BI o que planean realizar una implementación ampliada.
También puede ser útil para quienes trabajan en una organización con una o varias de
las características siguientes:
Power BI se adoptó con éxito en algunas partes de la organización, pero su

administración no es uniforme ni se controla de manera expresa.
Power BI está implementado a una escala algo significativa, pero hay muchas
oportunidades de mejora no aprovechadas.
 Sugerencia
Se presupone que tiene ciertos conocimientos sobre Power BI y los conceptos

generales de la inteligencia empresarial. Para aprovechar este contenido al máximo,
le recomendamos que se familiarice primero con la hoja de ruta de adopción de
Power BI.
Agradecimientos
Melissa Coates, MVP de plataforma de datos y propietaria de Coates Data Strategies
escribió esta serie de artículos con la importante colaboración de Peter Myers, Matthew
Roche, Alex Powers y Chris Webb.
Pasos siguientes
En el artículo siguiente de esta serie, obtendrá información sobre escenarios de uso en
los que se describe cómo usar Power BI de maneras distintas.

Información general sobre la migración a Power BI

Escenarios de uso de Power BI
Artículo • 20/04/2023
７ Nota
Este artículo forma parte de la serie de artículos sobre el planeamiento de la

implementación de Power BI. Para acceder a una introducción a la serie, consulte el
planeamiento de la implementación de Power BI.
El ecosistema de Power BI es muy diverso y se puede implementar de distintas formas.

En esta serie de artículos, se proporcionan escenarios de uso común para ilustrar
diferentes formas en las que los creadores y los consumidores pueden implementar y
usar Power BI. Entender cómo se aplican estos escenarios de uso en su organización y
quién se encarga de ello puede influir en las estrategias de implementación que decida
adoptar.
７ Nota
En cada escenario se identifican los componentes más frecuentes de Power BI en

función de cómo se planea usar este para el escenario en cuestión. El objetivo no es
mencionar todas las opciones posibles para cada escenario de uso. En su lugar, en
cada diagrama de escenario se describen las características principales que son más
relevantes para este.
Cómo usar los escenarios

Use los escenarios como ayuda para tomar decisiones de planeamiento e
implementación de la arquitectura de Power BI. Estas son algunas sugerencias:
Para empezar, lea los escenarios en el orden en que se documentan. Familiarícese

con los conceptos y en cómo unos escenarios se basan en otros.
Céntrese en los escenarios que se adapten bien a su cultura de datos. Para
determinar qué escenarios de uso son una buena opción, tenga en cuenta también
cómo se controla la administración y propiedad del contenido, así como el ámbito
de entrega del contenido.
Piense qué áreas de las operaciones de BI podrían reforzarse en su organización.
Por ejemplo, si su objetivo es reducir el nivel de duplicación de datos, céntrese en
el escenario de BI de autoservicio administrada. Si su objetivo es mejorar la eficacia
de los esfuerzos de preparación de datos, céntrese en el escenario de preparación
de datos de autoservicio.
Determine si hay formas de usar Power BI que puedan aportar un valor adicional o
reducir el riesgo para la organización. Por ejemplo, si su objetivo es lograr el
equilibrio entre la centralización y la descentralización (que se describen más
adelante en los artículos de administración y propiedad del contenido), tenga en
cuenta el escenario de BI de autoservicio administrada personalizable.
Una vez que haya comprendido las áreas de las operaciones de BI que quiere
implementar o reforzar, cree un plan de proyecto que defina los pasos tácticos
para alcanzar el estado futuro deseado.
 Sugerencia
Puede que tenga que mezclar y combinar las ideas descritas en los escenarios de
uso para crear una estrategia de implementación de Power BI que se adapte a sus
circunstancias. Para satisfacer las necesidades de usuarios de distintos
departamentos y unidades de negocio, lo mejor es adoptar distintas partes de los
diversos métodos de implementación de Power BI de forma simultánea. De este
modo, podrá respaldar a diversos creadores de contenido y distintas soluciones.
Escenarios de colaboración y entrega de

contenido
Los escenarios de uso siguientes abordan la colaboración y la entrega de contenido.
Estos cuatro escenarios iniciales se centran principalmente en la propiedad y la
administración de contenido y en el ámbito de entrega de contenido. Se relacionan
entre sí y se basan uno en otro de manera que se ajustan a la forma en que los equipos
de inteligencia empresarial evolucionan y crecen a lo largo del tiempo. Pueden
considerarse como los bloques de creación en los que se basan otros escenarios, en
especial los escenarios de BI de autoservicio que se describen en la sección siguiente.
Por lo tanto, es recomendable revisar primero esos escenarios.
BI personal: el creador de contenido tiene mucha libertad y flexibilidad para crear

contenido de uso individual. En este escenario se describe la utilización de un área
de trabajo personal para uso privado.
BI de equipo: el objetivo principal es la colaboración informal entre miembros de

un equipo que trabajan en estrecha colaboración. En este escenario se describe el
uso de un área de trabajo tanto para colaboración como para distribución.
También muestra el valor de usar Microsoft Teams para la colaboración entre
creadores y consumidores de Power BI.
BI de departamento: se enfoca a la distribución de contenido a un mayor número

de usuarios dentro de un departamento o unidad de negocio. En este escenario se
describe el uso de una aplicación de Power BI para distribuir contenido.
BI empresarial: el objetivo principal es la distribución de contenido a escala. En

este escenario se describe el uso de la capacidad Premium para distribuir
contenido a un mayor número de consumidores de solo lectura que tengan una
licencia gratuita de Power BI.
７ Nota
En la hoja de ruta de adopción de Power BI se describe información adicional

sobre la propiedad y la administración del contenido y el ámbito de entrega
de contenido.
Escenarios de BI de autoservicio
Hay cuatro escenarios de uso que se centran en la compatibilidad con las actividades de
BI de autoservicio, en las que diversas personas de numerosas áreas de la organización
controlan las responsabilidades de análisis. Los escenarios de colaboración y entrega de
contenido (descritos en el grupo de escenarios anterior) también incluyen aspectos de
BI de autoservicio, pero desde un punto de vista ligeramente distinto. La intención de
este conjunto de escenarios es centrarse en varios aspectos importantes para planear
una implementación de Power BI.
Los escenarios de BI de autoservicio que se presentan aquí resaltan principalmente el

uso de la BI de autoservicio administrada en la que la administración de datos está
centralizada. La reutilización de estos datos centralizados es uno de los objetivos
principales. Los usuarios empresariales tienen la responsabilidad de crear informes y
paneles.
BI de autoservicio administrada: el objetivo es que muchos de los creadores de

informes reutilicen los conjuntos de datos compartidos. En este escenario se
describe cómo se desacopla el proceso de creación de informes del proceso de
creación de conjuntos de datos. Para fomentar que los autores de informes
busquen y reutilicen un conjunto de datos compartido existente, antes debe
aprobarse y hacerse detectable en el centro de datos del servicio Power BI.
BI de autoservicio administrada personalizable: se centra en la personalización de
un creador de conjuntos de datos o en la ampliación de un conjunto de datos
existente para satisfacer nuevos requisitos. En este escenario, se describe la
publicación de un modelo de datos personalizado en el que algunas tablas son
nuevas, mientras que otras dependen del conjunto de datos compartido existente.
Preparación de datos de autoservicio: el objetivo es centralizar las actividades de

preparación de datos para mejorar la coherencia y reducir el esfuerzo. En este
escenario, se describe la creación de flujos de datos de Power BI para evitar la
repetición de la lógica de preparación de datos de Power Query en muchos
archivos de Power BI Desktop diferentes. Diversos conjuntos de datos pueden
consumir un flujo de datos como origen de datos.
Preparación de datos avanzada: el objetivo es mejorar el alcance y la reutilización

de flujos de datos para varios usuarios, equipos y casos de uso. En este escenario
se describe el uso de varias áreas de trabajo en función de su fin: almacenamiento
provisional, limpio y final.
Creación de prototipos y uso compartido: las técnicas de creación de prototipos

son muy útiles para validar los requisitos de objetos visuales y cálculos por
expertos en la materia. Las soluciones de creación de prototipos pueden ser
soluciones temporales de duración breve, o bien evolucionar y convertirse en una
solución plenamente validada y difundida. En este escenario, se describe el uso de
Power BI Desktop durante una sesión de creación de prototipos interactiva.
Después, se comparten en el servicio Power BI cuando se necesitan comentarios
adicionales de un experto en la materia.
７ Nota
En la hoja de ruta de adopción de Power BI se describe información adicional

sobre la propiedad y la administración del contenido y el ámbito de entrega
de contenido que afectan a las decisiones y las actividades de BI de
autoservicio.
Escenarios de implementación y administración

de contenido
En los escenarios siguientes de implementación y administración de contenido se
describen diversos enfoques de cómo los creadores y los propietarios de contenido
usan procesos de administración del ciclo de vida metódicos y disciplinados para reducir
los errores, minimizar las incoherencias y mejorar la experiencia del usuario para los
consumidores.
Publicación de contenido de autoservicio: el objetivo es garantizar que el

contenido sea estable para los consumidores. En este escenario se describe el uso
de una canalización de implementación de Power BI para publicar contenido
mediante áreas de trabajo de desarrollo, pruebas y producción. También se
describe la opción de usar el modo de licencia Premium por usuario para áreas de
trabajo de desarrollo y prueba, así como el modo de licencia Premium por
capacidad para el área de trabajo de producción.
Administración avanzada de modelos de datos: el objetivo es capacitar a los
creadores con funcionalidades avanzadas de modelado y publicación de datos. En
este escenario se describe la administración de un modelo de datos mediante la
herramienta de terceros Tabular Editor. Los modeladores de datos publican sus
modelos en el servicio Power BI mediante el punto de conexión XMLA, que está
disponible con Power BI Premium.
Publicación de contenido empresarial: se centra en el uso de técnicas de
programación más sofisticadas para publicar contenido a través de áreas de
trabajo de desarrollo, pruebas y producción. En este escenario, describe cómo
puede usar Azure DevOps para orquestar la colaboración y la publicación de
contenido.
Escenarios en tiempo real

Los escenarios en tiempo real describen distintas técnicas para permitir la presentación
de actualizaciones de datos prácticamente en tiempo real. La supervisión de los datos
en tiempo real permite a la organización reaccionar de forma más rápida cuando deben
tomarse decisiones sujetas a limitación temporal.
Análisis en tiempo real de autoservicio: el enfoque se centra en cómo un analista

de negocios genera informes de Power BI en tiempo real.
Análisis en tiempo real mediante programación (artículo del escenario de uso no
disponible actualmente): se centra en cómo un desarrollador puede generar
informes de Power BI en tiempo real.
Escenarios híbridos y de inserción

Hay dos escenarios de inserción e híbridos: inserción de contenido y de informes locales.
Describen formas de implementar y distribuir contenido que se puede usar además del
servicio Power BI o en lugar de este.
Inserción para la organización: se centra en facilitar el acceso de los datos
analíticos a los usuarios empresariales mediante la integración de objetos visuales
en las herramientas y las aplicaciones que usan a diario. En este escenario se
describe el uso de las API REST de Power BI para insertar contenido en una
aplicación personalizada para los usuarios que tienen los permisos y las licencias
adecuadas para acceder al contenido de Power BI en su organización.
Inserción para los clientes: en este escenario se describe el uso de las API REST de
Power BI para insertar contenido en una aplicación personalizada para los usuarios
que no tienen permiso o las licencias adecuadas para acceder al contenido de
Power BI en su organización. La aplicación personalizada requiere una identidad de
inserción que tenga permiso y una licencia adecuada para acceder al contenido de
Power BI. La aplicación personalizada podría ser una aplicación multiinquilino.
Informes locales: el objetivo es usar un portal básico para publicar, compartir y
consumir contenido de inteligencia empresarial dentro de la red de la
organización. En este escenario se describe el uso de Power BI Report Server para
este fin.
Pasos siguientes
En el siguiente artículo de esta serie se describe cómo habilitar el análisis privado para
una persona con el escenario de uso de BI personal.
Escenarios de uso de Power BI:
BI personal
７ Nota

implementación de Power BI. Para acceder a una introducción a la serie, vea
Planificación de la implementación de Power BI.
Tal como se describe en la Hoja de ruta de adopción de Power BI, BI Personal consiste
en permitir que un individuo obtenga valor analítico. También se trata de permitirle
realizar tareas empresariales de forma más eficaz con el uso de datos, información y
análisis. BI Personal se considera a veces como el punto de entrada para BI de
autoservicio.
En escenarios de BI Personal, el creador del contenido tiene mucha libertad y flexibilidad

a fin de crear contenido para uso individual. La simplicidad y la velocidad suelen ser
prioridades altas. No hay uso compartido ni colaboración en este escenario de uso:
estos temas se tratan en los artículos de escenarios de BI de equipo, BI de departamento
y BI de empresa.
７ Nota
Hay cuatro escenarios de colaboración y entrega de contenido que se basan entre sí.
El escenario de BI Personal es el primero de los cuatro escenarios. Puede encontrar
una lista de todos los escenarios en el artículo Información general sobre
escenarios de uso de Power BI.
Diagrama del escenario

En el diagrama siguiente se muestra información general de alto nivel de las acciones de
usuario más comunes y los componentes de Power BI que admite BI Personal. El
enfoque se centra en el análisis privado de una persona.

En el diagrama de escenario se muestran las siguientes acciones de usuario,

herramientas y características:
Elemento Descripción
El creador de contenido de Power BI desarrolla una solución de BI mediante Power BI

Desktop.
Power BI Desktop se conecta a los datos de uno o varios orígenes de datos. Las
consultas y los mashups de datos, que combinan varios orígenes, se desarrollan en el
Editor de Power Query.
El desarrollo del modelo de datos y la creación de informes se realizan en Power BI

Desktop. En una solución de BI Personal, la intención principal suele ser la exploración
y el análisis de datos.
Cuando esté a punto, el creador de contenido publica el archivo de Power BI Desktop

(.pbix) en el servicio Power BI.
Puesto que la intención principal es el uso personal, el contenido se publica en el área

de trabajo personal del creador de contenido. Entre las ventajas de usar el servicio
Power BI (en lugar de permanecer únicamente en Power BI Desktop) se incluye la
actualización programada de datos, las alertas del panel y la capacidad de consumir
contenido mediante una aplicación móvil.
El creador de contenido ve el contenido publicado e interactúa con él. Una opción es

iniciar sesión en el servicio Power BI mediante un explorador web.
El creador de contenido también puede usar una aplicación móvil de Power BI para
ver el contenido publicado.
La actualización programada de datos se puede configurar en el servicio Power BI

para mantener actualizados los datos importados.
A fin de conectarse a orígenes de datos que residen en una red organizativa privada,
se requiere una puerta de enlace de datos local para la actualización de datos.
Los administradores de Power BI vigilan y supervisan la actividad en el servicio

Power BI. Normalmente, las áreas de trabajo personales se rigen a un nivel mucho
menor que las áreas de trabajo destinadas a la colaboración y distribución.
Puntos clave
A continuación se muestran algunos puntos clave que se deben destacar sobre el
escenario de BI Personal.
Elección de herramientas de creación

Power BI Desktop es la herramienta de creación para desarrollar consultas, modelos e
informes de Power BI. Es posible usar diferentes herramientas para crear informes de
Excel e informes paginados de Power BI (no descritos en el diagrama de escenarios).
Dependencia del área de trabajo personal

El uso del área de trabajo personal se puede considerar como un espacio aislado
analítico. Para muchas organizaciones, el contenido personal está sujeto a poca
gobernanza o supervisión formal. Pero sigue siendo aconsejable educar a los creadores
de contenido sobre las directrices para tener éxito con BI Personal. El uso de la
característica de uso compartido disponible en un área de trabajo personal no se
describe en este escenario de uso, ya que el enfoque es el análisis individual.
） Importante
Limite el uso de áreas de trabajo personales y asegúrese de que no haya contenido

crítico almacenado en ellas. Aunque un administrador de Power BI puede acceder y
controlar el área de trabajo personal de un usuario, el almacenamiento de
contenido crítico en áreas de trabajo personales representa un riesgo para la
organización.
Uso de una licencia gratuita de Power BI

Para un uso personal, que por definición significa que no hay ningún uso compartido o
colaboración con otros usuarios, solo ciertas capacidades del servicio Power BI están
disponibles para un usuario con una licencia gratuita de Power BI. Al usar una licencia
gratuita, la mayoría de las actividades para crear y publicar contenido en el servicio
Power BI se limitan a su área de trabajo personal.
 Sugerencia
En el escenario BI de empresa se describe cómo los usuarios con una licencia

gratuita de Power BI pueden ver contenido cuando se hospeda en una capacidad
Premium.
Instalación de la puerta de enlace

Normalmente, se requiere una puerta de enlace de datos al acceder a orígenes de datos
que residen en la red privada de la organización o en una red virtual. La puerta de
enlace de datos local se vuelve relevante una vez que se publica un archivo de Power BI
Desktop en el servicio Power BI. Los dos propósitos de una puerta de enlace son
actualizar los datos importados o ver un informe que consulta una conexión dinámica o
un conjunto de datos de DirectQuery (no descrito en el diagrama de escenarios).
７ Nota
Una puerta de enlace de datos en modo personal se instala con una frecuencia
mucho mayor en la máquina de un usuario individual. Por lo tanto, una puerta de
enlace de datos en el modo personal es más adecuada para escenarios de uso de
BI Personal. Su organización puede impedir que los usuarios instalen puertas de
enlace de datos, en cuyo caso el creador de contenido puede usar una puerta de
enlace de datos en modo estándar (normalmente la configura y administra TI).
Protección de la información
Las directivas de protección de la información se pueden aplicar al contenido del
servicio Power BI. Algunas organizaciones tienen una directiva de etiqueta obligatoria
que requiere que se asigne una etiqueta de confidencialidad, incluso en un área de
trabajo personal.

El registro de actividad registra las actividades del usuario que se producen en el
servicio Power BI y se amplía a las áreas de trabajo personales. Los administradores de
Power BI pueden usar los datos del registro de actividad recopilados para realizar la
auditoría como ayuda para comprender los patrones de uso y detectar las actividades
de riesgo. Los requisitos de auditoría y gobernanza suelen ser menos estrictos para
escenarios de BI Personal.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre la colaboración
pequeña en equipo con el escenario de uso de BI de equipo.
Escenarios de uso de Power BI: BI para
equipos
７ Nota

implementación de Power BI. Para obtener una introducción a la serie, consulte el
Una vez creada una solución de BI valiosa, es el momento de colaborar con los
compañeros. El objetivo es ofrecer un valor adicional al que se puede lograr con el
escenario de BI personal.
Como se describe en la hoja de ruta de adopción de Power BI, la BI para equipos se

centra en un pequeño equipo de personas que trabajan en estrecha colaboración. La
colaboración y el uso compartido de contenido de manera informal suelen ser un
objetivo clave de la BI para equipos (en los escenarios de BI de departamento y BI
empresarial se trata una entrega de contenido más formal).
A veces, cuando se trabaja con compañeros cercanos, la colaboración para equipos

pequeños puede llevarse a cabo simplemente dentro de un área de trabajo. Un área de
trabajo se puede considerar como una forma de ver contenido de manera informal (sin
la formalidad de la publicación de una aplicación de Power BI, que se trata en el
escenario de BI de departamento) por parte de los miembros de un equipo pequeño.
７ Nota
Hay cuatro escenarios de uso de colaboración y entrega de contenido

interdependientes. El escenario de BI para equipos es el segundo de los cuatro.
Puede encontrar una lista de todos los escenarios en el artículo Escenarios de uso
de Power BI.
El escenario de BI de autoservicio administrada presenta un concepto importante

sobre el desacoplamiento del conjunto de datos y el desarrollo de informes. Por
motivos de simplicidad, este concepto no se describe explícitamente en este
artículo. Se recomienda aplicar los conceptos descritos en el escenario de BI de
autoservicio administrada siempre que sea posible.
usuario más comunes y de los componentes de Power BI que admiten la BI para
equipos. El enfoque principal es la colaboración en equipos pequeños.

Los creadores de contenido de Power BI desarrollan soluciones de BI mediante

Power BI Desktop. En un escenario de BI para equipos, es habitual que los creadores
trabajen en un equipo, departamento o unidad de negocio que estén
descentralizados.
El desarrollo del modelos de datos y la creación de informes se realizan en Power BI

Desktop. En una solución de BI para equipos, el propósito es ayudar a los miembros
del equipo a comprender el significado y la importancia de los datos colocándolos en
un contexto visual.
Cuando está listo, los creadores de contenido publican su archivo de Power BI

Desktop (.PBIX) en el servicio Power BI.
El contenido se publica en un área de trabajo. Su propósito principal es proporcionar

información y habilitar la colaboración para un equipo pequeño.
Todos los usuarios asignados a un rol de área de trabajo (visor o superior) ven el
contenido en el área de trabajo e interactúan con este. Una opción es iniciar sesión
en el servicio Power BI mediante un explorador web.
Las aplicaciones móviles de Power BI también están disponibles para ver el contenido
publicado.
A los usuarios que trabajan con frecuencia en Microsoft Teams puede resultarles
conveniente administrar o ver contenido de Power BI directamente en Teams. Pueden
usar la aplicación Power BI para Microsoft Teams o ver informes insertados en un
canal de equipo. Los usuarios también pueden realizar chats privados entre sí y recibir
notificaciones directamente en Teams.
Los usuarios asignados al rol de área de trabajo de administrador, miembro o

colaborador pueden publicar y administrar el contenido del área de trabajo.
La actualización de datos programada se puede configurar en el servicio Power BI

para mantener actualizados los datos importados (en conjuntos de datos o en flujos
de datos).
Para conectarse a orígenes de datos que residen dentro de una red organizativa
privada, se requiere una puerta de enlace de datos local para la actualización de
datos.
Otros creadores de contenido de autoservicio pueden crear nuevos informes

mediante un conjunto de datos existente. Pueden optar por usar Power BI Desktop,
Excel o Power BI Report Builder (no representado en el diagrama de escenarios). Se
recomienda la reutilización de los conjuntos de datos existentes de esta forma.
Los administradores de Power BI controlan y supervisan la actividad en el servicio

Power BI. Las soluciones de BI para equipos pueden estar sujetas a más requisitos de
gobernanza que las de BI personal, pero menos que las soluciones de BI de
departamento y BI empresarial.
Puntos clave
escenario de BI para equipos.
Almacenamiento de archivos de origen

informes interactivos. Dado que la colaboración es una prioridad principal en la BI para
equipos, es importante almacenar el archivo de Power BI Desktop de origen en una
ubicación compartida segura. Las ubicaciones como OneDrive profesional o educativo o
SharePoint (no representadas en el diagrama de escenarios) son útiles por el historial de
versiones integrado y la sincronización automática de archivos. Una biblioteca
compartida se puede proteger, es fácilmente accesible para compañeros e integra
funcionalidades de control de versiones.
Cuando la administración conjunta de una solución de BI implica a varias personas con

diferentes conjuntos de aptitudes, considere la posibilidad de desacoplar el modelo y
los informes en archivos de Power BI Desktop independientes (descritos en el escenario
de BI de autoservicio administrada). Este enfoque fomenta la reutilización del conjunto
de datos y es más eficaz que alternar continuamente entre las personas que editan el
archivo de Power BI Desktop. Esto resulta especialmente útil cuando, por ejemplo, una
persona trabaja en el conjunto de datos mientras que otra persona trabaja en los
informes.
Áreas de trabajo
Un área de trabajo de Power BI actúa como contenedor lógico en el servicio Power BI
para almacenar elementos relacionados con Power BI, como conjuntos de datos e
informes. En un escenario de BI para equipos, es práctico y sencillo que un número
reducido de usuarios utilice el área de trabajo para la colaboración, así como para la
visualización de informes. La distribución del contenido como aplicación de Power BI se
describe en el escenario de BI de departamento.
Acceso y uso compartido del área de trabajo

Además de organizar el contenido, un área de trabajo forma un límite de seguridad.
Asigne usuarios a los roles del área de trabajo cuando un miembro del equipo necesite
editar o ver todos los elementos publicados en un área de trabajo. Los cuatro roles de
área de trabajo (administrador, miembro, colaborador y visor) respaldan la
productividad de los creadores y consumidores de contenido de autoservicio, sin
aprovisionamiento excesivo de permisos.
７ Nota
Como alternativa, los usuarios del área de trabajo pueden compartir informes
individuales y paneles (no representado en el diagrama de escenarios). Mediante el
uso compartido se puede conceder acceso de solo lectura a un usuario que no
tenga asignado ningún rol de área de trabajo. Sin embargo, intente limitar este tipo
de uso, ya que puede ser tedioso configurarlo para muchos elementos o usuarios.
Licencias de usuario de Power BI
Al colaborar en un área de trabajo, todos los usuarios deben tener una licencia de
Power BI Pro o Power BI Premium por usuario (PPU) .
７ Nota
Existe una excepción para el requisito de tener una licencia de Power BI Pro o PPU:
cuando el área de trabajo está asignada a la capacidad Premium, los usuarios de
licencias gratuitas de Power BI (con los permisos adecuados) pueden ver el
contenido del área de trabajo (o aplicación de Power BI). Este enfoque se describe
en el escenario de BI empresarial.
Reutilización de conjuntos de datos existentes

La reutilización de los conjuntos de datos existentes es importante para la colaboración
en equipo. Ayuda a promover una única versión de la verdad. Es especialmente
importante cuando un pequeño número de creadores de conjuntos de datos admiten
muchos creadores de informes. Una conexión dinámica de Power BI Desktop puede
conectar un informe a un conjunto de datos existente, lo que evita la necesidad de crear
otro conjunto de datos. Como alternativa, cuando los usuarios prefieren crear un
informe de Excel, pueden usar la característica Analizar en Excel. Este tipo de
conectividad es preferible a exportar datos a Excel por los motivos siguientes:
Evita crear conjuntos de datos duplicados.

Reduce el riesgo de datos y cálculos incoherentes.
Admite todas las funcionalidades de segmentación, fragmentación y dinamización
en los objetos visuales al tiempo que se permanece conectado al conjunto de
datos almacenado en el servicio Power BI.
Para acceder a un conjunto de datos existente, el creador del contenido debe tener el
permiso de compilación para el conjunto de datos. Se puede conceder directa o
indirectamente cuando el usuario se asigna a un rol de área de trabajo (colaborador o
superior), al publicar una aplicación de Power BI o al compartir un elemento de
Power BI. El escenario de BI de autoservicio administrada explora aún más la
reutilización de conjuntos de datos compartidos.
Integración de Power BI con Microsoft Teams

El uso de una herramienta de colaboración moderna como Microsoft Teams atrae a los
usuarios para tomar decisiones controladas por datos. Microsoft Teams admite
discusiones colaborativas sobre los datos mientras se visualiza el contenido de Power BI
en un flujo de trabajo natural. Para obtener más información sobre las opciones de
colaboración, consulte Colaborar con Power BI en Microsoft Teams.

que residen en la red organizativa privada o en una red virtual. La puerta de enlace de
datos local se vuelve relevante una vez que se publica un archivo de Power BI Desktop
en el servicio Power BI. Los dos propósitos de una puerta de enlace son actualizar los
datos importados o ver un informe que consulta una conexión dinámica o un conjunto
de datos de DirectQuery (no descrito en el diagrama de escenarios).
７ Nota
En el caso de escenarios de BI para equipo, para departamento y para empresa, se

recomiendan las puertas de enlace de datos centralizadas en modo estándar en
lugar de puertas de enlace en modo personal. En el modo estándar, la puerta de
enlace de datos admite conexiones dinámicas y operaciones de DirectQuery
(además de las operaciones de actualización de datos programadas).

servicio Power BI. Los administradores de Power BI pueden usar los datos del registro de
actividad recopilados para realizar auditorías que les ayuden a comprender los patrones
de uso y adopción. El registro de actividad también es valioso para proporcionar
asistencia a los esfuerzos de gobernanza, las auditorías de seguridad y los requisitos de
cumplimiento.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre cómo distribuir
contenido a un mayor número de visores en el escenario de uso de BI de departamento.
Escenarios de uso de Power BI: BI de
departamento
７ Nota

Como se describe en la hoja de ruta de adopción de Power BI, BI de departamento se

centra en distribuir contenido a un mayor número de usuarios. Estos usuarios suelen ser
miembros de un departamento o unidad de negocio.
Cuando los equipos crecen, resulta poco práctico usar un área de trabajo de forma
eficaz para la distribución de todos los informes (como se describe en el escenario de BI
para equipos). Una manera más eficaz de controlar escenarios de BI de departamento
más grandes consiste en usar el área de trabajo para la colaboración y distribuir el
contenido del área de trabajo como una aplicación a los consumidores.
７ Nota
Hay cuatro escenarios de uso de entrega y colaboración de contenido a medida que

el uso se va ampliando. El escenario de BI de departamento es el tercero de los
cuatro escenarios. Puede encontrar una lista de todos los escenarios en el artículo
Escenarios de uso de Power BI.


En el diagrama siguiente se muestra una visión general de las acciones de usuario más
comunes y los componentes de Power BI que admiten BI de departamento. El enfoque
principal es el uso de una aplicación de Power BI para la distribución de contenido a un
gran público de consumidores.

Los creadores de contenido de Power BI desarrollan soluciones de BI mediante

Power BI Desktop. En un escenario de BI de departamento, es habitual que los
creadores trabajen en un equipo descentralizado, departamento o unidad de
negocio.
El desarrollo del modelos de datos y la creación de informes se realizan en Power BI

Desktop. En una solución de BI de departamento, el propósito es ayudar a los
compañeros a comprender el significado y la importancia de los datos colocándolo
en un contexto visual.

El contenido se publica en un área de trabajo. Su objetivo principal es proporcionar

un área de colaboración para las personas responsables de crear, administrar y validar
contenido.
Algunos o todos los informes y paneles se publican como una aplicación de Power BI.
El propósito de la aplicación es proporcionar un conjunto de contenido relacionado
para que los consumidores puedan verlo de forma fácil de usar.
A los usuarios de aplicaciones de Power BI se les asignan permisos de solo lectura.

Los permisos de aplicación se administran por separado del área de trabajo.
Las aplicaciones móviles de Power BI también están disponibles para ver las
aplicaciones y el contenido del área de trabajo.
conveniente administrar o ver contenido de Power BI directamente en Teams.
Los usuarios asignados a los roles de área de trabajo de administrador, miembro o

La actualización de datos programada se configura en el servicio Power BI para

mantener los datos importados actualizados, ya sea en conjuntos de datos o en flujos
de datos.
datos.

mediante un conjunto de datos existente. Pueden optar por usar Power BI Desktop,
Excel o Power BI Report Builder (no representado en el diagrama de escenarios). Se
recomienda la reutilización de los conjuntos de datos existentes de esta forma.

Power BI. Las soluciones de BI de departamento pueden estar sujetas a más requisitos
de gobernanza que las soluciones de BI de equipo, pero menos requisitos que las
soluciones de BI empresarial.
Puntos clave
A continuación se muestran algunos puntos clave para destacar sobre el escenario de BI
de departamento.

informes interactivos. Para BI de departamento, es importante almacenar el archivo de
Power BI Desktop de origen en una ubicación segura y compartida. Las ubicaciones
como OneDrive para uso profesional o educativo o SharePoint (no representadas en el
diagrama de escenarios) son útiles. Una biblioteca compartida se puede proteger, es
fácilmente accesible para compañeros e integra funcionalidades de control de versiones.
los informes en archivos de Power BI Desktop independientes (descritos en el escenario
de BI de autoservicio administrada). Este enfoque fomenta la reutilización del conjunto
de datos y es más eficaz que alternar continuamente entre las personas que editan el
archivo de Power BI Desktop. Esto resulta especialmente útil cuando, por ejemplo, una
persona trabaja en el conjunto de datos mientras que otra persona trabaja en los
informes.
Áreas de trabajo
Un área de trabajo de Power BI es un contenedor lógico en el servicio Power BI para
almacenar elementos relacionados con Power BI, como conjuntos de datos e informes.
Aunque en este escenario se muestra una área de trabajo, normalmente se requieren
varias áreas de trabajo para satisfacer todos los requisitos de planeamiento del área de
trabajo.
En el escenario de BI de autoservicio administrado se describe el uso de áreas de trabajo

independientes.
Publicación en la aplicación de Power BI

En el caso de BI de departamento, una aplicación de Power BI funciona bien para la
distribución de contenido a los consumidores (en lugar del acceso directo al área de
trabajo, que se describe en el escenario de BI para equipos). Una aplicación de Power BI
proporciona la mejor experiencia para los consumidores, ya que presenta un conjunto
de contenido relacionado con una experiencia de navegación fácil de usar. Una
aplicación de Power BI es especialmente útil en situaciones en las que hay un número
mayor y más diverso de consumidores, o cuando el desarrollador de contenido no
trabaja estrechamente con los consumidores de la aplicación.
Permisos en la aplicación de Power BI

A los usuarios de la aplicación Power BI se les concede permiso de solo lectura en la
aplicación, y estos permisos se administran separadamente del área de trabajo. Este
nivel adicional de flexibilidad es útil para administrar quién puede ver el contenido.
En el caso de BI de departamento se recomienda limitar el acceso del área de trabajo a

los responsables de las actividades de creación, desarrollo y control de calidad del
contenido. Normalmente, solo un pequeño número de personas requieren acceso al
área de trabajo. Los consumidores pueden acceder al contenido abriendo la aplicación
Power BI, en lugar de abrir el área de trabajo.
Licencias de usuario de Power BI

Todos los creadores de contenido y consumidores del área de trabajo o la aplicación de
Power BI deben tener una licencia de Power BI Pro o Power BI Premium por usuario
(PPU) .
７ Nota
Hay una excepción al requisito de una licencia de Power BI Pro o PPU: cuando el
área de trabajo está asignada a la capacidad Premium, los usuarios de licencias
gratuitas de Power BI (con permisos adecuados) pueden ver el contenido del área
de trabajo (o aplicación). Este enfoque se describe en el escenario de BI
empresarial.

informe de Excel, pueden usar la característica Analizar en Excel. Se prefiere conservar la
conectividad con el conjunto de datos para exportar datos a Excel porque:

Power BI. El escenario de BI de autoservicio administrado explora aún más la
datos local se vuelve relevante una vez que se publica un archivo Power BI Desktop en el
servicio Power BI. Los dos propósitos de una puerta de enlace son actualizar los datos
importados y ver un informe que consulta una conexión dinámica o un conjunto de
datos de DirectQuery (no se muestra en el diagrama de escenarios).
７ Nota


cumplimiento.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre la distribución de
contenido en toda la organización a escala en el escenario de BI empresarial.
Escenarios de uso de Power BI: BI para
empresas
７ Nota

implementación de Power BI. Para obtener una introducción a la serie, consulte
Como se describe en la hoja de ruta de adopción de Power BI, BI para empresas se

caracteriza por tener un número significativamente mayor de consumidores de
contenido respecto a un número mucho menor de autores que crean y publican
contenido.
La distinción entre BI para empresas y los escenarios de BI para departamento es el uso

de capacidad de Power BI Premium, lo que permite distribuir el contenido ampliamente
a los consumidores que tienen una licencia gratuita de Power BI. Los consumidores
pueden incluir usuarios dentro de la organización, así como usuarios invitados externos
a la organización.
Las implementaciones de BI para empresas de gran tamaño suelen emplear un enfoque

centralizado. Normalmente, en las empresas, un equipo centralizado mantiene el
contenido de Power BI para su uso general en toda la organización. El equipo
centralizado responsable de la administración de contenido suele ser TI, BI o el centro
de excelencia (COE).
７ Nota
Hay cuatro escenarios de uso de entrega y colaboración de contenido a medida que

el uso se va ampliando. El escenario de BI para empresas es el cuarto escenario.
Puede encontrar una lista de todos los escenarios en el artículo Escenarios de uso
de Power BI.

usuario más comunes y los componentes de Power BI que se admiten en BI para
empresas. El objetivo principal es la distribución de contenido a gran escala en toda la
organización, incluido el uso de la capacidad de Power BI Premium. En este escenario
también se muestra el desarrollo de informes paginados de Power BI.

Los creadores de contenido de Power BI desarrollan soluciones de BI mediante Power

BI Desktop. En un escenario de BI para empresas, es habitual que los creadores sean
miembros de un equipo centralizado (como TI, BI o COE) que da soporte a los
usuarios a través de los límites de la organización.
El desarrollo del modelo de datos y la creación de informes tiene lugar en Power BI

Desktop. El propósito es ayudar a los compañeros a comprender el significado y la
importancia de los datos colocándolos en un contexto visual.

Los creadores de informes desarrollan informes paginados mediante Power BI Report

Builder.
Power BI Report Builder consulta datos de uno o varios tipos de origen de datos. Se
genera un informe paginado para cumplir los requisitos de un informe de gran
formato y listo para imprimir.
Cuando está listo, los creadores de informes publican su archivo de Power BI Report
Builder (.RDL) en el servicio Power BI.
Se pueden publicar varios tipos de elementos de Power BI en un área de trabajo

Premium.
En el escenario de BI para empresas se muestra el uso de la capacidad Premium (en

lugar de Premium por usuario). Se hace esta elección para admitir la entrega de
contenido a muchos visores de contenido que tienen una licencia gratuita de Power
BI.
Algunos o todos los informes y paneles se publican como una aplicación de Power BI.
El propósito de la aplicación es proporcionar un conjunto de contenido relacionado
para que los consumidores puedan verlo de forma fácil de usar.
A los usuarios de aplicaciones de Power BI se les asignan permisos de solo lectura.

Los permisos de aplicación se administran por separado del área de trabajo. En un
escenario de BI para empresas los usuarios con cualquier tipo de licencia de Power BI
(gratis, Power BI Pro o PPU) se pueden asignar como visores de la aplicación. Esta
característica solo se aplica cuando se asigna un modo de licencia Premium por
capacidad al área de trabajo (los usuarios gratuitos no pueden acceder al contenido
del área de trabajo cuando se le asigna un modo de licencia de Premium por usuario
o Embedded).
Las aplicaciones móviles de Power BI también están disponibles para ver el contenido
de la aplicación y del área de trabajo.
conveniente administrar o ver contenido de Power BI directamente en Teams.
Los usuarios asignados a los roles de área de trabajo de administrador, miembro o

La actualización de datos programada se configura en el servicio Power BI para

mantener los datos importados actualizados, ya sea en conjuntos de datos o en flujos
de datos.
datos.

mediante un conjunto de datos existente. Pueden elegir usar Power BI Desktop, Excel
o Power BI Report Builder. Se recomienda la reutilización de los conjuntos de datos
existentes. El escenario de BI de autoservicio administrado explora aún más la
reutilización de conjuntos de datos.

Power BI. Las soluciones de BI para empresas suelen estar sujetas a requisitos de
gobernanza más estrictos que las soluciones de BI para equipo o de BI para
departamento.
Puntos clave
escenario de BI para empresas.
Elección de las herramientas de creación de informes

Power BI Desktop es una herramienta para desarrollar informes altamente interactivos,
mientras que Power BI Report Builder es una herramienta para desarrollar informes
paginados. Para obtener más información sobre cuándo usar informes paginados,
consulte Cuándo usar informes paginados en Power BI.
Los informes de Excel también se pueden publicar en el servicio Power BI (no se

muestran en el diagrama de escenarios) si una tabla dinámica o un gráfico dinámico
cumplen mejor los requisitos de los informes.

Para BI para empresas, es importante almacenar los archivos de Power BI Desktop de
origen y los archivos de Power BI Report Builder en una ubicación compartida y segura.
Las ubicaciones como OneDrive para uso profesional o educativo o SharePoint (no
representadas en el diagrama de escenarios) son útiles. Una biblioteca compartida se
puede proteger, es fácilmente accesible para compañeros e integra funcionalidades de
control de versiones.

los informes en archivos Power BI Desktop independientes (descritos en el escenario de
BI de autoservicio administrado). Este enfoque fomenta la reutilización del conjunto de
datos y es más eficaz que alternar continuamente entre las personas que editan el
archivo Power BI Desktop. Esto resulta especialmente útil cuando, por ejemplo, una
persona trabaja en el conjunto de datos mientras otra persona trabaja en los informes.
Áreas de trabajo
Un área de trabajo de Power BI es un contenedor lógico en el servicio Power BI para
almacenar elementos relacionados con Power BI, como conjuntos de datos e informes.
Aunque en este escenario se muestra una área de trabajo, normalmente se requieren
varias áreas de trabajo para satisfacer todos los requisitos de planeamiento del área de
trabajo.
En el escenario de BI de autoservicio administrado se describe el uso de áreas de trabajo

independientes.
Modo de licencia del área de trabajo

Se puede asignar un modo de licencia de área de trabajo a Pro, Premium por usuario
(PPU), Premium por capacidad o Embedded. Esta opción afecta a la disponibilidad de
características, así como a qué usuarios pueden acceder al contenido del área de trabajo
y a la aplicación de Power BI asociada. Un escenario de BI para empresas suele implicar
a muchos consumidores del contenido. Por lo tanto, puede ser rentable usar el modo de
licencia Premium por capacidad para distribuir contenido a los usuarios con una
licencia gratuita.
Publicación en la aplicación de Power BI

Para BI para empresas, una aplicación de Power BI funciona bien para la distribución de
contenido a los consumidores (en lugar de un acceso directo al área de trabajo, que se
describe en el escenario de BI para equipo). Una aplicación de Power BI proporciona la
mejor experiencia para los consumidores, ya que presenta un conjunto de contenido
relacionado con una experiencia de navegación fácil de usar. Una aplicación de Power BI
es especialmente útil en situaciones en las que hay un número mayor y más diverso de
consumidores, o cuando el desarrollador de contenido no trabaja estrechamente con
los consumidores de la aplicación.
Permisos en la aplicación de Power BI

A los usuarios de la aplicación Power BI se les concede permiso de solo lectura en la
aplicación, y estos permisos se administran separadamente del área de trabajo. Este
nivel adicional de flexibilidad es útil para administrar quién puede ver el contenido.
En el caso de BI para empresas se recomienda limitar el acceso del área de trabajo a los
responsables de las actividades de creación, desarrollo y control de calidad del
contenido. Normalmente, solo un pequeño número de personas requieren acceso al
área de trabajo. Los consumidores pueden acceder al contenido abriendo la aplicación
Power BI, en lugar de abrir el área de trabajo.
Distribución de contenido a usuarios de licencias

gratuitas de Power BI
Los usuarios con una licencia gratuita de Power BI (o licencias Power BI Pro o PPU)
pueden ver el contenido cuando se concede acceso a la aplicación o cuando se agregan
a un rol de área de trabajo, siempre que el área de trabajo esté asignada a la capacidad
Premium. Esta capacidad para distribuir contenido a los usuarios con una licencia
gratuita no está disponible para ninguno de los demás modos de licencia del área de
trabajo, incluidos Pro, Premium por usuario y Embedded.
Licencia de capacidad de Power BI Premium

En este escenario se describe el uso de una SKU P (como P1, P2, P3, P4 o P5). Se
requiere una SKU P para escenarios de producción típicos y es adecuada para el
escenario de BI para empresas descrito en este artículo.
Administrar el ciclo de vida del contenido

Por lo general, las soluciones de BI empresarial requieren estabilidad para el contenido
de producción. Uno de los aspectos es controlar cuándo y cómo se implementa el
contenido en producción. El uso de canalizaciones de implementación se describe en el
escenario de publicación de contenido de autoservicio.

informe de Excel, pueden usar la característica Analizar en Excel. Se prefiere conservar la
conectividad con el conjunto de datos para exportar datos a Excel porque:
Power BI. El escenario de BI de autoservicio administrado explora aún más la

７ Nota


cumplimiento.
Pasos siguientes
En el siguiente artículo de esta serie, obtendrá más información sobre la importancia de
reutilizar conjuntos de datos en el escenario de BI de autoservicio administrado.
autoservicio administrado
７ Nota

Como se describe en la hoja de ruta de adopción de Power BI, la BI de autoservicio

administrada se caracteriza por un enfoque combinado que enfatiza la disciplina en el
núcleo y la flexibilidad en el borde. Normalmente, la arquitectura de datos se mantiene
mediante un único equipo de expertos de BI centralizados, mientras que la
responsabilidad de los informes pertenece a los creadores dentro de departamentos o
Normalmente, hay muchos más creadores de informes que los creadores de conjuntos
de datos. Estos creadores de informes pueden existir en cualquier área de la
organización. Dado que los creadores de informes de autoservicio a menudo necesitan
generar contenido rápidamente, un enfoque combinado les permite centrarse en la
generación de informes que admiten la toma de decisiones oportunas sin el esfuerzo
adicional de crear un conjunto de datos.
７ Nota
El escenario de BI de autoservicio administrado es el primero de los escenarios de

BI de autoservicio. Para obtener una lista completa de los escenarios de BI de
autoservicio, consulte el artículo Escenarios de uso de Power BI.
Por motivos de brevedad, algunos aspectos descritos en el tema Escenarios de

colaboración y entrega de contenido no se tratan en este artículo. Si quiere
obtener una cobertura completa, lea primero esos artículos.

usuario más comunes y los componentes de Power BI que admiten la BI de autoservicio
administrada. El objetivo principal es que muchos creadores de informes reutilicen
conjuntos de datos compartidos centralizados. Para ello, este escenario se centra en
desacoplar el proceso de desarrollo de modelos del proceso de creación de informes.

Los creadores de conjuntos de datos desarrollan modelos mediante Power BI

Desktop. En el caso de los conjuntos de datos que están diseñados para su
reutilización, es habitual (pero no necesario) que los creadores pertenezcan a un
equipo centralizado que admita a los usuarios a través de límites de la organización
(como TI, BI empresarial o centro de excelencia).
Power BI Desktop se conecta a los datos de uno o varios orígenes de datos.
El desarrollo del modelo de datos se realiza en Power BI Desktop. Se realiza un

esfuerzo adicional para crear un modelo bien diseñado y fácil de usar, ya que muchos
creadores de informes de autoservicio lo usarán como origen de datos.
Cuando esté listo, los creadores de conjuntos de datos publican su archivo Power BI
Desktop (.pbix) que contiene solo un modelo en el servicio Power BI.
El conjunto de datos se publica en un área de trabajo dedicada a almacenar y

proteger conjuntos de datos compartidos. Dado que el conjunto de datos está
pensado para su reutilización, está aprobado (certificado o promocionado, según
corresponda). El conjunto de datos también se marca como detectable para fomentar
su reutilización. La vista de linaje de la servicio Power BI se puede usar para realizar
un seguimiento de las dependencias que existen entre los elementos de Power BI,
incluidos los informes conectados al conjunto de datos.
La detección de conjuntos de datos en el centro de datos está habilitada porque el

conjunto de datos está marcado como detectable. La detectabilidad permite que
otros creadores de contenido de Power BI que busquen datos puedan ver la
existencia de un conjunto de datos en el centro de datos.
Los creadores de informes usan el centro de datos del servicio Power BI para buscar
conjuntos de datos reconocibles.
Si los creadores de informes no tienen permiso, pueden solicitar permiso de

compilación en el conjunto de datos. Esto inicia un flujo de trabajo para solicitar el
permiso de compilación desde un aprobador autorizado.
Los creadores de informes crean nuevos informes mediante Power BI Desktop. Los
informes usan una conexión dinámica a un conjunto de datos compartido.
Los creadores de informes desarrollan informes en Power BI Desktop.
Cuando está listo, los creadores de informes publican su archivo de Power BI Desktop
en el servicio Power BI.
Los informes se publican en un área de trabajo dedicada al almacenamiento y

protección de informes y paneles.
Los informes publicados permanecen conectados al conjunto de datos compartido

almacenado en un área de trabajo diferente. Los cambios en el conjunto de datos
compartido afectan a todos los informes conectados a él.
Otros creadores de informes de autoservicio pueden crear nuevos informes mediante

el conjunto de datos compartido existente. Los creadores de informes pueden elegir
usar Power BI Desktop, Power BI Report Builder o Excel.
datos.
Los administradores de Power BI monitorizan y supervisan la actividad del servicio

Power BI.
Puntos clave
A continuación, se muestran algunos puntos clave para destacar sobre el escenario de
publicación de contenido de autoservicio.
Conjunto de datos compartidos

El aspecto clave de hacer que la BI de autoservicio administrada funcione es minimizar el
número de conjuntos de datos. Este escenario trata sobre conjuntos de datos
compartidos que ayudan a lograr una única versión de la verdad.
７ Nota
Para simplificar, el diagrama de escenarios muestra solo un conjunto de datos

compartido. Sin embargo, no suele ser práctico modelar todos los datos de la
organización en un único conjunto de datos. El otro extremo es crear un nuevo
conjunto de datos para cada informe, ya que los creadores de contenido menos
experimentados suelen hacer. El objetivo de la BI de autoservicio administrada es
encontrar el equilibrio adecuado, inclinarse hacia relativamente pocos conjuntos de
datos y crear nuevos conjuntos de datos cuando tenga sentido hacerlo.
Desacoplar el conjunto de datos y los informes

Cuando el conjunto de datos se desacopla de los informes, facilita la separación del
esfuerzo y la responsabilidad. Normalmente, un equipo centralizado mantiene un
conjunto de datos compartido (como TI, BI o Centro de excelencia), mientras que los
informes los mantienen los expertos en la materia en las unidades de negocio. Sin
embargo, eso no es necesario. Por ejemplo, cualquier creador de contenido que quiera
lograr la reutilización puede adoptar este patrón.
７ Nota
Por motivos de simplicidad, los flujos de datos no se muestran en el diagrama de

escenarios. Para más información sobre los flujos de datos, consulte el escenario de
preparación de datos de autoservicio.
Aprobación del conjunto de datos

Dado que los conjuntos de datos compartidos están diseñados para su reutilización,
resulta útil aprobarlos. Un conjunto de datos certificado transmite a los creadores de
informes que los datos son de confianza y cumplen los estándares de calidad de la
organización. Un conjunto de datos promocionado resalta que el propietario del
conjunto de datos cree que los datos son valiosos y vale la pena para que otros lo usen.
 Sugerencia
Se recomienda tener un proceso coherente, repetible y riguroso para respaldar el

contenido. El contenido certificado debe indicar que se ha validado la calidad de
los datos. También debe seguir las normas de administración de cambios, contar
mayores.
Detección de conjuntos de datos

El centro de datos ayuda a los creadores de informes a buscar, explorar y usar conjuntos
de datos en toda la organización. Además de la aprobación del conjunto de datos,
habilitar la detección de conjuntos de datos es fundamental para promover su
reutilización. Un conjunto de datos reconocible está visible en el centro de datos para
los creadores de informes que buscan datos.
７ Nota
Si un conjunto de datos no está configurado para ser reconocible, solo los usuarios
de Power BI con permiso de compilación pueden encontrarlo.
Solicitud de acceso al conjunto de datos

Un creador de informes puede encontrar un conjunto de datos en el centro de datos
que desea usar. Si no tienen permiso de compilación para el conjunto de datos, pueden
solicitar acceso. En función de la configuración de acceso de solicitud para el conjunto
de datos, se enviará un correo electrónico al propietario del conjunto de datos o a las
instrucciones personalizadas a la persona que solicita acceso.
Conexión dinámica al conjunto de datos compartido

Una conexión dinámica de Power BI Desktop conecta un informe a un conjunto de
datos existente. Las conexiones dinámicas evitan la necesidad de crear un nuevo
modelo de datos en el archivo Power BI Desktop.
） Importante
Al usar una conexión dinámica, todos los datos que el creador del informe necesita
deben residir en el conjunto de datos conectado. Sin embargo, el escenario de BI
de autoservicio administrada personalizable describe cómo se puede ampliar un
conjunto de datos con datos y cálculos adicionales.
Publicación en áreas de trabajo independientes

Hay varias ventajas para publicar informes en un área de trabajo diferente de donde se
almacena el conjunto de datos.
En primer lugar, hay claridad sobre quién es responsable de administrar el contenido en

qué área de trabajo. En segundo lugar, los creadores de informes tienen permisos para
publicar contenido en un área de trabajo de informes (a través de roles de
administrador, miembro o colaborador del área de trabajo). Sin embargo, solo tienen
permisos de lectura y compilación para conjuntos de datos específicos. Esta técnica
permite que la seguridad de nivel de fila (RLS) surta efecto cuando sea necesario para
los usuarios asignados al rol de visor.
） Importante
Cuando se publica un informe de Power BI Desktop en un área de trabajo, los roles

RLS se aplican a los miembros que tienen asignado el rol de visor en el área de
trabajo. Aunque los visores tienen permiso de compilar el conjunto de datos, el RLS
se sigue aplicando. Para más información, consulte Uso de RLS con áreas de
trabajo en Power BI.
Análisis de dependencias e impacto

Cuando muchos informes usan un conjunto de datos compartido, esos informes pueden
existir en muchas áreas de trabajo. La vista de linaje ayuda a identificar y comprender las
dependencias de bajada. Al planear un cambio de conjunto de datos, realice primero un
análisis de impacto para comprender qué informes dependientes pueden requerir
edición o pruebas.

datos de DirectQuery.
７ Nota
En escenarios de BI de autoservicio administrados, se recomienda encarecidamente

una puerta de enlace de datos centralizada en modo estándar a través de puertas
de enlace en modo personal. En el modo estándar la puerta de enlace de datos
admite conexiones dinámicas y operaciones de DirectQuery (además de las
operaciones de actualización de datos programadas).

cumplimiento. Con un escenario de BI de autoservicio administrada, resulta
especialmente útil realizar un seguimiento del uso de conjuntos de datos compartidos.
Una relación elevada entre informes y conjuntos de datos indica una buena reutilización
de los conjuntos de datos.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre las formas de
personalizar y ampliar un conjunto de datos compartido para cumplir otros tipos de
requisitos.
autoservicio administrado
personalizable
７ Nota

Como se describe en la hoja de ruta de adopción de Power BI, la BI de autoservicio

administrada se caracteriza por un enfoque combinado que enfatiza la disciplina en el
núcleo y la flexibilidad en el borde. Normalmente, la arquitectura de datos se mantiene
mediante un único equipo de expertos de BI centralizados, mientras que la
responsabilidad de los informes pertenece a los creadores dentro de departamentos o
Sin embargo, cuando la arquitectura de datos principal no incluye todos los datos
necesarios, los creadores de conjuntos de datos pueden ampliar, personalizar o
personalizar conjuntos de datos compartidos existentes. Se pueden crear nuevos
conjuntos de datos especializados que cumplan los requisitos empresariales no
cumplidos por los conjuntos de datos entregados centralmente existentes. Lo
importante es que no haya duplicación de datos principales. Este escenario de uso se
denomina BI de autoservicio administrado personalizable.
７ Nota
Este escenario de BI de autoservicio administrado personalizable es el segundo de

los escenarios de BI de autoservicio. Este escenario se basa en lo que se puede
hacer con un conjunto de datos compartido centralizado (que se introdujo en el
escenario de BI de autoservicio administrado ). Puede encontrar una lista de todos
los escenarios en el artículo Escenarios de uso de Power BI.
Para mayor brevedad, algunos aspectos descritos en el tema Escenarios de

usuario más comunes y los componentes de Power BI para admitir BI de autoservicio
administrado personalizable. El objetivo principal es proporcionar a los creadores de
contenido en las unidades de negocio la capacidad de crear un modelo de datos
especializado mediante la extensión de un conjunto de datos compartido existente. El
objetivo es lograr la reutilización siempre que sea posible y permitir la flexibilidad para
satisfacer requisitos analíticos adicionales.

El creador de conjuntos de datos A desarrolla un modelo mediante Power BI Desktop.

Para un conjunto de datos destinado a su reutilización, es común (pero no necesario)
que el creador pertenezca a un equipo centralizado que admita usuarios a través de
límites de la organización (como TI, BI empresarial o centro de excelencia).
Power BI Desktop se conecta a los datos de uno o varios orígenes de datos.
El desarrollo del modelo de datos se realiza en Power BI Desktop. Se realiza un

esfuerzo adicional para crear un modelo bien diseñado y fácil de usar, ya que muchos
creadores de informes de autoservicio pueden usarse como origen de datos.
Cuando esté listo, el creador del conjunto de datos A publica su archivo de Power BI
Desktop (.pbix) que solo contiene un modelo en el servicio Power BI.
El conjunto de datos se publica en un área de trabajo dedicada a almacenar y

proteger conjuntos de datos compartidos. Dado que el conjunto de datos está
pensado para su reutilización, está aprobado (certificado o promocionado, según
corresponda). El conjunto de datos también se marca como detectable para fomentar
su reutilización. La vista de linaje de la servicio Power BI se puede usar para realizar
un seguimiento de las dependencias que existen entre los elementos de Power BI.
La detección de datos en el centro de datos está habilitada porque el conjunto de

datos está marcado como reconocible. La detectabilidad permite que otros creadores
de contenido de Power BI que busquen datos puedan ver la existencia de un
conjunto de datos en el centro de datos.
El creador del conjunto de datos B usa el centro de datos en el servicio Power BI para
buscar conjuntos de datos reconocibles.
Si el creador del conjunto de datos B no tiene permiso, puede solicitar el permiso de

compilación en el conjunto de datos. Esto inicia un flujo de trabajo para solicitar el
permiso de compilación desde un aprobador autorizado.
En Power BI Desktop, el creador del conjunto de datos B crea una conexión dinámica
al conjunto de datos compartido original que se encuentra en el servicio Power BI.
Dado que la intención es ampliar y personalizar el conjunto de datos original, la
conexión dinámica se convierte en un modelo de DirectQuery. Esta acción da como
resultado un modelo local en el archivo Power BI Desktop.
Power BI Desktop se conecta a datos de orígenes de datos adicionales. El objetivo es

aumentar el conjunto de datos compartido para que el nuevo conjunto de datos
especializado cumpla los requisitos analíticos adicionales.
Las relaciones se crean en Power BI Desktop entre las tablas existentes (del conjunto
de datos compartido, también conocido como modelo remoto) y las nuevas tablas
recién importadas (almacenadas en el modelo local). Los cálculos adicionales y el
trabajo de modelado se realizan en Power BI Desktop para completar el diseño del
modelo especializado.
Cuando esté listo, el creador del conjunto de datos B publica su archivo Power BI
Desktop en el servicio Power BI.
El nuevo conjunto de datos especializado se publica en un área de trabajo dedicada a

almacenar y proteger los conjuntos de datos que son propiedad y administran el
departamento.
El conjunto de datos especializado permanece conectado al conjunto de datos

compartido de Power BI original. Los cambios realizados en el conjunto de datos
compartido original afectarán a los conjuntos de datos especializados de bajada que
tienen dependencia de él.
Otros creadores de informes de autoservicio pueden crear nuevos informes

conectados al conjunto de datos especializado. Los creadores de informes pueden
elegir usar Power BI Desktop, Power BI Report Builder o Excel.
Los creadores de informes crean nuevos informes mediante Power BI Desktop.

Los informes publicados permanecen conectados al conjunto de datos especializado

que se almacena en otra área de trabajo. Cualquier cambio en el conjunto de datos
especializado afecta a todos los informes conectados a él.
datos.

Power BI.
Puntos clave
escenario de BI de autoservicio administrado personalizable.
Conjunto de datos compartidos

El aspecto clave de hacer que la BI de autoservicio administrada funcione es minimizar el
número de conjuntos de datos. En este escenario se muestra un conjunto de datos
compartido que contribuye a lograr una única versión de la verdad.
７ Nota
Para simplificar, el diagrama de escenarios muestra solo un conjunto de datos

compartido. Sin embargo, no suele ser práctico modelar todos los datos de la
organización en un único conjunto de datos. El otro extremo es crear un nuevo
conjunto de datos para cada informe, ya que los creadores de contenido menos
experimentados suelen hacer. El objetivo es encontrar el equilibrio adecuado,
inclinarse hacia relativamente pocos conjuntos de datos y crear nuevos conjuntos
de datos cuando tenga sentido hacerlo.
Aumento del conjunto de datos compartido inicial
A veces, los creadores de autoservicio necesitan aumentar un conjunto de datos
existente con, por ejemplo, datos adicionales específicos de su departamento. En este
caso, pueden usar conexiones de DirectQuery a conjuntos de datos de Power BI. Esta
característica permite un equilibrio ideal de la capacitación de autoservicio, al tiempo
que se aprovecha la inversión en recursos de datos que se administran de forma
centralizada. En el diagrama de escenario se muestra una conexión de DirectQuery. El
acto de convertir una conexión dinámica a una conexión DirectQuery crea un modelo
local que permite agregar nuevas tablas. Las relaciones se pueden crear entre tablas del
conjunto de datos compartido original (el modelo remoto) y las nuevas tablas recién
agregadas (el modelo local). Se pueden realizar cálculos adicionales y modelado de
datos para personalizar el nuevo modelo de datos.
 Sugerencia
En este escenario se resalta la reutilización de un conjunto de datos compartido.

Sin embargo, a veces hay situaciones en las que los modeladores de datos quieren
limitar la creación del modelo de datos de bajada. En ese caso, pueden habilitar la
propiedad Desalentar las conexiones de DirectQuery en la configuración de Power
BI Desktop.
Aprobación del conjunto de datos

Dado que los conjuntos de datos compartidos están diseñados para su reutilización,
resulta útil aprobarlos. Un conjunto de datos certificado transmite a los creadores de
informes que los datos son de confianza y cumplen los estándares de calidad de la
organización. Un conjunto de datos promocionado resalta que el propietario del
conjunto de datos cree que los datos son valiosos y vale la pena para que otros lo usen.
 Sugerencia
Se recomienda tener un proceso coherente, repetible y riguroso para respaldar el

contenido. El contenido certificado debe indicar que se ha validado la calidad de
los datos. También debe seguir las normas de administración de cambios, contar
mayores.
Detección de conjuntos de datos
El centro de datos ayuda a los creadores de informes a buscar, explorar y usar conjuntos
de datos en toda la organización. Además de la aprobación del conjunto de datos,
habilitar la detección de conjuntos de datos es fundamental para promover su
reutilización. Un conjunto de datos reconocible está visible en el centro de datos para
los creadores de informes que buscan datos.
７ Nota
Si un conjunto de datos no está configurado para ser reconocible, solo los usuarios
de Power BI con permiso de compilación pueden encontrarlo.
Solicitud de acceso al conjunto de datos

Un creador de informes puede encontrar un conjunto de datos en el centro de datos
que desea usar. Si no tienen permiso de compilación para el conjunto de datos, pueden
solicitar acceso. En función de la configuración de acceso de solicitud para el conjunto
de datos, se enviará un correo electrónico al propietario del conjunto de datos o a las
instrucciones personalizadas a la persona que solicita acceso.

Hay varias ventajas para publicar informes en un área de trabajo diferente de donde se
almacena el conjunto de datos.
En primer lugar, hay claridad sobre quién es responsable de administrar el contenido en

qué área de trabajo. En segundo lugar, los creadores de informes tienen permisos para
publicar contenido en un área de trabajo de informes (a través de roles de
administrador, miembro o colaborador del área de trabajo). Sin embargo, solo tienen
permisos de lectura y compilación para conjuntos de datos específicos. Esta técnica
permite que la seguridad de nivel de fila (RLS) surta efecto cuando sea necesario para
los usuarios asignados al rol de visor.
Análisis de dependencias e impacto

Cuando otros conjuntos de datos o informes usan un conjunto de datos compartido,
esos objetos dependientes pueden existir en muchas áreas de trabajo. La vista de linaje
ayuda a identificar y comprender las dependencias de bajada. Al planear un cambio de
conjunto de datos, realice primero un análisis de impacto para comprender qué
conjuntos de datos o informes se deben editar o probar.

datos de DirectQuery.
７ Nota
Para escenarios de BI de autoservicio administrados personalizables, se recomienda

encarecidamente una puerta de enlace de datos centralizada en modo estándar a
través de puertas de enlace en modo personal. En el modo estándar, la puerta de

cumplimiento. Con un escenario de BI de autoservicio administrado personalizable,
resulta especialmente útil realizar un seguimiento del uso del conjunto de datos
compartido original, así como de los conjuntos de datos dependientes.
Pasos siguientes
En el siguiente artículo de esta serie, obtenga información sobre cómo reutilizar el
trabajo de preparación de datos con flujos de datos en el escenario de preparación de
datos de autoservicio.
preparación de datos de autoservicio
７ Nota

La preparación de datos (a veces denominada "ETL", que es un acrónimo de Extract,

Transform y Load) suele implicar una cantidad significativa de trabajo en función de la
calidad y la estructura de los datos de origen. El escenario de uso de preparación de
datos de autoservicio se centra en la reutilización de las actividades de preparación de
datos por parte de los analistas empresariales. Logra este objetivo de reutilización
reasignando el trabajo de preparación de datos de Power Query (dentro de archivos de
Power BI Desktop concretos) a Power Query Online (mediante un flujo de datos de
Power BI). La centralización de la lógica ayuda a lograr una única fuente de la verdad y
reduce el nivel de esfuerzo requerido por otros creadores de contenido.
Los flujos de datos se crean mediante Power Query Online en una de varias
herramientas: el servicio Power BI, Power Apps o Dynamics 365 Customer Insights. Un
flujo de datos creado en Power BI se conoce como "flujo de datos analítico". Los flujos
de datos creados en Power Apps pueden ser uno de los dos tipos: estándar o analíticos.
Este escenario solo abarca el uso de un flujo de datos de Power BI creado y
administrado dentro del servicio Power BI.
７ Nota
El escenario de preparación de datos de autoservicio es uno de los escenarios de BI

de autoservicio. Para obtener una lista completa de los escenarios de autoservicio,
consulte el artículo Escenarios de uso de Power BI.


En el diagrama siguiente se muestra una introducción general de las acciones de usuario
más comunes y los componentes de Power BI que admiten la preparación de datos de
autoservicio. El objetivo principal es crear un flujo de datos en Power Query Online que
se convierta en un origen de datos para varios conjuntos de datos. El objetivo es que
muchos conjuntos de datos aprovechen la preparación de datos que realiza una vez el
flujo de datos.

El creador del flujo de datos desarrolla una colección de tablas dentro de un flujo de
datos de Power BI. En el caso de un flujo de datos destinado a su reutilización, es
habitual (pero no necesario) que el creador pertenezca a un equipo centralizado que
admita usuarios en toda la organización (como TI, BI empresarial o el Centro de
excelencia).
El flujo de datos conecta con los datos de uno o más orígenes de datos.
Los flujos de datos se desarrollan mediante Power Query Online, que es una versión
web de Power Query. La conocida interfaz de Power Query en Power Query Online
facilita la transición de Power BI Desktop.
El flujo de datos se guarda como un elemento de un área de trabajo dedicada al

almacenamiento y la protección de flujos de datos. Se requiere una programación de
actualización de flujo de datos para mantener los datos actualizados (no se muestran
en el diagrama de escenarios).
El creador del conjunto de datos desarrolla un nuevo modelo de datos mediante

Power BI Desktop.
El flujo de datos es un origen de datos para el nuevo modelo de datos.
El creador del conjunto de datos puede usar todas las funcionalidades de Power
Query dentro de Power BI Desktop. Opcionalmente, pueden aplicar pasos de consulta
adicionales para transformar aún más los datos del flujo de datos o combinar la salida
del flujo de datos.
Cuando esté listo, el creador del conjunto de datos publica el archivo Power BI
Desktop (.pbix) que contiene el modelo de datos en el servicio Power BI. La
actualización del conjunto de datos se administra independientemente del flujo de
datos (no se muestra en el diagrama del escenario).
El flujo de datos se puede reutilizar como origen de datos por otros conjuntos de
datos que podrían residir en diferentes áreas de trabajo.
Los administradores de Power BI administran la configuración en el portal de

administración.
En el portal de administración, los administradores de Power BI pueden configurar

conexiones de Azure para almacenar los datos de los flujos de datos en su cuenta de
Azure Data Lake Storage Gen2 (ADLS Gen2). La configuración incluye la asignación de
una cuenta de almacenamiento de nivel de inquilino y la habilitación de permisos de
almacenamiento de nivel de área de trabajo.
De forma predeterminada, los flujos de datos almacenan datos mediante el

almacenamiento interno administrado por el servicio Power BI. De forma opcional, la
salida de datos del flujo de datos se puede almacenar en la cuenta de ADLS Gen2 de
la organización. A veces, este tipo de almacenamiento se denomina traiga su propio
lago de datos. Una ventaja de almacenar datos de flujo de datos en el lago de datos
es que otras herramientas de BI pueden acceder a ellos y consumirlos.
Los datos de flujo de datos de ADLS Gen2 se almacenan en un contenedor específico

de Power BI conocido como sistema de archivos. Dentro de este contenedor, existe
una carpeta para cada área de trabajo. Se crea una subcarpeta para cada flujo de
datos, así como para cada tabla. Power BI genera una instantánea cada vez que se
actualizan los datos del flujo de datos. Las instantáneas se describen
automáticamente, que constan de metadatos y archivos de datos.
Otros creadores de conjuntos de datos de autoservicio pueden crear nuevos modelos

de datos en Power BI Desktop mediante el flujo de datos como origen de datos.
Los administradores de Azure administran permisos para la cuenta de ADLS Gen2 de

la organización.
datos.

Power BI.
 Sugerencia
También se recomienda revisar el escenario de uso de preparación avanzada de

datos. Se basa en los conceptos introducidos en este escenario.
Puntos clave
Estos son algunos puntos clave que se deben destacar sobre el escenario de
Flujos de datos
Un flujo de datos consta de una colección de tablas (también conocidas como
entidades). Todo el trabajo de creación de un flujo de datos se realiza en Power Query
Online . Puede crear flujos de datos en varios productos, como Power Apps, Dynamics
365 Customer Insights y Power BI.
７ Nota
No se pueden crear flujos de datos en un área de trabajo personal en el servicio

Power BI.
Compatibilidad con creadores de conjuntos de datos

En el diagrama de escenario se muestra el uso de un flujo de datos de Power BI para
proporcionar datos preparados a otros creadores de conjuntos de datos de autoservicio.
７ Nota
Los conjuntos de datos usan el flujo de datos como origen de datos. Un informe no
se puede conectar directamente a un flujo de datos.
Estas son algunas ventajas del uso de flujos de datos de Power BI:
Los creadores de conjuntos de datos usan la misma interfaz de Power Query

conocida que se encuentra en Power BI Desktop.
La lógica de preparación y transformación de datos definida por un flujo de datos
se puede reutilizar muchas veces porque está centralizada.
Cuando se realizan cambios en la lógica de preparación de datos en el flujo de
datos, es posible que no requiera actualizar los modelos de datos dependientes.
Quitar o cambiar el nombre de las columnas o cambiar los tipos de datos de
columna requerirá actualizar los modelos de datos dependientes.
Los datos preparados previamente se pueden poner fácilmente a disposición de
los creadores de conjuntos de datos de Power BI. La reutilización es especialmente
útil para las tablas que se usan habitualmente, especialmente las tablas de
dimensiones, como la fecha, el cliente y el producto.
El nivel de esfuerzo requerido por los creadores de conjuntos de datos se reduce
porque el trabajo de preparación de datos se ha desacoplado del trabajo de
modelado de datos.
Menos creadores de conjuntos de datos necesitan acceso directo a los sistemas de
origen. Los sistemas de origen pueden ser complejos de consultar y pueden
requerir permisos de acceso especializados.
El número de actualizaciones ejecutadas en los sistemas de origen se reduce
porque las actualizaciones del conjunto de datos se conectan a los flujos de datos
y no a los sistemas de origen desde los que los flujos de datos extraen datos.
Los datos de flujo de datos representan una instantánea en el tiempo y promueven
la coherencia cuando los usan muchos conjuntos de datos.
La desacoplación de la lógica de preparación de datos en flujos de datos puede
ayudar a mejorar el éxito de la actualización del conjunto de datos. Si se produce
un error en una actualización de flujo de datos, los conjuntos de datos se
actualizarán con la última actualización correcta del flujo de datos.
 Sugerencia
Cree tablas de flujo de datos aplicando principios de diseño de esquema de

estrella. Un diseño de esquema de estrella es adecuado para crear conjuntos de
datos de Power BI. Además, refinar la salida del flujo de datos para aplicar nombres
descriptivos y usar tipos de datos específicos. Estas técnicas promueven la
coherencia en conjuntos de datos dependientes y ayudan a reducir la cantidad de
trabajo que los creadores de conjuntos de datos necesitan hacer.
Flexibilidad del creador del conjunto de datos
Cuando un creador de conjuntos de datos se conecta a un flujo de datos en Power BI
Desktop, el creador no se limita al uso de la salida exacta del flujo de datos. Todavía
tienen la funcionalidad completa de Power Query están disponibles. Esta funcionalidad
es útil si se requiere un trabajo adicional de preparación de datos o los datos requieren
una transformación adicional.
Características avanzadas de flujo de datos

Hay muchas técnicas de diseño, patrones y procedimientos recomendados para flujos
de datos que pueden pasar del autoservicio a estar listos para la empresa. Los flujos de
datos de un área de trabajo con su modo de licencia establecido en Premium por
usuario o Premium por capacidad pueden beneficiarse de características avanzadas.
７ Nota
Una de las características avanzadas es la actualización incremental de los flujos de

datos. Aunque la actualización incremental de los conjuntos de datos es una
característica de Power BI Pro, la actualización incremental de los flujos de datos es
una característica Premium.
Para obtener más información sobre las características avanzadas del flujo de datos,
consulte el escenario de uso avanzado de la preparación de datos.
Actualización de flujos y conjuntos de datos

Como se mencionó anteriormente, un flujo de datos es un origen de datos para
conjuntos de datos. En la mayoría de los casos, hay varias programaciones de
actualización de datos implicadas: una para el flujo de datos y otra para cada conjunto
de datos. Como alternativa, es posible usar DirectQuery desde el conjunto de datos al
flujo de datos, que es una característica Premium (no se muestra en el diagrama de
escenarios).
Azure Data Lake Storage Gen2

En Microsoft Azure, una cuenta de ADLS Gen2 es un tipo específico de cuenta de Azure
Storage que tiene habilitado el espacio de nombres jerárquico. ADLS Gen2 tiene
ventajas de rendimiento, administración y seguridad para operar cargas de trabajo
analíticas. De forma predeterminada, los flujos de datos de Power BI usan el
almacenamiento interno, que es una cuenta integrada de lago de datos administrada
por el servicio Power BI. Opcionalmente, las organizaciones pueden traer su propio lago
de datos mediante la conexión a la cuenta de ADLS Gen2 de su organización.
Estas son algunas de las ventajas de usar la cuenta de Data Lake de la organización:
Otros usuarios o procesos pueden acceder a los datos almacenados por un flujo
de datos de Power BI (opcionalmente) desde el lago de datos. Esto es útil cuando
el flujo de datos se reutiliza fuera de Power BI. Por ejemplo, Azure Data Factory
podría acceder a los datos.
Los datos del lago de datos pueden administrarse (opcionalmente) mediante otras
herramientas o sistemas. En este caso, Power BI puede consumir los datos en lugar
de administrarlos (lo cual no se representa en el diagrama de escenarios).
Almacenamiento de nivel de inquilino

La sección Conexiones de Azure del portal de Administración incluye una configuración
para configurar una conexión a una cuenta de ADLS Gen2. La configuración de esta
opción permite traer su propio lago de datos. Una vez configurado, puede establecer
áreas de trabajo para que usen esa cuenta de Data Lake.
） Importante
Establecer conexiones de Azure no significa que todos los flujos de datos del
inquilino de Power BI se almacenen en esta cuenta de forma predeterminada. Para
usar una cuenta de almacenamiento explícita (en lugar de almacenamiento
interno), cada área de trabajo debe estar conectada específicamente.
Es fundamental establecer las conexiones de Azure del área de trabajo antes de

crear flujos de datos en el área de trabajo. La misma cuenta de almacenamiento de
Azure se usa para las copias de seguridad del conjunto de datos de Power BI.
Almacenamiento de nivel de área de trabajo

Un administrador de Power BI puede configurar una opción para permitir permisos de
almacenamiento de nivel de área de trabajo (en la sección Conexiones de Azure del
portal de Administración). Cuando se habilita, esta opción permite a los administradores
del área de trabajo usar una cuenta de almacenamiento diferente a la definida en el
nivel de inquilino. Habilitar esta configuración es especialmente útil para las unidades de
negocio descentralizadas que administran su propio lago de datos en Azure.
７ Nota
El permiso de almacenamiento de nivel de área de trabajo del portal de

Administración se aplica a todas las áreas de trabajo del inquilino de Power BI.
Formato Common Data Model

Los datos de una cuenta de ADLS Gen2 se almacenan en la estructura Common Data
Model (CDM). La estructura de CDM es un formato de metadatos que determina cómo
se almacena el esquema autodescripto, así como los datos. La estructura de CDM
permite la coherencia semántica en un formato estandarizado para compartir datos en
numerosas aplicaciones (no se muestra en el diagrama de escenarios).

Hay varias ventajas para publicar un flujo de datos en un área de trabajo independiente
de donde se almacenan los conjuntos de datos dependientes. Una ventaja es la claridad
sobre quién es responsable de administrar qué tipos de contenido (si tiene diferentes
personas que controlan diferentes responsabilidades). Otra ventaja es que se pueden
asignar permisos de área de trabajo específicos para cada tipo de contenido.
７ Nota

Power BI.
En el escenario de uso avanzado de preparación de datos se describe cómo

configurar varias áreas de trabajo para proporcionar una mejor flexibilidad al
admitir creadores de autoservicio de nivel empresarial.

Normalmente, se requiere una puerta de enlace de datos local para conectarse a los
orígenes de datos que residan en una red de organización privada o una red virtual.
Se requiere una puerta de enlace de datos en los casos siguientes:

Para crear un flujo de datos en Power Query Online que se conecte a los datos
privados de una organización.
Para actualizar un flujo de datos que se conecte a los datos privados de una
organización.
 Sugerencia
Los flujos de datos requieren una puerta de enlace de datos centralizada en modo
estándar. Al trabajar con flujos de datos, no se admite una puerta de enlace en
modo personal.

cumplimiento. Con un escenario de preparación de datos de autoservicio, resulta
especialmente útil realizar un seguimiento del uso de flujos de datos.
Pasos siguientes
En el siguiente artículo de la serie, obtenga información sobre el escenario de uso
avanzado de preparación de datos.
Preparación de datos avanzada
７ Nota

implementación de Power BI. Para acceder a una introducción a la serie, consulte el
Las actividades de preparación de datos (a veces denominadas ETL, por el acrónimo en

inglés de extracción, transformación y carga [Extract, Transform and Load]) suelen
implicar un gran esfuerzo. El tiempo, la aptitud y el esfuerzo destinados a la
recopilación, limpieza, combinación y enriquecimiento de los datos depende de la
calidad y la estructura de los datos de origen.
Dedicar tiempo y esfuerzo a la preparación centralizada de los datos ayuda a lo

siguiente:
Mejorar la reutilización y obtener el máximo valor de los esfuerzos de preparación

de datos.
Mejorar la capacidad para proporcionar datos coherentes a varios equipos.
Reducir el nivel de esfuerzo requerido por otros creadores de contenido.
Lograr la escalabilidad y el rendimiento.
El escenario de uso de preparación de datos avanzada se expande en el escenario de

preparación de datos de autoservicio. La preparación de datos avanzada consiste en
incrementar la reutilización de los flujos de datos por parte de múltiples usuarios en
diversos equipos y para varios casos de uso.
Las áreas de trabajo independientes, organizadas por finalidad del flujo de datos, son
útiles cuando la salida del flujo de datos se proporciona a varios creadores de conjuntos
de datos, sobre todo cuando se encuentran en distintos equipos de la organización.
También son útiles para administrar los roles de seguridad cuando las personas que
crean y administran los flujos de datos son distintas de las personas que los consumen.
７ Nota
El escenario de preparación de datos avanzada es el segundo de los escenarios de

preparación de datos. Este escenario se basa en las acciones que se pueden realizar
con los flujos de datos centralizados, como se describe en el escenario de
El escenario de preparación de datos avanzada es uno de los escenarios de BI de

autoservicio. Sin embargo, un miembro del equipo centralizado puede usar las
técnicas de forma similar a la descrita en el escenario de BI de autoservicio
administrada. Para obtener una lista completa de los escenarios de autoservicio,
consulte el artículo Escenarios de uso de Power BI.

 Sugerencia
Se recomienda revisar el escenario de uso de preparación de datos de

autoservicio si no está familiarizado con él. El escenario de preparación avanzada
de datos de autoservicio se basa en él.
Este escenario de preparación de datos avanzada se centra en:
El uso de flujos de datos independientes en función de su finalidad:

almacenamiento provisional, transformación o final. Se recomienda usar bloques de
creación que admitan composición a fin de poder reutilizarlos más y en distintas
combinaciones para satisfacer requisitos específicos de los usuarios. Los bloques
de creación que admiten composición se describen más adelante en este artículo.
El uso de áreas de trabajo independientes que admitan creadores de flujos de
datos o consumidores de estos. Los modeladores de datos, que consumen flujos de
datos, pueden estar en equipos distintos o tener casos de uso diferentes.
El uso de tablas vinculadas (también conocidas como entidades vinculadas), tablas
calculadas (también conocidas como entidades calculadas) y el motor de proceso
mejorado.
７ Nota
A veces, los términos conjunto de datos y modelo de datos se usan indistintamente.

En general, desde una perspectiva del servicio Power BI, se usa el término conjunto
de datos. Desde una perspectiva de desarrollo, se conoce como modelo de datos (o
modelo para abreviar). En este artículo, ambos términos tienen el mismo
significado. Del mismo modo, el significado de creador de conjuntos de datos y
modelador de datos es el mismo.

usuario más comunes y los componentes de Power BI que admiten el escenario de
preparación de datos avanzada.
En el diagrama de escenarios se muestran las acciones de usuario, las herramientas y las

características siguientes:
El creador del flujo de datos desarrolla una colección de tablas dentro de un flujo de
datos. En el caso de un flujo de datos destinado a su reutilización, es habitual (pero
no necesario) que el creador pertenezca a un equipo centralizado que admita
usuarios en toda la organización (como TI, BI empresarial o el Centro de excelencia).
El flujo de datos conecta con los datos de uno o más orígenes de datos.
Los creadores de flujos de datos desarrollan flujos de datos con Power Query Online,
que es una versión de Power Query basada en web.
Se crea un flujo de datos de almacenamiento provisional en un área de trabajo

dedicada a la administración centralizada de los flujos de datos. Un flujo de datos de
almacenamiento provisional copia los datos sin procesar tal cual desde el origen. Se
aplican pocas transformaciones, en caso de hacerlo.
Se crea un flujo de datos de transformación (también conocido como flujo de datos

limpio) en la misma área de trabajo. Obtiene datos mediante el uso de tablas
vinculadas al flujo de datos de almacenamiento provisional. Las tablas calculadas
incluyen pasos de transformación que preparan, limpian y vuelven a dar forma a los
datos.
Los creadores de flujos de datos tienen acceso para administrar el contenido del área
de trabajo dedicada a la administración centralizada de los flujos de datos.
Existen una o varias áreas de trabajo destinadas a proporcionar acceso al flujo de

datos final, que ofrece datos listos para la producción a los modelos de datos.
El flujo de datos final se crea en un área de trabajo disponible para los modeladores
de datos. Obtiene datos mediante el uso de tablas vinculadas al flujo de datos de
transformación. Las tablas calculadas representan la salida preparada visible para los
modeladores de datos a los que se les concede el rol de visor del área de trabajo.
Los creadores de conjuntos de datos (que consumen la salida del flujo de datos)
tienen acceso de visor al área de trabajo que contiene la salida del flujo de datos
final. Los creadores de flujos de datos también tienen acceso para administrar y
publicar contenido en el área de trabajo (lo cual no se representa en el diagrama de
escenarios).
Todas las áreas de trabajo implicadas tienen el modo de licencia establecido en

Premium por usuario, Premium por capacidad o Embedded. Estos modos de licencia
permiten el uso de tablas vinculadas y tablas calculadas entre áreas de trabajo, lo cual
es necesario en este escenario.
Los creadores de conjuntos de datos usan el flujo de datos final como origen de datos
al desarrollar un modelo de datos en Power BI Desktop. Cuando está listo, el creador
del conjunto de datos publica el archivo de Power BI Desktop (.pbix) que contiene el
modelo de datos en el servicio Power BI (que no se representa en el diagrama de
escenarios).
Los administradores de Power BI administran la configuración en el portal de

administración.
En el portal de administración, los administradores de Power BI pueden configurar

conexiones de Azure para almacenar los datos de los flujos de datos en su cuenta de
Azure Data Lake Storage Gen2 (ADLS Gen2). La configuración incluye la asignación de
una cuenta de almacenamiento de nivel de inquilino y la habilitación de permisos de
almacenamiento de nivel de área de trabajo.
De forma predeterminada, los flujos de datos almacenan datos mediante el

almacenamiento interno administrado por el servicio Power BI. De forma opcional, la
salida de datos del flujo de datos se puede almacenar en la cuenta de ADLS Gen2 de
la organización.
Para conectarse a orígenes de datos que residen en una red organizativa privada, se
requiere una puerta de enlace de datos local para la creación del flujo de datos en
Power Query Online. La puerta de enlace de datos también se usa para actualizar el
flujo de datos.

Power BI.
Puntos clave
A continuación, se muestran algunos puntos clave que se deben destacar sobre el
escenario de preparación de datos avanzada.
Flujos de datos
Un flujo de datos consta de una colección de tablas (también conocidas como
entidades). Cada tabla se define mediante una consulta, que contiene los pasos de
preparación de datos necesarios para cargar la tabla con datos. Todo el trabajo de
creación de un flujo de datos se realiza en Power Query Online . Para crear un flujo de
datos se pueden usar varios productos, como Power Apps, Dynamics 365 Customer
Insights y Power BI.
７ Nota

Power BI.
Tipos de flujos de datos

El uso de bloques de creación que admiten composición es un principio de diseño que le
permite administrar, implementar y proteger los componentes de un sistema y
combinarlos de diversas formas para su uso. La creación de flujos de datos modulares y
autónomos para una finalidad específica es un procedimiento recomendado. Ayudan a
lograr la reutilización de los datos y su escala empresarial. Los flujos de datos modulares
también son más fáciles de administrar y de probar.
En el diagrama de escenarios se muestran tres tipos de flujos de datos: flujo de datos de
almacenamiento provisional, flujo de datos de transformación y flujo de datos final.
Flujo de datos de almacenamiento provisional
Un flujo de datos de almacenamiento provisional (a veces denominado flujo de datos de

extracción de datos) copia los datos sin procesar tal cual desde el origen. Si los datos sin
procesar se extraen con una transformación mínima significa que los flujos de datos de
transformación de bajada (descritos a continuación) pueden usar el flujo de datos de
almacenamiento provisional como origen. Esta modularidad resulta útil cuando:
El acceso a un origen de datos está restringido a ventanas de tiempo limitadas o a

unos pocos usuarios.
Se quiere mantener la coherencia temporal para garantizar que todos los flujos de
datos de bajada (y los conjuntos de datos relacionados) entreguen los datos
extraídos del origen de datos al mismo tiempo.
Se necesita reducir el número de consultas enviadas al origen de datos debido a
restricciones del sistema de origen o a su capacidad para admitir consultas
analíticas.
Es útil contar con una copia de los datos de origen para los procesos de
conciliación y las comprobaciones de calidad de los datos.
Flujo de datos de transformación

Un flujo de datos de transformación (a veces denominado flujo de datos limpio) tiene
como origen de sus datos tablas vinculadas que se conectan al flujo de datos de
almacenamiento provisional. Separar las transformaciones del proceso de extracción de
datos es un procedimiento recomendado.
Un flujo de datos de transformación incluye todos los pasos de transformación

necesarios para preparar y reestructurar los datos. Sin embargo, esta capa también se
centra en la reutilización para garantizar que el flujo de datos sea adecuado para
diversos fines y casos de uso.
Flujo de datos final

Un flujo de datos final representa la salida preparada. Puede que se realicen algunas
transformaciones adicionales en función del fin y del caso de uso. El diseño preferido
del flujo de datos final con fines de análisis es una tabla de esquema de estrella
(dimensión o hecho).
Las tablas calculadas son visibles para los modeladores de datos a los que se les
concede el rol de visor del área de trabajo. Este tipo de tabla se describe en el tema de
tipos de tablas de flujo de datos, a continuación.
７ Nota
Los lagos de datos suelen tener zonas, como bronce, plata y oro. Los tres tipos de
flujos de datos representan un patrón de diseño similar. Para tomar las mejores
decisiones posibles respecto a la arquitectura de los datos, piense en quién
mantendrá los datos, el uso que se espera que se haga de ellos y el nivel de aptitud
requerido por los usuarios que acceden a los datos.
Áreas de trabajo para flujos de datos

Si se crean todos los flujos de datos en una única área de trabajo, se limitaría
significativamente el alcance de la reutilización. El uso de una sola área de trabajo
también limita las opciones de seguridad disponibles al admitir varios tipos de usuarios
entre los equipos o para distintos casos de uso. Se recomienda usar varias áreas de
trabajo. Ofrecen mayor flexibilidad cuando es necesario admitir creadores de
autoservicio de varias áreas de la organización.
Los dos tipos de áreas de trabajo que se muestran en el diagrama de escenarios son:
Área de trabajo 1: almacena flujos de datos administrados centralmente (lo que a

veces se denomina área de trabajo de back-end). Contiene tanto flujos de datos de
almacenamiento provisional como de transformación porque los administran los
mismos usuarios. Los creadores de flujos de datos suelen pertenecer a un equipo
centralizado, como TI, BI o el Centro de excelencia. Deben tener asignado el rol de
administrador, miembro o colaborador del área de trabajo.
Área de trabajo 2: almacena y entrega la salida del flujo de datos final a los
consumidores de los datos (a veces denominada área de trabajo de usuario). Los
creadores de conjuntos de datos suelen ser analistas de autoservicio, usuarios
avanzados o ingenieros de datos ciudadanos. Deben asignarse al rol de visor del
área de trabajo porque solo necesitan consumir la salida del flujo de datos final.
Para admitir creadores de conjuntos de datos de varias áreas de la organización,
puede crear numerosas áreas de trabajo como esta, en función de las necesidades
de seguridad y los casos de uso.
 Sugerencia
Se recomienda revisar las formas de admitir creadores de conjuntos de datos
descritas en el escenario de uso de preparación de datos de autoservicio. Es
importante comprender que los creadores de conjuntos de datos también pueden
usar todas las funcionalidades de Power Query en Power BI Desktop. Pueden optar
por agregar pasos de consulta a fin de transformar aún más los datos del flujo de
datos o bien combinar la salida del flujo de datos con otros orígenes.
Tipos de tablas de flujo de datos

En el diagrama de escenarios se muestran tres tipos de tablas de flujo de datos (también
conocidas como entidades).
Tabla estándar: consulta un origen de datos externo, como una base de datos. En
el diagrama de escenarios, las tablas estándar se muestran en el flujo de datos de
almacenamiento provisional.
Tabla vinculada: hace referencia a una tabla de otro flujo de datos. Una tabla
vinculada no duplica los datos. En su lugar, permite la reutilización de una tabla
estándar varias veces con distintos fines. Los visores del área de trabajo no
visualizan las tablas vinculadas, ya que heredan los permisos del flujo de datos
original. En el diagrama de escenarios, las tablas vinculadas se muestran dos veces:
En el flujo de datos de transformación, para acceder a los datos del flujo de
datos de almacenamiento provisional.
En el flujo de datos final, para acceder a los datos del flujo de datos de
transformación.
Tabla calculada: realiza cálculos adicionales al usar un flujo de datos diferente
como origen. Las tablas calculadas permiten personalizar la salida según convenga
para los casos de uso individuales. En el diagrama de escenarios, las tablas
calculadas se muestran dos veces:
En el flujo de datos de transformación, para realizar transformaciones comunes.
En el flujo de datos final, para entregar la salida a los creadores de conjuntos de
datos. Dado que las tablas calculadas vuelven a conservar los datos (después de
la actualización del flujo de datos), los modeladores de datos pueden acceder a
las tablas calculadas en el flujo de datos final. En este caso, debe concederse
acceso a los modeladores de datos con el rol de visor del área de trabajo.
７ Nota
Hay muchas técnicas, patrones y procedimientos recomendados de diseño que

pueden hacer que los flujos de datos pasen del autoservicio a estar listos para la
empresa. Además, los flujos de datos de un área de trabajo con el modo de licencia
establecido en Premium por usuario o Premium por capacidad pueden
beneficiarse de características avanzadas. Las tablas vinculadas y las tablas
calculadas (también conocidas como entidades) son dos características avanzadas
esenciales para incrementar la reutilización de los flujos de datos.
Motor de proceso mejorado

El motor de proceso mejorado es una característica avanzada disponible con Power BI
Premium. Este motor mejora el rendimiento de las tablas vinculadas (dentro del mismo
área de trabajo) que hacen referencia (se vinculan) al flujo de datos. Para obtener la
máxima ventaja del motor de proceso mejorado, haga lo siguiente:
Divida los flujos de datos de almacenamiento provisional y de transformación.

Use la misma área de trabajo para almacenar los flujos de datos de
almacenamiento provisional y de transformación.
Aplique operaciones complejas que puedan plegar las consultas al principio de los
pasos de consulta. Clasificar por orden de prioridad las operaciones plegables
puede ayudar a lograr el mejor rendimiento de actualización.
Use la actualización incremental para reducir la duración de las actualizaciones y el
consumo de recursos.
Realice las pruebas de forma anticipada y frecuente durante la fase de desarrollo.
Actualización de flujos y conjuntos de datos

Un flujo de datos es un origen de datos para los conjuntos de datos. En la mayoría de
los casos, se realizan varias programaciones de las actualizaciones de datos: una para
cada flujo de datos y otra para cada conjunto de datos. Como alternativa, se puede usar
DirectQuery desde el conjunto de datos al flujo de datos, lo cual requiere Power BI
Premium y el motor de proceso mejorado (que no se representa en el diagrama de
escenarios).
Azure Data Lake Storage Gen2

Una cuenta de ADLS Gen2 es un tipo específico de cuenta de almacenamiento de Azure
que tiene habilitado el espacio de nombres jerárquico. ADLS Gen2 tiene ventajas de
rendimiento, administración y seguridad para operar cargas de trabajo analíticas. De
forma predeterminada, los flujos de datos de Power BI usan el almacenamiento interno,
que es una cuenta integrada de lago de datos administrada por el servicio Power BI.
Opcionalmente, las organizaciones pueden traer su propio lago de datos mediante la
conexión a una cuenta de ADLS Gen2 en su organización.
Estas son algunas de las ventajas de usar su propio lago de datos:
Los usuarios (o procesos) pueden acceder directamente a los datos de flujo de

datos almacenados en el lago de datos. Esto es útil cuando el flujo de datos se
reutiliza fuera de Power BI. Por ejemplo, Azure Data Factory puede acceder a los
datos del flujo de datos.
Otras herramientas o sistemas pueden administrar los datos en el lago de datos.
En este caso, Power BI puede consumir los datos en lugar de administrarlos (lo cual
no se representa en el diagrama de escenarios).
Al usar tablas vinculadas o calculadas, asegúrese de que cada área de trabajo esté
asignada a la misma cuenta de almacenamiento de ADLS Gen2.
７ Nota
Los datos de flujo de datos de ADLS Gen2 se almacenan en un contenedor

específico de Power BI. Este contenedor se representa en el diagrama del escenario
de uso de preparación de datos de autoservicio.
Configuración del portal de administración

Hay dos valores importantes que se administran en el portal de administración:
Conexiones de Azure: la sección Conexiones de Azure del portal de administración

incluye un valor para configurar una conexión a una cuenta de ADLS Gen2. Este
valor permite que un administrador de Power BI traiga su propio lago de datos a los
flujos de datos. Una vez configurado, las áreas de trabajo pueden usar esa cuenta
de lago de datos para el almacenamiento.
Almacenamiento de nivel de área de trabajo: un administrador de Power BI puede
establecer permisos de almacenamiento de nivel de área de trabajo. Cuando se
habilita, la configuración permite que los administradores del área de trabajo usen
una cuenta de almacenamiento distinta a la establecida en el nivel de inquilino.
Habilitar esta configuración resulta útil para las unidades de negocio
descentralizadas que administran su propio lago de datos en Azure.

Normalmente, se requiere una puerta de enlace de datos local para conectarse a los
orígenes de datos que residan en una red de organización privada o una red virtual.
Se requiere una puerta de enlace de datos en los casos siguientes:

Para crear un flujo de datos en Power Query Online que se conecte a los datos
privados de una organización.
Para actualizar un flujo de datos que se conecte a los datos privados de una
organización.
 Sugerencia
Los flujos de datos requieren una puerta de enlace de datos centralizada en modo
estándar. Al trabajar con flujos de datos, no se admite una puerta de enlace en
modo personal.

de uso y adopción. El registro de actividad también es muy útil para respaldar los
esfuerzos de gobernanza, las auditorías de seguridad y los requisitos de cumplimiento.
En el escenario de preparación de datos avanzada, los datos del registro de actividad
son útiles para realizar un seguimiento de la administración y el uso de los flujos de
datos.
Pasos siguientes
Para ver otros escenarios útiles que le ayuden con las decisiones de implementación de
Power BI, consulte el artículo Escenarios de uso de Power BI.
Escenarios de uso de Power BI: Creación
de prototipos y uso compartido
７ Nota

Como se describe en la hoja de ruta de adopción de Power BI, exploración,

experimentación y obtención de comentarios útiles de un pequeño grupo de usuarios
es el propósito de la fase 1 de la adopción de la solución.
Un prototipo (o prueba de concepto [POC]) es una solución de Power BI destinada a

abordar problemas desconocidos y mitigar el riesgo. Esta solución se puede compartir
con otros usuarios para recibir comentarios durante las iteraciones de desarrollo. La
solución puede ser una solución temporal, de corta duración o, en última instancia,
puede evolucionar en una solución totalmente validada y publicada. La creación de un
prototipo se suele realizar para escenarios de BI de departamento y BI empresarial (y, en
ocasiones, se pueden realizar en escenarios de BI para equipos).
La creación de prototipos a menudo se produce de forma natural durante los esfuerzos

de desarrollo de BI de autoservicio. O bien, un prototipo podría ser un proyecto
pequeño que tenga objetivos específicos y un ámbito.
７ Nota
El escenario de creación de prototipos y uso compartido es uno de los escenarios

de BI de autoservicio. Para obtener una lista completa de los escenarios de
autoservicio, consulte el artículo Escenarios de uso de Power BI.


más comunes y los componentes de Power BI para admitir actividades de creación de
prototipos. El enfoque se centra en el uso de Power BI Desktop durante una sesión de
creación de prototipos interactiva. También puede centrarse en compartir en el servicio
Power BI cuando se necesitan comentarios adicionales de expertos en la materia.
En el diagrama de escenario se muestran las siguientes acciones, herramientas y

características de usuario:
Los creadores de contenido de Power BI desarrollan soluciones de BI mediante Power

BI Desktop.
El desarrollo del modelo de datos y la creación de informes tiene lugar en Power BI

Desktop. El propósito es ayudar a los miembros del equipo a comprender el
significado y la importancia de los datos colocándolos en un contexto visual.
Los expertos en la materia proporcionan comentarios durante una sesión interactiva

de creación de prototipos. En función de los comentarios de los expertos en la
materia (y otros miembros del equipo), los creadores de contenido realizan mejoras
iterativas directamente en la solución de BI.
Si lo desea, los creadores de contenido publican su archivo de Power BI Desktop

(.pbix) en el servicio Power BI. La publicación de soluciones de creación de prototipos
en la servicio Power BI es opcional.
El contenido se publica en un área de trabajo que no es de producción. Su propósito

principal es proporcionar un área de desarrollo que permita la revisión por parte de
los miembros del equipo.
Un informe individual se comparte con un compañero para proporcionar permisos de

solo lectura al informe (y sus datos subyacentes). La operación de uso compartido se
puede realizar con un vínculo de uso compartido o un uso compartido de acceso
directo. El uso compartido puede ser ventajoso para una solución de creación de
prototipos para proporcionar acceso temporal durante el proceso de comentarios.
datos.

Power BI. Normalmente, un área de trabajo de desarrollo (que contiene soluciones
que no son de producción y de creación de prototipos) se rige por una extensión
mucho menor que un área de trabajo de producción.
Puntos clave
A continuación, se muestran algunos puntos clave que se deben destacar sobre el
escenario de creación de prototipos y uso compartido.
Sesiones de creación de prototipos interactivas

Las sesiones de creación de prototipos interactivas son valiosas para obtener
comentarios inmediatos al explorar los requisitos del usuario, validar cálculos, aclarar las
necesidades de diseño visual, validar la experiencia del usuario y confirmar la
presentación del informe. Use Power BI Desktop durante las sesiones de creación de
prototipos que se llevan a cabo de forma interactiva con expertos en la materia.
Servicio Power BI
La publicación de soluciones de creación de prototipos en el servicio Power BI es
opcional. Puede ser útil cuando es necesario compartir resultados preliminares con fines
de comentarios y toma de decisiones.
 Sugerencia
Las soluciones de creación de prototipos deben estar claramente separadas de otro

contenido de producción para que los consumidores tengan expectativas
adecuadas para una solución que no sea de producción. Por ejemplo, es posible
que los consumidores de un informe de prototipo no esperen que incluyan todos
los datos o se actualicen según una programación. Un informe de prototipo no se
debe usar para las decisiones empresariales hasta que se valide, finalice y publique
completamente en un área de trabajo de producción.
Área de trabajo
Un área de trabajo de desarrollo es adecuada en este escenario, ya que implica trabajar
con un pequeño escenario de colaboración de BI para equipos (en lugar de un área de
trabajo personal, como se describe en el escenario de BI personal). Una vez finalizada y
probada completamente la solución, se puede promover rápidamente a un área de
trabajo de producción (como se describe en el escenario de publicación de contenido
de autoservicio).
Uso compartido de informes y paneles

En el diagrama de escenario se muestra compartir directamente con un destinatario (en
lugar de roles de área de trabajo o mediante una aplicación de Power BI). El uso de la
característica de uso compartido es adecuado para escenarios de colaboración cuando
los compañeros trabajan estrechamente de forma informal. El uso compartido es útil en
esta situación porque se limita a un pequeño número de compañeros que necesitan
revisar y proporcionar comentarios sobre la solución prototipo.
 Sugerencia
El uso compartido de elementos individuales debe realizarse con poca frecuencia.

Dado que el uso compartido se configura por cada elemento individual de un área
de trabajo, es más tedioso de mantener y aumenta el riesgo de error. Una
alternativa válida al uso compartido (no representado en el diagrama de
escenarios) es usar roles de área de trabajo (descritos en el escenario de BI para
equipos). Los roles de área de trabajo funcionan mejor cuando los compañeros
necesitan acceder a todos los elementos de un área de trabajo.

７ Nota


actividad recopilados para realizar la auditoría como ayuda para comprender los
patrones de uso y detectar las actividades de riesgo. Los requisitos de auditoría y
gobernanza suelen ser menos estrictos para los escenarios de creación de prototipos y
BI personal.
Pasos siguientes
publicación de contenido de
autoservicio
７ Nota

Cuando las soluciones analíticas son críticas para la organización, es importante

asegurarse de que el contenido de la servicio Power BI sea estable y confiable para los
consumidores. Los equipos de TI suelen resolver este problema trabajando en varios
entornos:
En el entorno de desarrollo, los creadores de contenido y los propietarios realizan

cambios y mejoras en la solución. Cuando estos cambios están listos para una
revisión más amplia, la solución se implementa (a veces conocida como
promocionada) en el entorno de prueba.
En el entorno de prueba, los revisores validan los cambios realizados en la
solución. Esta revisión puede implicar la validación de la funcionalidad y los datos
de la solución. Una vez completada la revisión, la solución se implementa en el
entorno de producción.
El entorno de producción es donde los consumidores ven e interactúan con la
solución publicada.
Este enfoque estructurado garantiza que los creadores, propietarios y revisores de

contenido puedan realizar y validar cambios sin afectar negativamente a los
consumidores.
El uso de procesos metódicos y disciplinados de administración del ciclo de vida reduce

los errores, minimiza las incoherencias y mejora la experiencia de los usuarios. Los
creadores y propietarios de contenido pueden usar canalizaciones de implementación
de Power BI para la publicación de contenido de autoservicio. Las canalizaciones de
implementación simplifican el proceso y mejoran el nivel de control al publicar
contenido nuevo.
７ Nota
Este escenario de publicación de contenido de autoservicio es uno de los

escenarios de implementación y administración de contenido. Para obtener una
lista completa de los escenarios de autoservicio, consulte el artículo Escenarios de
uso de Power BI.


En el diagrama siguiente se muestra una introducción general de alto nivel de las
acciones de usuario más comunes y los componentes de Power BI para admitir la
publicación de contenido de autoservicio. El enfoque se centra en el uso de una
canalización de implementación de Power BI para promover contenido a través de áreas
de trabajo de desarrollo, pruebas y producción.

El creador de contenido de Power BI desarrolla una solución de BI mediante Power BI

Desktop.
El archivo Power BI Desktop (.pbix) se guarda en una biblioteca compartida en

OneDrive.
Cuando esté a punto, el creador de contenido publica el archivo de Power BI Desktop

en el servicio Power BI.
El contenido se publica en un área de trabajo dedicada al desarrollo.
El área de trabajo de desarrollo (o prueba) se establece en Premium por usuario,

Premium por capacidad o modo de licenciainsertado.
Los creadores y propietarios de contenido colaboran en el área de trabajo de

desarrollo para asegurarse de que se cumplen todos los requisitos.
Un administrador de canalización de implementación configura la canalización de

implementación de Power BI con tres fases: desarrollo, prueba y producción. Cada
fase se alinea con un área de trabajo independiente en el servicio Power BI. Las
opciones de implementación y el acceso se configuran para la canalización de
implementación.
Cuando el contenido de desarrollo está listo, la canalización de implementación

compara el contenido entre las fases de desarrollo y prueba. Algunos, o todos, los
elementos de Power BI se implementan en un área de trabajo dedicada a las pruebas.
El área de trabajo de prueba (o desarrollo) se establece en Premium por usuario,

Premium por capacidad o modo de licenciainsertado.
Una vez completada la implementación de la canalización de implementación, el

creador de contenido realiza manualmente actividades posteriores a la
implementación para el área de trabajo de prueba. Las actividades pueden incluir la
configuración de la actualización de datos programada o la publicación de una
aplicación de Power BI para el área de trabajo de prueba.
Los revisores del área de trabajo de prueba realizan el control de calidad, las
validaciones de datos y las pruebas de aceptación del usuario.
Cuando el contenido de prueba está totalmente validado, la canalización de

implementación compara el contenido entre las fases de prueba y producción.
Algunos, o todos, los elementos de Power BI se implementan en un área de trabajo
dedicada a producción.
El área de trabajo de producción se establece en Premium por usuario, Premium por

capacidad o modo de licenciainsertado. En el caso de un área de trabajo de
producción, el modo de licencia Premium por capacidad suele ser más adecuado
cuando hay un gran número de consumidores de solo lectura.
Una vez completada la implementación de la canalización de implementación, los

creadores de contenido pueden realizar manualmente actividades posteriores a la
implementación. Las actividades pueden incluir la configuración de la actualización de
datos programada o la publicación de una aplicación de Power BI para el área de
trabajo de producción.
Los visores de contenido acceden al contenido mediante el área de trabajo de

producción o una aplicación de Power BI.
privada, se requiere una puerta de enlace de datos local.

Power BI. El contenido que se considera lo suficientemente crítico como para tener
áreas de trabajo de desarrollo, pruebas y producción independientes puede estar
sujeto a requisitos de gobernanza más estrictos que el contenido menos crítico.
 Sugerencia
Se recomienda revisar también el escenario de uso avanzado de administración de

modelos de datos Se basa en los conceptos introducidos en este escenario.
Puntos clave
A continuación, se muestran algunos puntos clave para destacar sobre el escenario de
publicación de contenido de autoservicio.
Canalización de implementación
Una canalización de implementación consta de tres fases: desarrollo, prueba y
producción. Se asigna una sola área de trabajo a cada fase de la canalización de
implementación. Los elementos de Power BI admitidos por las canalizaciones de
implementación se publican (o clonan) de un área de trabajo a otra cuando se produce
una implementación. Una vez completadas las pruebas y validaciones, la canalización de
implementación se puede reutilizar muchas veces para promover el contenido
rápidamente. La interfaz de canalización de implementación es fácil de implementar
para los creadores de contenido que no tienen las aptitudes o el deseo de usar
implementaciones basadas en código (el uso de las API REST de Power BI se describe en
el escenario de publicación de contenido empresarial).
７ Nota
La publicación de contenido mediante una canalización de implementación se

conoce como una implementación de solo metadatos. En este caso, los datos no se
sobrescriben ni copian en el área de trabajo de destino. Normalmente, se requiere
una actualización de datos una vez completada la implementación; consulte el
tema actividades posteriores a la implementación a continuación.
Proceso de implementación
Es un procedimiento recomendado considerar todo el contenido del área de trabajo
como un paquete analítico que se puede implementar juntos como una unidad. Por lo
tanto, es importante tener claridad sobre el propósito y las expectativas de cada área de
trabajo. Aunque es posible una implementación selectiva de elementos específicos de
Power BI, es más eficaz y menos arriesgado cuando una implementación representa una
unidad lógica de contenido.
 Sugerencia
Planee cómo se controlarán los problemas urgentes, además de las

implementaciones planeadas. Si se requiere una corrección inmediata, siga la
práctica estándar de propagar todos los cambios desde el desarrollo hasta la
prueba y producción mediante la canalización de implementación.
Modelo de permisos
Dedique tiempo a planear el modelo de permisos. Se admite la flexibilidad total para
aplicar diferentes roles de área de trabajo (entre desarrollo, prueba y producción). Como
se muestra en el diagrama de escenarios, es habitual asignar los siguientes permisos de
área de trabajo:
Área de trabajo de desarrollo: limite el acceso a un equipo de creadores de

contenido y propietarios que colaboran juntos.
Área de trabajo de prueba: limite el acceso a los revisores implicados en el control
de calidad, las validaciones de datos y las actividades de prueba de aceptación del
usuario.
Área de trabajo de producción: conceda al visor acceso a los consumidores de
contenido de la aplicación Power BI (y el área de trabajo, cuando corresponda).
Limite el acceso a aquellos que necesiten administrar y publicar contenido de
producción, lo que implica el menor número posible de usuarios.
７ Nota
La mayoría de los consumidores de contenido no son conscientes de las áreas de

trabajo de desarrollo y pruebas.
Acceso a la canalización de implementación

Los permisos de usuario de canalización (para quién puede implementar contenido con
una canalización de implementación) se administran por separado de los roles del área
de trabajo. Se requiere acceso tanto al área de trabajo como a la canalización de
implementación para los usuarios que realizan una implementación. También se
requieren los permisos Premium pertinentes.
Cuando sea posible, se recomienda que el creador o propietario del contenido existente
realice las implementaciones. En algunas situaciones, los permisos están más
restringidos para el área de trabajo de producción. En ese caso, puede ser adecuado
coordinar la implementación de producción con otra persona que tenga permiso para
realizar la implementación en producción.
Los usuarios de canalización asignados al rol miembro del área de trabajo (o

administrador) pueden comparar fases e implementar contenido. La asignación de
usuarios de canalización a este rol minimiza los problemas de permisos y permite un
proceso de implementación más sencillo.
 Sugerencia
Tenga en cuenta que los roles de área de trabajo se establecen por separado para
desarrollo, prueba y producción. Sin embargo, el acceso a la canalización se
establece una vez para toda la canalización.
Licencias de Power BI Premium

Las canalizaciones de implementación de Power BI son una característica Premium. Hay
varias maneras de obtener licencias, en función de si el contenido se usa para fines de
desarrollo, prueba o producción. El diagrama del escenario muestra el uso de SKU P
Premium, como P1, P2, P3, P4 o P5, para el área de trabajo de producción, y una licencia
Premium por usuario (PPU) de Power BI basada en el usuario para las áreas de trabajo
de desarrollo y prueba. El uso de licencias PPU para áreas de trabajo con muy pocos
usuarios (como se muestra en el diagrama de escenarios) es una manera rentable de
usar características Premium, a la vez que las mantiene separadas de la capacidad
Premium asignada para cargas de trabajo de producción.
Configuración de implementación
Las reglas de orígenes de datos y las reglas de parámetros están disponibles para
administrar dinámicamente los valores que difieren entre desarrollo, prueba y
producción. El uso de la configuración de implementación es una manera eficaz de
reducir el esfuerzo y el riesgo de errores.
Acción posterior a la implementación

A propósito, algunas propiedades no se copian en el área de trabajo de destino durante
una implementación. Varias actividades clave posteriores a la implementación incluyen:
Actualización de datos: los datos no se copian del área de trabajo de origen al

área de trabajo de destino. La publicación desde una canalización de
implementación siempre es una implementación de solo metadatos. Por lo tanto,
normalmente se requiere una actualización de datos después de la
implementación en un área de trabajo de destino. Para las implementaciones por
primera vez, también se deben configurar las credenciales del origen de datos o la
conectividad de puerta de enlace (según corresponda).
Aplicaciones: las canalizaciones de implementación no publican automáticamente
las aplicaciones de Power BI.
Roles de acceso, permisos de uso compartido y permisos de aplicación: los
permisos no se sobrescriben durante una implementación.
Propiedades del área de trabajo: las propiedades, como los contactos y la
descripción del área de trabajo, no se sobrescriben durante una implementación.
Propiedades de elementos de Power BI: ciertas propiedades de elementos de
Power BI, como las etiquetas de confidencialidad, se pueden sobrescribir durante
una implementación en determinadas circunstancias.
Elementos de Power BI no admitidos: es posible que sea necesario realizar pasos
manuales adicionales para los elementos de Power BI que no son compatibles con
la canalización de implementación.
Ｕ Precaución
No hay un proceso de reversión una vez que se ha producido una implementación

con una canalización de implementación. Tenga en cuenta cuidadosamente qué
procesos y aprobaciones de administración de cambios son necesarios para
implementar en el área de trabajo de producción.
Almacenamiento de OneDrive
En el diagrama de escenario se muestra el uso de OneDrive para almacenar los archivos
de Power BI Desktop de origen. El objetivo es almacenar los archivos de origen en una
ubicación que:
Esté correctamente protegida para asegurarse de que solo los editores puedan
acceder a los archivos de origen. Una biblioteca compartida (en lugar de una
biblioteca personal) es una buena opción.
Se realizan copias de seguridad con frecuencia para que los archivos estén a salvo
de pérdidas.
Se versiona cuando se producen cambios, para permitir una reversión a una
versión anterior.
 Sugerencia
Si una ubicación de OneDrive está sincronizada con un área de trabajo,

configúrela solo para el área de trabajo de desarrollo.

importadoso ver un informe que consulta una conexión dinámica o un conjunto de
Al trabajar con varios entornos, es habitual configurar conexiones de desarrollo, prueba

y producción para usar diferentes sistemas de origen. En este caso, use reglas de origen
de datos y reglas de parámetros para administrar valores que difieren entre entornos.
７ Nota
Se recomienda encarecidamente una puerta de enlace de datos centralizada en

modo estándar a través de puertas de enlace en modo personal. En el modo
estándar la puerta de enlace de datos admite conexiones dinámicas y operaciones
de DirectQuery (además de las operaciones de actualización de datos
programadas).

actividad recopilados para realizar la auditoría para ayudarles a comprender las
actividades de implementación que se producen.
Pasos siguientes
En el siguiente artículo de la serie, obtenga información sobre el escenario de uso
avanzado del modelado de datos.
Escenarios de utilización de Power BI:
Administración avanzada de modelos de
datos
７ Nota

implementación de Power BI. Para una introducción a la serie, consulte Planificación
de la implementación de Power BI.
Este escenario de utilización se centra en la administración avanzada de modelos de

datos, que es cuando un creador de contenido de Power BI se basa en una herramienta
de terceros para desarrollar, administrar u optimizar modelos de datos. Algunas
herramientas de terceros son herramientas externas, que Power BI Desktop admite
directamente. También puede administrar un modelo de datos publicado (conjunto de
datos) mediante la comunicación directa con el punto de conexión XMLA en el servicio
Power BI.
Los modelos de datos se hospedan en el servicio Power BI, Azure Analysis Services (AAS)
o SQL Server Analysis Services (SSAS). Este escenario de utilización se centra en el uso
del punto de conexión XMLA en el servicio Power BI.
 Sugerencia
Muchas personas se refieren a herramientas de terceros como herramientas

externas. Pero, existen diferencias en la forma en que se pueden usar diferentes
herramientas. La conexión a un modelo de datos local en Power BI Desktop es la
interpretación más literal del término herramienta externa. Este escenario de
utilización avanzado de administración de modelos de datos se centra en
conectarse a un modelo de datos remoto (un conjunto de datos hospedado en el
servicio Power BI) mediante el punto de conexión XMLA. Más adelante en este
artículo se describe más información sobre las distintas formas de usar
herramientas de terceros.
Puede lograr la conectividad a un modelo de datos mediante el protocolo XML for

Analysis (XMLA). El protocolo XMLA es un protocolo estándar del sector compatible con
más de 25 proveedores, incluido Microsoft. Todas las herramientas, incluidas las
herramientas de terceros, que son compatibles con el protocolo XMLA usan bibliotecas
de cliente de Microsoft para leer o escribir datos en un modelo de datos. La
conectividad se logra con un punto de conexión XMLA, que es una API expuesta por un
modelo de datos que amplía las funcionalidades de desarrollo y administración
disponibles para los creadores de conjuntos de datos.
７ Nota
Este escenario de utilización avanzado del modelo de datos es uno de los

escenarios de implementación y administración de contenido. Para una lista
completa de los escenarios de utilización de autoservicio, consulte Escenarios de
uso de Power BI.
Por motivos de brevedad, algunos aspectos descritos en el tema Escenarios de


El enfoque de este escenario de utilización avanzado del modelo de datos consiste en
usar Tabular Editor para administrar el modelo de datos. Puede publicar un modelo de
datos en el servicio Power BI mediante el punto de conexión XMLA, que está disponible
con Power BI Premium.
 Sugerencia
Se recomienda revisar el escenario de utilización de publicación de contenido de

autoservicio si no está familiarizado con él. El escenario de administración
avanzada de modelos de datos se basa en ese escenario.
７ Nota
A veces, los términos conjunto de datos y modelo de datos se usan indistintamente.

En general, desde una perspectiva del servicio Power BI, se usa el término conjunto
de datos. Desde una perspectiva de desarrollo, se conoce como modelo de datos (o
modelo para abreviar). En este artículo, ambos términos tienen el mismo
significado. De forma similar, un creador de conjuntos de datos y un modelador de
datos significan lo mismo.
En el diagrama siguiente se muestra una visión general de alto nivel de las herramientas
y acciones de usuario más comunes que pueden ayudarle a desarrollar, administrar u
optimizar modelos de datos.

Los creadores de conjuntos de datos desarrollan modelos de datos mediante

Tabular Editor. Es habitual que el trabajo de diseño inicial (como trabajo Power Query)
se realice en Power BI Desktop antes de cambiar a Tabular Editor (no se muestra en el
diagrama de escenarios).
El modelo de datos conecta con los datos de uno o más orígenes de datos.
El desarrollo del modelo de datos se realiza en Tabular Editor. Se admite la edición de

scripts de Power Query (M).
Cuando está listo, los creadores de conjuntos de datos publican el modelo de datos
desde Tabular Editor en el servicio Power BI mediante el punto de conexión XMLA del
área de trabajo de destino.
El modelo de datos se publica en un área de trabajo dedicada a almacenar y proteger

conjuntos de datos compartidos. El acceso al área de trabajo mediante el punto de
conexión XMLA solo es posible cuando el license mode (modo de licencia) del área
de trabajo está establecido en Premium por usuario, Premium per capacity
(Premium por capacidad) o Embedded.
Los creadores de informes crean informes mediante una conexión dinámica al

conjunto de datos compartido.
Los creadores de informes desarrollan informes en Power BI Desktop. Aparte de

separar intencionadamente los informes de los conjuntos de datos, los creadores de
contenido siguen el proceso típico de creación de informes.
Cuando está listo, los creadores de informes publican su archivo de Power BI Desktop
(.pbix) en el servicio Power BI.

Los informes publicados permanecen conectados al conjunto de datos compartido

almacenado en un área de trabajo diferente. Los cambios realizados en el conjunto
de datos compartido afectan a todos los informes dependientes.
Las herramientas de terceros pueden usar el punto de conexión XMLA para consultar
el conjunto de datos compartido. Otras herramientas compatibles con XMLA, como
DAX Studio o PowerShell, se pueden usar para consultar o actualizar el conjunto de
datos compartido. Power BI Desktop, Excel y Report Builder también se pueden
conectar mediante el punto de conexión XMLA (no representado en el diagrama de
escenarios).
Otras herramientas de Microsoft y de terceros pueden usar el punto de

conexión XMLA para administrar el conjunto de datos y proporcionar administración
del ciclo de vida de las aplicaciones. Para obtener más información, consulte las
herramientas cliente basadas en puntos de conexión XMLA.
Los administradores de Power BI administran la configuración de inquilino para

habilitar el uso del punto de conexión XMLA. El administrador debe habilitar el punto
de conexión XMLA para las capacidades Premium y Premium por usuario.
Para conectarse a orígenes de datos que residen en una red organizativa privada, se
requiere una puerta de enlace de datos local para la actualización de datos. La
actualización de datos está programada y administrada en el servicio Power BI.
Los administradores de Power BI supervisan y monitorizan la actividad en el servicio

Power BI.
Puntos clave
A continuación se muestran algunos puntos clave a destacar sobre el escenario de
administración avanzada de modelos de datos.
Herramientas y aplicaciones de terceros

Los equipos de Enterprise BI suelen usar herramientas de cliente, como Tabular Editor
(representado en el diagrama de escenarios y descrito en el tema siguiente), para
ayudarles a administrar conjuntos de datos centralizados. Pero, cualquier creador de
conjuntos de datos que quiera trabajar con funcionalidades avanzadas de modelado
puede aprovechar los métodos descritos en este escenario de utilización.
Hay varias formas de usar aplicaciones de terceros:
Conectarse a un modelo de datos remoto mediante el punto de conexión XMLA:

algunas herramientas de terceros pueden conectarse directamente a un modelo de
datos remoto en el servicio Power BI (o Analysis Services). Una vez conectado al
punto de conexión XMLA, se admiten todas las operaciones del Modelo de objetos
tabulares (TOM). Este método es el enfoque principal de este escenario de
utilización.
Conectarse a un modelo de datos local en Power BI Desktop: algunas
herramientas de terceros pueden conectarse a un modelo de datos local abierto
en Power BI Desktop (no se muestra en el diagrama de escenarios). Pero hay
algunas limitaciones y no todas las funcionalidades de herramientas externas se
admiten de forma oficial.
Conectarse a un archivo de plantilla en Power BI Desktop: algunas herramientas
de terceros distribuyen su funcionalidad de forma ligera mediante un archivo de
plantilla de Power BI Desktop (.pbit) (no se muestra en el diagrama de escenarios).
Tabular Editor
Tabular Editor se muestra en el diagrama de escenarios. Se trata de una herramienta
de terceros que ha logrado una adopción generalizada por parte de la comunidad de
Power BI. Entre las ventajas de administrar modelos de datos tabulares con
Tabular Editor se incluyen las siguientes:
Configuración de funcionalidades de modelo de datos no admitidas en

Power BI Desktop: Tabular Editor proporciona una interfaz para configurar la
seguridad de nivel de objeto (OLS), grupos de cálculo, perspectivas, traducciones y
particiones.
Compatibilidad con el desarrollo simultáneo de modelos: las herramientas de
desarrollo de modelos de datos de Microsoft, como Visual Studio con proyectos
de Analysis Services, almacenan la definición completa del modelo de datos en un
archivo Model.bim. Este único archivo puede dificultar que un equipo de
desarrolladores trabaje de forma conjunta en un único modelo de datos.
Tabular Editor tiene una característica denominada Serialización de carpetas. La
serialización de carpetas deconstruye el archivo Model.bim en archivos
independientes específicos del objeto dentro de una estructura de carpetas
organizada. Después, diferentes modeladores de datos pueden trabajar en
diferentes archivos con menos riesgo de sobrescribir el trabajo de los demás.
Integración con el control de código fuente: la serialización de carpetas permite
que el sistema de control de código fuente detecte fácilmente los cambios del
modelo de datos, lo que facilita las combinaciones de origen y la resolución de
conflictos.
Mejora de la calidad y diseño del modelo de datos: Tabular Editor se integra con
el Analizador de procedimientos recomendados (BPA) . BPA ayuda a los
modeladores de datos con un conjunto de reglas personalizables que pueden
mejorar la calidad, la coherencia y el rendimiento de los modelos de datos. Puede
descargar un conjunto de reglas de procedimientos recomendados
(proporcionadas por Microsoft) desde GitHub .
Aumento de la productividad al desarrollar modelos de datos: la interfaz de
Tabular Editor hace que sea adecuado para realizar ediciones por lotes, depuración
y visualización de dependencias del modelo de datos. Tabular Editor se diferencia
de Power BI Desktop en que funciona en modo desconectado. Puede realizar
cambios en el modelo de datos en modo desconectado y confirmarlos como un
lote de ediciones. Trabajar de esta manera permite un desarrollo y una validación
más rápidos, especialmente para modeladores de datos experimentados. También
es posible crear scripts de C# y guardarlos como macros. Estos scripts pueden
ayudarle a mejorar la eficacia de la administración y sincronización de varios
modelos de datos.
Punto de conexión de XMLA

El punto de conexión XMLA usa el protocolo XMLA para exponer todas las
características de un modelo de datos tabular, incluidas algunas operaciones de
modelado de datos que no son compatibles con Power BI Desktop. Puede usar la API de
TOM para realizar cambios mediante programación en un modelo de datos.
El punto de conexión XMLA también proporciona conectividad. Solo puede conectarse a

un conjunto de datos cuando el área de trabajo que tiene su modo de licencia
establecido en Premium por usuario, Premium per capacity (Premium por capacidad)
o Embedded. Una vez realizada una conexión, una herramienta compatible con XMLA
puede funcionar en el modelo de datos de dos maneras:
Escritura de datos y metadatos: el uso de lectura y escritura del punto de
conexión XMLA permite:
Funcionalidades de modelado de datos que no son compatibles con
Power BI Desktop, como la seguridad de nivel de objeto (OLS), grupos de
cálculo, perspectivas, traducciones y administración de particiones.
Implementaciones más complejas. Por ejemplo, una implementación parcial o
una implementación solo de metadatos que publica una sola nueva medida.
Actualización del conjunto de datos asincrónica. Por ejemplo, la actualización de
una sola tabla o partición.
Lectura de datos y metadatos: el uso de solo lectura del punto de conexión XMLA
permite:
La supervisión, depuración y seguimiento de conjuntos de datos y consultas.
La visualización de los datos procedentes de un conjunto de datos compartido
por parte de herramientas de informes de datos de terceros. Esta técnica es una
excelente manera de ampliar las ventajas e inversiones en el autoservicio
administrado de BI.
２ Advertencia
Una vez que modifique o publique un conjunto de datos mediante el punto de

conexión XMLA, ya no podrá descargarlo desde el servicio Power BI como un
archivo Power BI Desktop.
Configuración de XMLA por capacidad

Cada capacidad Power BI Premium y Power BI Embedded tiene una configuración para
controlar si el punto de conexión XMLA es de solo lectura, lectura y escritura o está
desactivado. Esta configuración también está disponible para todas las áreas de trabajo
Premium por usuario en el inquilino de Power BI. El acceso XMLA de lectura y escritura
debe estar habilitado para cada capacidad que contenga conjuntos de datos que quiera
administrar con una herramienta que no sea Power BI Desktop.
 Sugerencia
La configuración del punto de conexión XMLA (lectura y escritura, solo lectura o

desactivado) se aplica a todas las áreas de trabajo y conjuntos de datos asignados
a una capacidad determinada. Puede configurar varias capacidades para
descentralizar o personalizar cómo se administra el contenido para cada capacidad.
Configuración del inquilino XMLA
Además de la configuración del punto de conexión XMLA, un administrador de Power BI
debe usar la configuración de inquilino para permitir puntos de conexión XMLA y
analizar en Excel con conjuntos de datos locales. Cuando se habilita, puede permitir que
todos los usuarios o grupos de seguridad específicos usen la funcionalidad del punto de
conexión XMLA.
７ Nota
Todas las características estándar de seguridad y protección de datos se siguen

aplicando para especificar qué usuarios pueden ver o editar contenido.
Herramientas de terceros
Power BI Desktop puede controlar las necesidades de un extremo a otro de la mayoría
de los creadores de contenido de autoservicio. Pero, las herramientas de terceros
ofrecen otras características y funcionalidades empresariales. Por este motivo, las
herramientas de terceros, como Tabular Editor , se han convertido en frecuentes en la
comunidad de Power BI, en especial para creadores de contenido avanzados,
desarrolladores y profesionales de TI.
 Sugerencia
En esta entrada de blog se describe cómo las herramientas de terceros permiten

al equipo de productos de Power BI volver a evaluar sus prioridades de desarrollo,
aumentar el alcance de la plataforma Power BI y satisfacer solicitudes más
avanzadas y diversas de la comunidad de usuarios.
７ Nota
Algunas herramientas de terceros requieren una licencia de pago, como

Tabular Editor 3. Otras herramientas de la comunidad son gratuitas y de código
abierto (como Tabular Editor 2, DAX Studio y ALM Toolkit). Se recomienda evaluar
cuidadosamente las características de cada herramienta, costo y modelo de soporte
técnico para que pueda apoyar adecuadamente a su comunidad de creadores de
contenido.
Administración de modelos de datos
El foco principal de este escenario de utilización está en el creador de contenido que
usa Tabular Editor para administrar un modelo de datos. Para los requisitos de
administración de modelos de datos avanzados poco frecuentes, como la
administración ocasional de particiones, puede optar por usar una herramienta como
SQL Server Management Studio. También es posible que un desarrollador de .NET cree y
administre conjuntos de datos de Power BI mediante la API de TOM.
 Sugerencia
Al usar el punto de conexión XMLA para la administración de modelos de datos, se

recomienda habilitar la configuración de formato de almacenamiento del
conjunto de datos grandes. Si se habilita, el formato de almacenamiento de
conjuntos de datos grandes puede mejorar el rendimiento de la operación de
escritura de XMLA.
Separación del modelo de datos e informes

Para que este escenario de utilización se realice correctamente, debe separar los
informes del modelo de datos. Este enfoque da como resultado la administración de
archivos independientes de Power BI Desktop, tal como se describe en el escenario de
uso del autoservicio administrado de BI. Incluso si la misma persona es responsable de
todo el desarrollo, la separación de conjuntos de datos e informes es importante porque
Tabular Editor no tiene conocimiento del contenido del informe.

que residen en la red privada de la organización o en una red virtual. La puerta de
enlace de datos local se vuelve relevante una vez que se publica un modelo de datos en
el servicio Power BI. Los dos propósitos de una puerta de enlace son actualizar los datos
importados o ver un informe que consulta una conexión dinámica o un conjunto de
datos de DirectQuery (no descrito en el diagrama de escenarios).
７ Nota
Se recomienda encarecidamente una puerta de enlace de datos centralizada en

modo estándar a través de puertas de enlace en modo personal. En el modo
estándar la puerta de enlace de datos admite conexiones dinámicas y operaciones
de DirectQuery (además de las operaciones de actualización de datos
programadas).

actividad recopilados para realizar la auditoría como ayuda para comprender las
actividades que se conectan mediante punto de conexión XMLA.
Pasos siguientes
Escenarios de uso de Power BI: informes
locales
７ Nota
Este artículo forma parte de la serie de artículos sobre la Planificación de la

El escenario de informes locales es uno de varios escenarios híbridos y personalizados

para implementar soluciones de Power BI sin usar el servicio Power BI.
Este escenario implica el uso de Power BI Report Server, que es un portal local para
publicar, compartir y consumir contenido de inteligencia empresarial dentro de la red
organizativa. Resulta útil cuando la organización necesita una alternativa al servicio
Power BI basado en la nube para implementar parte (o todo) del contenido de BI. Por
ejemplo, una plataforma totalmente administrada por el cliente puede ser necesaria por
motivos normativos, legales o de propiedad intelectual.

más comunes y los componentes de Power BI para admitir informes locales. El enfoque
se centra en el uso de Power BI Report Server, que se ejecuta en un servidor de
Windows dentro de la red organizativa.


Un creador de contenido de Power BI compila una solución de BI.
Power BI Desktop para Report Server se conecta a los datos desde uno o varios
orígenes de datos. Las consultas y los mashups de datos, que combinan varios
orígenes, se desarrollan en el Editor de Power Query.
El desarrollo del modelo de datos y la creación de informes se realizan en

Power BI Desktop para Report Server. Genera un tipo específico de archivo
Power BI Desktop (.pbix) que se puede publicar en Power BI Report Server.
El creador del informe también puede compilar informes paginados mediante

Power BI Report Builder. Esta herramienta genera un archivo de Lenguaje de
definición de informe (.rdl) que se puede publicar en Power BI Report Server.
El creador del informe también puede desarrollar informes con Excel. El archivo de
libro de Excel (.xlsx) se puede publicar en Power BI Report Server.
Cuando esté listo, el creador de contenido publica su archivo en Power BI

Report Server.
El contenido se publica en una carpeta de Power BI Report Server.
Los consumidores de informes ven los informes publicados en Power BI

Report Server.
Los consumidores de informes también pueden ver informes mediante aplicaciones

móviles de Power BI.
Los administradores del servidor administran la infraestructura del servidor de

Windows.
Los administradores de bases de datos administran Power BI Report Server, incluidas

las bases de datos de Report Server y Agente SQL Server.
Los trabajos de Agente SQL Server actualizan periódicamente los conjuntos de datos
de importación.
Los administradores supervisan y monitorizan la actividad en Power BI Report Server.
Puntos clave
Ahora se muestran algunos puntos clave que se deben destacar sobre el escenario de
informes local.
Experiencia del creador del informe

Los creadores de contenido usan una herramienta específica denominada Power BI
Desktop para Report Server . Esta versión de Power BI Desktop se actualiza tres veces
al año y es compatible con el ciclo de lanzamiento de Power BI Report Server.
７ Nota
En el caso de los creadores de informes que crean contenido para el servicio

Power BI y Power BI Report Server, ambas versiones de Power BI Desktop se
pueden instalar en paralelo.
Experiencia del consumidor de informes

La experiencia del consumidor de informes para Power BI Report Server es muy
diferente de la del servicio Power BI. Power BI Report Server es un portal web para ver,
almacenar y administrar contenido. Los archivos de contenido (.pbix, .rdl o .xlsx) se
publican en una jerarquía de carpetas. Para más información, consulte Administración
de contenido en el portal web.
Power BI Report Server

Power BI Report Server es un producto distinto de SQL Server Reporting Services (SSRS).
Tiene licencia y se instala por separado. Power BI Report Server se considera un
superconjunto de SSRS porque consta de funcionalidades adicionales más allá de SSRS.
） Importante
Aunque Power BI Report Server y el servicio Power BI son compatibles con el

mismo equipo de ingeniería de Microsoft, existen diferencias de funcionalidad
considerables entre los dos productos. Power BI Report Server es un portal de
informes básico para informes locales. Por este motivo, hay muchas diferencias de
características entre este y el servicio Power BI. El conjunto de características de
Power BI Report Server es intencionadamente sencillo y no debería esperarse
paridad. Antes de instalar Power BI Report Server, compruebe que se admiten las
características críticas que quiere usar.
Bases de datos del servidor de informes

SQL Server hospeda las bases de datos de Report Server. Normalmente, una instancia
del motor de base de datos de SQL Server se instala en un servidor de Windows en un
centro de datos local. También se puede instalar en una máquina virtual de Azure (nube
hospedada) u hospedar en Azure SQL Managed Instance (no se muestra en el diagrama
de escenarios). Un administrador de bases de datos administra la infraestructura de la
base de datos.
Acceso móvil
Se deben realizar configuraciones adicionales para habilitar el acceso móvil remoto a
Power BI Report Server. Para más información, vea Configuración del acceso de la
aplicación remota de Power BI a Report Server de manera remota.
Licencias de Power BI Report Server

Hay dos maneras de conceder licencias Power BI Report Server: Power BI Premium y
SQL Server Enterprise Edition con Software Assurance.
Con la compra de la capacidad Power BI Premium, Power BI Report Server puede

instalarse en un servidor local, siempre que tenga el mismo número de núcleos que los
núcleos virtuales del nodo de capacidad. Así, es posible adoptar un enfoque híbrido que
admita la publicación de contenido en la servicio Power BI (nube) y para Power BI
Report Server (en la nube local u hospedada en Azure).
７ Nota
Cuando se conceden licencias Power BI Report Server como parte del conjunto de
características de capacidad Premium, solo está disponible con las SKU P. Las otras
SKU basadas en capacidad (SKU EM y A) no ofrecen esta ventaja, ni
Power BI Premium por usuario (PPU).
Pasos siguientes
 Sugerencia
Este artículo se centra en la experiencia de Microsoft en el establecimiento de un

Centro de excelencia. Al configurar su propio Centro de excelencia, le
recomendamos que también revise la información que se trata en la Hoja de ruta
de adopción de Power BI.
Este artículo se dirige a los profesionales y administradores de TI. Conocerá nuestra

estrategia y visión de BI, que nos permite aprovechar continuamente nuestros datos
como recurso. También aprenderá a impulsar correctamente una referencia cultural de
datos de toma de decisiones empresariales con Power BI.
Alguna información previa primero: En la actualidad, la explosión de datos afecta a los

consumidores y a las empresas a velocidades de vértigo. Para tener éxito en este
entorno con un uso intensivo de datos se requieren analistas y ejecutivos que puedan
sintetizar una enorme cantidad de datos en conclusiones concisas. Las innovaciones en
las herramientas de BI de Microsoft han cambiado la forma en que Microsoft explora
sus datos y obtiene las conclusiones adecuadas que se necesitan para impulsar el
impacto en la empresa.
Por lo tanto, ¿cómo puede su organización revolucionar también la manera en que

trabaja con los datos? Para ayudarle a comprenderlo, vamos a contarle la historia de
nuestro recorrido de transformación de BI.
Recorrido de Microsoft
Hace varios años, en Microsoft, nuestra referencia cultural de la organización animaba a
los usuarios a buscar la plena propiedad de los datos y las conclusiones. También
experimentó una fuerte resistencia cultural a hacer cosas de forma estandarizada. Por lo
tanto, la referencia cultural de la organización nos condujo a desafíos de informes y
análisis. En concreto, nos condujo a:
Definiciones de datos, jerarquías, métricas e indicadores clave de rendimiento (KPI)

incoherentes. Por ejemplo, cada país o región tenía su propia forma de informar
sobre nuevos ingresos. No había ninguna coherencia, pero sí mucha confusión.
Los analistas dedican el 75 % del tiempo en recopilar y compilar los datos.
El 78 % de los informes se crean en un "entorno sin conexión".
Más de 350 herramientas y sistemas de finanzas centralizados.
Aproximadamente 30 millones de dólares en gasto anual en "aplicaciones en la
sombra".
Estos desafíos nos llevaron a pensar en cómo podríamos hacer mejor las cosas. Finanzas
y otros equipos internos recibieron el apoyo de los ejecutivos para transformar el
proceso de revisión de negocio, lo que nos llevó a crear una plataforma de BI unificada
como nuestra única fuente de confianza. (Más adelante en este capítulo hablaremos
más sobre nuestra plataforma de BI). En última instancia, estas innovaciones llevaron a
que las revisiones de negocio se transformasen de vistas tabulares densas en objetos
visuales más sencillos y comprensibles centrados en temas empresariales clave.
¿Cómo logramos este acertado resultado? La entrega de una BI centralizada y

administrada por TI y su ampliación con BI de autoservicio (SSBI) se tradujo en éxito. Lo
describiremos de dos formas creativa: disciplina en el núcleo y flexibilidad en el borde.
Disciplina en el núcleo
Disciplina en el núcleo significa que el equipo de TI conserva el control al mantener un
único origen de datos maestros. La entrega de BI corporativa estandarizada y la
definición de taxonomías y jerarquías de KPI coherentes forma parte de esa disciplina.
Lo importante es que los permisos de datos se aplican de forma centralizada para
garantizar que las personas solo puedan leer los datos que necesitan.
En primer lugar, entendimos que nuestra transformación de BI no era un problema

tecnológico. Para lograr el éxito, aprendimos a definir primero el éxito y luego a
convertirlo en métricas clave. No se puede subestimar lo importante que era para
nosotros lograr la coherencia de la definición en todos nuestros datos.
Nuestra transformación no se produjo de una sola vez. Priorizamos la entrega del

cuadro de mandos subsidiario que consta de unos 30 KPI. Luego, a lo largo de varios
años, ampliamos gradualmente el número y la profundidad de las áreas temáticas y
creamos jerarquías de KPI más complejas. Hoy en día, nos permite acumular KPI de nivel
inferior en el nivel de cliente a los más altos en el nivel de la empresa. El número total
de KPI supera ahora 2000 y cada uno de ellos es una medida clave de éxito y está
alineado con los objetivos corporativos. Ahora, en toda la empresa, los informes
corporativos y las soluciones de SSBI presentan KPI bien definidos, coherentes y
seguros.
Flexibilidad en el borde
En el borde del núcleo, nuestros analistas de los equipos de finanzas, ventas y marketing
se han convertido en más flexibles y ágiles. Ahora se benefician de la capacidad de
analizar los datos con mayor rapidez. Más formalmente, este escenario se describe
como BI de autoservicio (SSBI) administrado. Ahora sabemos que el SSBI administrado
supone beneficios mutuos para el departamento de TI y los analistas. Lo importante es
que experimentamos optimizaciones impulsando la estandarización, el conocimiento y
la reutilización de nuestros datos y soluciones de BI. Y, como empresa, derivamos más
valor sinérgicamente, ya que encontramos el equilibrio adecuado entre BI centralizada y
SSBI administrado.
La solución
Starlight es el nombre que damos a nuestra plataforma interna de unificación y análisis
de datos, que admite finanzas, ventas, marketing e ingeniería. Su misión es ofrecer una
plataforma de datos sólida, compartida y escalable. La plataforma fue creada
completamente por finanzas y continúa en funcionamiento hoy en día con los
productos más recientes de Microsoft.
KPI Lake no es una instancia de Azure Data Lake. Más bien, se trata de un modelo de BI
semántico tabular con tecnología de Starlight hospedado en IaaS de Azure que usa
Microsoft SQL Server Analysis Services. El modelo de BI semántico ofrece datos
procedentes de más de 100 orígenes internos y define numerosas jerarquías e
indicadores KPI. Su misión es habilitar equipos de análisis e informes de rendimiento
empresarial en finanzas, marketing y ventas. Lo hace para obtener conclusiones
oportunas, precisas y eficaces mediante modelos unificados de BI semántico de los
correspondientes orígenes.
Cuando se implementó por primera vez, fue un momento emocionante porque el

modelo de BI semántico tabular se tradujo en ventajas inmediatas y medibles. La
primera versión centralizada de las plataformas de BI de finanzas y marketing de C+E.
Después, en los últimos seis años, se ha ampliado para consolidar soluciones de
información empresarial adicionales. En la actualidad, sigue evolucionando, con lo que
se impulsan las revisiones de negocio globales y comerciales, así como la capacidad
SSBI y los informes estándar. Su adopción se ha multiplicado por cinco desde su
lanzamiento, lo que supera con creces nuestras expectativas iniciales.
Aquí se muestra un resumen de las principales ventajas:
Impulsa nuestro cuadro de mandos subsidiario, las revisiones de negocio

mundiales, además del análisis y los informes de finanzas, marketing y ventas.
Admite el análisis de autoservicio, lo que permite a los analistas detectar
conclusiones ocultas en los datos.
Impulsa la elaboración de informes y análisis para la compensación de incentivos,
el análisis de marketing y operaciones, las métricas de rendimiento de ventas, las
revisiones de alta dirección y el proceso de planeamiento anual.
Ofrece informes y análisis dinámicos y automatizados a partir de una única fuente
de confianza.
KPI Lake es una gran historia de éxito. A menudo, se presenta a nuestros clientes para
mostrar un ejemplo de cómo utilizar eficazmente nuestras tecnologías más recientes.
No resulta sorprendente que tenga gran resonancia en muchos de ellos.
Cómo funciona
La plataforma Starlight administra el flujo de datos de la adquisición al procesamiento, y
luego hasta la publicación:
1. La integración de datos sólida y ágil se realiza de forma programada, y se

consolidan los datos de más de 100 orígenes sin procesar dispares. Los sistemas
de datos de origen incluyen bases de datos relacionales, Azure Data Lake Storage y
bases de datos de Azure Synapse. Entre las áreas temáticas se incluyen finanzas,
marketing, ventas e ingeniería.
2. Una vez que se almacenan provisionalmente, los datos se ajustan y se enriquecen
con lógica de negocios y datos maestros. Luego se cargan en tablas de
almacenamiento de datos. Posteriormente, el modelo de BI semántico tabular se
actualiza.
3. Los analistas de toda la empresa usan Excel y Power BI para ofrecer conclusiones y
análisis a partir del modelo de BI semántico tabular. Además, permite a los
propietarios de empresas obtener definiciones de métricas para su propia
empresa. Cuando sea necesario, el escalado se consigue con IaaS de Azure con
equilibrio de carga.
Lograr el éxito
Curiosamente, todo el mundo quiere una versión de la verdad... siempre y cuando sea la
suya. Pero para algunas organizaciones es su realidad. Tienen varias versiones de la
verdad como consecuencia de que las personas reivindican la plena propiedad de los
datos y las conclusiones. Para estas organizaciones, no es probable que este enfoque no
administrado conduzca al éxito empresarial.
Por eso creemos que necesita un Centro de excelencia (COE) . Un COE es un equipo
central que se encarga de definir las métricas y definiciones de toda la empresa, y
mucho más. También es una función empresarial que organiza a las personas, los
procesos y los componentes tecnológicos en un conjunto completo de competencias y
funcionalidades empresariales.
Vemos muchas pruebas que respaldan que un COE amplio y robusto es fundamental
para ofrecer valor y maximizar el éxito empresarial. Puede incluir iniciativas de cambio,
procesos estándar, roles, instrucciones, procedimientos recomendados, soporte técnico,
entrenamiento y mucho más.
Le invitamos a leer los artículos de esta serie COE para saber más. Vamos a ayudarle a
descubrir el modo en que su organización puede adoptar el cambio para lograr el éxito.
Pasos siguientes
Establecimiento de un centro de excelencia

Hoja de ruta de adopción de Power BI: Centro de excelencia
En el siguiente artículo de esta serie, consulte cómo un COE nos ayudó en Microsoft a
crear una plataforma de datos y análisis estandarizada para extraer conclusiones a partir
de nuestros datos.
Servicios profesionales
Hay partners de Power BI certificados a su disposición para ayudar a su organización a
configurar un COE. Pueden ofrecerle un rentable aprendizaje o una auditoría de los
datos. Para ponerse en contacto con un partner de Power BI, visite el portal de partners
de Power BI .
También puede ponerse en contacto con partners de consultoría experimentados.

Pueden ayudarle a valorar , evaluar o implementar Power BI.
Cómo Microsoft estableció un Centro de
excelencia
 Sugerencia
Este artículo se centra en la experiencia de Microsoft en el establecimiento de un

Centro de excelencia. Al configurar su propio Centro de excelencia, le
recomendamos que también revise la información que se trata en la Hoja de ruta
de adopción de Power BI.
Este artículo se dirige a los profesionales y administradores de TI. Aprenderá a

configurar un centro de excelencia (COE) de BI y análisis en su organización, así como la
forma en que Microsoft ha configurado el suyo.
Para algunos, existe la idea equivocada de que un COE es tan solo un departamento de
soporte técnico; sin embargo, este concepto está muy lejos de la realidad.
Por lo general, un COE de BI y análisis es un equipo de profesionales que se encarga de

establecer y mantener una plataforma de BI. También se encarga de crear una única
fuente de confianza y de definir un conjunto de métricas coherentes de toda la empresa
para extraer y acelerar las conclusiones. Sin embargo, un COE es un término amplio.
Como tal, se puede implementar y administrar de distintas maneras, y su estructura y
ámbito pueden variar de una organización a otra. En esencia, siempre se trata de una
plataforma sólida que ofrece las funcionalidades de datos y de información adecuadas a
las personas adecuadas en el momento adecuado. Idealmente, también fomenta la
promoción, el entrenamiento y el soporte técnico. En Microsoft, se describe como
disciplina en el núcleo y se entrega como la plataforma de BI y única fuente de
confianza.
En organizaciones de mayor tamaño, podría encontrar varios COE donde el COE

principal se amplíe con distintos COE satélite, a menudo a nivel de departamento. De
este modo, un COE satélite es un grupo de expertos familiarizados con las taxonomías y
las definiciones, que saben cómo transformar los datos principales en lo que tiene
sentido para su departamento. A los analistas de departamento se les conceden
permisos a los datos principales y confían en ellos para su uso en sus propios informes.
Crean soluciones que se basan en las dimensiones, los hechos y la lógica de negocios
principales cuidadosamente preparados. En ocasiones, también podrían ampliarse con
conjuntos de datos y lógica de negocios más pequeños y específicos del departamento.
Lo importante es que los COE satélite no se desconectan nunca ni actúan aisladamente.
En Microsoft, los COE satélite promueven flexibilidad en el borde .
Para que este escenario ampliado tenga éxito, los departamentos deben pagar por
reproducir. En otras palabras, los departamentos deben invertir financieramente en el
COE principal. De este modo, no hay que preocuparse de que "no obtengan lo que les
corresponde" o de que sus requisitos tengan menos prioridad.
Para admitir este escenario, el COE principal debe escalarse a fin de satisfacer las
necesidades de los departamentos financiados. Cuando se hayan incorporado varios
conjuntos de datos, se generarán economías de escala. En Microsoft, en seguida se hizo
evidente que trabajar de forma centralizada resulta más económico y produce
resultados más rápidos. Cada vez que se incorporaba una nueva área temática,
experimentábamos economías de escala aún mayores que permitían aprovechar y
colaborar en toda la plataforma, lo que reforzaba nuestra referencia cultural de datos
subyacente.
Veamos un ejemplo: Nuestra plataforma de BI ofrece dimensiones, hechos y lógica de

negocios principales para finanzas, ventas y marketing. También define cientos de
indicadores clave de rendimiento (KPI). Ahora, un analista de la empresa en Power
Platform debe preparar un panel para la dirección. Algunos de los KPI, como los
ingresos y las canalizaciones, proceden directamente de la plataforma de BI. Sin
embargo, otros se basan en necesidades más pormenorizadas de la empresa. Una de
estas necesidades se refiere a un KPI sobre la adopción del usuario de una característica
específica de Power BI: los flujos de datos. Por lo tanto, el analista produce un modelo
compuesto en Power BI para integrar los datos de la plataforma principal de BI con los
datos del departamento. Luego agrega lógica de negocios para definir los KPI de su
departamento. Por último, crea su panel para la dirección en función del nuevo modelo,
que aprovecha los recursos de COE de toda la empresa ampliados con los datos y el
conocimiento local.
Lo importante es que una división de responsabilidad entre los COE satélite y el

principal permite que los analistas departamentales se centren en abrir nuevos caminos
y no en administrar una plataforma de datos. En ocasiones, incluso puede haber una
relación mutuamente beneficiosa entre los COE satélite y el COE principal. Por ejemplo,
un COE satélite puede definir nuevas métricas que, tras haber demostrado ser
beneficiosas para su departamento, terminen siendo métricas principales beneficiosas
para toda la empresa, disponibles en el COE principal y respaldadas por él.
Plataforma de BI
En su organización, el COE podría ser reconocido por otro nombre, como el equipo o
grupo de BI. El nombre importa menos que lo que realmente hace. Si no tiene un
equipo formalizado, le recomendamos que forme un equipo que reúna a sus expertos
principales en BI para establecer su plataforma de BI.
En Microsoft, el COE se conoce como plataforma de BI. Tiene muchos grupos de partes
interesadas que representan distintas divisiones dentro de la empresa, como finanzas,
ventas y marketing. Está organizado para ejecutar funcionalidades compartidas y
entregas dedicadas.
Funcionalidades compartidas
Se necesitan funcionalidades compartidas para establecer y usar la plataforma de BI.
Admiten todos los grupos de partes interesadas que financian la plataforma.
Comprenden los siguientes equipos:
Ingeniería de la plataforma principal: Diseñamos la plataforma de BI con una

mentalidad de ingeniería. En realidad, es un conjunto de marcos que admite la
ingesta de datos, el procesamiento para enriquecer los datos y la entrega de esos
datos en modelos semánticos de BI para consumo de los analistas. Los ingenieros
son responsables del diseño técnico y la implementación de las funcionalidades de
la plataforma principal de BI. Por ejemplo, diseñan e implementan las
canalizaciones de datos.
Infraestructura y hospedaje: Los ingenieros de TI se encargan del
aprovisionamiento y la administración de todos los servicios de Azure.
Soporte técnico y operaciones: Este equipo mantiene la plataforma en ejecución.
El soporte técnico se ocupa de las necesidades del usuario como los permisos de
datos. Las operaciones mantienen la plataforma en ejecución, lo que garantiza que
se cumplan los contratos de nivel de servicio (SLA) y se comuniquen los retrasos o
errores.
Administración de versiones: Los administradores de programas (PM) técnicos
publican los cambios. Los cambios pueden variar de las actualizaciones del marco
de la plataforma a las solicitudes de cambio a los modelos semánticos de BI que se
realicen. Son la última línea de defensa para garantizar que los cambios no
interrumpan nada.
Entregas dedicadas
Hay un equipo de entrega dedicada para cada grupo de partes interesadas.
Normalmente, se compone de un ingeniero de datos, un ingeniero de análisis y un PM
técnico, todos financiados por su grupo de partes interesadas.
Roles de equipo de BI
En Microsoft, nuestra plataforma de BI funciona a través de equipos escalables de
profesionales. Los equipos se alinean con recursos dedicados y compartidos.
Actualmente, tenemos los siguientes roles:
Administradores de programas: Los PM son un recurso dedicado. Actúan como

contacto principal entre el equipo de BI y las partes interesadas. Su trabajo
consiste en convertir los requisitos empresariales de las partes interesadas en una
especificación técnica. Además, administran la clasificación por orden de prioridad
de los resultados esperados de las partes interesadas.
Responsables de base de datos: Se trata de un recurso dedicado que se encarga
de la incorporación de nuevos conjuntos de datos al almacenamiento de datos
centralizado. La incorporación de un conjunto de datos puede implicar la
configuración de dimensiones compatibles, la adición de lógica de negocios y
atributos personalizados, así como el formato y los nombres estándar.
Responsables de análisis: Se trata de un recurso dedicado que se encarga del
diseño y desarrollo de modelos semánticos de BI. Procuran aplicar una
arquitectura coherente con la nomenclatura y el formato estándar. La optimización
del rendimiento es una parte importante de su rol.
Operaciones e infraestructura: Se trata de un recurso compartido que se encarga
de administrar trabajos y canalizaciones de datos. También se ocupa de
administrar suscripciones de Azure, funcionalidades de Power BI, máquinas
virtuales y puertas de enlace de datos.
Soporte técnico: Se trata de un recurso compartido que se encarga de redactar la
documentación, organizar el entrenamiento, comunicar los cambios del modelo
semántico de BI y responder a las preguntas de los usuarios.
Gobernanza y cumplimiento
Para cada grupo de partes interesadas, los responsables de administración de proyectos
se encargan de la gobernanza y supervisión entre programas. Su objetivo primordial es
garantizar que las inversiones en TI generen valor empresarial y mitiguen el riesgo. Las
reuniones del comité directivo se celebran periódicamente para revisar el progreso y
aprobar iniciativas importantes.
Crecimiento de su propia comunidad

Establezca una comunidad dentro de su organización y fomente su crecimiento
mediante prácticas como las siguientes:
Celebre de eventos regulares en "horario de oficina" que reserven tiempo con el

equipo de BI para que los empleados puedan plantear preguntas, hacer
sugerencias, compartir ideas e incluso presentar quejas.
Cree un canal de equipos que ofrezca asistencia y anime a cualquier persona a
preguntar y responder a las preguntas publicadas.
Organice y promocione grupos informales de usuarios y el estímulo a los
empleados para que se presenten o asistan.
Organice eventos de aprendizaje más formales en productos específicos y en la
propia plataforma de BI. Valore la posibilidad de impartir Power BI Dashboard in a
Day , que está disponible como kit de cursos gratuito y es una excelente manera
de introducir a los empleados en Power BI por primera vez.
Pasos siguientes
Arquitectura de la solución de BI en el COE

En el siguiente artículo de esta serie, conocerá la arquitectura de la solución de BI en el
COE y las distintas tecnologías empleadas.
de Power BI .

Arquitectura de la solución de BI en el
centro de excelencia
Este artículo se dirige a los profesionales y administradores de TI. Conocerá la

arquitectura de la solución de BI en el COE y las distintas tecnologías empleadas. Las
tecnologías incluyen Azure, Power BI y Excel. Juntas, pueden aprovecharse para ofrecer
una plataforma de BI en la nube escalable y controlada por datos.
El diseño de una plataforma de BI sólida es algo parecido a crear un puente; un puente

que conecta los datos de origen transformados y enriquecidos con los consumidores de
datos. El diseño de esta estructura compleja requiere una mentalidad de ingeniería,
aunque puede ser una de las arquitecturas de TI más creativas y gratificantes que pueda
diseñar. En una organización de gran tamaño, una arquitectura de la solución de BI
puede constar de lo siguiente:
Orígenes de datos
Ingesta de datos
Preparación de datos o macrodatos
Almacenamiento de datos
Modelos semánticos de BI
Informes
La plataforma debe admitir demandas específicas. En concreto, se debe escalar y

ejecutar para satisfacer las expectativas de los servicios de negocio y los consumidores
de datos. Al mismo tiempo, debe ser segura desde el principio. Además, debe ser
suficientemente resistente para adaptarse a los cambios, porque existe la certeza de
que, con el tiempo, habrá que poner en línea nuevos datos y áreas temáticas.
Marcos de trabajo
En Microsoft, desde el principio adoptamos un enfoque de tipo sistémico invirtiendo en
el desarrollo de un marco. Los marcos de procesos técnicos y empresariales aumentan
la reutilización del diseño y la lógica y ofrecen un resultado coherente. También ofrecen
flexibilidad en la arquitectura, lo que aprovecha muchas tecnologías, y optimizan y
reducen la sobrecarga de ingeniería a través de procesos repetibles.
Aprendimos que los marcos bien diseñados aumentan la visibilidad del linaje de datos,
el análisis de impacto, el mantenimiento de la lógica de negocios, la administración de
la taxonomía y la optimización de la gobernanza. Además, el desarrollo se hizo más
rápido y la colaboración en los equipos de gran tamaño era más eficaz y receptiva.
En este artículo se describen algunos de los marcos de trabajo.
Modelos de datos
Los modelos de datos proporcionan control sobre cómo se estructuran los datos y
cómo se accede a ellos. En el caso de servicios de negocio y consumidores de datos, los
modelos de datos son la interfaz de la plataforma de BI.
Una plataforma de BI puede ofrecer tres tipos diferentes de modelos:
Modelos empresariales
Modelos de Machine Learning (ML)
Modelos empresariales
Los arquitectos de TI compilan y mantienen los modelos empresariales. A veces se les
conoce como modelos dimensionales o data marts. Normalmente, los datos se
almacenan en formato relacional como tablas de dimensiones y tablas de hechos. Estas
tablas almacenan datos limpios y enriquecidos consolidados de muchos sistemas y
representan un origen autoritativo para informes y análisis.
Los modelos empresariales proporcionan un origen de datos coherente y único para los
informes y BI. Se crean una vez y se comparten como estándar corporativo. Las
directivas de gobernanza garantizan la seguridad de los datos, por lo que el acceso a los
conjuntos de datos confidenciales (como información de clientes o datos financieros), se
restringe en caso necesario. Adoptan convenciones de nomenclatura que garantizan la
coherencia, con lo que se afianza la credibilidad de los datos y la calidad.
En una plataforma de BI en la nube, los modelos empresariales se pueden implementar
en un grupo de Synapse SQL en Azure Synapse. A continuación, el grupo de Synapse
SQL se convierte en la versión única de la verdad con la que puede contar la
organización para obtener conclusiones rápidas y eficaces.
Los modelos semánticos de BI representan una capa semántica en los modelos
empresariales. Los desarrolladores de BI y los usuarios empresariales los compilan y
mantienen. Los desarrolladores de BI crean modelos semánticos de BI principales que
obtienen datos de los modelos empresariales. Los usuarios empresariales pueden crear
modelos independientes de menor escala, o bien pueden ampliar los modelos
semánticos de BI principales con orígenes externos o de departamento. Los modelos
semánticos de BI normalmente se centran en una sola área temática y a menudo son
ampliamente compartidos.
Las capacidades empresariales no solo se habilitan por datos, sino también por modelos
semánticos de BI que describen conceptos, relaciones, reglas y estándares. De este
modo, representan estructuras intuitivas y fáciles de entender que definen relaciones de
datos y encapsulan reglas de negocios como cálculos. También pueden aplicar permisos
de datos específicos, que garanticen que las personas adecuadas tengan acceso a los
datos correctos. Lo importante es que aceleran el rendimiento de las consultas y
proporcionan un análisis interactivo con gran capacidad de respuesta, incluso con varios
terabytes de datos. Al igual que los modelos empresariales, los modelos semánticos
de BI adoptan convenciones de nomenclatura para garantizar la coherencia.
En una plataforma de BI en la nube, los desarrolladores de BI pueden implementar

modelos semánticos de BI en Azure Analysis Services o capacidades de Power BI
Premium. Se recomienda su implementación en Power BI cuando se usa como capa de
informes y análisis. Estos productos admiten diferentes modos de almacenamiento, lo
que permite que las tablas del modelo de datos almacenen en memoria caché sus datos
o utilicen DirectQuery, que es una tecnología que pasa las consultas a través del origen
de datos subyacente. DirectQuery es un modo de almacenamiento ideal cuando las
tablas del modelo representan grandes volúmenes de datos o es necesario ofrecer
resultados casi en tiempo real. Los dos modos de almacenamiento se pueden combinar:
Los modelos compuestos combinan tablas que usan distintos modos de
almacenamiento en un único modelo.
En el caso de modelos con gran cantidad de consultas, puede usarse Azure Load
Balancer para distribuir uniformemente la carga de consultas entre réplicas de los
modelos. También permite escalar las aplicaciones y crear modelos semánticos de BI de
alta disponibilidad.
Modelos de Machine Learning
Los modelos de Machine Learning (ML) los compilan y mantienen los científicos de
datos. Se desarrollan principalmente a partir de orígenes sin procesar en el lago de
datos.
Los modelos de ML entrenados pueden revelar patrones dentro de los datos. En muchas
circunstancias, esos patrones pueden usarse para hacer predicciones que pueden
emplearse para enriquecer los datos. Por ejemplo, el comportamiento de compra se
puede usar para predecir el abandono de clientes o para segmentarlos. Los resultados
de la predicción se pueden agregar a los modelos empresariales para permitir el análisis
por segmento de clientes.
En una plataforma de BI en la nube, se puede usar Azure Machine Learning para

entrenar, implementar, automatizar, administrar y realizar un seguimiento de los
modelos de ML.
En el centro de una plataforma de BI se encuentra el almacenamiento de datos, que
hospeda los modelos empresariales. Se trata de un origen de datos autorizados, como
sistema de registro y como centro de conectividad, que presenta modelos empresariales
para informes, BI y ciencia de datos.
Muchos servicios de negocio, como las aplicaciones de línea de negocio (LOB), pueden
basarse en el almacenamiento de datos como un origen autoritativo y controlado de
conocimiento empresarial.
En Microsoft, el almacenamiento de datos se hospeda en Azure Data Lake Storage Gen2

(ADLS Gen2) y Azure Synapse Analytics.
ADLS Gen2 convierte a Azure Storage en los cimientos para crear lagos de datos
empresariales en Azure. Está diseñado para proporcionar varios petabytes de
información, al mismo tiempo que mantiene un rendimiento de cientos de
gigabits. También ofrece transacciones y capacidad de almacenamiento de bajo
costo. Además, admite el acceso compatible con Hadoop, lo que permite
administrar los datos y acceder a ellos del mismo modo que lo haría con un
sistema de archivos distribuido de Hadoop (HDFS). De hecho, Azure HDInsight,
Azure Databricks y Azure Synapse Analytics pueden acceder a los datos
almacenados en ADLS Gen2. Por lo tanto, en una plataforma de BI, es una buena
opción almacenar datos de origen sin procesar, datos semiprocesados o
almacenados provisionalmente y datos listos para producción. La usamos para
almacenar todos los datos empresariales.
Azure Synapse Analytics es un servicio de análisis que engloba el almacenamiento
de datos empresariales y el análisis de macrodatos. Le ofrece la libertad de
consultar los datos como prefiera, ya sea a petición sin servidor o con recursos
aprovisionados, a escala. Synapse SQL, un componente de Azure Synapse
Analytics, admite análisis completos basados en T‑SQL, por lo que resulta ideal
para hospedar modelos empresariales que consten de tablas de dimensiones y de
hechos. Las tablas se pueden cargar eficazmente desde ADLS Gen2 mediante
consultas sencillas de T-SQL de Polybase. Entonces tiene la potencia de MPP para
ejecutar análisis de alto rendimiento.
Marco del Motor de reglas de negocio

Hemos desarrollado un marco de Motor de reglas de negocio (BRE) para catalogar
cualquier lógica de negocios que se pueda implementar en la capa de almacenamiento
de datos. Un BRE puede significar muchas cosas, pero en el contexto de un
almacenamiento de datos resulta útil para crear columnas calculadas en tablas
relacionales. Estas columnas calculadas normalmente se representan como cálculos
matemáticos o expresiones que utilizan instrucciones condicionales.
Lo que se pretende es separar la lógica de negocios del código principal de BI.

Tradicionalmente, las reglas de negocios están codificadas de forma rígida en
procedimientos almacenados de SQL, por lo que a menudo resulta muy difícil
mantenerlas cuando las necesidades del negocio cambian. En un BRE, las reglas de
negocios se definen una vez y se usan varias veces cuando se aplican a distintas
entidades de almacenamiento de datos. Si es necesario cambiar la lógica de cálculo,
solo debe actualizarse en un único lugar y no en numerosos procedimientos
almacenados. También hay una ventaja añadida: un marco de BRE impulsa la
transparencia y visibilidad de la lógica de negocios implementada, que se puede
exponer a través de un conjunto de informes que crean documentación de actualización
automática.
Orígenes de datos
Un almacenamiento de datos puede consolidar datos de prácticamente cualquier origen
de datos. Se basa principalmente en orígenes de datos de aplicación de línea de
negocio, que suelen ser bases de datos relacionales que almacenan datos específicos de
cada tema para ventas, marketing, finanzas, etc. Estas bases de datos pueden estar
hospedadas en la nube o residir en el entorno local. Otros orígenes de datos pueden
estar basados en archivos, especialmente registros web o datos de IOT procedentes de
dispositivos. Además, los datos pueden tener su origen en proveedores de software
como servicio (SaaS).
En Microsoft, algunos de nuestros sistemas internos envían datos operativos directos a

ADLS Gen2 con formatos de archivo sin procesar. Además de nuestro lago de datos,
otros sistemas de origen incluyen aplicaciones de línea de negocio relacionales, libros
de Excel, otros orígenes basados en archivos y repositorios de datos personalizados y de
administración de datos maestros (MDM). Los repositorios de MDM nos permiten
administrar los datos maestros para garantizar versiones de datos autoritativas,
estandarizadas y validadas.
Ingesta de datos
Periódicamente, y según los ritmos de la empresa, los datos se ingieren desde los
sistemas de origen y se cargan en el almacenamiento de datos. Podría ser una vez al día
o a intervalos más frecuentes. La ingesta de datos se refiere a la extracción,
transformación y carga de datos. O, quizás al revés: extracción, carga y transformación
de datos. La diferencia estriba en el lugar donde se produce la transformación. Las
transformaciones se aplican para limpiar, ajustar, integrar y estandarizar los datos. Para
obtener más información, consulte Extracción, transformación y carga de datos (ETL).
En última instancia, el objetivo es cargar los datos correctos en el modelo empresarial

con la mayor rapidez y eficacia posibles.
En Microsoft, usamos Azure Data Factory (ADF). Los servicios se usan para programar y
orquestar validaciones, transformaciones y cargas masivas de datos de los sistemas de
origen externos en nuestro lago de datos. Todo esto se administra mediante marcos
personalizados para procesar datos en paralelo y a escala. Además, se lleva a cabo un
registro completo para admitir la solución de problemas, la supervisión del rendimiento
y el desencadenamiento de notificaciones de alerta cuando se cumplen determinadas
condiciones.
Mientras tanto, Azure Databricks (una plataforma de análisis basada en Apache Spark
optimizada para la plataforma de servicios en la nube de Azure) realiza
transformaciones específicas para la ciencia de datos. También se compilan y ejecutan
modelos de ML con cuadernos de Python. Las puntuaciones de estos modelos de ML se
cargan en el almacenamiento de datos para integrar las predicciones con los informes y
las aplicaciones empresariales. Dado que Azure Databricks accede directamente a los
archivos de lago de datos, elimina o minimiza la necesidad de copiar o adquirir datos.
Marco de ingesta
Hemos desarrollado un marco de ingesta como un conjunto de procedimientos y tablas
de configuración. Admite un enfoque controlado por datos para adquirir grandes
volúmenes de datos a alta velocidad y con código mínimo. En resumen, este marco
simplifica el proceso de adquisición de datos para cargar el almacenamiento de datos.
El marco depende de tablas de configuración que almacenan información relacionada
con el origen y el destino de los datos tales como tipo de origen, servidor, base de
datos, esquema y detalles relacionados con las tablas. Este enfoque de diseño significa
que no es necesario desarrollar canalizaciones específicas de Azure Data Factory ni
paquetes de SQL Server Integration Services (SSIS). En su lugar, los procedimientos se
escriben en el lenguaje de nuestra elección para crear canalizaciones de Azure Data
Factory que se generan dinámicamente y se ejecutan en tiempo de ejecución. Por lo
tanto, la adquisición de datos se convierte en un ejercicio de configuración que se pone
en práctica fácilmente. Tradicionalmente, se necesitarían amplios recursos de desarrollo
extensos para crear paquetes de Azure Data Factory o SSIS codificados de forma rígida.
El marco de ingesta se diseñó para simplificar el proceso de control de los cambios de

esquema de origen ascendentes. Resulta fácil actualizar los datos de configuración,
manual o automáticamente, cuando se detectan cambios en el esquema para adquirir
los atributos recién agregados al sistema de origen.
Marco de orquestación
Hemos desarrollado un marco de orquestación para poner en práctica y orquestar
nuestras canalizaciones de datos. Utiliza un diseño controlado por datos que depende
de un conjunto de tablas de configuración. Estas tablas almacenan metadatos que
describen las dependencias de canalización y cómo asignar los datos de origen a las
estructuras de datos de destino. La inversión en el desarrollo de este marco adaptable
se ha amortizado desde entonces; ya no es necesario codificar de forma rígida cada
movimiento de datos.
Un lago de datos puede almacenar grandes volúmenes de datos sin procesar para su
uso posterior junto con transformaciones de datos de almacenamiento provisional.
En Microsoft, usamos ADLS Gen2 como única fuente de confianza. Almacena datos sin
procesar junto con datos almacenados provisionalmente y datos listos para producción.
Proporciona una solución de lago de datos rentable y altamente escalable para análisis
de macrodatos. La combinación del potencial de un sistema de archivos de alto
rendimiento con una escala masiva, está optimizada para cargas de trabajo de análisis
de datos, lo que acelera la obtención de conclusiones.
ADLS Gen2 proporciona lo mejor de dos mundos: el almacenamiento de blobs y un

espacio de nombres de sistema de archivos de alto rendimiento, que se configuran con
permisos de acceso específicos.
Los datos refinados se almacenan en una base de datos relacional para ofrecer un
almacén de datos de alto rendimiento y altamente escalable para los modelos
empresariales, con seguridad, gobernanza y capacidad de administración. Los data
marts específicos de cada tema se almacenan en Azure Synapse Analytics, que luego se
cargan mediante consultas de T-SQL de Polybase o de Azure Databricks.
Consumo de datos
En la capa de informes, los servicios de negocio consumen datos empresariales
procedentes del almacenamiento de datos. También tienen acceso a los datos
directamente en el lago de datos para realizar tareas de análisis ad hoc o de ciencia de
datos.
Los permisos específicos se aplican en todas las capas: en el lago de datos, los modelos
empresariales y los modelos semánticos de BI. Los permisos garantizan que los
consumidores de datos solo pueden ver los datos para los que tienen derechos de
acceso.
En Microsoft, usamos informes y paneles de Power BI e informes paginados de Power BI

Algunos informes y análisis ad hoc se realizan en Excel, especialmente en el caso de los
informes financieros.
Publicamos diccionarios de datos, que proporcionan información de referencia sobre

nuestros modelos de datos. Se han puesto a disposición de los usuarios a fin de que
puedan descubrir información sobre nuestra plataforma de BI. Los diccionarios
documentan los diseños de modelos y proporcionan descripciones sobre entidades,
formatos, estructura, linaje de datos, relaciones y cálculos. Usamos Azure Data Catalog
para que nuestros orígenes de datos sean fáciles de detectar y entender.
Normalmente, los patrones de consumo de datos difieren en función del rol:
Los analistas de datos se conectan directamente a los modelos semánticos de BI

principales. Cuando los modelos semánticos de BI principales contienen todos los
datos y la lógica que necesitan, usan conexiones dinámicas para crear informes y
paneles de Power BI. Cuando tienen que ampliar los modelos con datos
departamentales, crean modelos compuestos de Power BI. Si se necesitan informes
de tipo de hoja de cálculo, usan Excel para generar informes basados en modelos
semánticos de BI principales o modelos semánticos de BI de departamento.
Los desarrolladores de BI y los autores de informes operativos se relacionan
directamente con los modelos empresariales. Usan Power BI Desktop para crear
informes de análisis de conexión dinámica. También pueden crear informes de BI
de tipo operativo como informes paginados de Power BI si escriben consultas SQL
nativas para acceder a los datos de los modelos empresariales de Azure Synapse
Analytics mediante T-SQL, o los modelos semánticos de Power BI mediante DAX o
MDX.
Los científicos de datos se conectan directamente a los datos del lago de datos.
Usan cuadernos de Azure Databricks y Python para desarrollar modelos de ML,
que a menudo son experimentales y requieren aptitudes especializadas para su
uso en producción.
Pasos siguientes

Inteligencia empresarial con Azure Synapse Analytics
de Power BI .

Notas del producto de Power BI
Las white papers le permiten explorar Power BI temas en un nivel más profundo. Aquí
puede encontrar una lista de las white papers disponibles para Power BI.
White paper Descripción Date

(Documento
técnico)
Planning a Power BI En este documento técnico actualizado se describen las Junio de

Enterprise consideraciones y los procedimientos recomendados para 2020
Deployment una implementación de organización segura y Power BI
(Planeación de una rendimiento.
implementación de
Power BI Enterprise)
Power BI y flujos de En estas white paper se describen los flujos de datos con Noviembre
datos detalle técnico y se describen las funcionalidades y las de 2018
iniciativas subyacentes a las características y funcionalidades
del flujo de datos.
Planeamiento e El contenido de estas directrices se ha incorporado a la guía Marzo de

implementación de general. Consulte el vínculo para obtener instrucciones y 2019
Power BI Premium procedimientos recomendados para planear e implementar
Premium capacidad para cargas de trabajo bien definidas.
Instrucciones para el Este documento pretende ofrecer instrucciones sobre el Marzo de

planeamiento de la planeamiento de la capacidad de Power BI Report Server 2018
capacidad de Power mediante el uso compartido de los resultados de numerosas
BI Report Server ejecuciones de pruebas de carga en un servidor de informes.
Seguridad Proporciona una explicación detallada de la seguridad de Marzo de

Power BI. 2019
Distribuir Power BI En este documento se describe cómo distribuir contenido a Marzo de

contenido a los usuarios de fuera de la organización mediante la 2019
usuarios invitados integración de Azure Active Directory Business-to-business
externos mediante (AAD B2B).
Azure Active
Directory B2B
Análisis avanzado Describe las funcionalidades analíticas avanzadas de Power Febrero de

con Power BI BI, como el análisis predictivo, las visualizaciones 2017
personalizadas, la integración de R y las expresiones de
análisis de datos.
White paper Descripción Date
(Documento
técnico)
Filtrado Explica el filtrado cruzado bidireccional en Power BI Desktop Julio de

bidireccional (en las SQL Server Analysis Services 2016, ambos tienen el 2018
mismo comportamiento).
DirectQuery en SQL Para SQL Server 2016, DirectQuery se ha rediseñado para Enero de
Server 2016 Analysis lograr una importante mejora en el rendimiento y la 2017
Services velocidad. Sin embargo, ahora se ha hecho más compleja su
comprensión e implementación.
Power BI y SAP En este documento se describe cómo los clientes de SAP Noviembre
BW pueden beneficiarse al conectar Power BI a sus sistemas SAP de 2019
Business Warehouse (BW) existentes. Actualizado en
noviembre de 2019.
Securing the Tabular En este documento se presenta el modelo de seguridad para Abril de
BI Semantic la semántica de BI tabular y Power BI. Aprenderá a crear 2016
Model (Protección roles, implementar la seguridad dinámica, configurar
del modelo opciones de suplantación, administrar roles y elegir un
semántico de BI método para conectarse a modelos que funcione en su
tabular) contexto de seguridad de red.
Power BI y RGPD Este vínculo le lleva a la lista de documentos técnicos del Abril de
Portal de confianza de servicios, incluidas las Power BI rgpd 2018
de Microsoft.
Información general Este vínculo le lleva a un artículo que describe cómo migrar Septiembre
sobre la migración a desde otras herramientas de business intelligence a Power de 2020
Power BI BI.
７ Nota
Si está interesado en ver o eliminar datos personales, revise las instrucciones de

Microsoft en el sitio Solicitudes del titular de los datos de Windows para el RGPD.
Si quiere obtener información general sobre el RGPD, vea la sección sobre RGPD
del Portal de confianza del servicio .
¿Tiene más preguntas? Pruebe a preguntar a la comunidad de Power BI

Notas del producto sobre la seguridad
de Power BI
Resumen: Power BI es un servicio de software en línea (SaaS o software como servicio)

de Microsoft que le permite crear fácilmente y rápidamente paneles de Inteligencia
empresarial de autoservicio, informes, conjuntos de datos y visualizaciones. Con Power
BI, se puede conectar a muchos orígenes de datos diferentes, combinar y dar forma a
los datos de esas conexiones y, después, crear informes y paneles que se pueden
compartir con otros usuarios.
Escritores: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan
Turuvekere, Christian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny
Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton
Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth,
Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit
Chattopadhyay, Yariv Maimon, Bogdan Crivat
Revisores técnicos: Christian Petculescu, Amir Netz, Sergio Gundorov
Se aplica a: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded

Analytics, Power BI Mobile
７ Nota
Para guardar o imprimir este documento técnico, seleccione Imprimir en el

explorador y, a continuación, seleccione Guardar como PDF.
Introducción
Power BI es una oferta de servicio de software en línea (SaaS o Software como servicio)
de Microsoft que permite crear de forma rápida y sencilla paneles de inteligencia
empresarial con características de autoservicio, informes, conjuntos de datos y
visualizaciones. Con Power BI, se puede conectar a muchos orígenes de datos diferentes,
combinar y dar forma a los datos de esas conexiones y, después, crear informes y
paneles que se pueden compartir con otros usuarios.
El mundo está cambiando rápidamente; las organizaciones están pasando por una
transformación digital acelerada y estamos viendo un aumento masivo en el trabajo
remoto, una mayor demanda de clientes para servicios en línea y un mayor uso de
tecnologías avanzadas en las operaciones y la toma de decisiones empresariales. Y todo
esto funciona con la nube.
A medida que la transición a la nube ha cambiado de un truco a una inundación, y con

el nuevo área expuesta expuesta que viene con ella, más y más empresas preguntan
¿Qué seguridad tienen mis datos en la nube? y ¿Qué protección de un extremo a otro está
disponible para evitar que se filtren mis datos confidenciales? Y para las plataformas de BI
que a menudo controlan parte de la información más estratégica de la empresa, estas
preguntas son doblemente importantes.
Los fundamentos de décadas del modelo de seguridad de BI : seguridad de nivel de

objeto y de nivel de fila, aunque aún son importantes, ya no bastan para proporcionar el
tipo de seguridad necesaria en la era de la nube. En su lugar, las organizaciones deben
buscar una solución de seguridad de defensa en profundidad y nativa de la nube para
sus datos de inteligencia empresarial.
Power BI se creó para proporcionar protección hermética y completa líder del sector
para los datos. El producto ha obtenido las clasificaciones de seguridad más altas
disponibles en la industria, y hoy en día muchos organismos de seguridad nacionales,
instituciones financieras y proveedores de atención médica lo confían con su
información más confidencial.
Todo comienza con la fundación. Después de un período aproximado en los primeros

años de 2000, Microsoft realizó inversiones masivas para abordar sus vulnerabilidades
de seguridad, y en las décadas siguientes creó una pila de seguridad muy fuerte que va
tan profundamente como el kernel del bios del equipo en chip y amplía todo el camino
hasta las experiencias del usuario final. Estas inversiones profundas continúan y hoy en
día más de 3500 ingenieros de Microsoft se dedican a crear y mejorar la pila de
seguridad de Microsoft y abordar proactivamente el panorama de amenazas cada vez
más cambiante. Con miles de millones de equipos, billones de inicios de sesión e
innumerables zettabytes de información encomendada a la protección de Microsoft, la
empresa ahora posee la pila de seguridad más avanzada del sector tecnológico y se
considera ampliamente como líder global en la lucha contra actores malintencionados.
Power BI se basa en esta base muy sólida. Usa la misma pila de seguridad que ganó el
derecho de Azure a servir y proteger los datos más confidenciales del mundo, y se
integra con las herramientas de cumplimiento y protección de la información más
avanzadas de Microsoft 365. Además de esto, ofrece seguridad a través de medidas de
seguridad multicapa, lo que da lugar a una protección integral diseñada para abordar
los desafíos únicos de la era de la nube.
Para proporcionar una solución de un extremo a otro para proteger los recursos
confidenciales, el equipo del producto necesitaba abordar problemas desafiantes de los
clientes en varios frentes simultáneos:
¿Cómo controlamos quién puede conectarse, dónde se conectan y cómo se conectan?

¿Cómo podemos controlar las conexiones?
¿Cómo se almacenan los datos?¿Cómo se cifra?¿Qué controles tengo en mis datos?
Cómo controlar y proteger mis datos confidenciales?Cómo asegurarse de que estos
datos no se pueden filtrar fuera de la organización?
Cómo auditar quién lleva a cabo las operaciones?Cómo reaccionar rápidamente si
hay actividad sospechosa en el servicio?
En este artículo se proporciona una respuesta completa a todas estas preguntas.

Comienza con una visión general de la arquitectura del servicio y explica cómo
funcionan los flujos principales del sistema. A continuación, pasa a describir cómo se
autentican los usuarios en Power BI, cómo se establecen las conexiones de datos y
cómo Power BI almacena y mueve los datos a través del servicio. En la última sección se
describen las características de seguridad que le permiten, como administrador del
servicio, proteger los recursos más valiosos.
El servicio Power BI se rige por los términos de Microsoft Online Services y la

Declaración de privacidad de Microsoft Enterprise . Para obtener la ubicación del
procesamiento de datos, consulte La ubicación de los términos de procesamiento de
datos en los términos de Microsoft Online Services y el anexo de protección de
datos . Para obtener información de cumplimiento, el Centro de confianza de
Microsoft es el principal recurso para Power BI. El equipo de Power BI se esfuerza para
brindar a sus clientes las innovaciones y la productividad más recientes. Obtenga más
información sobre el cumplimiento en las ofertas de cumplimiento de Microsoft.
El servicio Power BI sigue el ciclo de vida de desarrollo de seguridad (SDL), prácticas de

seguridad estrictas que admiten los requisitos de cumplimiento y garantía de seguridad.
El SDL ayuda a los desarrolladores a crear software más seguro al reducir el número y la
gravedad de las vulnerabilidades en el software, a la vez que reduce el costo de
desarrollo. Obtenga más información en Prácticas del ciclo de vida de desarrollo de
seguridad de Microsoft .
Arquitectura de Power BI
El servicio Power BI se basa en Azure, la plataforma informática en la nube de
Microsoft. En la actualidad, Power BI se implementa en muchos centros de datos en
todo el mundo: hay muchas implementaciones activas a disposición de los clientes en
las regiones a las que sirven esos centros de datos y un número equivalente de
implementaciones pasivas que actúan como copias de seguridad para cada
implementación activa.
Clúster front-end web (WFE)

El clúster WFE proporciona al explorador del usuario el contenido inicial de la página
HTML en la carga del sitio, así como punteros al contenido de la red CDN que se usa
para representar el sitio en el explorador.
Un clúster WFE consta de un sitio web de ASP.NET que se ejecuta en el entorno de

Azure App Service. Cuando los usuarios intentan conectarse al servicio Power BI, el
servicio DNS del cliente puede comunicarse con Azure Traffic Manager para encontrar el
centro de datos más adecuado (normalmente más cercano) con una implementación de
Power BI. Para más información sobre este proceso, consulte Método de enrutamiento
de tráfico de rendimiento para Azure Traffic Manager.
Los recursos estáticos como *.js, *.css y archivos de imagen se almacenan principalmente
en Azure Content Delivery Network (CDN) y se recuperan directamente mediante el
explorador. Tenga en cuenta que las implementaciones de clústeres de Gobierno
soberano son una excepción a esta regla y, por motivos de cumplimiento, omitirán la
red CDN y, en su lugar, usarán un clúster WFE de una región compatible para hospedar
contenido estático.
Clúster de back-end de Power BI (BE)

El clúster de back-end es la red troncal de toda la funcionalidad disponible en Power BI.
Consta de varios puntos de conexión de servicio consumidos por clientes front-end web
y api, así como servicios de trabajo en segundo plano, bases de datos, cachés y otros
componentes.
El back-end está disponible en la mayoría de las regiones de Azure y se implementa en

nuevas regiones a medida que están disponibles. Una sola región de Azure hospeda
uno o varios clústeres de back-end que permiten un escalado horizontal ilimitado del
servicio Power BI una vez agotados los límites de escalado vertical y horizontal de un
único clúster.
Cada clúster de back-end tiene estado y hospeda todos los datos de todos los
inquilinos asignados a ese clúster. Un clúster que contiene los datos de un inquilino
específico se conoce como clúster principal del inquilino. El servicio global proporciona
información del clúster principal de un usuario autenticado y lo usa el front-end web
para enrutar las solicitudes al clúster principal del inquilino.
Cada clúster de back-end consta de varias máquinas virtuales combinadas en varios

conjuntos de escalado redimensionable optimizados para realizar tareas específicas,
recursos con estado, como bases de datos SQL, cuentas de almacenamiento, buses de
servicio, cachés y otros componentes de nube necesarios.
Los metadatos y los datos del inquilino se almacenan dentro de los límites del clúster,
excepto para la replicación de datos en un clúster back-end secundario en una región
de Azure emparejada en la misma geografía de Azure. El clúster back-end secundario
actúa como un clúster de conmutación por error en caso de interrupción regional y es
pasivo en cualquier otro momento.
Los microservicios que se ejecutan en diferentes máquinas dentro de la red virtual del
clúster que no son accesibles desde fuera, excepto para dos componentes a los que se
puede acceder desde la red pública de Internet:
Servicio de puerta de enlace
Azure API Management
infraestructura de Power BI Premium

Power BI Premium ofrece un servicio para los suscriptores que requieren características
premium de Power BI, como flujos de datos, informes paginados, inteligencia artificial,
etc. Cuando un cliente se suscribe a una suscripción de Power BI Premium, la capacidad
Premium se crea a través de Azure Resource Manager.
Power BI Premium capacidades se hospedan en clústeres back-end que son

independientes del back-end normal de Power BI( consulte más arriba). Esto
proporciona un mejor aislamiento, asignación de recursos, compatibilidad, aislamiento
de seguridad y escalabilidad de la oferta Premium.
En el diagrama siguiente se muestra la arquitectura de la infraestructura de Power BI

Premium:
La conexión a la infraestructura de Power BI Premium se puede realizar de varias
maneras, en función del escenario de usuario. Power BI Premium clientes pueden ser el
explorador de un usuario, un back-end de Power BI normal, conexiones directas a través
de clientes XMLA, API de ARM, etc.
La infraestructura Power BI Premium de una región de Azure consta de varios clústeres

de Power BI Premium (el mínimo es uno). La mayoría de los recursos Premium se
encapsulan dentro de un clúster (por ejemplo, proceso) y hay algunos recursos
regionales comunes (por ejemplo, almacenamiento de metadatos). La infraestructura
Premium permite dos maneras de lograr la escalabilidad horizontal en una región:
aumentar los recursos dentro de los clústeres o agregar más clústeres a petición según
sea necesario (si los recursos del clúster se aproximan a sus límites).
La red troncal de cada clúster son recursos de proceso administrados por Virtual
Machine Scale Sets y Azure Service Fabric. Virtual Machine Scale Sets y Service Fabric
permiten un aumento rápido e indolido de los nodos de proceso a medida que
aumenta el uso y organiza la implementación, administración y supervisión de servicios
y aplicaciones de Power BI Premium.
Hay muchos recursos circundantes que garantizan una infraestructura segura y

confiable: equilibradores de carga, redes virtuales, grupos de seguridad de red, service
bus, almacenamiento, etc. Azure Key Vault administra exclusivamente los secretos, las
claves y los certificados necesarios para Power BI Premium. Cualquier autenticación se
realiza a través de la integración con Azure AD exclusivamente.
Cualquier solicitud que llegue a Power BI Premium infraestructura se dirige primero a los
nodos front-end: son los únicos nodos disponibles para las conexiones externas. El resto
de los recursos se ocultan detrás de las redes virtuales. Los nodos front-end autentican
la solicitud, la controlan o reenvía a los recursos adecuados (por ejemplo, nodos back-
end).
Los nodos back-end proporcionan la mayoría de las funcionalidades y características de

Power BI Premium.
Power BI Mobile
Power BI Mobile es una colección de aplicaciones diseñadas para las tres plataformas
móviles principales: Android, iOS y Windows (UWP). Las consideraciones de seguridad
para las aplicaciones de Power BI Mobile se dividen en dos categorías:
Comunicación de dispositivos
La aplicación y los datos en el dispositivo
Para la comunicación de dispositivos, todas las aplicaciones Power BI Mobile se

comunican con el servicio Power BI y usan las mismas secuencias de conexión y
autenticación usadas por los exploradores, que se describen con detalle anteriormente
en esta notas del producto. Las aplicaciones móviles de Power BI para iOS y Android
traen una sesión del explorador dentro de la propia aplicación, mientras que la
aplicación móvil de Windows abre un agente para establecer el canal de comunicación
con Power BI (para el proceso de inicio de sesión).
En la tabla siguiente se muestra la compatibilidad con la autenticación basada en
certificados (CBA) para Power BI Mobile, en función de la plataforma de dispositivos
móviles:
Compatibilidad con CBA iOS Android Windows
Power BI (inicio de sesión en el servicio) Compatible Compatible No compatible
SSRS ADFS local (conéctese al servidor SSRS) No compatible Compatible No compatible
Proxy de aplicación de SSRS Compatible Compatible No compatible
Las aplicaciones Power BI Mobile se comunican activamente con el servicio Power BI. La
telemetría se usa para recopilar estadísticas de uso de aplicaciones móviles y datos
similares, que se transmiten a los servicios que se usan para supervisar el uso y la
actividad; no se envían datos de cliente con telemetría.
La aplicación Power BI almacena datos en el dispositivo que facilita el uso de la

aplicación:
Azure AD y los tokens de actualización se almacenan en un mecanismo seguro en

el dispositivo mediante medidas de seguridad estándar del sector.
Los datos y la configuración (pares clave-valor para la configuración del usuario) se
almacenan en caché en el almacenamiento en el dispositivo y se pueden cifrar
mediante el sistema operativo. En iOS, esto se realiza automáticamente cuando el
usuario establece un código de acceso. En Android, esto se puede configurar en la
configuración. En Windows, se logra mediante BitLocker.
En el caso de las aplicaciones Android e iOS, los datos y la configuración (pares
clave-valor para la configuración de usuario) se almacenan en caché en el
almacenamiento en el dispositivo en un espacio aislado y en un almacenamiento
interno que solo es accesible para la aplicación. Para la aplicación de Windows, el
usuario solo puede acceder a los datos (y al administrador del sistema).
El usuario habilita o deshabilita explícitamente la geolocalización. Si está
habilitado, los datos de geolocalización no se guardan en el dispositivo y no se
comparten con Microsoft.
El usuario habilita o deshabilita explícitamente las notificaciones. Si está habilitado,
Android e iOS no admiten los requisitos de residencia de datos geográficos para
las notificaciones.
El cifrado de datos se puede mejorar aplicando el cifrado de nivel de archivo a través de

Microsoft Intune, un servicio de software que proporciona administración de
aplicaciones y dispositivos móviles. Las tres plataformas para las que Power BI Mobile
está disponible admiten Intune. Con Intune habilitado y configurado, se cifran los datos
en el dispositivo móvil y la propia aplicación de Power BI no se puede instalar en una
tarjeta SD. Obtenga más información sobre Microsoft Intune .
La aplicación de Windows también admite Windows Information Protection (WIP).
Para implementar el inicio de sesión único, algunos valores de almacenamiento

protegidos relacionados con la autenticación basada en tokens están disponibles para
otras aplicaciones de Microsoft 1st (como Microsoft Authenticator) y se administran
mediante el SDK de la Biblioteca de autenticación de Azure Active Directory (ADAL).
Power BI Mobile datos almacenados en caché se elimina cuando se quita la aplicación,

cuando el usuario cierra la sesión de Power BI Mobile o cuando el usuario no puede
iniciar sesión (por ejemplo, después de un evento de expiración de token o un cambio
de contraseña). La caché de datos incluye los paneles e informes a los que se ha
accedido anteriormente desde la aplicación de Power BI Mobile.
Power BI Mobile no tiene acceso a otras carpetas o archivos de aplicación en el

dispositivo.
Las aplicaciones de Power BI para iOS y Android le permiten proteger los datos
mediante la configuración de una identificación adicional, como proporcionar Face ID,
Touch ID o un código de acceso para iOS y datos biométricos (id. de huella digital) para
Android. Más información sobre la identificación adicional.
Autenticación en el servicio Power BI

La autenticación de usuarios en el servicio Power BI consta de una serie de solicitudes,
respuestas y redireccionamientos entre el explorador del usuario y el servicio Power BI o
los servicios de Azure que se usan en Power BI. Esta secuencia describe el proceso de
autenticación de usuario en Power BI, que sigue el flujo de concesión de código de
autenticación de Azure Active Directory. Para obtener más información sobre las
opciones de los modelos de autenticación de usuario (modelos de inicio de sesión) de
una organización, consulte Elección de un modelo de inicio de sesión para Microsoft
365 .
Secuencia de autenticación
La secuencia de autenticación de usuario para el servicio Power BI se produce como se
describe en los pasos siguientes, que se muestran en la imagen que los sigue.
1. Un usuario inicia una conexión con el servicio Power BI desde un explorador,

escribiendo la dirección de Power BI en la barra de direcciones o seleccionando
Iniciar sesión en la página de marketing de Power BI
(https://powerbi.microsoft.com ). La conexión se establece mediante TLS y
HTTPS, y todas las comunicaciones posteriores entre el explorador y el servicio
Power BI usan HTTPS.
2. Azure Traffic Manager comprueba el registro DNS del usuario para determinar el
centro de datos más adecuado (normalmente más cercano) donde se implementa
Power BI y responde al DNS con la dirección IP del clúster WFE al que se debe
enviar el usuario.
3. A continuación, WFE devuelve una página HTML al cliente del explorador, que
contiene una referencia de biblioteca de MSAL.js necesaria para iniciar el flujo de
inicio de sesión.
4. El cliente del explorador carga la página HTML recibida de WFE y redirige al

usuario a la página de inicio de sesión de Microsoft Online Services.
5. Una vez autenticado el usuario, la página de inicio de sesión redirige al usuario de

nuevo a la página WFE de Power BI con un código de autenticación.
6. El cliente del explorador carga la página HTML y usa el código de autenticación

para solicitar tokens (acceso, identificador, actualización) desde el servicio Azure
AD.
7. El cliente del explorador usa el identificador de inquilino del usuario para consultar
el servicio global de Power BI, que mantiene una lista de inquilinos y sus
ubicaciones de clúster de back-end de Power BI. El servicio global de Power BI
determina qué clúster del servicio back-end de Power BI contiene el inquilino del
usuario y devuelve la dirección URL del clúster de back-end de Power BI al cliente.
8. El cliente ahora puede comunicarse con la API de dirección URL del clúster back-
end de Power BI mediante el token de acceso en el encabezado autorización de las
solicitudes HTTP. El token de acceso de Azure AD tendrá una fecha de expiración
establecida según las directivas de Azure AD y, para mantener la sesión actual, el
cliente de Power BI en el explorador del usuario realizará solicitudes periódicas
para renovar el token de acceso antes de que expire.
En los casos muy raros en los que se produce un error de autenticación del lado cliente
debido a un error inesperado, el código intentará revertir al uso de la autenticación del
lado servidor en WFE. Consulte la sección de preguntas y respuestas al final de este
documento para obtener más información sobre el flujo de autenticación del lado
servidor.
Residencia de datos
A menos que se indique lo contrario en la documentación, Power BI almacena los datos
de los clientes en una geografía de Azure que se asigna cuando un inquilino de Azure
AD se suscribe por primera vez a los servicios de Power BI. Un inquilino de Azure AD
aloja las identidades de usuario y aplicación, los grupos y otra información relevante
que pertenecen a una organización y a su seguridad.
La asignación de una ubicación geográfica de Azure para el almacenamiento de datos

de inquilino se realiza mediante la asignación del país o región seleccionado como parte
de la configuración del inquilino de Azure AD a la ubicación geográfica de Azure más
adecuada en la que existe una implementación de Power BI. Una vez realizada esta
determinación, todos los datos del cliente de Power BI se almacenarán en esta geografía
de Azure seleccionada (también conocida como geográfica principal), excepto en los
casos en los que las organizaciones usen implementaciones multigeográficas.
Varias zonas geográficas (multigeográficas)

Algunas organizaciones tienen una presencia global y pueden requerir servicios de
Power BI en varias zonas geográficas de Azure. Por ejemplo, una empresa puede tener
su sede central en la Estados Unidos, pero también puede hacer negocios en otras áreas
geográficas, como Australia. En tales casos, la empresa puede requerir que
determinados datos de Power BI permanezcan almacenados en reposo en la región
remota para cumplir con las regulaciones locales. Esta característica del servicio Power BI
se conoce como multigeográfica.
La capa de ejecución de consultas, las cachés de consultas y los datos de artefacto

asignados a un área de trabajo multigeográfica se hospedan y permanecen en la zona
geográfica de Azure de capacidad remota. Sin embargo, algunos metadatos de
artefacto, como la estructura del informe, pueden permanecer almacenados en reposo
en la ubicación geográfica principal del inquilino. Además, es posible que algunos
tránsitos y procesamientos de datos sigan ocurriendo en la ubicación geográfica
principal del inquilino, incluso para áreas de trabajo hospedadas en una capacidad
Premium multigeográfica.
Consulte Configuración de la compatibilidad multigeográfica para Power BI Premium

para obtener más información sobre cómo crear y administrar implementaciones de
Power BI que abarcan varias zonas geográficas de Azure.
Regiones y centros de datos

Los servicios de Power BI están disponibles en zonas geográficas de Azure específicas,
como se describe en el Centro de confianza de Microsoft . Para obtener más
información sobre dónde se almacenan los datos y cómo se usan, consulte el Centro de
confianza de Microsoft . Los compromisos relativos a la ubicación de los datos del
cliente en reposo se especifican en los Términos de procesamiento de datos de los
Términos de Microsoft Online Services .
Microsoft también proporciona centros de datos para entidades soberanas. Para

obtener más información sobre la disponibilidad del servicio Power BI para nubes
nacionales, vea Nubes nacionales de Power BI .
Control de datos
En esta sección se describen los procedimientos de control de datos de Power BI en lo
que respecta al almacenamiento, procesamiento y transferencia de datos de los clientes.
Datos en reposo
Power BI usa dos tipos de recursos de almacenamiento de datos principales:
Azure Storage
Azure SQL Database
En la mayoría de los escenarios, Azure Storage se usa para conservar los datos de los
artefactos de Power BI, mientras que las bases de datos de Azure SQL se usan para
conservar los metadatos del artefacto.
Todos los datos guardados por Power BI se cifran de forma predeterminada mediante
claves administradas por Microsoft. Los datos del cliente almacenados en Azure SQL
Bases de datos se cifran completamente mediante la tecnología de cifrado de datos
transparente (TDE) de Azure SQL. Los datos del cliente almacenados en Azure Blob
Storage se cifran mediante Azure Storage Encryption.
Opcionalmente, las organizaciones pueden usar Power BI Premium para usar sus propias
claves para cifrar los datos en reposo que se importan en un conjunto de datos. Este
enfoque suele describirse como Bring Your Own Key (BYOK). El uso de BYOK ayuda a
garantizar que, incluso en el caso de un error del operador de servicio, los datos del
cliente no se expongan, algo que no se puede lograr fácilmente mediante el cifrado
transparente del lado del servicio. Consulte Traiga sus propias claves de cifrado para
Power BI para más información.
Los conjuntos de datos de Power BI permiten una variedad de modos de conexión de

origen de datos que determinan si los datos del origen de datos se conservan en el
servicio o no.
Modo de conjunto de datos (Tipo) Datos persistentes en Power BI
Importar Sí
DirectQuery. No
Live Connect No
Compuesto Si contiene un origen de datos de importación
Streaming Si está configurado para conservarse

Independientemente del modo de conjunto de datos utilizado, Power BI puede
almacenar temporalmente en caché los datos recuperados para optimizar el
rendimiento de la carga de consultas y informes.
Datos en procesamiento
Los datos se procesan cuando uno o varios usuarios los usan activamente como parte
de un escenario interactivo, o cuando un proceso en segundo plano, como la
actualización, toca estos datos. Power BI carga datos procesados activamente en el
espacio de memoria de una o varias cargas de trabajo de servicio. Para facilitar la
funcionalidad requerida por la carga de trabajo, los datos procesados en memoria no se
cifran.
Datos en tránsito
Power BI requiere que todo el tráfico HTTP entrante se cifre mediante TLS 1.2 o superior.
Se rechazarán todas las solicitudes que intenten usar el servicio con TLS 1.1 o inferior.
Autenticación en orígenes de datos

Al conectarse a un origen de datos, un usuario puede optar por importar una copia de
los datos en Power BI o conectarse directamente al origen de datos.
En el caso de la importación, un usuario establece una conexión basada en el inicio de

sesión del usuario y accede a los datos con la credencial. Una vez publicado el conjunto
de datos en el servicio Power BI, Power BI siempre usa la credencial de este usuario para
importar datos. Una vez importados los datos, ver los datos en informes y paneles no
tiene acceso al origen de datos subyacente. Power BI admite la autenticación de inicio
de sesión único para orígenes de datos seleccionados. Si la conexión está configurada
para usar el inicio de sesión único, las credenciales del propietario del conjunto de datos
se usan para conectarse al origen de datos.
Si un origen de datos se conecta directamente mediante credenciales preconfiguradas,

las credenciales preconfiguradas se usan para conectarse al origen de datos cuando
cualquier usuario ve los datos. Si un origen de datos está conectado directamente
mediante el inicio de sesión único, las credenciales del usuario actual se usan para
conectarse al origen de datos cuando un usuario ve los datos. Cuando se usa con el
inicio de sesión único, la seguridad de nivel de fila (RLS) o la seguridad de nivel de
objeto (OLS) se puede implementar en el origen de datos. Esto permite a los usuarios
ver solo los datos a los que tienen privilegios de acceso. Cuando la conexión es a
orígenes de datos en la nube, se usa la autenticación de Azure AD para el inicio de
sesión único; para orígenes de datos locales, Kerberos, lenguaje de marcado de aserción
de seguridad (SAML) y Azure AD se admiten.
Si el origen de datos está Azure Analysis Services o Analysis Services local, y se configura
RLS o OLS, el servicio Power BI aplicará esa seguridad de nivel de fila y los usuarios que
no tengan credenciales suficientes para acceder a los datos subyacentes (que podrían
ser una consulta usada en un panel, informe u otro artefacto de datos) no verán los
datos que no tienen privilegios suficientes. Para.
Características Premium
Arquitectura de flujos de datos

Los flujos de datos proporcionan a los usuarios la capacidad de configurar operaciones
de procesamiento de datos de back-end que extraerán datos de orígenes de datos
polimórficos, ejecutarán la lógica de transformación en los datos y, a continuación, la
colocarán en un modelo de destino para su uso en diversas tecnologías de presentación
de informes. Cualquier usuario que tenga un rol de miembro, colaborador o
administrador en un área de trabajo puede crear un flujo de datos. Los usuarios del rol
de visor pueden ver los datos procesados por el flujo de datos, pero no pueden realizar
cambios en su composición. Una vez creado un flujo de datos, cualquier miembro,
colaborador o administrador del área de trabajo puede programar actualizaciones, así
como ver y editar el flujo de datos tomando posesión de él.
Cada origen de datos configurado está enlazado a una tecnología de cliente para
acceder a ese origen de datos. La estructura de las credenciales necesarias para acceder
a ellas se forma para que coincida con los detalles de implementación necesarios del
origen de datos. La lógica de transformación se aplica mediante Power Query servicios
mientras los datos están en curso. En el caso de los flujos de datos Premium, los
servicios Power Query se ejecutan en nodos back-end. Los datos se pueden extraer
directamente de los orígenes de nube o a través de una puerta de enlace instalada en el
entorno local. Cuando se extrae directamente de un origen en la nube al servicio o a la
puerta de enlace, el transporte usa la metodología de protección específica de la
tecnología de cliente, si procede. Cuando los datos se transfieren de la puerta de enlace
al servicio en la nube, se cifran. Consulte la sección Datos en procesamiento anterior.
Cuando los orígenes de datos especificados por el cliente requieren credenciales para el
acceso, el propietario o creador del flujo de datos los proporcionará durante la creación.
Se almacenan mediante el almacenamiento de credenciales estándar para todo el
producto. Consulte la sección Autenticación a orígenes de datos anterior. Hay varios
enfoques que los usuarios pueden configurar para optimizar la persistencia y el acceso a
los datos. De forma predeterminada, los datos se colocan en una cuenta de
almacenamiento protegida y propiedad de Power BI. El cifrado de almacenamiento está
habilitado en los contenedores de Blob Storage para proteger los datos mientras están
en reposo. Consulte la sección Datos en reposo a continuación. Sin embargo, los
usuarios pueden configurar su propia cuenta de almacenamiento asociada a su propia
suscripción de Azure. Al hacerlo, a una entidad de seguridad servicio Power BI se le
concede acceso a esa cuenta de almacenamiento para que pueda escribir los datos allí
durante la actualización. En este caso, el propietario del recurso de almacenamiento es
responsable de configurar el cifrado en la cuenta de almacenamiento de ADLS
configurada. Los datos siempre se transmiten a Blob Storage mediante cifrado.
Dado que el rendimiento al acceder a las cuentas de almacenamiento puede ser poco
óptimo para algunos datos, los usuarios también tienen la opción de usar un motor de
proceso hospedado en Power BI para aumentar el rendimiento. En este caso, los datos
se almacenan con redundancia en una base de datos SQL que está disponible para
DirectQuery a través del acceso mediante el sistema back-end de Power BI. Los datos
siempre se cifran en el sistema de archivos. Si el usuario proporciona una clave para
cifrar los datos almacenados en la base de datos SQL, esa clave se usará para cifrarlo
doblemente.
Al consultar mediante DirectQuery, el protocolo de transporte cifrado HTTPS se usa para

acceder a la API. Todo el uso secundario o indirecto de DirectQuery se controla
mediante los mismos controles de acceso descritos anteriormente. Dado que los flujos
de datos siempre están enlazados a un área de trabajo, el acceso a los datos siempre
está limitado por el rol del usuario en esa área de trabajo. Un usuario debe tener al
menos acceso de lectura para poder consultar los datos a través de cualquier medio.
Cuando se usa Power BI Desktop para acceder a los datos de un flujo de datos, primero
debe autenticar al usuario mediante Azure AD para determinar si el usuario tiene
derechos suficientes para ver los datos. Si es así, se adquiere una clave SaS y se usa para
acceder al almacenamiento directamente mediante el protocolo de transporte cifrado
HTTPS.
El procesamiento de datos en toda la canalización emite Office 365 eventos de

auditoría. Algunos de estos eventos capturarán las operaciones relacionadas con la
seguridad y la privacidad.
Informes paginados
Están diseñados para imprimirse o compartirse. Se denominan paginados porque
presentan un formato apto para encajar en una página. Muestran todos los datos en
una tabla, incluso si esta abarca varias páginas. Puede controlar el diseño de la página
del informe totalmente.
Los informes paginados admiten expresiones enriquecidas y eficaces escritas en

Microsoft Visual Basic .NET. En los informes paginados de Power BI Report Builder se
usan ampliamente expresiones para recuperar, calcular, mostrar, agrupar, ordenar, filtrar,
parametrizar y dar formato a los datos.
El autor del informe crea expresiones con acceso a la amplia gama de características de
.NET Framework. El procesamiento y la ejecución de informes paginados se realiza
dentro de un espacio aislado.
Las definiciones de informes paginados (.rdl) se almacenan en Power BI y para publicar o

representar un informe paginado, un usuario debe autenticarse y autorizar de la misma
manera que se describe en la sección Autenticación en el servicio Power BI anterior.
El token de Azure AD obtenido durante la autenticación se usa para comunicarse

directamente desde el explorador al clúster de Power BI Premium.
En Power BI Premium, el entorno de ejecución de servicio Power BI proporciona un

entorno de ejecución aislado adecuado para cada representación de informe. Esto
incluye los casos en los que los informes que se representan pertenecen a áreas de
trabajo asignadas a la misma capacidad.
Un informe paginado puede acceder a un amplio conjunto de orígenes de datos como

parte de la representación del informe. El espacio aislado no se comunica directamente
con ninguno de los orígenes de datos, sino que se comunica con el proceso de
confianza para solicitar datos y, a continuación, el proceso de confianza anexa las
credenciales necesarias a la conexión. De este modo, el espacio aislado nunca tiene
acceso a ninguna credencial o secreto.
Para admitir características como mapas de Bing o llamadas a Azure Functions, el

espacio aislado tiene acceso a Internet.
Análisis integrados de Power BI

Los proveedores de software independientes (ISV) y los proveedores de soluciones
tienen dos modos principales de insertar artefactos de Power BI en sus aplicaciones web
y portales: insertar para su organización e insertar para los clientes. El artefacto se
inserta en un IFrame en la aplicación o el portal. No se permite que un IFrame lea o
escriba datos desde la aplicación web externa o el portal, y la comunicación con el
IFrame se realiza mediante el SDK de cliente de Power BI mediante mensajes POST.
En un escenario de inserción para su organización , los usuarios de Azure AD acceden a
su propio contenido de Power BI a través de portales personalizados por sus empresas e
identificadores. Todas las directivas y funcionalidades de Power BI descritas en este
documento, como seguridad de nivel de fila (RLS) y seguridad de nivel de objeto (OLS)
se aplican automáticamente a todos los usuarios independientemente de si acceden a
Power BI a través del portal de Power BI o a través de portales personalizados.
En un escenario de inserción para los clientes , los ISV suelen ser propietarios de
inquilinos de Power BI y artefactos de Power BI (paneles, informes, conjuntos de datos,
etc.). Es responsabilidad de un servicio back-end de ISV autenticar a sus usuarios finales
y decidir qué artefactos y qué nivel de acceso es adecuado para ese usuario final. Las
decisiones de directiva de ISV se cifran en un token de inserción generado por Power BI
y se pasan al back-end de ISV para su posterior distribución a los usuarios finales según
la lógica de negocios del ISV. Los usuarios finales que usan un explorador u otras
aplicaciones cliente no pueden descifrar o modificar tokens de inserción. Los SDK del
lado cliente, como las API de cliente de Power BI , anexan automáticamente el token de
inserción cifrado a las solicitudes de Power BI como un encabezado Authorization:
EmbedToken . En función de este encabezado, Power BI aplicará todas las directivas
(como el acceso o RLS) exactamente tal como lo especificó el ISV durante la generación.
Para habilitar la inserción y la automatización, y para generar los tokens de inserción

descritos anteriormente, Power BI expone un amplio conjunto de API rest. Estas API rest
de Power BI admiten métodos de autenticación y autorización delegados por el usuario
y la entidad de servicio de Azure AD.
Los análisis integrados de Power BI y sus API REST admiten todas las funcionalidades de
aislamiento de red de Power BI que se describen en este artículo: por ejemplo, etiquetas
de servicio y vínculos privados.
Características de inteligencia artificial

Actualmente, Power BI admite dos amplias categorías de características de inteligencia
artificial en el producto: objetos visuales de inteligencia artificial y enriquecimientos con
ia. Las características de inteligencia artificial de nivel visual incluyen funcionalidades
como Key-Influencers, Descomposition-Tree, Smart-Narrative, Anomaly-Detection, R-
visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights etc. Las
funcionalidades de enriquecimiento con IA incluyen funcionalidades como AutoML,
AzureML, CognitiveServices, transformaciones de R/Python, etc.
La mayoría de las características mencionadas anteriormente se admiten en las áreas de

trabajo Compartidas y Premium en la actualidad. Sin embargo, AutoML y
CognitiveServices solo se admiten en áreas de trabajo Premium, debido a restricciones
de IP. En la actualidad, con la integración de AutoML en Power BI, un usuario puede
compilar y entrenar un modelo de ML personalizado (por ejemplo, predicción,
clasificación, regresión, etc.) y aplicarlo para obtener predicciones al cargar datos en un
flujo de datos definido en un área de trabajo Premium. Además, los usuarios de Power
BI pueden aplicar varias API de CognitiveServices, como TextAnalytics e ImageTagging,
para transformar los datos antes de cargarlos en un flujo de datos o conjunto de datos
definido en un área de trabajo Premium.
Las características de enriquecimiento con inteligencia artificial Premium se pueden ver

mejor como una colección de funciones o transformaciones de inteligencia artificial sin
estado que los usuarios de Power BI pueden usar en sus canalizaciones de integración
de datos usadas por un conjunto de datos o un flujo de datos de Power BI. Tenga en
cuenta que también se puede acceder a estas funciones desde entornos actuales de
creación de flujos de datos o conjuntos de datos en el servicio Power BI y Power BI
Desktop. Estas funciones o transformaciones de inteligencia artificial siempre se
ejecutan en un área de trabajo o capacidad Premium. Estas funciones se exponen en
Power BI como un origen de datos que requiere un token de Azure AD para el usuario
de Power BI que usa la función de IA. Estos orígenes de datos de IA son especiales
porque no exponen ninguno de sus propios datos y solo proporcionan estas funciones
o transformaciones. Durante la ejecución, estas características no realizan ninguna
llamada saliente a otros servicios para transmitir los datos del cliente. Echemos un
vistazo a los escenarios Premium individualmente para comprender los patrones de
comunicación y los detalles pertinentes relacionados con la seguridad relacionados con
ellos.
Para el entrenamiento y la aplicación de un modelo de AutoML, Power BI usa el SDK de

Azure AutoML y ejecuta todo el entrenamiento en la capacidad de Power BI del cliente.
Durante las iteraciones de entrenamiento, Power BI llama a un servicio AzureML de
experimentación para seleccionar un modelo adecuado y hiperparámetres para la
iteración actual. En esta llamada saliente, solo se envían metadatos de experimento
relevantes (por ejemplo, precisión, algoritmo ml, parámetros de algoritmo, etc.) de la
iteración anterior. El entrenamiento de AutoML genera un modelo ONNX y los datos del
informe de entrenamiento que, a continuación, se guardan en el flujo de datos. Más
adelante, los usuarios de Power BI pueden aplicar el modelo de APRENDIZAJE
automático entrenado como una transformación para poner en marcha el modelo de
ML de forma programada. En el caso de las API TextAnalytics e ImageTagging, Power BI
no llama directamente a las API del servicio CognitiveServices, sino que usa un SDK
interno para ejecutar las API en la capacidad de Power BI Premium. Actualmente, estas
API se admiten en flujos de datos y conjuntos de datos de Power BI. Al crear un
conjunto de datos en Power BI Desktop, los usuarios solo pueden acceder a esta
funcionalidad si tienen acceso a un área de trabajo de Power BI Premium. Por lo tanto,
se pide a los clientes que proporcionen sus credenciales de Azure AD.
Aislamiento de red
En esta sección se describen las características de seguridad avanzadas en Power BI.
Algunas de las características tienen requisitos de licencia específicos. Consulte las
secciones siguientes para obtener más información.
Etiquetas de servicio
Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio
de Azure determinado. Ayuda a minimizar la complejidad de las actualizaciones
frecuentes de las reglas de seguridad de red. Los clientes pueden usar etiquetas de
servicio para definir controles de acceso a la red en grupos de seguridad de red o Azure
Firewall. Los clientes pueden usar etiquetas de servicio en lugar de direcciones IP
específicas al crear reglas de seguridad. Al especificar el nombre de la etiqueta de
servicio (como PowerBI ) en el campo de origen o destino adecuado (para las API) de
una regla, los clientes pueden permitir o denegar el tráfico para el servicio
correspondiente. Microsoft administra los prefijos de direcciones que la etiqueta de
servicio incluye y actualiza automáticamente dicha etiqueta a medida que las
direcciones cambian.
Integración de Private Link

La categoría Redes de Azure ofrece la característica Azure Private Link, que permite que
Power BI Proporcione un acceso seguro mediante los puntos de conexión privados de
Redes de Azure. Con Azure Private Link y puntos de conexión privados, el tráfico de
datos se envía de forma privada mediante la infraestructura de red troncal de Microsoft
y, por tanto, los datos no atraviesan Internet.
Private Link garantiza que los usuarios de Power BI usen la red troncal privada de
Microsoft al ir a los recursos de la servicio Power BI.
El uso de Private Link con Power BI proporciona las siguientes ventajas:
Private Link garantiza que el tráfico fluya por la red troncal de Azure a un punto de
conexión privado para los recursos basados en la nube de Azure.
El aislamiento del tráfico de red de la infraestructura no basada en Azure, como el
acceso local, requeriría que los clientes tuvieran expressRoute o una red privada
virtual (VPN) configurada.
Consulte Vínculos privados para acceder a Power BI para obtener información adicional.
Conectividad de red virtual (versión preliminar:

próximamente)
Aunque la característica de integración de Private Link proporciona conexiones
entrantes seguras a Power BI, la característica de conectividad de red virtual permite una
conectividad saliente segura de Power BI a orígenes de datos dentro de una red virtual.
Las puertas de enlace de red virtual (administradas por Microsoft) eliminarán la

sobrecarga de instalar y supervisar puertas de enlace de datos locales para conectarse a
orígenes de datos asociados a una red virtual. Sin embargo, seguirán siguiendo el
proceso familiar de administración de orígenes de datos y seguridad, como con una
puerta de enlace de datos local.
A continuación se muestra información general sobre lo que sucede cuando interactúa

con un informe de Power BI que está conectado a un origen de datos dentro de una red
virtual mediante puertas de enlace de red virtual:
1. El servicio en la nube de Power BI (o uno de los otros servicios en la nube

admitidos) inicia una consulta y envía la consulta, los detalles del origen de datos y
las credenciales al servicio de red virtual de Power Platform (VNet PP).
2. Después, el servicio de red virtual pp inserta de forma segura un contenedor que

ejecuta una puerta de enlace de red virtual en la subred. Este contenedor ahora
puede conectarse a los servicios de datos accesibles desde dentro de esta subred.
3. Después, el servicio de red virtual pp envía la consulta, los detalles del origen de
datos y las credenciales a la puerta de enlace de red virtual.
4. La puerta de enlace de red virtual obtiene la consulta y se conecta a los orígenes

de datos con esas credenciales.
5. La consulta se envía al origen de datos para su ejecución.
6. Después de la ejecución, los resultados se envían a la puerta de enlace de red

virtual y el servicio de red virtual pp inserta de forma segura los datos del
contenedor en el servicio en la nube de Power BI.
Esta característica estará disponible en versión preliminar pública próximamente.
Entidades de servicio
Power BI admite el uso de entidades de servicio. Almacene las credenciales de entidad
de servicio usadas para cifrar o acceder a Power BI en un Key Vault, asignar directivas de
acceso adecuadas al almacén y revisar periódicamente los permisos de acceso.
Consulte Automatización de tareas de conjunto de datos y áreas de trabajo Premium

con entidades de servicio para más información.
Microsoft Purview para Power BI
Microsoft Purview Information Protection

Power BI está profundamente integrado con Microsoft Purview Information Protection
(anteriormente, Information Protection de cumplimiento de Microsoft 365). Microsoft
Purview Information Protection permite a las organizaciones tener una única solución
integrada para la clasificación, el etiquetado, la auditoría y el cumplimiento en Azure,
Power BI y Office.
Cuando la protección de la información está habilitada en Power BI:
Los datos confidenciales, tanto en el servicio Power BI como en Power BI Desktop,

se pueden clasificar y etiquetar con las mismas etiquetas de confidencialidad que
se usan en Office y en Azure.
Las directivas de gobernanza se pueden aplicar cuando el contenido de Power BI
se exporta a archivos excel, PowerPoint, PDF, Word o .pbix , para ayudar a
garantizar que los datos están protegidos incluso cuando salen de Power BI.
Es fácil clasificar y proteger archivos .pbix en Power BI Desktop, al igual que se hace
en aplicaciones de Excel, Word y PowerPoint. Los archivos se pueden etiquetar
fácilmente según su nivel de confidencialidad. Aún más, se pueden cifrar si
contienen datos confidenciales empresariales, lo que garantiza que solo los
usuarios autorizados puedan editar estos archivos.
Los libros de Excel heredan automáticamente las etiquetas de confidencialidad
cuando se conectan a Power BI (versión preliminar), lo que permite mantener la
clasificación de un extremo a otro y aplicar protección cuando se analizan los
conjuntos de datos de Power BI en Excel.
Las etiquetas de confidencialidad aplicadas a los informes y paneles de Power BI
están visibles en las aplicaciones móviles de iOS y Android de Power BI.
Las etiquetas de confidencialidad se conservan cuando un informe de Power BI se
inserta en Teams, SharePoint o en un sitio web seguro. Esto ayuda a las
organizaciones a mantener la clasificación y la protección tras la exportación al
insertar contenido de Power BI.
La herencia de etiquetas tras la creación de nuevo contenido en el servicio Power
BI garantiza que las etiquetas aplicadas a conjuntos de datos o datamarts del
servicio Power BI se aplicarán al nuevo contenido creado sobre esos conjuntos de
datos y datamarts.
Las API de examen de administrador de Power BI pueden extraer la etiqueta de
confidencialidad de un elemento de Power BI, lo que permite a los administradores
de Power BI e InfoSec supervisar el etiquetado en el servicio Power BI y generar
informes ejecutivos.
Las API de administración de Power BI permiten a los equipos centrales aplicar
mediante programación etiquetas de confidencialidad al contenido del servicio
Power BI.
Los equipos centrales pueden crear directivas de etiquetas obligatorias para aplicar
etiquetas en contenido nuevo o editado en Power BI.
Los equipos centrales pueden crear directivas de etiqueta predeterminadas para
asegurarse de que una etiqueta de confidencialidad se aplica a todo el contenido
de Power BI nuevo o cambiado.
El etiquetado automático de confidencialidad de bajada en el servicio Power BI
garantiza que, cuando se aplica o cambia una etiqueta en un conjunto de datos o
datamart, la etiqueta se aplicará o cambiará automáticamente en todo el
contenido de nivel inferior conectado al conjunto de datos o datamart.
Para más información, consulte Etiquetas de confidencialidad en Power BI.
directivas de Prevención de pérdida de datos de

Microsoft Purview (DLP) para Power BI (versión
preliminar)
Las directivas DLP de Microsoft Purview pueden ayudar a las organizaciones a reducir el
riesgo de pérdida de datos empresariales confidenciales de Power BI. Las directivas DLP
pueden ayudarles a cumplir los requisitos de cumplimiento de las regulaciones
gubernamentales o del sector, como rgpd (reglamento general de protección de datos
de la Unión Europea) o CCPA (la Ley de privacidad del consumidor de California) y
asegurarse de que sus datos en Power BI se administran.
Cuando se configuran directivas DLP para Power BI:
La directiva evalúa todos los conjuntos de datos de las áreas de trabajo

especificadas en la directiva.
Puede detectar cuándo se cargan datos confidenciales en sus capacidades
Premium. Las directivas DLP pueden detectar:
Etiquetas de confidencialidad
Tipos de información confidencial. Se admiten más de 260 tipos. La detección
de tipos de información confidencial se basa en el análisis de contenido de
Microsoft Purview.
Al encontrar un conjunto de datos identificado como confidencial, puede ver una
sugerencia de directiva personalizada que le ayude a comprender lo que debe
hacer.
Si es propietario del conjunto de datos, puede invalidar una directiva e impedir
que el conjunto de datos se identifique como "confidencial" si tiene un motivo
válido para hacerlo.
Si es propietario del conjunto de datos, puede notificar un problema con una
directiva si concluye que se ha identificado un tipo de información confidencial de
forma falsa.
Se pueden invocar mitigaciones automáticas de riesgos, como alertas al
administrador de seguridad.
Para más información, consulte Directivas de prevención de pérdida de datos para

Power BI.
Microsoft Defender for Cloud Apps para Power

BI
Microsoft Defender for Cloud Apps es uno de los agentes de seguridad de acceso a la
nube líderes del mundo, denominados líderes en el cuadrante mágico de Gartner para
el mercado del agente de seguridad de acceso a la nube (CASB). Defender for Cloud
Apps se usa para proteger el uso de aplicaciones en la nube. Permite a las
organizaciones supervisar y controlar, en tiempo real, sesiones de Power BI arriesgadas,
como el acceso de usuarios desde dispositivos no administrados. Los administradores
de seguridad pueden definir directivas para controlar las acciones del usuario, como
descargar informes con información confidencial.
Con Defender for Cloud Apps, las organizaciones pueden obtener las siguientes
funcionalidades DLP:
Establezca controles en tiempo real para aplicar sesiones de usuario de riesgo en

Power BI. Por ejemplo, si un usuario se conecta a Power BI desde fuera de su país o
región, los controles en tiempo real de Defender for Cloud Apps pueden
supervisar la sesión y las acciones de riesgo, como descargar datos etiquetados
con una etiqueta de confidencialidad "Extremadamente confidencial", se pueden
bloquear inmediatamente.
Investigue la actividad del usuario de Power BI con el registro de actividad de
Defender for Cloud Apps. El registro de actividad de Defender for Cloud Apps
incluye la actividad de Power BI, como se captura en el registro de auditoría de
Office 365, que contiene información sobre todas las actividades de usuario y
administrador, así como información de etiquetas de confidencialidad para
actividades relevantes, como aplicar, cambiar y quitar etiqueta. Los
administradores pueden aprovechar los filtros avanzados de Defender for Cloud
Apps y las acciones rápidas para una investigación de problemas eficaz.
Cree directivas personalizadas para alertar sobre la actividad sospechosa del
usuario en Power BI. La característica de directiva de actividad de Defender for
Cloud Apps se puede aprovechar para definir sus propias reglas personalizadas,
para ayudarle a detectar el comportamiento del usuario que se desvía de la norma
e incluso posiblemente actuar sobre ella automáticamente, si parece demasiado
peligroso.
Trabaje con la detección de anomalías integrada de Defender for Cloud Apps. Las
directivas de detección de anomalías de Defender for Cloud Apps proporcionan
análisis de comportamiento de usuario listos para usar y aprendizaje automático
para que esté listo desde el principio para ejecutar la detección avanzada de
amenazas en el entorno en la nube. Cuando una directiva de detección de
anomalías identifica un comportamiento sospechoso, desencadena una alerta de
seguridad.
Rol de administrador de Power BI en el portal de Defender for Cloud Apps.
Defender for Cloud Apps proporciona un rol de administrador específico de la
aplicación que se puede usar para conceder a los administradores de Power BI solo
los permisos que necesitan para acceder a los datos pertinentes de Power BI en el
portal, como alertas, usuarios en riesgo, registros de actividad y otra información
relacionada con Power BI.
Consulte Uso de controles de Microsoft Defender for Cloud Apps en Power BI para
obtener más información.
Vista previa de las características de seguridad

En este tema se enumeran las características que se planean publicar hasta marzo de
2021. Dado que en este tema se enumeran las características que es posible que aún no
se hayan publicado, es posible que las escalas de tiempo de entrega cambien y que la
funcionalidad proyectada se publique más tarde de marzo de 2021 o que no se
publiquen en absoluto. Para obtener más información, sobre las versiones preliminares,
revise los Términos de Online Services .
Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics permite la integración entre Power BI y Azure Log
Analytics. Esta integración incluye el motor de análisis avanzado de Azure Log Analytics,
el lenguaje de consulta interactivo y las construcciones de aprendizaje automático
integradas.
Preguntas y respuestas de seguridad de Power

BI
Las preguntas siguientes son preguntas y respuestas comunes sobre seguridad para
Power BI. Estos se organizan en función de cuándo se agregaron a estas notas del
producto, para facilitar su capacidad de encontrar rápidamente nuevas preguntas y
respuestas cuando se actualice este documento. Las preguntas más recientes se han
agregado al final de esta lista.
¿Cómo se conectan los usuarios y obtienen acceso a los orígenes de datos mientras
usan Power BI?
Power BI administra las credenciales en los orígenes de datos de cada usuario para
las credenciales en la nube o para la conectividad a través de una puerta de enlace
personal. Los orígenes de datos administrados por una puerta de enlace de datos
local se pueden compartir entre la empresa y los permisos de estos orígenes de
datos se pueden administrar mediante el Administración de puerta de enlace. Al
configurar un conjunto de datos, el usuario puede seleccionar una credencial de su
almacén personal o usar una puerta de enlace de datos local para usar una
credencial compartida.
En el caso de importación, un usuario establece una conexión basada en el inicio

de sesión del usuario y accede a los datos con la credencial. Una vez publicado el
conjunto de datos en servicio Power BI, Power BI siempre usa la credencial de este
usuario para importar datos. Una vez importados los datos, ver los datos en los
informes y el panel no tiene acceso al origen de datos subyacente. Power BI
admite la autenticación de inicio de sesión único para orígenes de datos
seleccionados. Si la conexión está configurada para usar el inicio de sesión único,
la credencial del propietario del conjunto de datos se usa para conectarse con el
origen de datos.
En el caso de los informes conectados con DirectQuery, el origen de datos se

conecta directamente mediante una credencial preconfigurada, la credencial
preconfigurada se usa para conectarse al origen de datos cuando cualquier usuario
ve los datos. Si un origen de datos está conectado directamente mediante el inicio
de sesión único, la credencial del usuario actual se usa para conectarse al origen
de datos cuando el usuario ve los datos. Cuando se usa con el inicio de sesión
único, seguridad de nivel de fila (RLS) o seguridad de nivel de objeto (OLS) se
puede implementar en el origen de datos y esto permite a los usuarios ver los
datos a los que tienen privilegios de acceso. Cuando la conexión es a orígenes de
datos en la nube, se usa la autenticación de Azure AD para el inicio de sesión
único; para orígenes de datos locales, se admiten Kerberos, SAML y Azure AD.
Al conectarse con Kerberos, el UPN del usuario se pasa a la puerta de enlace y se

usa la delegación restringida de Kerberos, el usuario se suplanta y se conecta a los
orígenes de datos correspondientes. SAML también se admite en el origen de
datos gateway for SAP HANA. Puede encontrar más información en información
general sobre el inicio de sesión único para puertas de enlace.
Si el origen de datos está configurado Azure Analysis Services o la seguridad de

nivel de fila (RLS) local o seguridad de nivel de objeto (OLS), el servicio Power BI
aplicará esa seguridad de nivel de fila y los usuarios que no tengan credenciales
suficientes para acceder a los datos subyacentes (que podrían ser una consulta
usada en un panel, informe u otro artefacto de datos) no verán datos para los que
el usuario no tiene privilegios suficientes.
La seguridad de nivel de fila con Power BI se puede usar para restringir el acceso a
datos para los usuarios dados. Los filtros restringen el acceso a los datos en el
nivel de fila y puede definir filtros dentro del rol.
La seguridad de nivel de objeto (OLS) se puede usar para proteger las tablas o
columnas confidenciales. Sin embargo, a diferencia de la seguridad de nivel de fila,
la seguridad de nivel de objeto también protege los nombres de objeto y los
metadatos. Esto ayuda a evitar que los usuarios malintencionados detecten incluso
la existencia de estos objetos. Las tablas y columnas protegidas se ocultan en la
lista de campos cuando se usan herramientas de informes como Excel o Power BI,
y además, los usuarios sin permisos no pueden acceder a objetos de metadatos
protegidos a través de DAX o cualquier otro método. Desde el punto de vista de
los usuarios sin permisos de acceso adecuados, las tablas y columnas protegidas
simplemente no existen.
La seguridad de nivel de objeto, junto con la seguridad de nivel de fila, permite

mejorar la seguridad de nivel empresarial en informes y conjuntos de datos, lo que
garantiza que solo los usuarios con los permisos necesarios tengan acceso para ver
e interactuar con datos confidenciales.
¿Cómo se transfieren los datos a Power BI?

Todos los datos solicitados y transmitidos por Power BI se cifran en tránsito
mediante HTTPS (excepto cuando el origen de datos elegido por el cliente no
admite HTTPS) para conectarse desde el origen de datos al servicio Power BI. Se
establece una conexión segura con el proveedor de datos, y los datos se desplazan
por la red solo cuando se haya establecido esa conexión.
En Power BI, ¿cómo se almacena en caché un modelo, panel o informe? ¿Es seguro?
Cuando se accede a un origen de datos, el servicio Power BI sigue el proceso

descrito en la sección Autenticación a orígenes de datos anteriormente en este
documento.
¿Los clientes almacenan en caché los datos de la página web localmente?
Cuando los clientes de explorador acceden a Power BI, los servidores web de
Power BI establecen la directiva Cache-Control en no-store. La directiva no-store
indica a los exploradores que no almacenen en caché la página web que está
viendo el usuario, y que tampoco almacenen la página web en la carpeta de caché
del cliente.
¿Qué sucede con la seguridad basada en roles, el uso compartido de informes o

paneles, y las conexiones de datos? ¿Cómo funciona en términos de acceso a los
datos, visualización de paneles, acceso o actualización de informes?
Para los orígenes de datos habilitados que no admiten la seguridad de nivel de

rol (RLS), si un panel, informe o modelo de datos se comparte con otros usuarios a
través de Power BI, los datos estarán disponibles para verlos e interactuar con ellos
para los usuarios con los que se hayan compartido. Power BI no vuelve a autenticar
a los usuarios en el origen inicial de los datos; una vez que los datos se cargan en
Power BI, el usuario que se ha autenticado en el origen de datos es responsable de
administrar qué usuarios y grupos pueden ver los datos.
Cuando se realizan conexiones de datos a un origen de datos compatible con RLS,

como un origen de datos de Analysis Services, solo los datos del panel se
almacenan en caché en Power BI. Cada vez que se ve o se accede a un informe o
conjunto de datos en Power BI en el que se usan datos procedentes del origen de
datos compatible con RLS, el servicio Power BI accede al origen de datos para
obtener datos en función de las credenciales del usuario, y si existen permisos
suficientes, los datos se cargan en el modelo de datos o informe para ese usuario.
Si se produce un error de autenticación, el usuario verá un error.
Para obtener más información, consulte la sección Autenticación en orígenes de

datos anteriormente en este documento.
Nuestros usuarios se conectan continuamente a los mismos orígenes de datos, y
algunos requieren credenciales diferentes de sus credenciales de dominio. ¿Cómo
pueden evitar tener que escribir estas credenciales cada vez que realicen una
conexión de datos?
Power BI ofrece Power BI Personal Gateway, una característica que permite a los
usuarios crear credenciales para varios orígenes de datos diferentes y luego usarlas
de forma automática cuando accedan a cada uno de esos orígenes de datos. Para
más información, vea Power BI Personal Gateway.
¿Qué puertos se usan en la puerta de enlace de datos local y en la puerta de enlace

de datos (modo personal)? ¿Hay algún nombre de dominio que se deba permitir con
fines de conectividad?
La respuesta detallada a esta pregunta está disponible en el siguiente vínculo:

Puertos de puerta de enlace
Cuando se trabaja con la puerta de enlace de datos local, ¿cómo se usan las claves de
recuperación y dónde se almacenan? ¿Qué sucede con la administración segura de
credenciales?
Durante la instalación y configuración de puertas de enlace, el administrador

escribe una clave de recuperación de puerta de enlace. Esa clave de recuperación
se usa para generar una clave simétrica AES segura. También se crea una clave
asimétrica RSA al mismo tiempo.
Esas claves generadas (RSA y AES) se almacenan en un archivo que se encuentra

en el equipo local. Ese archivo también se cifra. El contenido del archivo solo lo
puede descifrar ese equipo Windows concreto, y solo mediante esa cuenta de
servicio de puerta de enlace concreta.
Cuando un usuario escribe las credenciales del origen de datos en la interfaz de

usuario del servicio Power BI, las credenciales se cifran con la clave pública en el
explorador. La puerta de enlace descifra las credenciales mediante la clave privada
RSA y las vuelve a cifrar con una clave simétrica AES antes de que los datos se
almacenen en el servicio Power BI. Con este proceso, el servicio Power BI nunca
tiene acceso a los datos sin cifrar.
¿Qué protocolos de comunicación usa la puerta de enlace de datos local y cómo se

protegen?
La puerta de enlace admite los dos siguientes protocolos de comunicaciones:

AMQP 1.0 : TCP + TLS: este protocolo requiere que los puertos 443, 5671-5672
y 9350-9354 estén abiertos para la comunicación saliente. Es el protocolo
preferido, porque tiene una menor sobrecarga de comunicación.
HTTPS: WebSockets a través de HTTPS + TLS: este protocolo solo usa el puerto
443. WebSocket se inicia con un único mensaje HTTP CONNECT. Una vez que se
ha establecido el canal, la comunicación es esencialmente TCP+TLS. Puede
forzar que la puerta de enlace use este protocolo modificando una
configuración descrita en el artículo puerta de enlace local.
¿Cuál es el rol de Azure CDN en Power BI?
Como se ha mencionado antes, Power BI usa Azure Content Delivery Network

(CDN) para distribuir de forma eficaz el contenido estático y los archivos
necesarios a los usuarios en función de la configuración regional geográfica. Para
entrar en más detalle, el servicio Power BI usa varias CDN para distribuir de forma
eficaz el contenido estático y los archivos necesarios a los usuarios a través de la
red Internet pública. Estos archivos estáticos incluyen descargas de productos
(como Power BI Desktop, la puerta de enlace de datos local o aplicaciones de
Power BI de distintos proveedores de servicios independientes), archivos de
configuración del explorador que se usan para iniciar y establecer las sucesivas
conexiones con Power BI, así como la página de inicio de sesión seguro inicial de
Power BI.
En función de la información proporcionada durante la conexión inicial al servicio

Power BI, el explorador del usuario contacta con la instancia de Azure CDN
especificada (o para algunos archivos, el WFE) para descargar la colección de
archivos comunes especificados que se necesitan para habilitar la interacción del
explorador con el servicio Power BI. A continuación, la página del explorador
incluye el token de Azure AD, la información de sesión, la ubicación del clúster
back-end asociado y la colección de archivos descargados del clúster de Azure
CDN y WFE, durante la sesión del explorador de servicio Power BI.
En el caso de los objetos visuales de Power BI, ¿Microsoft realiza alguna evaluación de
seguridad o privacidad del código visual personalizado antes de publicar elementos
en la Galería?
No. Es responsabilidad del cliente revisar y determinar si se debe confiar en el

código del objeto visual personalizado. El código de todos los objetos visuales
personalizados funciona en un entorno de espacio aislado, por lo que cualquier
código incorrecto en un objeto visual personalizado no afecta de forma negativa al
resto del servicio Power BI.
¿Hay otros objetos visuales de Power BI que envían información fuera de la red del
cliente?
Sí. Los objetos visuales Bing Maps y ESRI transmiten datos fuera del servicio Power
BI para los objetos visuales que usan esos servicios.
En el caso de las aplicaciones de plantilla, ¿Microsoft realiza alguna evaluación de

seguridad o privacidad de la aplicación de plantilla antes de publicar elementos en la
Galería?
No. El publicador de la aplicación es responsable del contenido mientras es

responsabilidad del cliente revisar y determinar si debe confiar en el publicador de
la aplicación de plantilla.
¿Hay aplicaciones de plantilla que puedan enviar información fuera de la red del
cliente?
Sí. Es responsabilidad del cliente revisar la directiva de privacidad del publicador y

determinar si se debe instalar la aplicación de plantilla en el inquilino. El publicador
es responsable de informar al cliente sobre el comportamiento y las
funcionalidades de la aplicación.
¿Qué sucede con la soberanía de los datos? ¿Se pueden aprovisionar inquilinos en
centros de datos ubicados en zonas geográficas específicas para asegurarse de que
los datos no salen de los bordes de país o región?
Algunos clientes de zonas geográficas concretas tienen la opción de crear un

inquilino en una nube nacional, donde el almacenamiento y el procesamiento de
datos son independientes de otros centros de datos. Las nubes nacionales tienen
un tipo de seguridad ligeramente diferente, puesto que un administrador de datos
independiente controla el servicio Power BI de la nube nacional en nombre de
Microsoft.
Como alternativa, los clientes también pueden configurar un inquilino en una

región específica. Sin embargo, estos inquilinos no tienen un administrador de
datos independiente de Microsoft. Los precios de las nubes nacionales son
diferentes del servicio Power BI comercial disponible con carácter general. Para
obtener más información sobre la disponibilidad del servicio Power BI para nubes
nacionales, vea Nubes nacionales de Power BI .
¿Cómo trata Microsoft las conexiones para los clientes que tienen suscripciones de
Power BI Premium? ¿Esas conexiones son diferentes a las que se establecen para el
servicio Power BI que no es Premium?
Las conexiones establecidas para los clientes con suscripciones de Power BI
Premium implementan un proceso de autorización de negocio a negocio (B2B) de
Azure, mediante Azure AD para habilitar el control de acceso y la autorización.
Power BI controla las conexiones de los suscriptores de Power BI Premium a los
recursos de Power BI Premium como haría con cualquier otro usuario de Azure AD.
¿Cómo funciona la autenticación del lado servidor en WFE?
La autenticación del lado del servicio de secuencia de autenticación de usuario se

produce como se describe en los pasos siguientes, que se muestran en la imagen
que los sigue.
1. Un usuario inicia una conexión a la servicio Power BI desde un explorador, ya sea

escribiendo la dirección de Power BI en la barra de direcciones o seleccionando
Iniciar sesión en la página de marketing de Power BI
(https://powerbi.microsoft.com ). La conexión se establece mediante TLS 1.2 y
HTTPS, y toda la comunicación posterior entre el explorador y el servicio Power BI
usa HTTPS.
2. Azure Traffic Manager comprueba el registro DNS del usuario para determinar el
centro de datos más adecuado (normalmente más cercano) donde se implementa
Power BI y responde al DNS con la dirección IP del clúster wfe al que se debe
enviar el usuario.
3. Después, WFE redirige al usuario a la página de inicio de sesión de Microsoft

Online Services.
4. Una vez autenticado el usuario, la página de inicio de sesión redirige al usuario a la

servicio Power BI clúster WFE más cercano determinado previamente con un
código de autenticación.
5. El clúster WFE comprueba con el servicio Azure AD para obtener un token de

seguridad de Azure AD mediante el código de autenticación. Cuando Azure AD
devuelve la autenticación correcta del usuario y devuelve un token de seguridad
de Azure AD, el clúster WFE consulta el servicio global de Power BI, que mantiene
una lista de inquilinos y sus ubicaciones de clúster back-end de Power BI y
determina qué clúster del servicio back-end de Power BI contiene el inquilino del
usuario. A continuación, el clúster WFE devuelve una página de aplicación al
explorador del usuario con la información de sesión, acceso y enrutamiento
necesaria para su operación.
6. Ahora, cuando el explorador del cliente requiera datos de cliente, enviará

solicitudes a la dirección del clúster back-end con el token de acceso de Azure AD
en el encabezado Autorización. El clúster de back-end de Power BI lee el token de
acceso de Azure AD y valida la firma para asegurarse de que la identidad de la
solicitud es válida. El token de acceso de Azure AD tendrá una fecha de expiración
establecida según las directivas de Azure AD y, para mantener la sesión actual, el
cliente de Power BI en el explorador del usuario realizará solicitudes periódicas
para renovar el token de acceso antes de que expire.
Recursos adicionales
Para obtener más información sobre Power BI, vea los recursos siguientes.
Introducción a Power BI Desktop

Información general sobre la API REST de Power BI
Referencia de la API de Power BI
Puerta de enlace de datos local
Nubes nacionales de Power BI
Power BI Premium
Introducción al inicio de sesión único (SSO) para puertas de enlace de Power BI
Notas del producto sobre la
implementación de Power BI Enterprise
La implementación Power BI en una gran empresa es una tarea compleja que requiere
mucha reflexión y planeamiento. Obtener instrucciones y procedimientos
recomendados adecuados puede ayudarle a comprender las opciones que va a tomar,
recopilar los requisitos y aprender los procedimientos recomendados que pueden hacer
que la implementación de Power BI enterprise sea un éxito. Para facilitar esos pasos y
mucho más, Microsoft proporciona las Power BI Enterprise de implementación.
Acerca de las whitepaper

El propósito de las Enterprise Deployment es ayudar a que la implementación de Power
BI se realice correctamente: trata las consideraciones clave, las decisiones que serán
necesarias a lo largo del proceso y los posibles problemas que pueda encontrar. Se
ofrecen procedimientos recomendados y sugerencias siempre que sea posible.
El público objetivo de estas whitepaper son los profesionales de la tecnología. Se

asumen algunos conocimientos Power BI conceptos business intelligence generales.
Puede descargar las whitepaper de implementación empresarial completa en el

vínculo siguiente:
Planeamiento de una Power BI Enterprise de implementación de aplicaciones
Pasos siguientes
Para más información sobre Power BI, consulte los siguientes recursos:
Notas del producto de Power BI

Notas del producto sobre la seguridad de Power BI
Power BI Premium
Implementación y administración de las
capacidades de Power BI Premium
Hemos retirado las notas del producto Power BI Premium en favor de proporcionar
información actualizada en artículos independientes. Use la tabla siguiente para buscar
contenido de las notas del producto.
Artículos Descripción
Conceptos básicos para Información general sobre servicio Power BI capacidades, áreas de
los diseñadores de los trabajo, paneles, informes, libros, conjuntos de datos y flujos de
servicio Power BI datos.
Datasets en los modos
servicio Power BI
Dataset del servicio
Power BI
¿Qué es Power BI Información general de Power BI Premium, que abarca los conceptos
Premium? básicos de las capacidades reservadas, las cargas de trabajo
admitidas, el uso compartido de contenido ilimitado y otras
características.
Administración de
capacidades
Premium Configuración y
administración de
capacidades en Power BI
Premium
Información detallada sobre cómo configurar y administrar

Configuración de cargas capacidades y cargas de trabajo.
de trabajo en una
capacidad Premium
Uso de la aplicación de Supervisión con Power BI Premium Capacity Metrics aplicación e

métricas Premium interpretación de las métricas que ve en la aplicación.
Preguntas más frecuentes Respuestas a preguntas sobre la compra y las licencias, las
sobre Power BI Premium características y los escenarios comunes.
Distribución del contenido de Power BI
a usuarios invitados externos mediante
Azure Active Directory B2B
Resumen: Se trata de una guía técnica que describe cómo distribuir contenido a los
usuarios fuera de la organización mediante la integración de Azure Active Directory
Business-to-business (Azure AD B2B).
Escritores: Lukasz Pawlowski, Kasper de Jonge
Revisores técnicos: Adam Wilson, Shenhav, Nimrod Shalit, Elizabeth Olson, Sergio
Gundorov, Jacob Grimm, Adam Saxton, Maya Shenhav, Nimrod Shalit, Elizabeth Olson
７ Nota
Para guardar o imprimir estas notas del producto, haga clic en Imprimir en el
explorador y después en Guardar como PDF.
Introducción
Power BI ofrece a las organizaciones una visión de 360 grados de su negocio y permite a
todos los usuarios de estas organizaciones tomar decisiones inteligentes mediante
datos. Muchas de estas organizaciones tienen relaciones sólidas y de confianza con
asociados externos, clientes y contratistas. Estas organizaciones deben proporcionar
acceso seguro a los paneles e informes de Power BI a los usuarios de estos asociados
externos.
Power BI se integra con Azure Active Directory Business-to-business (Azure AD B2B)

para permitir la distribución segura del contenido de Power BI a los usuarios invitados
fuera de la organización, a la vez que mantiene el control y el control del acceso a los
datos internos.
En estas notas del producto se describen todos los detalles que necesita para
comprender la integración de Power BI con Azure Active Directory B2B. Tratamos su
caso de uso más común, la configuración, las licencias y la seguridad de nivel de fila.
７ Nota
A lo largo de estas notas del producto, nos referimos a Azure Active Directory
como Azure AD y Azure Active Directory Business to Business como Azure AD B2B.
Escenarios
Contoso es un fabricante de automóviles y trabaja con muchos proveedores diversos
que lo proporcionan con todos los componentes, materiales y servicios necesarios para
ejecutar sus operaciones de fabricación. Contoso quiere simplificar su logística de la
cadena de suministro y planea usar Power BI para supervisar las métricas clave de
rendimiento de su cadena de suministro. Contoso quiere compartir con asociados
externos de la cadena de suministro análisis de forma segura y manejable.
Contoso puede habilitar las siguientes experiencias para los usuarios externos mediante
Power BI y Azure AD B2B.
Uso compartido ad hoc por elemento

Contoso trabaja con un proveedor que construye radiadores para automóviles de
Contoso. A menudo, necesitan optimizar la confiabilidad de los radiadores mediante
datos de todos los coches de Contoso. Un analista de Contoso usa Power BI para
compartir un informe de confiabilidad del radiador con un ingeniero en el proveedor. El
ingeniero recibe un correo electrónico con un vínculo para ver el informe.
Como se ha descrito anteriormente, los usuarios empresariales realizan este uso

compartido ad hoc según sea necesario. El vínculo enviado por Power BI al usuario
externo es un vínculo de invitación de Azure AD B2B. Cuando el usuario externo abre el
vínculo, se les pide que se unan a la organización de Azure AD de Contoso como
usuario invitado. Una vez aceptada la invitación, el vínculo abre el informe o panel
específicos. El administrador de Azure Active Directory delega el permiso para invitar a
usuarios externos a la organización y elige lo que esos usuarios pueden hacer una vez
que acepten la invitación, tal como se describe en la sección Gobernanza de este
documento. El analista de Contoso solo puede invitar al usuario invitado porque el
administrador de Azure AD permitió esa acción y el administrador de Power BI permitía
a los usuarios invitar a los invitados a ver el contenido en la configuración del inquilino
de Power BI.
1. El proceso comienza con un usuario interno de Contoso que comparte un panel o
un informe con un usuario externo. Si el usuario externo aún no es invitado en
Azure AD de Contoso, se les invita. Se envía un correo electrónico a su dirección de
correo electrónico que incluye una invitación a Azure AD de Contoso.
2. El destinatario acepta la invitación a Azure AD de Contoso y se agrega como
usuario invitado en Azure AD de Contoso.
3. A continuación, el destinatario se redirige al panel, informe o aplicación de Power
BI, que son de solo lectura para el usuario.
El proceso se considera ad hoc, ya que los usuarios empresariales de Contoso realizan la

acción de invitación según sea necesario para sus fines empresariales. Cada elemento
compartido es un único vínculo al que el usuario externo puede acceder para ver el
contenido.
Una vez que se ha invitado al usuario externo a acceder a los recursos de Contoso, se
puede crear una cuenta instantánea para ellos en Contoso Azure AD y no es necesario
volver a invitarla. La primera vez que intentan acceder a un recurso de Contoso como un
panel de Power BI, pasan por un proceso de consentimiento, que canjea la invitación. Si
no completan el consentimiento, no podrán acceder a ningún contenido de Contoso. Si
tienen problemas para canjear su invitación a través del vínculo original proporcionado,
un administrador de Azure AD puede reenviar un vínculo de invitación específico para
que los canjeen.
Uso compartido planeado por elemento

Contoso trabaja con un subcontratista para realizar análisis de confiabilidad de
radiadores. El subcontratista tiene un equipo de 10 personas que necesitan acceso a los
datos en el entorno de Power BI de Contoso. El administrador de Azure AD de Contoso
está implicado para invitar a todos los usuarios y controlar las adiciones o cambios
como personal en el cambio del subcontratista. El administrador de Azure AD crea un
grupo de seguridad para todos los empleados del subcontratista. Con el grupo de
seguridad, los empleados de Contoso pueden administrar fácilmente el acceso a los
informes y garantizar que todo el personal subcontratista necesario tenga acceso a
todos los informes, paneles y aplicaciones de Power BI necesarios. El administrador de
Azure AD también puede evitar participar en el proceso de invitación por completo si
elige delegar derechos de invitación a un empleado de confianza en Contoso o en el
subcontratista para garantizar la administración oportuna del personal.
Algunas organizaciones requieren más control sobre cuándo se agregan usuarios

externos, invitan a muchos usuarios de una organización externa o a muchas
organizaciones externas. En estos casos, el uso compartido planeado se puede usar para
administrar la escala de uso compartido, para aplicar directivas organizativas e incluso
delegar derechos a usuarios de confianza para invitar y administrar usuarios externos.
Azure AD B2B admite invitaciones planeadas que un administrador de TI envía
directamente desde el Azure Portal, o a través de PowerShell mediante la API del
administrador de invitaciones donde se puede invitar a un conjunto de usuarios en una
acción. Con el enfoque de invitaciones planeadas, la organización puede controlar quién
puede invitar a los usuarios e implementar procesos de aprobación. Las funcionalidades
avanzadas de Azure AD, como los grupos dinámicos, pueden facilitar el mantenimiento
automático de la pertenencia a grupos de seguridad.
1. El proceso comienza con un administrador de TI que invita al usuario invitado

manualmente o a través de la API proporcionada por Azure Active Directory.
2. El usuario acepta la invitación a la organización.
3. Una vez que el usuario haya aceptado la invitación, un usuario de Power BI puede
compartir un informe o panel con el usuario externo o un grupo de seguridad en
el que se encuentran. Al igual que con el uso compartido normal en Power BI, el
usuario externo recibe un correo electrónico con el vínculo al elemento.
4. Cuando el usuario externo accede al vínculo, su autenticación en su directorio se
pasa a Azure AD de Contoso y se usa para obtener acceso al contenido de Power
BI.
Uso compartido ad hoc o planeado de aplicaciones de

Power BI
Contoso tiene un conjunto de informes y paneles que deben compartir con uno o varios
proveedores. Para asegurarse de que todos los usuarios externos necesarios tienen
acceso a este contenido, se empaqueta como una aplicación de Power BI. Los usuarios
externos se agregan directamente a la lista de acceso a la aplicación o a través de
grupos de seguridad. A continuación, alguien de Contoso envía la dirección URL de la
aplicación a todos los usuarios externos, por ejemplo, en un correo electrónico. Cuando
los usuarios externos abren el vínculo, ven todo el contenido en una sola experiencia
fácil de navegar.
El uso de una aplicación de Power BI facilita a Contoso la compilación de un portal de BI

para sus proveedores. Una única lista de acceso controla el acceso a todo el contenido
necesario, lo que reduce la comprobación de tiempo y la configuración de permisos de
nivel de elemento. Azure AD B2B mantiene el acceso de seguridad mediante la
identidad nativa del proveedor para que los usuarios no necesiten credenciales de inicio
de sesión adicionales. Si usa invitaciones planeadas con grupos de seguridad, se
simplifica la administración de acceso a la aplicación a medida que el personal gira hacia
o fuera del proyecto. Pertenencia a grupos de seguridad manualmente o mediante
grupos dinámicos, de modo que todos los usuarios externos de un proveedor se
agreguen automáticamente al grupo de seguridad adecuado.
1. El proceso se inicia mediante la invitación del usuario a la organización de Azure
AD de Contoso a través de la Azure Portal o PowerShell.
2. El usuario se puede agregar a un grupo de usuarios en Azure AD. Se puede usar un
grupo de usuarios estático o dinámico, pero los grupos dinámicos ayudan a
reducir el trabajo manual.
3. A los usuarios externos se les concede acceso a la aplicación de Power BI a través
del grupo de usuarios. La dirección URL de la aplicación se debe enviar
directamente al usuario externo o colocarla en un sitio al que tienen acceso. Power
BI hace un mejor esfuerzo para enviar un correo electrónico con el vínculo de la
aplicación a usuarios externos, pero cuando se usan grupos de usuarios cuya
pertenencia puede cambiar, Power BI no puede enviar a todos los usuarios
externos administrados a través de grupos de usuarios.
4. Cuando el usuario externo accede a la dirección URL de la aplicación de Power BI,
se autentica mediante Azure AD de Contoso, la aplicación se instala para el usuario
y el usuario puede ver todos los informes y paneles contenidos dentro de la
aplicación.
Las aplicaciones también tienen una característica única que permite a los autores de
aplicaciones instalar la aplicación automáticamente para el usuario, por lo que está
disponible cuando el usuario inicia sesión. Esta característica solo se instala
automáticamente para los usuarios externos que ya forman parte de la organización de
Contoso en el momento en que la aplicación se publica o actualiza. Por lo tanto, se usa
mejor con el enfoque de invitaciones planeadas y depende de la aplicación que se
publique o actualice después de que los usuarios se agreguen a Azure AD de Contoso.
Los usuarios externos siempre pueden instalar la aplicación mediante el vínculo de la
aplicación.
Comentarios y suscripción al contenido entre

organizaciones
A medida que Contoso sigue trabajando con sus subcontratistas o proveedores, los
ingenieros externos deben trabajar estrechamente con los analistas de Contoso. Power
BI proporciona varias características de colaboración que ayudan a los usuarios a
comunicarse sobre el contenido que pueden consumir. Los comentarios del panel (y
pronto comentarios de informes) permiten a los usuarios analizar los puntos de datos
que ven y se comunican con los autores de informes para formular preguntas.
Actualmente, los usuarios invitados externos pueden participar en comentarios dejando

comentarios y leyendo las respuestas. Sin embargo, a diferencia de los usuarios
internos, los usuarios invitados no pueden ser @mentioned y no reciben notificaciones
que han recibido un comentario. En una próxima versión, esas restricciones se
levantarán y el usuario invitado recibirá un correo electrónico cuando un comentario les
haga un comentario @mentions . Los usuarios invitados pueden usar la característica de
suscripciones de Power BI para suscribirse a un informe o panel. Obtenga más
información en Email suscripciones para informes y paneles en el servicio Power BI.
Acceso al contenido en las aplicaciones móviles de Power

BI
En una próxima versión, cuando los usuarios de Contoso compartan informes o paneles
con sus homólogos invitados externos, Power BI enviará un correo electrónico que
notifique al invitado. Cuando el usuario invitado abra el vínculo al informe o panel en su
dispositivo móvil, el contenido se abrirá en las aplicaciones móviles nativas de Power BI
en su dispositivo, si están instalados. A continuación, el usuario invitado podrá navegar
entre el contenido compartido con ellos en el inquilino externo y volver a su propio
contenido desde su inquilino principal.
７ Nota
El usuario invitado no puede abrir la aplicación móvil de Power BI y navegar

inmediatamente al inquilino externo, debe empezar con un vínculo a un elemento
del inquilino externo. Las soluciones alternativas comunes se describen en la
sección Distribución de vínculos a contenido en la sección Power BI de la
organización primaria más adelante en este documento.
Edición y administración entre organizaciones del

contenido de Power BI
Contoso y sus proveedores y subcontratistas trabajan cada vez más estrechamente
juntos. A menudo, un analista del subcontratista necesita que se agreguen métricas o
visualizaciones de datos adicionales a un informe que Contoso ha compartido con ellos.
Los datos deben residir en el inquilino de Power BI de Contoso, pero los usuarios
externos deben poder editarlos, crear nuevo contenido e incluso distribuirlos a los
usuarios adecuados.
Power BI proporciona una opción que permite a los usuarios invitados externos editar
y administrar contenido en la organización. De manera predeterminada, los usuarios
externos tienen una experiencia orientada al consumo de solo lectura. Sin embargo, esta
configuración nueva permite al administrador de Power BI elegir los usuarios externos
que pueden editar y administrar el contenido dentro de su propia organización. Una vez
que tiene la autorización, el usuario externo puede editar informes, paneles, publicar o
actualizar aplicaciones, trabajar en áreas de trabajo y conectarse a los datos que tiene
permiso para usar.
Este escenario se describe en detalle en la sección Habilitación de usuarios externos

para editar y administrar contenido en Power BI más adelante en este documento.
Relaciones organizativas mediante Power BI y

Azure AD B2B
Cuando todos los usuarios de Power BI son internos de la organización, no es necesario
usar Azure AD B2B. Sin embargo, una vez que dos o más organizaciones desean
colaborar en datos e información, la compatibilidad de Power BI con Azure AD B2B
facilita y rentable hacerlo.
A continuación se suelen encontrar estructuras organizativas adecuadas para la

colaboración entre organizaciones de estilo B2B de Azure AD en Power BI. Azure AD B2B
funciona bien en la mayoría de los casos, pero en algunas situaciones los enfoques
alternativos comunes tratados al final de este documento merecen la pena tener en
cuenta.
Caso 1: Colaboración directa entre organizaciones

La relación de Contoso con su proveedor de radiadores es un ejemplo de colaboración
directa entre organizaciones. Dado que hay relativamente pocos usuarios en Contoso y
su proveedor que necesitan acceso a la información de confiabilidad del radiador, el uso
compartido externo basado en Azure AD B2B es ideal. Es fácil de usar y fácil de
administrar. También es un patrón común en los servicios de consultoría en los que es
posible que un consultor necesite crear contenido para una organización.
Normalmente, este uso compartido se produce inicialmente mediante el uso

compartido ad hoc por elemento. Sin embargo, a medida que los equipos crecen o se
profundizan las relaciones, el enfoque planeado por uso compartido de elementos se
convierte en el método preferido para reducir la sobrecarga de administración. Además,
el uso compartido ad hoc o planeado de aplicaciones de Power BI, comentarios y
suscripción al contenido entre organizaciones, el acceso al contenido de las aplicaciones
móviles también puede entrar en juego, y la edición y administración entre
organizaciones del contenido de Power BI. Importantemente, si los usuarios de ambas
organizaciones tienen licencias de Power BI Pro en sus respectivas organizaciones,
pueden usar esas licencias Pro en los entornos de Power BI entre sí. Esto proporciona
licencias ventajosas, ya que es posible que la organización que invita no tenga que
pagar una licencia de Power BI Pro para los usuarios externos. Esto se describe con más
detalle en la sección Licencias más adelante en este documento.
Caso 2: Matriz y sus subsidiarias o filiales

Algunas estructuras de la organización son más complejas, incluidas las subsidiarias de
propiedad parcial o total, las empresas afiliadas o las relaciones de proveedores de
servicios administrados. Estas organizaciones tienen una organización primaria, como
una empresa de retención, pero las organizaciones subyacentes operan de forma
semiautonómica, a veces bajo requisitos regionales diferentes. Esto conduce a que cada
organización tenga su propio entorno de Azure AD y a inquilinos de Power BI
independientes.
En esta estructura, la organización primaria normalmente necesita distribuir información

estandarizada a sus subsidiarias. Normalmente, este uso compartido se produce
mediante el enfoque Ad hoc o planeado de aplicaciones de Power BI, como se muestra
en la imagen siguiente, ya que permite la distribución de contenido autoritativo
estandarizado a audiencias amplias. En la práctica se usa una combinación de todos los
escenarios mencionados anteriormente en este documento.
Esto sigue el siguiente proceso:
1. Se invita a los usuarios de cada filial a Azure AD de Contoso.

2. A continuación, se publica la aplicación power BI para conceder a estos usuarios
acceso a los datos necesarios.
3. Por último, los usuarios abren la aplicación a través de un vínculo que se les ha
dado para ver los informes.
En esta estructura se enfrentan varios desafíos importantes:
Cómo distribuir vínculos a contenido en Power BI de la organización primaria

Cómo permitir que los usuarios subsidiarios accedan al origen de datos
hospedado por la organización primaria
Distribución de vínculos a contenido en Power BI de la

organización primaria
Normalmente se usan tres enfoques para distribuir vínculos al contenido. La primera y la

más básica es enviar el vínculo a la aplicación a los usuarios necesarios o colocarlo en un
sitio de SharePoint Online desde el que se puede abrir. A continuación, los usuarios
pueden marcar el vínculo en sus exploradores para obtener acceso más rápido a los
datos que necesitan.
El segundo enfoque se basa en la edición y administración entre organizaciones de la

funcionalidad de contenido de Power BI. La organización primaria permite a los usuarios
de las subsidiarias acceder a sus Power BI y controla lo que pueden acceder a través del
permiso. Esto proporciona acceso a Inicio de Power BI donde el usuario de la filial ve
una lista completa de contenido compartido en el inquilino de la organización primaria.
A continuación, se asigna la dirección URL al entorno de Power BI de las organizaciones
primarias a los usuarios de las subsidiarias.
El enfoque final usa una aplicación de Power BI creada dentro del inquilino de Power BI
para cada filial. La aplicación Power BI incluye un panel con iconos configurados con la
opción de vínculo externo. Cuando el usuario presiona el icono, se le lleva al informe, el
panel o la aplicación adecuados en Power BI de la organización primaria. Este enfoque
tiene la ventaja adicional de que la aplicación se puede instalar automáticamente para
todos los usuarios de la filial y está disponible para ellos siempre que inicien sesión en
su propio entorno de Power BI. Una ventaja adicional de este enfoque es que funciona
bien con las aplicaciones móviles de Power BI que pueden abrir el vínculo de forma
nativa. También puede combinar esto con el segundo enfoque para facilitar el cambio
entre entornos de Power BI.
Permitir que los usuarios subsidiarios accedan a orígenes de datos

hospedados por la organización primaria
A menudo, los analistas de una filial necesitan crear su propio análisis mediante los
datos proporcionados por la organización primaria. En este caso, normalmente se usan
orígenes de datos en la nube para abordar el desafío.
El primer enfoque aprovecha Azure Analysis Services para crear un almacenamiento de

datos de nivel empresarial que sirva a las necesidades de los analistas en el primario y
sus subsidiarias, como se muestra en la imagen siguiente. Contoso puede hospedar los
datos y usar funcionalidades como la seguridad de nivel de fila para asegurarse de que
los usuarios de cada filial solo pueden acceder a sus datos. Los analistas de cada
organización pueden acceder al almacenamiento de datos a través de Power BI Desktop
y publicar análisis resultantes en sus respectivos inquilinos de Power BI.
El segundo enfoque aprovecha Azure SQL Database para crear un almacenamiento de
datos relacional para proporcionar acceso a los datos. Esto funciona de forma similar al
enfoque de Azure Analysis Services, aunque algunas funcionalidades como la seguridad
de nivel de fila pueden ser más difíciles de implementar y mantener entre subsidiarias.
Los enfoques más sofisticados también son posibles, pero lo anterior es, con mucho, el
más común.
Caso 3: Entorno compartido entre asociados

Contoso puede participar en una asociación con un competidor para construir
conjuntamente un automóvil en una línea de montaje compartida, pero para distribuir el
vehículo bajo diferentes marcas o en regiones diferentes. Esto requiere una amplia
colaboración y copropiedad de datos, inteligencia y análisis en todas las organizaciones.
Esta estructura también es común en el sector de servicios de consultoría donde un
equipo de consultores puede realizar análisis basados en proyectos para un cliente.
En la práctica, estas estructuras son complejas, como se muestra en la imagen siguiente,

y requieren que el personal mantenga. Para ser eficaz, esta estructura se basa en la
edición y administración entre organizaciones de la funcionalidad de contenido de
Power BI, ya que permite a las organizaciones reutilizar Power BI Pro licencias adquiridas
para sus respectivos inquilinos de Power BI.
Para establecer un inquilino de Power BI compartido, es necesario crear una instancia de

Azure Active Directory y, al menos, una cuenta de usuario de Power BI Pro debe
adquirirse para un usuario de esa instancia de Active Directory. Este usuario invita a los
usuarios necesarios a la organización compartida. Lo importante es que, en este
escenario, los usuarios de Contoso se tratan como usuarios externos cuando operan
dentro de Power BI de la organización compartida.
El proceso es el siguiente:
1. La organización compartida se establece como una nueva instancia de Azure

Active Directory y se crea al menos una cuenta de usuario en la nueva
organización. Ese usuario debe tener asignada una licencia de Power BI Pro.
2. A continuación, este usuario establece un inquilino de Power BI e invita a los
usuarios necesarios de Contoso y a la organización partner. El usuario también
establece los recursos de datos compartidos, como Azure Analysis Services.
Contoso y los usuarios del partner pueden acceder a Power BI de la organización
compartida como usuarios invitados. Si se permite editar y administrar contenido
en Power BI, los usuarios externos pueden usar la página principal de Power BI,
usar áreas de trabajo, cargar o editar contenido y compartir informes.
Normalmente, todos los recursos compartidos se almacenan y se accede a ellos
desde la organización compartida.
3. En función de cómo las partes acepten colaborar, es posible que cada organización
desarrolle sus propios datos y análisis propietarios mediante recursos de
almacenamiento de datos compartidos. Pueden distribuirlos a sus respectivos
usuarios internos mediante sus inquilinos internos de Power BI.
Caso 4: Distribución a cientos o miles de asociados

externos
Aunque Contoso creó un informe de confiabilidad del radiador para un proveedor,
ahora Contoso desea crear un conjunto de informes estandarizados para cientos de
proveedores. Esto permite a Contoso asegurarse de que todos los proveedores tienen el
análisis que necesitan para realizar mejoras o corregir defectos de fabricación.
Cuando una organización necesita distribuir datos estandarizados e información a

muchos usuarios o organizaciones externos, puede usar el escenario Ad hoc o planeado
de Aplicaciones de Power BI para crear un portal de BI rápidamente y sin costos de
desarrollo extensos. El proceso para compilar este portal mediante una aplicación de
Power BI se trata en el caso práctico: Creación de un portal de BI mediante Power BI +
Azure AD B2B: instrucciones paso a paso más adelante en este documento.
Una variante común de este caso es cuando una organización intenta compartir
información con los consumidores, especialmente cuando se busca usar Azure B2C con
Power BI. Power BI no admite de forma nativa Azure B2C. Si va a evaluar las opciones de
este caso, considere la posibilidad de usar la opción 2 alternativa en la sección Enfoques
alternativos comunes que encontrará más adelante en este documento.
Caso práctico: Creación de un portal de BI

mediante Power BI + Azure AD B2B:
instrucciones paso a paso
La integración de Power BI con Azure AD B2B proporciona a Contoso una forma sin
problemas y sin problemas para proporcionar a los usuarios invitados acceso seguro a
su portal de BI. Contoso puede configurarlo con tres pasos:
1. Crear portal de BI en Power BI
La primera tarea de Contoso es crear su portal de BI en Power BI. El portal de BI de

Contoso constará de una colección de paneles e informes creados específicamente
que estarán disponibles para muchos usuarios internos e invitados. La manera
recomendada de hacerlo en Power BI es compilar una aplicación de Power BI.
Obtenga más información sobre las aplicaciones en Power BI .
El equipo de BI de Contoso crea un área de trabajo en Power BI

Otros autores se agregan al área de trabajo.
El contenido se crea dentro del área de trabajo.
Ahora que el contenido se crea en un área de trabajo, Contoso está listo para
invitar a los usuarios invitados de las organizaciones asociadas a consumir este
contenido.
2. Invitar a usuarios externos
Hay dos maneras de que Contoso invite a los usuarios invitados a su portal de BI
en Power BI:
Invitaciones planeadas
Invitaciones ad hoc
Invitaciones planeadas
En este enfoque, Contoso invita a los usuarios invitados a su instancia de Azure AD

con antelación y, a continuación, distribuye contenido de Power BI a ellos. Contoso
puede invitar a usuarios invitados desde el Azure Portal o mediante PowerShell.
Estos son los pasos para invitar a los usuarios invitados desde el Azure Portal:
El administrador de Azure AD de Contoso navega a Azure Portal>Azure

Active DirectoryUsers All usersNew guest user (Usuarios> de Azure Active
Directory >Todos los usuarios nuevos usuarios>)
Agregue un mensaje de invitación para los usuarios invitados y haga clic en
Invitar.
７ Nota
Para invitar a usuarios invitados desde el Azure Portal, debe tener un

administrador para Azure Active Directory del inquilino.
Si Contoso quiere invitar a muchos usuarios invitados, puede hacerlo mediante

PowerShell. El administrador de Azure AD de Contoso almacena las direcciones de
correo electrónico de todos los usuarios invitados en un archivo CSV. Estos son el
código de colaboración B2B de Azure Active Directory y ejemplos e instrucciones
de PowerShell.
Después de la invitación, los usuarios invitados reciben un correo electrónico con

el vínculo de invitación.
Una vez que los usuarios invitados hacen clic en el vínculo, pueden acceder al
contenido en el inquilino de Azure AD de Contoso.
７ Nota
Es posible cambiar el diseño del correo electrónico de invitación mediante la

característica de personalización de marca de Azure AD, como se describe
aquí.
Invitaciones ad hoc
¿Qué ocurre si Contoso no conoce a todos los usuarios invitados que desea invitar
con antelación? O bien, ¿qué ocurre si el analista de Contoso que creó el portal de
BI quiere distribuir contenido a los usuarios invitados? También se admite este
escenario en Power BI con invitaciones ad hoc.
El analista solo puede agregar los usuarios externos a la lista de acceso de la

aplicación al publicarla. Los usuarios invitados obtienen una invitación y, una vez
que lo aceptan, se redirigen automáticamente al contenido de Power BI.
７ Nota
Las invitaciones solo son necesarias la primera vez que se invita a un usuario
externo a su organización.
3. Distribuir contenido
Ahora que el equipo de BI de Contoso ha creado el portal de BI e invitado a los

usuarios invitados, puede distribuir su portal a sus usuarios finales al conceder
acceso a los usuarios invitados a la aplicación y publicarlo. Power BI completa
automáticamente los nombres de los usuarios invitados que se han agregado
previamente al inquilino de Contoso. También se pueden agregar invitaciones
Adhoc a otros usuarios invitados en este momento.
７ Nota
Si usa grupos de seguridad para administrar el acceso a la aplicación para

usuarios externos, use el enfoque Invitaciones planeadas y comparta el
vínculo de la aplicación directamente con cada usuario externo que deba
acceder a ella. De lo contrario, es posible que el usuario externo no pueda
instalar ni ver contenido desde la app._
Los usuarios invitados reciben un correo electrónico con un vínculo a la aplicación.

Al hacer clic en este vínculo, se pide a los usuarios invitados que se autentiquen
con la identidad de su propia organización.
Una vez que se autentican correctamente, se redirigen a la aplicación de BI de

Contoso.
Los usuarios invitados pueden acceder posteriormente a la aplicación de Contoso
haciendo clic en el vínculo del correo electrónico o marcando el vínculo. Contoso
también puede facilitar a los usuarios invitados agregar este vínculo a cualquier
portal de extranet existente que los usuarios invitados ya usen.
4. Pasos siguientes
Con una aplicación de Power BI y Azure AD B2B, Contoso pudo crear rápidamente
un portal de BI para sus proveedores sin código. Esto simplifica considerablemente
la distribución de análisis estandarizados a todos los proveedores que lo
necesitaban.
Aunque en el ejemplo se muestra cómo se puede distribuir un único informe

común entre proveedores, Power BI puede ir mucho más lejos. Para asegurarse de
que cada asociado solo ve los datos relevantes para sí mismos, la seguridad de
nivel de fila se puede agregar fácilmente al modelo de datos y el informe. La
sección Seguridad de datos para asociados externos más adelante en este
documento describe este proceso en detalles.
A menudo, los informes y paneles individuales deben insertarse en un portal

existente. Esto también se puede lograr reutilizando muchas de las técnicas que se
muestran en el ejemplo. Sin embargo, en esas situaciones puede ser más fácil
insertar informes o paneles directamente desde un área de trabajo. El proceso para
invitar y asignar permisos de seguridad a los usuarios necesarios sigue siendo el
mismo.
En segundo plano: ¿Cómo puede Lucy del
proveedor1 acceder al contenido de Power BI
desde el inquilino de Contoso?
Ahora que hemos visto cómo Contoso puede distribuir sin problemas el contenido de
Power BI a los usuarios invitados de las organizaciones asociadas, veamos cómo
funciona en segundo plano.
Cuando Contoso invitado lucy@supplier1.com a su directorio, Azure AD crea un vínculo

entre Lucy@supplier1.com y el inquilino de Azure AD de Contoso. Este vínculo permite a
Azure AD saber que Lucy@supplier1.com puede acceder al contenido en el inquilino de
Contoso.
Cuando Lucy intenta acceder a la aplicación power BI de Contoso, Azure AD comprueba

que Lucy puede acceder al inquilino de Contoso y, a continuación, proporciona a Power
BI un token que indica que Lucy está autenticado para acceder al contenido en el
inquilino de Contoso. Power BI usa este token para autorizar y asegurarse de que Lucy
tiene acceso a la aplicación power BI de Contoso.
La integración de Power BI con Azure AD B2B funciona con todas las direcciones de
correo electrónico empresariales. Si el usuario no tiene una identidad de Azure AD, es
posible que se le pida que cree una. En la imagen siguiente se muestra el flujo detallado:
Es importante reconocer que la cuenta de Azure AD se usará o creará en Azure AD del
tercero externo, lo que permitirá a Lucy usar su propio nombre de usuario y contraseña
y sus credenciales dejarán de funcionar automáticamente en otros inquilinos siempre
que Lucy abandone la empresa cuando su organización también use Azure AD.
Licencias
Contoso puede elegir uno de los tres enfoques para conceder licencias a los usuarios
invitados de sus proveedores y organizaciones asociadas para tener acceso al contenido
de Power BI.
７ Nota
El nivel gratis de Azure AD B2B es suficiente para usar Power BI con Azure AD B2B.
Algunas características avanzadas de Azure AD B2B, como los grupos dinámicos,
requieren licencias adicionales. Para obtener más información, consulte la
Documentación de Azure AD B2B.
Enfoque 1: Contoso usa Power BI Premium

Con este enfoque, Contoso compra Power BI Premium capacidad y asigna su contenido
del portal de BI a esta capacidad. Esto permite a los usuarios invitados de las
organizaciones asociadas acceder a la aplicación power BI de Contoso sin ninguna
licencia de Power BI.
Los usuarios externos también están sujetos a las experiencias de consumo que solo se
ofrecen a los usuarios "gratis" en Power BI al consumir contenido dentro de Power BI
Premium.
Contoso también puede aprovechar otras funcionalidades de Power BI Premium para
sus aplicaciones, como aumento de las tasas de actualización, la capacidad y los
tamaños de modelo grandes.
Enfoque 2: Contoso asigna licencias Power BI Pro a los

usuarios invitados
Con este enfoque, Contoso asigna licencias pro a los usuarios invitados de
organizaciones asociadas: esto se puede hacer desde el Centro de administración de
Microsoft 365 de Contoso. Esto permite a los usuarios invitados de las organizaciones
asociadas acceder a la aplicación power BI de Contoso sin adquirir una licencia por sí
mismos. Esto puede ser adecuado para compartir con usuarios externos cuya
organización aún no ha adoptado Power BI.
７ Nota
La licencia pro de Contoso solo se aplica a los usuarios invitados cuando acceden al
contenido del inquilino de Contoso. Las licencias Pro permiten el acceso al
contenido que no está en una capacidad de Power BI Premium. Sin embargo, los
usuarios externos con una licencia Pro están restringidos de forma predeterminada
a una experiencia de solo consumo. Esto se puede cambiar mediante el enfoque
descrito en la sección Habilitación de usuarios externos para editar y administrar
contenido en Power BI más adelante en este documento.
Enfoque 3: Los usuarios invitados traigan su propia
licencia de Power BI Pro
Con este enfoque, el Proveedor 1 asigna una licencia de Power BI Pro a Lucy. Después,
pueden acceder a la aplicación Power BI de Contoso con esta licencia. Dado que Lucy
puede usar su licencia Pro de su propia organización al acceder a un entorno externo de
Power BI, este enfoque se conoce a veces como traiga su propia licencia (BYOL). Si
ambas organizaciones usan Power BI, esto ofrece licencias ventajosas para la solución de
análisis general y minimiza la sobrecarga de asignar licencias a usuarios externos.
７ Nota
La licencia profesional dada a Lucy by Supplier 1 se aplica a cualquier inquilino de

Power BI donde Lucy es un usuario invitado. Las licencias Pro permiten el acceso al
contenido que no está en una capacidad de Power BI Premium. Sin embargo, los
usuarios externos con una licencia Pro están restringidos de forma predeterminada
a una experiencia de solo consumo. Esto puede cambiarse mediante el enfoque
descrito en la sección Habilitación de usuarios externos para editar y administrar
contenido en Power BI más adelante en este documento.
Seguridad de datos para asociados externos

Normalmente, al trabajar con varios proveedores externos, Contoso debe asegurarse de
que cada proveedor solo ve datos sobre sus propios productos. La seguridad basada en
el usuario y la seguridad de nivel de fila dinámica facilitan este proceso con Power BI.
Seguridad basada en el usuario

Una de las características más eficaces de Power BI es seguridad de nivel de fila. Esta
característica permite a Contoso crear un único informe y un conjunto de datos, pero
seguir aplicando reglas de seguridad diferentes para cada usuario. Para obtener una
explicación detallada, consulte Seguridad de nivel de fila (RLS).
La integración de Power BI con Azure AD B2B permite a Contoso asignar reglas de

seguridad de nivel de fila a los usuarios invitados en cuanto se les invita al inquilino de
Contoso. Como hemos visto antes, Contoso puede agregar usuarios invitados a través
de invitaciones planeadas o ad hoc. Si Contoso quiere aplicar la seguridad de nivel de
fila, se recomienda encarecidamente usar invitaciones planeadas para agregar los
usuarios invitados con antelación y asignarlos a los roles de seguridad antes de
compartir el contenido. Si Contoso en su lugar usa invitaciones ad hoc, es posible que
haya un breve período de tiempo en el que los usuarios invitados no podrán ver ningún
dato.
７ Nota
Este retraso en el acceso a los datos protegidos por RLS cuando se usan
invitaciones ad hoc puede dar lugar a solicitudes de soporte técnico al equipo de
TI, ya que los usuarios verán informes o paneles en blanco o rotos al abrir un
vínculo para compartir en el correo electrónico que reciben. Por lo tanto, se
recomienda encarecidamente usar invitaciones planeadas en este escenario.**
Veamos esto con un ejemplo.
Como se mencionó anteriormente, Contoso tiene proveedores de todo el mundo y

quieren asegurarse de que los usuarios de sus organizaciones de proveedores obtengan
información de los datos solo de su territorio. Pero los usuarios de Contoso pueden
acceder a todos los datos. En lugar de crear varios informes diferentes, Contoso crea un
único informe y filtra los datos en función del usuario que lo ve.
Para asegurarse de que Contoso puede filtrar los datos en función de quién se conecta,
se crean dos roles en Power BI Desktop. Uno para filtrar todos los datos de
SalesTerritory "Europa" y otro para "Norteamérica".
Cada vez que se definen roles en el informe, se debe asignar un usuario a un rol
específico para que obtenga acceso a los datos. La asignación de roles se produce
dentro de la servicio Power BI ( Seguridad de conjuntos > de datos )
Se abre una página en la que el equipo de BI de Contoso puede ver los dos roles que
han creado. Ahora el equipo de BI de Contoso puede asignar usuarios a los roles.
En el ejemplo, Contoso agrega un usuario en una organización asociada con una

dirección admin@fabrikam.com de correo electrónico al rol Europa:
Cuando Azure AD resuelve esto, Contoso puede ver que el nombre aparece en la
ventana lista para agregarse:
Ahora, cuando este usuario abre la aplicación que se ha compartido con ellos, solo ve
un informe con datos de Europa:
Seguridad de nivel de fila dinámica

Otro tema interesante es ver cómo funciona la seguridad dinámica de nivel de fila (RLS)
con Azure AD B2B.
En resumen, la seguridad de nivel de fila dinámica funciona filtrando los datos en el

modelo en función del nombre de usuario de la persona que se conecta a Power BI. En
lugar de agregar varios roles para grupos de usuarios, defina los usuarios en el modelo.
Aquí no describiremos el patrón en detalle. Kasper de Jong ofrece una escritura
detallada sobre todos los tipos de seguridad de nivel de fila en Power BI Desktop hoja
de referencia rápida de seguridad dinámica , y en esta notas del producto .
Veamos un pequeño ejemplo: Contoso tiene un informe sencillo sobre las ventas por
grupos:
Ahora este informe debe compartirse con dos usuarios invitados y un usuario interno: el
usuario interno puede ver todo, pero los usuarios invitados solo pueden ver los grupos
a los que tienen acceso. Esto significa que debemos filtrar los datos solo para los
usuarios invitados. Para filtrar los datos correctamente, Contoso usa el patrón RLS
dinámico, tal como se describe en las notas del producto y la entrada de blog. Esto
significa que Contoso agrega los nombres de usuario a los datos en sí:
A continuación, Contoso crea el modelo de datos correcto que filtra los datos de forma
adecuada con las relaciones correctas:
Para filtrar los datos automáticamente en función de quién ha iniciado sesión, Contoso
debe crear un rol que pase al usuario que se conecta. En este caso, Contoso crea dos
roles: el primero es el "securityrole" que filtra la tabla Usuarios con el nombre de usuario
actual del usuario que ha iniciado sesión en Power BI (esto funciona incluso para los
usuarios invitados de Azure AD B2B).
Contoso también crea otro "AllRole" para sus usuarios internos que pueden ver todo:
este rol no tiene ningún predicado de seguridad.
Después de cargar el archivo de Power BI Desktop en el servicio, Contoso puede asignar

usuarios invitados a "SecurityRole" y usuarios internos a "AllRole"
Ahora, cuando los usuarios invitados abran el informe, solo ven las ventas del grupo A:
En la matriz de la derecha puede ver el resultado de la función USERNAME() y
USERPRINCIPALNAME() ambos devuelven la dirección de correo electrónico de los
usuarios invitados.
Ahora el usuario interno obtiene para ver todos los datos:
Como puede ver, RLS dinámico funciona con usuarios internos o invitados.
７ Nota
Este escenario también funciona cuando se usa un modelo en Azure Analysis

Services. Normalmente, Azure Analysis Service está conectado a la misma instancia
de Azure AD que Power BI; en ese caso, Azure Analysis Services también conoce a
los usuarios invitados a través de Azure AD B2B.
Conexión a orígenes de datos locales

Power BI ofrece la capacidad de Contoso para aprovechar orígenes de datos locales,
como SQL Server Analysis Services o SQL Server directamente gracias a la puerta de
enlace de datos local. Incluso es posible iniciar sesión en esos orígenes de datos con
las mismas credenciales que se usan con Power BI.
７ Nota
Al instalar una puerta de enlace para conectarse al inquilino de Power BI, debe usar
un usuario creado en el inquilino. Los usuarios externos no pueden instalar una
puerta de enlace y conectarla a la tenant._
En el caso de los usuarios externos, esto podría ser más complicado, ya que
normalmente no se conoce a los usuarios externos de AD local. Power BI ofrece una
solución alternativa para ello, ya que permite a los administradores de Contoso asignar
los nombres de usuario externos a nombres de usuario internos, como se describe en
Administración del origen de datos: Analysis Services . Por ejemplo,
lucy@supplier1.com se puede asignar a lucy_supplier1_com#EXT@contoso.com.
Este método está bien si Contoso solo tiene un puñado de usuarios o si Contoso puede
asignar todos los usuarios externos a una sola cuenta interna. Para escenarios más
complejos en los que cada usuario necesita sus propias credenciales, hay un enfoque
más avanzado que usa atributos de AD personalizados para realizar la asignación, tal y
como se describe en Administración del origen de datos: Analysis Services . Esto
permitiría al administrador de Contoso definir una asignación para cada usuario de
Azure AD (también usuarios B2B externos). Estos atributos se pueden establecer a través
del modelo de objetos de AD mediante scripts o código para que Contoso pueda
automatizar completamente la asignación en la invitación o en una cadencia
programada.
Permitir que los usuarios externos editen y
administren contenido en Power BI
Contoso puede permitir que los usuarios externos contribuyan al contenido dentro de la
organización, tal como se ha descrito anteriormente en la sección edición y
administración entre organizaciones del contenido de Power BI.
７ Nota
Para editar y administrar el contenido dentro de Power BI de la organización, el

usuario debe tener una licencia de Power BI Pro en un área de trabajo distinta de
Mi área de trabajo. Los usuarios pueden obtener licencias Pro como se describe en
la sección Licencias de este documento.
Power BI Administración Portal proporciona la opción permitir que los usuarios

invitados externos editen y administren contenido en la configuración de la
organización en Configuración de inquilinos. De forma predeterminada, la
configuración se establece en deshabilitada, lo que significa que los usuarios externos
obtienen una experiencia de solo lectura restringida de forma predeterminada. La
configuración se aplica a los usuarios con UserType establecido en Invitado en Azure
AD. En la tabla siguiente se describen los comportamientos que los usuarios
experimentan en función de su UserType y cómo se configuran las opciones.
Tipo de Permitir que los Comportamiento

usuario usuarios
en invitados
Azure externos editen
AD y administren la
configuración
de contenido
Invitado Deshabilitado Vista solo de consumo por elemento. Permite el acceso de solo
para el usuario lectura a informes, paneles y aplicaciones cuando se ven a través de
(valor una dirección URL enviada al usuario invitado. Power BI Mobile
predeterminado) aplicaciones proporcionan una vista de solo lectura al usuario
invitado.
Tipo de Permitir que los Comportamiento
usuario usuarios
en invitados
Azure externos editen
AD y administren la
configuración
de contenido
Invitado Habilitado para El usuario externo obtiene acceso a la experiencia completa de

el usuario Power BI, aunque algunas características no están disponibles para
ellos. El usuario externo debe iniciar sesión en Power BI mediante la
dirección URL del servicio Power BI con la información del inquilino
incluida. El usuario obtiene la experiencia Inicio, mi área de trabajo
y, en función de los permisos, puede examinar, ver y crear
contenido.
Power BI Mobile aplicaciones proporcionan una vista de solo

lectura al usuario invitado.
７ Nota
Los usuarios externos de Azure AD también se pueden establecer en UserType

Member. Actualmente no se admite en Power BI.
En el portal de Power BI Administración, la configuración se muestra en la imagen

siguiente.
Los usuarios invitados obtienen la experiencia predeterminada de solo lectura y que
pueden editar y administrar contenido. El valor predeterminado es Deshabilitado, lo que
significa que todos los usuarios invitados tienen la experiencia de solo lectura. El
Administración de Power BI puede habilitar la configuración para todos los usuarios
invitados de la organización o para grupos de seguridad específicos definidos en Azure
AD. En la imagen siguiente, Contoso Power BI Administración creó un grupo de
seguridad en Azure AD para administrar qué usuarios externos pueden editar y
administrar contenido en el inquilino de Contoso.
Para ayudar a estos usuarios a iniciar sesión en Power BI, proporciónelos con la dirección
URL del inquilino. Para buscar la dirección URL del inquilino, siga estos pasos.
1. En el servicio Power BI, en el menú superior, seleccione ayuda ( ? ) y, después,

Acerca de Power BI.
2. Vea el valor junto a URL de inquilino. Esta es la dirección URL del inquilino que
puede compartir con los usuarios invitados.
Al usar permitir que los usuarios invitados externos editen y administren contenido en la
organización, los usuarios invitados especificados obtienen acceso a Power BI de la
organización y ven cualquier contenido al que tengan permiso. Pueden acceder a Inicio,
examinar y contribuir al contenido a las áreas de trabajo, instalar aplicaciones en las que
se encuentran en la lista de acceso y tener un área de trabajo Mi. Puede ser el
administrador de las áreas de trabajo o crear la opción de serlo.
７ Nota
Al usar esta opción, asegúrese de revisar la sección de gobernanza de este

documento, ya que la configuración predeterminada de Azure AD impide que los
usuarios invitados usen determinadas características como selectores de personas
que pueden dar lugar a una experiencia reducida.**
Para los usuarios invitados habilitados mediante la opción Permitir que los usuarios
invitados externos editen y administren contenido en la configuración del inquilino de la
organización, algunas experiencias no están disponibles para ellos. Para actualizar o
publicar informes, los usuarios invitados deben usar la interfaz de usuario web de
servicio Power BI, incluido Obtener datos para cargar archivos Power BI Desktop. Las
siguientes experiencias no se admiten:
Publicación directa desde Power BI Desktop en el servicio Power BI

Los usuarios invitados no pueden usar Power BI Desktop para conectarse a
conjuntos de datos de servicio en el servicio Power BI
No se admite el envío de invitaciones ad hoc para listas de acceso al área de
trabajo
Power BI Publisher para Excel no se admite para usuarios invitados
Los usuarios invitados no pueden instalar Power BI Gateway y conectarlo a la
organización
Los usuarios invitados no pueden instalar la publicación de aplicaciones para toda
la organización
Los usuarios invitados no pueden usar, crear, actualizar ni instalar aplicaciones de
plantilla
Los usuarios invitados no pueden usar Analizar en Excel
Los usuarios invitados no pueden estar @mentioned en comentarios ( esta
funcionalidad se agregará en una próxima versión )
Los usuarios invitados que usen esta funcionalidad deben tener una cuenta
profesional o educativa. Los usuarios invitados que usan cuentas personales
experimentan más limitaciones debido a restricciones de inicio de sesión.
Gobernanza
Configuración adicional de Azure AD que afecta a las

experiencias de Power BI relacionadas con Azure AD B2B
Cuando se usa el uso compartido de Azure AD B2B, el administrador de Azure Active
Directory controla los aspectos de la experiencia del usuario externo. Estos se controlan
en la página Configuración de colaboración externa dentro de la configuración de Azure
Active Directory para el inquilino.
Para más información, consulte Configuración de la colaboración externa.
７ Nota
De forma predeterminada, los permisos de los usuarios invitados son una opción
limitada se establece en Sí, por lo que los usuarios invitados de Power BI tienen
experiencias limitadas, especialmente rodeando el uso compartido en el que las
interfaces de usuario del selector de personas no funcionan para esos usuarios. Es
importante trabajar con el administrador de Azure AD para establecerlo en No,
como se muestra a continuación para garantizar una buena experiencia.**
Controlar las invitaciones de invitado
Los administradores de Power BI pueden controlar el uso compartido externo solo para
Power BI visitando el portal de administración de Power BI. Pero los administradores
también pueden controlar el uso compartido externo con varias directivas de Azure AD.
Estas directivas permiten a los administradores:
Desactivar invitaciones por parte de los usuarios finales

Solo los administradores y usuarios del rol Invitador de personas pueden invitar
Los administradores, el rol Invitador de personas y los miembros pueden invitar
Todos los usuarios, incluidos los invitados, pueden invitar
Puede obtener más información sobre estas directivas en Delegación de invitaciones

para la colaboración B2B de Azure Active Directory.
Todas las acciones de Power BI por parte de los usuarios externos también se auditan en
nuestro portal de auditoría .
Directivas de acceso condicional para usuarios invitados
Contoso puede aplicar directivas de acceso condicional para los usuarios invitados que
acceden al contenido desde el inquilino de Contoso. Puede encontrar instrucciones
detalladas en Acceso condicional para usuarios de colaboración B2B.
Enfoques alternativos comunes

Aunque Azure AD B2B facilita el uso compartido de datos e informes entre
organizaciones, hay otros enfoques que se usan habitualmente y pueden ser superiores
en determinados casos.
Opción alternativa 1: Crear identidades duplicadas para

los usuarios asociados
Con esta opción, Contoso tenía que crear manualmente identidades duplicadas para
cada usuario asociado en el inquilino de Contoso, como se muestra en la siguiente
imagen. A continuación, en Power BI, Contoso puede compartir con las identidades
asignadas los informes, paneles o aplicaciones adecuados.
Motivos para elegir esta alternativa:
Dado que la identidad del usuario está controlada por su organización, cualquier
servicio relacionado, como correo electrónico, SharePoint, etc. también está dentro
del control de su organización. Los administradores de TI pueden restablecer
contraseñas, deshabilitar el acceso a las cuentas o las actividades de auditoría en
estos servicios.
A menudo, los usuarios que usan cuentas personales para su empresa están
restringidos a acceder a determinados servicios, por lo que es posible que
necesiten una cuenta de organización.
Algunos servicios solo funcionan con los usuarios de la organización. Por ejemplo,
es posible que no sea posible usar Intune para administrar el contenido en los
dispositivos personales o móviles de usuarios externos mediante Azure B2B.
Motivos para no elegir esta alternativa:

Los usuarios de organizaciones asociadas deben recordar dos conjuntos de
credenciales: uno para acceder al contenido de su propia organización y el otro
para acceder al contenido de Contoso. Esto es una molestia para estos usuarios
invitados y muchos usuarios invitados están confundidos por esta experiencia.
Contoso debe comprar y asignar licencias por usuario a estos usuarios. Si un
usuario necesita recibir correo electrónico o usar aplicaciones de office, necesita
las licencias adecuadas, incluidas las Power BI Pro para editar y compartir
contenido en Power BI.
Contoso podría querer aplicar directivas de gobernanza y autorización más
estrictas para los usuarios externos en comparación con los usuarios internos. Para
lograrlo, Contoso debe crear una nomenclatura interna para los usuarios externos
y todos los usuarios de Contoso deben estar informados sobre esta nomenclatura.
Cuando el usuario abandona su organización, seguirá teniendo acceso a los
recursos de Contoso hasta que el administrador de Contoso elimine manualmente
su cuenta.
Los administradores de Contoso tienen que administrar la identidad del invitado,
incluida la creación, los restablecimientos de contraseña, etc.
Opción alternativa 2: Creación de una aplicación de

Power BI Embedded personalizada mediante la
autenticación personalizada
Otra opción para Contoso es crear su propia aplicación de Power BI insertada
personalizada con autenticación personalizada ("La aplicación posee datos"). Aunque
muchas organizaciones no tienen tiempo ni recursos para crear una aplicación
personalizada para distribuir contenido de Power BI a sus asociados externos, para
algunas organizaciones, este es el mejor enfoque y merece una consideración seria.
A menudo, las organizaciones tienen portales de asociados existentes que centralizan el

acceso a todos los recursos de la organización para los asociados, proporcionan
aislamiento de los recursos internos de la organización y proporcionan experiencias
simplificadas para que los asociados admitan a muchos asociados y a sus usuarios
individuales.
En el ejemplo anterior, los usuarios de cada inicio de sesión de proveedor en el Portal de
partners de Contoso que usa AAD como proveedor de identidades. Podría usar AAD
B2B, Azure B2C, identidades nativas o federarse con cualquier número de otros
proveedores de identidades. El usuario iniciaría sesión y accedería a una compilación del
portal de partners mediante Azure Web App o una infraestructura similar.
Dentro de la aplicación web, los informes de Power BI se insertan desde una

implementación de Power BI Embedded. La aplicación web simplificaría el acceso a los
informes y a los servicios relacionados de una experiencia cohesiva destinada a facilitar
a los proveedores la interacción con Contoso. Este entorno del portal se aislaría del
entorno interno de AAD de Contoso y de Power BI interno de Contoso para asegurarse
de que los proveedores no podían acceder a esos recursos. Normalmente, los datos se
almacenarían en un almacenamiento de datos de partner independiente para garantizar
también el aislamiento de los datos. Este aislamiento tiene ventajas, ya que limita el
número de usuarios externos con acceso directo a los datos de su organización,
limitando los datos que podrían estar disponibles para el usuario externo y limitando el
uso compartido accidental con usuarios externos.
Con Power BI Embedded, el portal puede aprovechar las licencias ventajosas, mediante
el token de aplicación o el usuario maestro más la capacidad premium adquirida en el
modelo de Azure, lo que simplifica las preocupaciones sobre la asignación de licencias a
los usuarios finales y se puede escalar o reducir verticalmente en función del uso
esperado. El portal puede ofrecer una experiencia general de mayor calidad y coherente,
ya que los asociados acceden a un único portal diseñado teniendo en cuenta todas las
necesidades de un partner. Por último, dado que las soluciones basadas en Power BI
Embedded suelen diseñarse para ser multiinquilino, facilita la garantía de aislamiento
entre las organizaciones asociadas.
Motivos para elegir esta alternativa:

Más fácil de administrar a medida que crece el número de organizaciones
asociadas. Dado que los asociados se agregan a un directorio independiente
aislado del directorio de AAD interno de Contoso, simplifica las tareas de
gobernanza de TI y ayuda a evitar el uso compartido accidental de datos internos a
usuarios externos.
Los portales de partners típicos son experiencias altamente personalizadas con
experiencias coherentes entre asociados y optimizadas para satisfacer las
necesidades de los asociados típicos. Por lo tanto, Contoso puede ofrecer una
mejor experiencia general a los asociados mediante la integración de todos los
servicios necesarios en un único portal.
Los costos de licencia para escenarios avanzados, como editar contenido dentro
del Power BI Embedded, están cubiertos por la Power BI Premium comprada por
Azure y no requiere la asignación de licencias de Power BI Pro a esos usuarios.
Proporciona un mejor aislamiento entre asociados si se diseña como una solución
multiinquilino.
El Portal de partners suele incluir otras herramientas para asociados más allá de
informes, paneles y aplicaciones de Power BI.
Motivos para no elegir esta alternativa:
Se requiere un esfuerzo significativo para crear, operar y mantener este portal, lo

que hace que sea una inversión significativa en recursos y tiempo.
El tiempo de solución es mucho mayor que el uso compartido de B2B, ya que se
requiere una planeación y ejecución cuidadosas en varias secuencias de trabajo.
Si hay un número menor de asociados, es probable que el esfuerzo necesario para
esta alternativa sea demasiado alto para justificarlo.
La colaboración con el uso compartido ad hoc es el escenario principal al que se
enfrenta su organización.
Los informes y paneles son diferentes para cada asociado. Esta alternativa presenta
una sobrecarga de administración más allá de compartir directamente con
asociados.
Preguntas más frecuentes

¿Puede Contoso enviar una invitación que se canjee automáticamente, por lo que el
usuario solo está listo para usarse? ¿O bien, el usuario siempre tiene que hacer clic
para desplazarse a la dirección URL de canje?
El usuario final siempre debe hacer clic en la experiencia de consentimiento para poder
acceder al contenido.
Si va a invitar a muchos usuarios invitados, se recomienda delegarlo desde los
administradores principales de Azure AD agregando un usuario al rol invitador de
invitador de invitados en la organización de recursos. Este usuario puede invitar a otros
usuarios de la organización asociada mediante la interfaz de usuario de inicio de sesión,
los scripts de PowerShell o las API. Esto reduce la carga administrativa de los
administradores de Azure AD para invitar o volver a enviar invitaciones a los usuarios de
la organización asociada.
¿Puede Contoso forzar la autenticación multifactor para los usuarios invitados si sus
asociados no tienen autenticación multifactor?
Sí. Para más información, consulte Acceso condicional para usuarios de colaboración
B2B.
¿Cómo funciona la colaboración B2B cuando el asociado invitado utiliza la federación

para agregar su propia autenticación local?
Si el asociado tiene un inquilino de Azure AD que está federado en la infraestructura de

autenticación local, se consigue automáticamente el inicio de sesión único (SSO) local. Si
el asociado no tiene un inquilino de Azure AD, se puede crear una cuenta de Azure AD
para los nuevos usuarios.
¿Puedo invitar a usuarios invitados con cuentas de correo electrónico de consumidor?
Se admite la invitación de usuarios invitados con cuentas de correo electrónico de

consumidor en Power BI. Esto incluye dominios como hotmail.com, outlook.com y
gmail.com. Sin embargo, esos usuarios pueden experimentar limitaciones más allá de lo
que encuentran los usuarios con cuentas profesionales o educativas.

Manual Power Bi

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual Power Bi

Cargado por

Copyright:

Formatos disponibles

Díganos qué opina sobre la experiencia de descarga del PDF.

Documentación de guía de Power BI

Instrucciones para Power BI

Guía de optimización para Power BI

Información general sobre las notas del producto

Transformar y dar forma a los datos

La importancia del plegado de consultas

Deshabilitación de la actualización en segundo plano de Power Query

Referencia de las consultas de Power Query

Procedimientos recomendados para flujos de datos

¿Qué es un esquema de estrella?

Técnicas de reducción de datos

Relaciones uno a uno

Relaciones de varios a varios

Relaciones activas frente a inactivas

Solución de problemas de relación

Guía del modelo DirectQuery

Guía del modelo compuesto

Guía de la Seguridad de nivel de fila (RLS)

Uso adecuado de las funciones de error

Impedimento de la conversión de BLANK en valores

Evitar el uso de FILTER como argumento de filtro

Referencias de columnas y medidas

Diferencias entre la función DIVIDE y el operador de división

Uso de COUNTROWS en lugar de COUNT

Uso de SELECTEDVALUE en lugar de VALUES

Uso de variables para mejorar las fórmulas

Separación de informes y modelos

Uso de información sobre herramientas de la página de informes

Uso de detalles de la página del informe

Informes paginados de Power BI

Cuándo usar informes paginados

Guía de recuperación de datos

Uso de parámetros en cascada

Eliminación de páginas en blanco al imprimir

Migración de informes de SSRS a Power BI

Ajuste de tamaño de la puerta de enlace de datos local

Supervisión del rendimiento de los informes

Solución de problemas de rendimiento de los informes

Procedimientos recomendados para las canalizaciones de implementación

Acceso al registro de actividad de Power BI

Información general sobre la migración

Reunir los requisitos

Realización de una prueba de concepto

Aprender de las migraciones de Power BI de los clientes

Migración de modelos de AAS a Power BI Premium

Hoja de ruta de adopción

Cultura de los datos

Propiedad del contenido

Ámbito de entrega del contenido

Mentoría y capacitación de los usuarios

Asistencia técnica de usuario

Configuración del inquilino

Protección de información y DLP

Centro de excelencia (COE)

Arquitectura de la solución de BI en el COE

Descripción de un Se describe el diseño de un esquema de estrella y su importancia

DAX: diferencias entre la función DIVIDE y el Se describe el uso correcto de la función

Procedimientos recomendados Se describen los procedimientos recomendados para diseñar

¿Tiene más preguntas? Pruebe a preguntar a la comunidad de Power BI

En este artículo se proporcionan instrucciones que permiten a los desarrolladores y

Optimización del modelo de datos

Para obtener instrucciones sobre el modo de conjunto de datos específico, vea:

Técnicas de reducción de datos para modelos de importación