Tienes Microsoft 365 y Power BI. ¿Por qué tus datos siguen sin hablar entre sí?

El problema no es que falten cuadros de mando

El director financiero recibe el cierre mensual de su ERP. Comercial consulta las oportunidades desde el CRM. Operaciones mantiene indicadores en hojas de cálculo y la dirección accede a distintos informes Power BI. Cada equipo tiene una versión aparentemente correcta de la actividad, pero las cifras no coinciden al cruzar facturación, cartera, margen o previsión de demanda. El problema no suele ser la ausencia de herramientas. Es que cada dato ha sido definido, extraído y transformado con reglas diferentes.

Cuando una empresa pregunta si necesita Microsoft Fabric, una respuesta responsable empieza por comprender cómo se construyen y gobiernan sus indicadores. La cuestión decisiva no es si una herramienta puede conectar cien orígenes, sino si la organización puede construir un significado compartido de cliente, producto, pedido, proyecto, coste y rentabilidad. Sin ese acuerdo, centralizar tecnología solo traslada el desorden a un sistema más moderno.

En esta guía nos centramos en un escenario concreto: organizaciones que ya utilizan Microsoft 365, disponen de informes Power BI y quieren integrar la información operativa de ERP, CRM y otros sistemas. Para una explicación general del producto, sus componentes y alcance, consulta la página de Microsoft Fabric para empresas. Aquí abordamos una decisión distinta: qué cambiar primero, qué no tocar y cómo justificar el siguiente paso desde negocio.

Seis señales de que tu arquitectura de datos necesita una conversación seria

Microsoft Fabric no es otro Power BI con un nombre nuevo

Power BI permite modelar, analizar y compartir información, pero el ecosistema de datos de una empresa exige mucho más: ingesta, transformación, almacenamiento, seguridad, monitorización, gobierno y reutilización entre equipos. Fabric unifica en una experiencia SaaS distintas cargas de integración, ingeniería, almacenamiento, analítica y visualización sobre OneLake. Eso no significa que todas las necesidades queden resueltas automáticamente, sino que puede reducir la fragmentación de componentes cuando se diseña una arquitectura apropiada.

OneLake funciona como capa lógica común para distintos tipos de datos. En determinados escenarios, los shortcuts permiten referenciar información sin copiarla, mientras que mirroring puede replicar bases de datos admitidas. Cuando se requieren transformaciones complejas, calendarios de actualización o integraciones adicionales, siguen siendo relevantes los pipelines y otras capacidades de movimiento de datos. Elegir entre estas alternativas requiere revisar volumen, latencia, cambios en origen, residencia de datos, seguridad y coste.

La decisión no tiene que ser radical. Una organización puede seguir utilizando Power BI sobre sistemas ya bien modelados y adoptar Fabric primero en el dominio que más retorno aporta. También puede descubrir que todavía no necesita Fabric y que su principal problema se corrige normalizando indicadores y estabilizando sus flujos actuales. Esta posibilidad debería formar parte de cualquier evaluación independiente.

El modelo objetivo: del dato operativo a una decisión que se pueda defender

Una arquitectura útil distingue cinco responsabilidades. Los sistemas operacionales —Dynamics 365, Business Central, CRM, aplicaciones sectoriales o bases de datos— siguen siendo el lugar en el que se ejecutan las transacciones. La capa de ingesta obtiene y actualiza la información mediante mecanismos compatibles con cada origen. Una zona analítica organiza, transforma y documenta los datos. Una capa semántica define las métricas comunes del negocio. Por último, aplicaciones, informes y procesos autorizados consumen esa información.

Lo que convierte una plataforma en un activo empresarial es la disciplina de las transiciones entre capas. Una tabla con facturas no responde por sí sola cuánto vendió la empresa: hay que decidir si se descuentan abonos, cómo se trata el tipo de cambio, qué fecha gobierna el reconocimiento y cómo se agrupan las sociedades. Tampoco una oportunidad en CRM constituye automáticamente ingresos futuros. Las reglas deben quedar documentadas, aprobadas y sometidas a controles de calidad.

