Antes de contratar un proyecto de datos, exige un diagnóstico que responda cinco cosas: qué decisiones se toman y quién las toma, cómo se calcula cada métrica, dónde vive el dato y qué calidad tiene, quién consume qué, y qué reglas de gobierno aplican. Si el proveedor salta directo a herramientas sin ese mapa, no estás contratando un proyecto, estás encargando objetos técnicos que no resolverán tu problema de gestión.
Por qué el diagnóstico separa un proyecto de una lista de pedidos
Un proyecto de datos serio no empieza cuando alguien enciende Microsoft Fabric. Empieza cuando alguien descubre qué decisiones necesita mejorar tu negocio y qué información las alimenta. Esa fase inicial es el diagnóstico, y saber cómo implementar ese diagnóstico antes de construir en Fabric es lo que separa un proyecto real de una colección de pedidos técnicos sueltos.
La lógica es simple: la herramienta amplifica lo que ya existe. Si el modelo de tus métricas es pobre, la IA lo repetirá más rápido y con más confianza aparente; por eso conviene entender qué necesita tu empresa antes de implementar IA sobre sus datos antes de encender cualquier herramienta. Por eso en Acadevor sostenemos que primero se ordenan las métricas y las decisiones, y después las herramientas. El modelo semántico es el contrato común de las métricas del negocio, y sin ese contrato Fabric se llena de objetos técnicos que no resuelven el problema de gestión.
Antes de firmar, tu trabajo como dirección es verificar que quien contratas piensa en ese orden. Las preguntas de este artículo son el filtro.
¿Qué decisiones va a mejorar este proyecto?
Un proyecto de datos existe para cambiar decisiones, no para producir pantallas bonitas. La primera conversación con cualquier proveedor debería girar alrededor de las decisiones, no de los informes.
Preguntas concretas que deberías hacer y que un buen diagnóstico responde:
- ¿Qué se decide cada día, cada semana y cada mes en esta área?
- ¿Quién toma cada una de esas decisiones?
- ¿Qué acción concreta debería disparar el dato cuando llega?
La salida esperada es un mapa de decisiones con prioridades, cadencia y responsables. Si nadie puede nombrar la decisión que va a cambiar, el tablero terminará siendo decoración cara. Un dato que no dispara una acción es un costo, no un activo.
¿Cómo se calcula cada métrica y quién es su dueño?
La mayoría de las discusiones de reunión no son sobre estrategia, son sobre de dónde salió ese número. Ese es el síntoma de un negocio donde cada área trae su propia versión de la misma cifra, porque nadie acordó una definición compartida.
Por eso la segunda familia de preguntas es sobre las métricas:
- ¿Qué significa exactamente cada KPI?
- ¿Cómo se calcula, con qué fórmula y con qué nivel de detalle?
- ¿Qué excepciones y filtros existen?
- ¿Quién es el propietario de esa definición?
El entregable correcto es un catálogo de métricas con fórmula, grano, filtros y propietario. Ese catálogo es la base del modelo semántico: el contrato que hace que dirección y equipo vean el mismo número en Excel, en Power BI o al preguntarle a cualquier IA. Sin ese contrato, cada herramienta devuelve una cifra distinta y la reunión vuelve a discutir números en lugar de decidir.
¿Dónde vive el dato y qué calidad tiene?
El tercer bloque es sobre las fuentes. Aquí es donde muchos proyectos se rompen después de firmados, porque el dato prometido no existe con la calidad o el histórico que se asumió.
Preguntas que evitan esa sorpresa:
- ¿Dónde vive cada dato hoy?
- ¿Qué calidad tiene y qué histórico existe?
- ¿Quién puede autorizar el acceso a cada fuente?
- ¿Qué dependencias y riesgos de integración hay?
La salida es un inventario de fuentes con riesgos, dependencias y una estrategia de ingesta. La guía de migración a Microsoft Fabric de Microsoft Learn estructura precisamente este descubrimiento por origen y por carga, ordenando cómo entra el dato antes de transformarlo. Sobre esa base se construye la arquitectura medallion (Bronze, Silver, Gold), donde el dato crudo se refina en capas hasta convertirse en producto listo para consumo.
¿Quién va a consumir el resultado y cómo?
Un proyecto de datos no termina en el modelo, termina en la persona que usa el resultado para actuar. Distintos perfiles necesitan distintas experiencias, y confundirlas produce sistemas que nadie abre.
- Dirección suele querer pocos indicadores y alertas cuando algo se sale de rango.
- Controllers y analistas necesitan detalle y a menudo conectar la información a Excel.
- Otros perfiles piden preguntas en lenguaje natural o una aplicación puntual.
El entregable es una matriz de experiencias por rol y prioridad. Poder conectar el modelo directamente a Excel, por ejemplo, es una decisión de consumo que cambia la adopción, y Microsoft documenta cómo analizar en Excel un modelo publicado. La pregunta de fondo: ¿este proyecto entrega la experiencia que cada rol realmente va a usar, o una sola pantalla genérica para todos?
¿Qué reglas de gobierno y acceso aplican?
El último bloque suele quedar para el final, y ese es el error. Gobierno no es burocracia, es lo que permite que un sistema de datos sobreviva y se pueda auditar cuando crece.
Preguntas mínimas antes de contratar:
- ¿Qué datos son sensibles y quién puede verlos?
- ¿Qué permisos aplican por rol y por área?
- ¿Qué cambios deben pasar por revisión antes de publicarse?
La salida es un modelo de acceso, un ciclo de cambios y criterios de publicación. La documentación de planificación de capacidad de Microsoft Learn suma a esta conversación los usuarios, la concurrencia, el crecimiento y la operación, que también condicionan qué prometer y qué no. Un proyecto sin gobierno definido funciona el primer mes y se vuelve ingobernable en el trimestre.
Las cinco áreas del diagnóstico, en una tabla
Esta es la estructura que un buen proveedor debería reconocer sin dudar. Úsala como checklist en la conversación de venta.
| Área | Pregunta que resuelve | Entregable esperado |
|---|---|---|
| Decisión | Qué se decide, cuándo y quién decide | Mapa de decisiones, cadencia y responsables |
| Métricas | Qué significa cada KPI y cómo se calcula | Catálogo con fórmula, grano, filtros y propietario |
| Fuentes | Dónde vive el dato y qué calidad tiene | Inventario de fuentes, riesgos y estrategia de ingesta |
| Consumo | Quién necesita informes, Excel, alertas o apps | Matriz de experiencias por rol y prioridad |
| Gobierno | Qué es sensible y qué pasa por revisión | Modelo de acceso, ciclo de cambios y publicación |
Si las cinco filas tienen respuesta antes de escribir la primera línea técnica, estás contratando un proyecto. Si faltan tres, estás encargando pedidos sueltos.
El siguiente paso
Contratar bien empieza por poder hacer estas preguntas con criterio. Tanto si el camino de tu empresa es la consultoría como si prefieres desarrollar ese criterio dentro de tu propio equipo con formación, el punto de partida es el mismo: ver cómo se trabaja con este enfoque antes de comprometer presupuesto. Para eso, mira la demo gratuita y evalúa con evidencia si es la forma de trabajar que tu negocio necesita.
Preguntas relacionadas
¿Cuál es la primera pregunta que debo hacer antes de contratar un proyecto de datos?
Qué decisiones concretas va a mejorar el proyecto y quién las toma. Un proyecto de datos existe para cambiar decisiones, no para producir pantallas. Si nadie puede nombrar la decisión que cambiará ni la acción que el dato debería disparar, el resultado será decoración cara en lugar de una herramienta de gestión.
¿Por qué es tan importante el diagnóstico inicial?
Porque separa un proyecto real de una colección de pedidos técnicos. El diagnóstico descubre decisiones, métricas, fuentes, consumo y gobierno antes de tocar la herramienta. Sin ese mapa, Microsoft Fabric se llena de objetos técnicos que no resuelven el problema de gestión, ya que la herramienta amplifica un modelo pobre en lugar de arreglarlo.
¿Qué es el modelo semántico y por qué debería preguntarlo?
Es la definición compartida de las métricas del negocio: establece qué significa cada KPI, cómo se calcula, con qué grano, filtros y quién es su propietario. Ese contrato hace que dirección y equipo vean el mismo número en Excel, en Power BI o en cualquier IA, y evita que cada área maneje una versión distinta de la misma cifra.
¿Qué entregables debería producir un buen diagnóstico?
Cinco: un mapa de decisiones con responsables y cadencia, un catálogo de métricas con fórmula y propietario, un inventario de fuentes con riesgos y estrategia de ingesta, una matriz de experiencias de consumo por rol, y un modelo de acceso y gobierno con su ciclo de cambios. Si faltan varios, aún no estás contratando un proyecto completo.
¿Debo contratar el desarrollo o formar a mi equipo?
Depende de dónde quieras que viva la capacidad. Tras una evaluación de preparación, una empresa puede implementar con su equipo, avanzar con acompañamiento o delegar el desarrollo a medida. Si buscas autonomía a largo plazo, formar al equipo hace que estas preguntas las hagan tus propios analistas sin depender de un proveedor externo.