No estás comprando Fabric: estás confiando decisiones críticas a una arquitectura de datos
Imagina una empresa que tiene la facturación en Dynamics 365, oportunidades en otro CRM, operaciones en una aplicación sectorial, contratos en SharePoint y previsiones en hojas de cálculo. Cada departamento presenta cifras razonables, pero ninguna coincide. Dirección pide una visión consolidada del margen y recibe cuatro respuestas distintas. La pregunta relevante no es cuánto tarda una consultora en desplegar un lakehouse; es si puede reconciliar los datos, explicar sus diferencias y conseguir que el resultado sea aceptado por negocio.
Una selección de proveedor precipitada puede producir un sistema vistoso que nadie utiliza, una factura de capacidad difícil de prever o una dependencia operativa que impida incorporar nuevas fuentes sin volver a contratar al mismo equipo. Un buen partner empieza por definir decisiones, dominios, responsabilidades y pruebas de aceptación. Solo después propone qué papel corresponde a Microsoft Fabric, a Azure y a las aplicaciones existentes.
Esta guía está pensada para CIO, CDO, CFO y responsables de operaciones que necesitan comparar consultoras con criterios observables. No pretende sustituir una licitación formal: proporciona preguntas, evidencias y una matriz para distinguir experiencia real de promesas comerciales.
Cuando la fragmentación de datos empieza a convertirse en un riesgo de negocio
Antes de comparar tecnología, identifica síntomas concretos. Estos seis escenarios permiten convertir una conversación genérica sobre modernización en un diagnóstico que pueda priorizarse y medirse.
El informe de ventas no coincide
ERP y CRM usan fechas, estados y monedas distintos. Sin reglas compartidas, cada dashboard puede ser correcto técnicamente e incorrecto para la decisión.
Los cierres requieren conciliaciones manuales
El equipo financiero exporta datos y rehace tablas cada mes. El proyecto debe identificar qué discrepancias se automatizan y cuáles requieren control humano.
Los datos de clientes están duplicados
Varias sociedades o unidades de negocio registran el mismo cliente con claves diferentes. Una plataforma no resuelve por sí sola el dato maestro.
La IA responde sin evidencia
Un asistente puede citar documentos obsoletos o mostrar información que no debería. Se necesita recuperación con permisos, procedencia y evaluación.
El coste crece sin explicación
Pipelines, consultas y modelos compiten por recursos. Sin observabilidad y límites, un piloto económico puede volverse difícil de sostener.
Todo depende de dos especialistas
La empresa no controla despliegues, incidentes o definiciones. El contrato debe contemplar transferencia, documentación y responsabilidades.
Del dato transaccional a una decisión trazable: qué debe diseñar el proveedor
La arquitectura siguiente es conceptual. No presupone que todas las empresas necesiten cada componente: muestra responsabilidades que una propuesta debe resolver y justificar.
Microsoft Fabric
Ingesta y transformación, OneLake, ingeniería, warehouse, modelos analíticos y experiencia integrada de Power BI, según el diseño elegido.
Servicios Azure
Identidades, redes, integración adicional, aplicaciones, búsqueda e IA cuando las necesidades de conectividad, seguridad o consumo lo requieran.
La identidad, el gobierno, la seguridad, la calidad y la observabilidad atraviesan todas las capas. El diagrama no implica que los permisos de origen se propaguen automáticamente ni que cada componente esté incluido en una licencia.
La consultora debe entregar un mapa de flujos y dependencias, no solo un dibujo de productos. Para cada origen deberían constar propietario, sensibilidad, frecuencia de actualización, mecanismo de extracción, controles de reconciliación y responsable de resolver errores. En cada salida debe existir una definición de la métrica, su procedencia y el nivel de acceso permitido.
También hay que discutir las alternativas. Para determinadas cargas pueden bastar Power BI y un almacén ya existente; para otras, un enfoque híbrido de Fabric y servicios de Azure puede ser más adecuado. Las decisiones deben quedar documentadas y revisarse cuando cambien el volumen, la concurrencia o los requisitos de seguridad.
La prueba de una arquitectura no es la demo: es el cierre financiero
Si el mismo indicador no se puede reconciliar con el sistema de registro y explicar a Dirección Financiera, la plataforma todavía no está lista para operar.
Qué debe demostrar una consultora Microsoft Fabric y Azure
No basta con que el proveedor conozca los servicios. Debe demostrar cómo toma decisiones, gestiona excepciones y transfiere conocimiento. Estos criterios son una base para entrevistas y solicitudes de propuesta.
Integración y arquitectura
Solicita un inventario de fuentes con APIs, límites de extracción, lotes, eventos, cargas históricas y recuperación de errores. La consultora debe explicar qué se replica, qué permanece en origen y cómo evita interrumpir procesos transaccionales. Pregunta cómo gestionará cambios de esquema, duplicados, reintentos y nuevas sociedades.
Gobierno, seguridad y privacidad
Exige clasificación de datos, mapa de identidades, roles, segregación de funciones, auditoría, retención y pruebas con perfiles reales. La propuesta debe abordar información personal, contratos confidenciales y accesos desde modelos semánticos, informes y aplicaciones. Un esquema de permisos dibujado no equivale a una validación.
Calidad y significado del dato
Pide reglas de reconciliación entre origen y destino, definición de indicadores, umbrales de completitud y procesos para corregir anomalías. La plataforma debe distinguir pedido, factura, cobro, ingreso reconocido y margen. Si el proveedor evita hablar con los propietarios funcionales, falta una pieza esencial.
Analítica y Power BI
La consultora debe mostrar cómo organiza modelos semánticos, versiones, certificación de métricas, autoservicio y ciclo de publicación. Solicita ejemplos de informes utilizados en decisiones reales y un plan de adopción que no dependa de que el usuario entienda la arquitectura.
IA y documentos empresariales
La preparación para IA exige evaluar acceso a contenido no estructurado, permisos, calidad documental, procedencia, vigencia, recuperación y pruebas de respuestas. No aceptes una promesa genérica de RAG o agentes sin delimitar casos, fuentes, métricas de precisión y supervisión humana.
Rendimiento y economía
Solicita hipótesis de capacidad, almacenamiento, concurrencia, procesos programados, picos de cierre, licencias y servicios complementarios. Debe existir un método de medición y revisión mensual, con alertas de consumo y decisiones de optimización. Una cifra sin supuestos no es un presupuesto.
Entrega, operación y continuidad
El contrato debe incluir responsables, equipo nominal, hitos, pruebas de aceptación, repositorios, automatización, documentación y soporte. Pregunta quién resolverá un fallo un lunes a las ocho, cómo se restaurará un proceso y qué autonomía tendrá el equipo interno al finalizar.
Cuándo elegir Fabric, Azure o una solución más sencilla
Fabric y Azure pueden complementarse, pero no es necesario desplegar ambos. La decisión depende de las fuentes, los equipos, el gobierno, el coste y las necesidades reales.
Fabric como eje analítico
Puede encajar para una experiencia integrada de ingeniería y analítica con Power BI, siempre que se validen capacidad y permisos.
Azure con servicios específicos
Puede encajar en integración compleja, redes privadas, búsqueda, aplicaciones y procesamiento especializado.
Arquitectura combinada
Fabric puede cubrir analítica y Azure servicios complementarios, evitando duplicidades y definiendo responsabilidades.
Evolución mínima viable
A veces basta con corregir el modelo semántico y los informes antes de invertir en una plataforma mayor.
Preparar datos para IA no significa comprar IA por adelantado
Antes de desplegar agentes, hay que resolver permisos, trazabilidad, calidad, vigencia documental y criterios de evaluación. El caso de uso manda sobre la herramienta.
Matriz ponderada para comparar consultoras sin dejarse llevar por la presentación comercial
Puntúa cada criterio entre 0 y 5 y multiplica por su peso. Por ejemplo, una puntuación de 4 en un criterio del 20 % aporta 16 puntos sobre 100. Los pesos son orientativos y deben adaptarse al riesgo de cada organización.
| Criterio | Peso | Importancia relativa | Valoración |
|---|---|---|---|
| Comprensión del negocio | 20% | 0–5, con evidencia | |
| Integración y arquitectura | 20% | 0–5, con evidencia | |
| Seguridad y gobierno | 15% | 0–5, con evidencia | |
| Calidad y semántica | 10% | 0–5, con evidencia | |
| Analítica y adopción | 10% | 0–5, con evidencia | |
| Costes y rendimiento | 10% | 0–5, con evidencia | |
| Entrega y transferencia | 10% | 0–5, con evidencia | |
| Soporte y continuidad | 5% | 0–5, con evidencia |
La puntuación total permite ordenar propuestas, pero no debe ocultar riesgos eliminatorios. Si una consultora no puede demostrar seguridad, cumplimiento o capacidad para recuperar operaciones críticas, una media alta no compensa esa carencia. Pide evidencias escritas y contrástalas con una prueba limitada a un proceso relevante.
De cuatro versiones del margen a una definición compartida
Una empresa industrial con varias sociedades trabaja con un ERP financiero, un CRM comercial, un sistema de producción y un conjunto de ficheros de planificación. Dirección quiere conocer margen por cliente y línea de producto, pero cada área presenta un dato distinto. Comercial utiliza el valor de la oportunidad, finanzas toma facturación neta y operaciones imputa costes con otro calendario. El proveedor que proponga simplemente consolidar tablas habrá resuelto una parte técnica y dejado intacta la discrepancia.
El primer paso consiste en acordar qué significa margen: ingresos reconocidos, descuentos, devoluciones, costes directos y reglas de asignación. El segundo es identificar sistemas de registro, claves de cliente y producto, fechas y excepciones. Después se construye un primer dominio de datos con controles de conciliación y un modelo semántico que explique el cálculo. Solo entonces se publica un cuadro de mando y se mide si las áreas dejan de rehacer los números manualmente.
Antes del proyecto
Cuatro fuentes, tres definiciones del margen, cierres manuales y discusiones sobre qué dato es correcto. No se trata de una cifra real de Ayesa: es un escenario de trabajo ilustrativo.
Resultado que debería validarse
Una definición aprobada, conciliaciones documentadas, accesos autorizados, alertas de calidad y un informe aceptado por las áreas responsables.
Para medir el retorno se deben registrar horas dedicadas a conciliaciones, tiempo de disponibilidad del informe, número de incidencias, uso de métricas certificadas y decisiones que mejoran por disponer de información fiable. No sería riguroso prometer un porcentaje de ahorro sin medir la situación inicial. El piloto debe diseñarse para producir evidencias y permitir una decisión de inversión posterior.
El presupuesto debe mostrar más que el precio de implantación
Una comparación económica sólida separa el esfuerzo de descubrimiento, conectividad, modelado, gobierno, visualización, pruebas, formación y operación. También identifica licencias, capacidades y servicios de terceros que no estén incluidos. Las condiciones de precio y licenciamiento pueden cambiar, por lo que el cálculo debe basarse en la configuración vigente y en el consumo esperado, no en importes genéricos publicados en una presentación.
Inversión inicial
Inventario de fuentes, diseño, integración, calidad, seguridad, modelos, informes, migración de históricos y puesta en producción. Pregunta qué entregables quedan fuera.
Coste recurrente
Capacidad, almacenamiento, conectividad, servicios Azure adicionales, licencias aplicables, soporte, monitorización y mantenimiento. Exige escenarios de crecimiento.
Coste de cambio
Nuevas sociedades, campos, conectores, reglas fiscales, indicadores o fuentes documentales. La arquitectura debe permitir evolucionar sin rehacer todo el modelo.
Riesgo de dependencia
Documentación, repositorios, propiedad de activos, accesos administrativos, automatización y transferencia. Un proyecto aparentemente barato puede salir caro si no puede operarse internamente.
Seis etapas para pasar de una promesa tecnológica a una plataforma operativa
Descubrimiento
Identificar decisiones de negocio, fuentes, propietarios, calidad y restricciones. Priorizar un caso con valor medible.
Diseño y validación
Documentar arquitectura, gobierno, costes, pruebas de seguridad y criterios de aceptación. Confirmar hipótesis con usuarios.
Primer dominio
Integrar datos reales, reconciliar cifras, publicar un modelo semántico y comprobar rendimiento y permisos.
Adopción
Formar usuarios, medir uso y corregir definiciones. Integrar la solución en el proceso de decisión.
Industrialización
Automatizar despliegues, monitorización, alertas, recuperación y soporte. Documentar y transferir capacidades.
Escalado
Incorporar nuevos dominios y casos de IA solo cuando existan controles, demanda y economía demostrada.
Qué debe aparecer en la propuesta antes de firmar
La propuesta debe identificar un alcance por dominios, entregables verificables, criterios de aceptación, equipo nominal, dependencias del cliente y exclusiones. Conviene exigir un inventario de fuentes, una arquitectura objetivo con decisiones justificadas, un plan de seguridad, un modelo de operación y un presupuesto con supuestos de consumo. La ausencia de cualquiera de estos elementos no significa automáticamente que el proveedor sea incapaz, pero obliga a aclararlo antes de comprometer inversión.
También deben acordarse responsabilidades sobre los datos: el proveedor puede implementar controles, pero las áreas de negocio deben aprobar definiciones y gestionar excepciones. Si nadie asume la propiedad de una métrica, la plataforma no resolverá el desacuerdo. Para entornos regulados o multinacionales, revisa residencia, privacidad, retención y controles contractuales con los equipos competentes.
En el contrato de evolución, especifica tiempos de atención, ventanas de mantenimiento, gestión de cambios, escalado, documentación y salida ordenada del proveedor. Solicita que los activos y las configuraciones queden bajo control de la organización, con acceso suficiente para auditoría y continuidad.
Capacidades relacionadas para completar la evaluación
La selección de consultora no puede separarse de la arquitectura, la integración y la seguridad. Estos recursos permiten profundizar en problemas específicos antes de definir un alcance de contratación.
Microsoft Fabric y escenarios empresariales
Conoce aplicaciones de analítica y plataformas de datos. Explorar contenido relacionado →
Integración de ERP y CRM
Revisa el reto de conectar datos operativos y comerciales. Explorar contenido relacionado →
Gobierno de OneLake
Profundiza en la seguridad y el control de acceso. Explorar contenido relacionado →
Preparación de datos para IA
Entiende por qué calidad y contexto condicionan los resultados. Explorar contenido relacionado →
Una consultora debe entender tanto el dato como el proceso que lo produce
Ayesa aborda la evaluación desde aplicaciones empresariales, plataformas cloud, integración, analítica y seguridad. El objetivo es construir una hoja de ruta justificable y operable, no multiplicar herramientas.
Capacidad tecnológica, contexto empresarial y acompañamiento
En una plataforma de datos empresarial confluyen disciplinas distintas: especialistas de ERP y CRM que entienden las transacciones, profesionales de integración que conocen los límites de cada fuente, equipos de cloud y seguridad, analistas de datos y responsables funcionales. La propuesta debe coordinar esas capacidades en un modelo de entrega coherente. Ayesa puede acompañar el análisis del escenario y la definición de una arquitectura adaptada a las prioridades de la organización.
Antes de adjudicar, solicita siempre una relación de perfiles asignados, experiencias relevantes y responsabilidades concretas. Las designaciones y especializaciones de Microsoft aportan contexto sobre las capacidades del partner, pero no sustituyen la validación del equipo y de la propuesta para tu proyecto.
Conoce las designaciones, especializaciones y certificaciones Microsoft de Ayesa
Información corporativa para evaluar el alcance de las capacidades tecnológicas y contrastarlas con el equipo que participará en tu iniciativa.
Respuestas para quienes tienen que justificar la inversión
¿Qué diferencia hay entre una consultora de Fabric y una de Azure?
La distinción depende de su experiencia y alcance, no de una frontera absoluta entre productos. Una consultora puede dominar analítica en Fabric y requerir apoyo para redes, aplicaciones o integración compleja en Azure. Solicita competencias y referencias por necesidad, no por etiqueta comercial.
¿Cuánto tarda un proyecto de plataforma de datos?
Depende de fuentes, calidad, seguridad, disponibilidad del cliente y alcance. Conviene contratar un primer dominio con entregables verificables antes de fijar un calendario global que no contemple dependencias.
¿Es obligatorio migrar todos los datos a OneLake?
No. La arquitectura debe justificar qué se ingiere, qué se consulta desde otros sistemas y qué información no debe duplicarse. También debe establecer políticas de retención y eliminación.
¿Se puede empezar por Power BI sin desplegar una plataforma nueva?
Sí, cuando las fuentes y el gobierno existentes permiten resolver el problema con seguridad y fiabilidad. Lo importante es no confundir un dashboard rápido con una solución sostenible si los datos siguen siendo inconsistentes.
¿Qué debería entregar una prueba de concepto?
Una hipótesis, un conjunto representativo de datos, pruebas de acceso y calidad, medidas de rendimiento, estimación de costes y criterios claros para decidir si avanzar o detenerse.
¿Cómo saber si la plataforma está preparada para IA?
Hay que verificar procedencia, actualización, calidad, permisos y evaluación de respuestas. La existencia de un repositorio central no garantiza que un agente use datos correctos o autorizados.
¿Cómo se evita la dependencia del partner?
Con documentación, repositorios bajo control del cliente, automatización, transferencia, acceso administrativo, criterios de soporte y un plan de salida pactado.
¿Qué debe evaluar el CFO además del presupuesto?
Coste total de propiedad, riesgo operativo, ahorro verificable de conciliaciones, impacto sobre decisiones y escenarios de crecimiento. Un ROI basado solo en horas estimadas puede ser engañoso.
Antes de solicitar una propuesta, define qué decisión quieres mejorar
Si la organización está valorando una plataforma de datos, una conversación útil debería comenzar con tres elementos: las fuentes que hoy generan fricción, los indicadores que necesitan confianza y el proceso de negocio que mejoraría al resolverlos. Con esa base se puede valorar si conviene iniciar un assessment, diseñar un primer dominio o revisar una arquitectura ya existente.
El objetivo de la evaluación no es decidir por adelantado que Fabric o Azure serán la respuesta. Es construir una hoja de ruta técnica y económica que permita a la empresa invertir con criterios, reducir incertidumbre y medir resultados.
¿Tu empresa necesita una plataforma de datos que el negocio pueda utilizar y confiar?
Cuéntanos qué sistemas necesitas conectar, qué decisiones quieres mejorar y dónde aparecen los principales problemas de calidad, seguridad o costes. Podemos ayudarte a definir un punto de partida realista.
Business Development Manager | PSELLER Microsoft en Ayesa | Miembro Unidad Transición Energética, Climática y Urbana en Tecnalia | Secretaria de la Junta Directiva del Cluster de la Construcción (Build INN)