No se trata de llevar toda la empresa a un único lago de datos el primer día. Un diseño evolutivo permite priorizar un producto de datos —por ejemplo, rentabilidad por cliente y proyecto—, medir su calidad y reutilizarlo después en otros análisis. Esa aproximación minimiza el riesgo de crear un enorme repositorio cuyo catálogo nadie mantiene y cuyos indicadores nadie confía.

Caso empresarial: rentabilidad comercial cuando el ERP y el CRM cuentan historias distintas

Imagina una empresa industrial con un CRM que registra oportunidades, un ERP que gestiona pedidos y facturas y una herramienta logística que registra expediciones. Comercial asegura que la cartera crecerá; operaciones alerta de retrasos; finanzas observa que el margen bruto está cayendo. Los tres pueden tener razón. La dificultad es construir una visión que permita explicar dónde se pierde rentabilidad antes de que termine el trimestre.

Un primer producto de datos podría relacionar oportunidades ganadas, pedidos confirmados, entregas, facturación y margen por cliente, familia de producto y territorio. La clave no es solo conectar tablas: se necesita un identificador maestro consistente, reglas de correspondencia y una decisión explícita sobre cómo tratar modificaciones de pedidos, devoluciones y facturas posteriores. Sin este trabajo, un dashboard más atractivo amplifica las contradicciones.

El resultado esperado no debería formularse como “tener Fabric”. Debería formularse como reducir el tiempo entre detectar una desviación comercial y poder explicar su causa. El indicador puede ser el número de días necesarios para obtener una visión conciliada de cartera y margen, o el porcentaje de cuentas con datos completos en ambos sistemas. Solo después conviene definir la capacidad técnica adecuada.

Caso empresarial: el CFO quiere previsiones, no más pantallas

Las previsiones de tesorería y margen suelen cruzar información que vive en sistemas distintos. Cobros pendientes, vencimientos de proveedores, pedidos comprometidos, hitos de proyecto, costes de personal y variables externas se combinan en un Excel que funciona mientras el responsable conoce todos sus supuestos. El problema aparece al cambiar una condición de pago, incorporar una filial o exigir escenarios semanales.

Una arquitectura de datos gobernada puede aportar fuentes reconciliadas y trazabilidad de hipótesis. Sin embargo, Fabric no sustituye la definición financiera de cada métrica ni el control de versiones de los escenarios. Un modelo con datos de calidad insuficiente seguirá produciendo previsiones débiles aunque el motor de cálculo sea muy rápido. Por eso la conversación debe incluir desde el inicio al área financiera y no limitarse al equipo de sistemas.

Un escenario práctico consiste en elegir un proceso de planificación, identificar qué datos realmente cambian la decisión y determinar la frecuencia necesaria. No toda previsión exige tiempo real. Si los datos de facturación se consolidan una vez al día y la planificación es semanal, pagar por latencias de segundos puede no aportar valor. La arquitectura correcta es la que responde a la decisión, no la que incorpora más componentes.

Cuatro rutas tecnológicas: no todas las empresas deben seguir la misma

Cuándo NO recomendaríamos Microsoft Fabric

No hay valor automático en implantar una plataforma nueva si el problema real es un cuadro de mando mal definido. Cuando una organización necesita tres indicadores, consulta una sola base de datos y dispone de un proceso fiable de actualización, una mejora específica en Power BI o SQL puede ser suficiente. El riesgo de sobredimensionar la arquitectura es comprometer al equipo con un coste recurrente y una complejidad que no se corresponden con el beneficio esperado.

Tampoco aconsejaríamos iniciar un despliegue amplio cuando nadie es responsable de la definición de cliente, producto o centro de coste. Una plataforma compartida exige acuerdos sobre los datos maestros, su propietario y los criterios de calidad. Sin ese gobierno, cada departamento seguirá publicando su propia verdad, ahora en un entorno nuevo. La prioridad inicial sería acordar definiciones y establecer un primer dominio gobernado.

Una tercera razón para esperar son las restricciones operativas no resueltas: permisos de datos sensibles, sistemas legados sin conectores adecuados, dependencia de proveedores terceros o necesidad de residencia específica que no se haya validado. La decisión razonable es plantear una fase de estudio técnico posterior y verificar compatibilidad antes de comprometer una fecha de despliegue. En Ayesa, el enfoque de modernización de aplicaciones e IA en Azure permite situar esos condicionantes en una arquitectura más amplia.

Mirroring, shortcuts y pipelines: tres decisiones que afectan al coste

Los shortcuts de OneLake permiten incorporar referencias a datos de orígenes compatibles sin crear necesariamente una nueva copia física. Tienen sentido cuando queremos reutilizar información ya gestionada en otra ubicación y el modelo de seguridad y acceso está bien resuelto. Pero un acceso directo no elimina los problemas de calidad, ni garantiza una latencia determinada, ni convierte cualquier fuente en un origen compatible. La operativa concreta depende del tipo de acceso y de la identidad utilizada.

El mirroring, cuando está disponible para el origen correspondiente, permite disponer de datos replicados para análisis sin diseñar desde cero ciertos procesos de extracción. Hay que comprobar qué bases y modalidades están soportadas, qué cambios se capturan, cómo se gestionan errores y qué consumo generan. En entornos con sistemas transaccionales sensibles se deben analizar efectos sobre origen y patrones de recuperación ante fallos. Nunca conviene asumir que “replicación” significa consistencia instantánea de todo el modelo de negocio.

Los pipelines, dataflows y otros mecanismos de ingeniería siguen siendo necesarios cuando hay transformaciones, reglas de negocio o movimientos con dependencia de calendario. Elegirlos exige valorar facilidad de mantenimiento, observabilidad, trazabilidad y capacidad. La comparación correcta incorpora el ciclo de vida completo: puesta en marcha, cambios en sistemas fuente, monitorización, tratamiento de errores y gestión de costes. Microsoft explica expresamente que estas opciones son complementarias, no sustitutos universales.

Integrar Business Central, Dynamics 365 y aplicaciones sectoriales

En un entorno empresarial real, las conexiones más importantes no son las que aparecen en una demo, sino las que sobreviven a una actualización del ERP. Business Central, Dynamics 365 Finance, Sales u otras aplicaciones disponen de modelos de datos y mecanismos de acceso diferentes. Antes de hablar de conectores hay que identificar entidades, límites de API, permisos, frecuencia de actualización, integración existente y dependencias de procesos críticos. No todos los datos deben extraerse con la misma cadencia ni por el mismo canal.

Para relacionar clientes y pedidos entre plataformas se necesita una política de correspondencia de identificadores. También hay que decidir qué hacer con registros históricos, compañías múltiples, divisas, ejercicios cerrados y cambios de estructura comercial. Una integración técnicamente correcta puede producir decisiones erróneas si interpreta de manera incorrecta cancelaciones, abonos o estados de procesos. El control funcional debe participar tanto como la ingeniería.

En Ayesa planteamos que el recorrido del dato acompañe al recorrido del negocio. Las decisiones sobre Power BI y Fabric conectan de forma natural con automatización de procesos sobre ERP con Power Platform: una métrica compartida puede desencadenar una alerta o una revisión operativa, siempre que se controle qué sistema tiene autoridad para ejecutar cada acción.

Fabric y la inteligencia artificial: primero contexto, después agentes

Las organizaciones quieren que la IA responda preguntas sobre pedidos, contratos, proyectos y clientes. Pero una respuesta generada con información contradictoria no se vuelve fiable por estar redactada con seguridad. Para un uso empresarial se necesita definir qué conjuntos de datos están aprobados, quién puede consultarlos, cuál es su fecha de actualización y cómo se presenta la evidencia. Una capa semántica consistente puede ayudar a interpretar preguntas, pero no reemplaza la validación de los resultados.

Fabric ofrece capacidades y superficies para preparar y consumir datos que pueden integrarse en escenarios de IA. La arquitectura concreta depende del caso de uso, licencias, capacidades disponibles y controles de seguridad. No debe darse por supuesto que cualquier tenant con Microsoft 365 Copilot accede automáticamente a todos los datos de Fabric o que puede activar agentes sin configurar permisos y servicios complementarios. La conectividad, la autorización y el comportamiento de cada solución requieren validación independiente.

Un comienzo sólido podría ser un asistente interno que conteste preguntas delimitadas sobre un producto de datos de ventas previamente reconciliado, con medidas controladas y revisión humana. Antes de usarlo para aprobar descuentos o comprometer entregas, habría que definir umbrales de confianza y responsabilidades. Ese recorrido es menos espectacular que una demostración genérica, pero mucho más defendible frente a un comité de dirección.

La seguridad no puede añadirse al final

En un diseño corporativo conviven permisos del origen, permisos de espacios de trabajo, roles sobre elementos y medidas de seguridad de los modelos semánticos. OneLake shortcuts puede utilizar acceso con identidad del usuario o mecanismos delegados según el tipo de conexión. Esa distinción afecta a quién puede leer el dato y dónde se aplica efectivamente la autorización. Diseñar permisos únicamente a nivel de informe es insuficiente si existen otros motores o rutas de acceso a la misma información.

Hay que clasificar datos personales, financieros, comerciales y sensibles, y establecer acceso por función y necesidad. Asimismo, resulta imprescindible gestionar cuentas de servicio, secretos, conexiones a terceros, auditoría y ciclo de vida de usuarios. Una revisión de seguridad debe incluir escenarios de colaboración entre departamentos y acceso externo, no solo las identidades de los administradores.

El gobierno de datos exige responsables de dominios, controles de calidad, reglas de retención, documentación de linaje y procedimiento de cambios. También deben revisarse condiciones regulatorias aplicables: RGPD en tratamiento de datos personales, contratos y políticas internas. Fabric puede aportar mecanismos técnicos, pero la obligación de definir finalidades, permisos y controles permanece en la organización.

Licencias, capacidad y costes: qué debe entender un CFO

Microsoft Fabric utiliza capacidades y licencias asociadas a los usos concretos. El coste de una solución depende de la capacidad F seleccionada, horas activas bajo modalidad de consumo cuando corresponda, almacenamiento, perfiles de carga, concurrencia, operaciones y licencias de Power BI para autores y consumidores. La existencia de Microsoft 365 en la empresa no significa que el uso de Fabric esté incluido sin coste adicional. Tampoco es correcto asumir que todos los usuarios podrán visualizar informes sin licencias individuales.

En determinadas capacidades F64 o superiores existen condiciones de consumo de Power BI para usuarios con licencia gratuita, mientras que en tamaños menores suelen mantenerse requisitos de Pro o PPU para la visualización compartida. La evaluación económica debe considerar ambas dimensiones: recursos de plataforma y derechos de acceso. Un presupuesto de infraestructura que ignore licencias de consumo de informes puede dar una fotografía incompleta.

Las decisiones sobre tamaño de capacidad no deberían basarse únicamente en el número de empleados. Intervienen volumen de datos, procesos de actualización, consultas simultáneas, complejidad de modelos y horarios. Para analizar alternativas conviene construir un escenario de carga habitual, uno de cierre o pico y otro de crecimiento. Además de facturación de capacidad se deben contemplar implantación, gobierno, mantenimiento, soporte y formación. Es ahí donde aparece el coste total de propiedad.

La nueva promoción Azure CSP: interesante, pero no cambia las reglas del proyecto

El 12 de octubre de 2026 Microsoft anunció promociones de Azure CSP, con disponibilidad prevista desde el 2 de noviembre. Entre ellas figuran dos iniciativas relevantes para Microsoft Fabric: un descuento de hasta el 20 % en capacidad Fabric de pago por uso para determinados clientes de Microsoft 365 nuevos en Fabric, y otro de hasta el 20 % para determinados clientes de bases de datos Azure sin gasto anterior en Fabric. Son promociones segmentadas: no implican que cualquier cliente de Microsoft 365 pueda acceder automáticamente al beneficio.

La promoción se dirige a operaciones CSP elegibles y debe comprobarse y activarse en los sistemas correspondientes. También importa distinguir entre descuento promocional sobre uso elegible y reducción sobre todos los elementos del coste de implantación. La configuración de capacidades, licencias Power BI, servicios profesionales y posibles componentes adicionales requiere una propuesta específica. En la fecha de esta publicación, el lanzamiento comercial está anunciado, no debe describirse como si el descuento ya estuviera aplicado a un tenant concreto.

Una empresa puede aprovechar esta coyuntura para explorar Fabric, pero el criterio de decisión debe ser independiente del incentivo temporal. Un coste de entrada más atractivo no compensa una plataforma mal dimensionada o sin responsabilidades de gobierno. En proyectos canalizados mediante CSP, Ayesa confirmará las condiciones concretas con los participantes del canal antes de trasladar cualquier ahorro a una propuesta económica. Puedes consultar el anuncio oficial de Microsoft.

Ejemplo ilustrativo: cómo comparar dos escenarios de inversión

Supongamos una empresa con seis analistas que dedican ocho horas mensuales cada uno a reconciliar informes de tres departamentos. El esfuerzo suma cuarenta y ocho horas al mes. Si, exclusivamente como supuesto ilustrativo, el coste interno completo fuera de cuarenta y cinco euros por hora, el coste directo mensual de esa conciliación alcanzaría 2.160 euros y el anual 25.920 euros. Esto no es un ahorro garantizado; es una aproximación que permite cuantificar el problema antes de comprar software.

Supongamos que un proyecto reduce ese trabajo a veinte horas mensuales. La diferencia de veintiocho horas representa 1.260 euros al mes bajo las mismas hipótesis, es decir, 15.120 euros al año. A esa cifra podrían añadirse mejoras en precisión y oportunidad de decisión, pero estas deberían medirse por separado y sin convertirlas de forma arbitraria en euros. Si el coste total anualizado de la solución supera ese beneficio directo, habrá que justificar su valor en otros procesos o rediseñar el alcance.

El análisis serio compara al menos tres alternativas: corregir Power BI sin nueva plataforma, implantar un dominio piloto en Fabric y abordar una arquitectura más amplia. Para cada una hay que estimar inversión, coste recurrente, esfuerzo de cambio, riesgos, dependencia de especialistas y plazo para observar mejoras. Una promoción comercial puede alterar el coste temporal de una opción, pero no debe sustituir el cálculo del retorno.

Indicadores que importan más que el número de dashboards

El primer indicador es la confiabilidad del dato: porcentaje de registros con claves maestras completas, conciliaciones correctas entre sistemas y anomalías detectadas antes de publicar indicadores. El segundo es el tiempo de disponibilidad: cuánto tarda una operación relevante en reflejarse en el análisis y si esa latencia responde a una necesidad del negocio. Ninguno mejora simplemente por tener más informes.

El tercero es la productividad del proceso: horas invertidas en preparar cierres, investigar discrepancias y mantener integraciones. El cuarto es la adopción útil: no basta contar visitas a cuadros de mando, conviene observar si las reuniones de planificación, riesgos o cartera se apoyan efectivamente en métricas acordadas. El quinto es el coste por producto de datos: recursos de plataforma, licencias, ingeniería, soporte e incidencias respecto al valor que obtiene cada área.

Un sexto indicador conecta con inteligencia artificial: proporción de respuestas o decisiones asistidas que pueden trazarse a fuentes autorizadas y verificables. Esto obliga a medir calidad y gobierno antes de prometer automatización inteligente. Una organización que gobierna pocas métricas esenciales puede estar mejor preparada para IA que otra que acumula decenas de dashboards desconectados.

Matriz de decisión: seis preguntas antes de invertir

Una ruta de adopción en cuatro decisiones

Primero, seleccionar un caso empresarial con responsable claro. Evita comenzar por “migrar el data warehouse” si el comité aún no ha definido qué decisión pretende mejorar. El punto de partida puede ser margen por proyecto, previsión de demanda o visibilidad de cartera. Se documenta la situación actual, la calidad de los datos disponibles y cómo se medirá la mejora.

Segundo, diseñar el flujo de datos mínimo viable. Hay que identificar fuentes, mecanismos de acceso, integraciones existentes y reglas para reconocer entidades comunes. Se decide qué conservar, qué transformar y qué nuevas piezas tecnológicas serían necesarias. La seguridad y los costes se revisan desde el diseño, no después de la primera demostración.

Tercero, construir un producto de datos limitado y validarlo con sus usuarios reales. Finanzas, operaciones y tecnología deben comprobar conjuntamente las definiciones, reconciliaciones y frecuencia de actualización. La aprobación funcional resulta tan importante como la prueba de rendimiento. Cuarto, establecer un modelo de operación con responsables, documentación, monitorización y controles de cambios; solo entonces conviene extender nuevos dominios.

Qué haríamos en una primera reunión gratuita con Ayesa

La primera conversación no es una auditoría técnica ni compromete un diagnóstico exhaustivo. Su objetivo es escuchar qué decisiones están siendo difíciles por la dispersión de datos, comprender qué sistemas utiliza la empresa y determinar qué líneas merecen un análisis posterior. Puede que la respuesta sea trabajar sobre Power BI existente; puede que convenga explorar Fabric; o que antes haya que mejorar procesos y definiciones internas.

Plantearíamos preguntas sobre el proceso de reporting, la relación entre ERP y CRM, los principales cuellos de botella, la urgencia empresarial y las restricciones de seguridad o inversión. Con esa información orientaríamos posibles caminos para profundizar con especialistas, sin prometer diseños, estimaciones finales o conclusiones técnicas antes de disponer de evidencias. La finalidad es que el cliente termine la conversación con mayor claridad sobre su siguiente decisión.

Si aparecen señales de un proyecto viable, el siguiente paso podría ser un estudio más específico de fuentes, arquitectura, capacidad y costes. También revisaríamos, cuando proceda, si una promoción CSP anunciada por Microsoft pudiera ser aplicable al escenario, siempre sujeta a verificación formal de elegibilidad. La reunión inicial es gratuita y no obliga a contratar una fase posterior.

Preguntas frecuentes antes de dar el siguiente paso

La mejor decisión es empezar por una necesidad, no por un catálogo

Una organización que ya dispone de Microsoft 365 y Power BI está en una posición interesante para evolucionar su análisis, pero no por ello tiene que contratar Fabric de inmediato. La primera decisión consiste en identificar dónde se rompe la continuidad de los datos, qué indicadores están en disputa y qué consecuencia tiene ese problema sobre ventas, costes, servicio o riesgo. La segunda consiste en valorar si los mecanismos actuales pueden corregirse o si una plataforma común aportaría una ventaja estructural.

Fabric puede ser una opción potente para conectar integración, analítica y datos reutilizables cuando existen necesidades reales de escala y gobierno. También exige disciplina de arquitectura, operación, seguridad y economía de capacidad. Las promociones de Microsoft pueden mejorar el contexto de entrada para ciertos clientes, pero no reemplazan el diagnóstico empresarial.

Si estás intentando conectar ERP, CRM y Power BI, el siguiente paso más útil no es recibir otra presentación de producto. Es mantener una conversación concreta sobre qué decisiones quieres mejorar y qué rutas merece la pena estudiar. Esa es la propuesta de la primera reunión gratuita de Ayesa.