Antes de contratar una implementación de datos e IA, revisa cinco cosas: qué decisiones necesitan soporte, cómo se define cada métrica, dónde vive el dato y con qué calidad, quién consume qué, y qué reglas de acceso aplican. Sin ese diagnóstico, cualquier plataforma se llena de objetos técnicos que no cambian la gestión.
La pregunta habitual es "qué herramienta necesito". La pregunta útil es distinta: "qué decisiones quiero sostener y qué me falta para sostenerlas". Un proyecto de datos no empieza en la herramienta, empieza en la pregunta correcta. Una IA montada sobre definiciones débiles multiplica errores con más velocidad. Por eso conviene diagnosticar antes de comprar alcance.
Esta guía no es un caso de cliente ni una promesa de resultado. Es el conjunto de preguntas y entregables que permiten decidir, con criterio, si un proyecto es viable y con qué alcance.
El diagnóstico separa un proyecto de una lista de pedidos
Cuando no hay diagnóstico, el trabajo se vuelve una colección de solicitudes sueltas: un informe aquí, una exportación allá, un tablero que nadie mantiene. La fase inicial existe para descubrir decisiones, fricciones, fuentes, definiciones y límites antes de mover un solo dato.
El diagnóstico responde preguntas concretas y entrega documentos, no impresiones. Estas son las áreas mínimas que conviene cubrir:
| Área | Qué se resuelve | Entregable |
|---|---|---|
| Decisión | Qué se decide cada día, semana y mes, quién decide y qué acción debería disparar el dato | Mapa de decisiones con prioridades, cadencia y responsables |
| Métricas | Qué significa cada indicador, cómo se calcula, qué excepciones y qué grano requiere | Catálogo de métricas con fórmula, grano, filtros y propietario |
| Fuentes | Dónde vive el dato, qué calidad tiene, qué histórico existe y quién autoriza acceso | Inventario de fuentes, riesgos, dependencias y estrategia de ingesta |
| Consumo | Qué perfiles necesitan informes, Excel, preguntas en lenguaje natural, alertas o aplicaciones | Matriz de experiencias por rol y prioridad |
| Gobierno | Qué datos son sensibles, qué permisos aplican y qué cambios exigen revisión | Modelo de acceso, ciclo de cambios y criterios de publicación |
Si un proveedor propone una implementación sin poder llenar esta tabla, está vendiendo objetos técnicos, no una solución de gestión.
Empieza por las decisiones, no por las pantallas
El error más caro es diseñar informes antes de saber qué se decide con ellos. Conviene invertir el orden: listar las decisiones recurrentes, quién las toma y qué acción debería seguir a cada número. Una métrica sin decisión asociada es decoración.
Este mapa de decisiones es también el primer filtro de viabilidad. Si una decisión importante depende de un dato que nadie captura, el proyecto no es "difícil", es imposible en su forma actual, y eso hay que saberlo antes de firmar. Si quieres revisar de forma más amplia si tu organización está lista, sirve como complemento la lectura sobre las seis áreas que definen una empresa lista para IA.
Sin una definición acordada por métrica, cada área defiende su propio número
Dos áreas que calculan "ventas" de forma distinta no tienen un problema de herramienta, tienen un problema de contrato. El modelo semántico es ese contrato: una definición, un origen reconocible y una seguridad consistente por métrica. Antes de contratar, conviene revisar cuántas definiciones duplicadas conviven hoy y cuáles están en disputa.
El entregable aquí es un catálogo de métricas con fórmula, grano, filtros y propietario. No es burocracia: evita que la IA responda con números que nadie puede defender en una reunión. Cuando esa capa está ordenada, alimenta de forma coherente informes, Excel conectado y asistentes; cuando no lo está, cada consumo inventa su propia verdad.
Revisa las fuentes por calidad e historial, no por cantidad de conectores
Un inventario de fuentes no se mide por cuántos sistemas se pueden conectar, sino por la calidad, el histórico y la autoridad de acceso de cada uno. Las preguntas que importan: ¿cuánto historial existe?, ¿quién puede autorizar el acceso?, ¿qué tan confiable es el dato en origen?
Microsoft Fabric organiza este trabajo alrededor de OneLake y de una arquitectura por capas que reduce silos y copias, según la documentación general de Microsoft Fabric. Pero la plataforma no decide por ti qué fuentes valen la pena ni cómo entran. Esa es una decisión del diagnóstico, y determina el esfuerzo real del proyecto. Para entender cómo se conecta el descubrimiento de fuentes con el diseño del sistema, ayuda la lectura sobre cómo se arma un sistema de datos e IA con Microsoft.
El consumo depende del rol, y eso cambia el alcance
No todos consumen datos igual. Dirección quiere un scorecard, finanzas quiere Excel conectado con medidas gobernadas, operaciones a veces necesita una aplicación con carga y aprobación, y algunos perfiles preguntan en lenguaje natural. La matriz de experiencias por rol define buena parte del costo del proyecto, porque escribir de vuelta al sistema (aprobar, clasificar, cargar) es mucho más que mostrar un número.
Este punto suele quedar fuera de las cotizaciones y luego aparece como sobrecosto. Diagnosticarlo antes evita la sorpresa: si un rol necesita una capa operativa que escribe datos, eso es un proyecto distinto a un informe de lectura.
Gobierno y capacidad: los límites que definen viabilidad
Antes de prometer un sistema, hay que saber qué datos son sensibles, qué permisos aplican y qué cambios deben pasar por revisión. Fabric trata identidad, acceso y protección como parte del diseño, no como un añadido, y su documentación de gobierno y cumplimiento describe los controles disponibles. Diseñar seguridad al final casi siempre obliga a rehacer trabajo.
La otra restricción es la capacidad. Usuarios, concurrencia, crecimiento y operación no son detalles posteriores: condicionan el costo y la sostenibilidad. La guía de planificación de capacidad de Fabric suma esas variables al diagnóstico. Un proyecto viable contempla desde el inicio cómo se encienden, asignan y verifican esas capacidades, no las descubre en producción.
Qué debería quedar en tus manos al terminar el diagnóstico
Un buen diagnóstico entrega activos que sobreviven a la propuesta, no solo una conversación:
- Un mapa de decisiones con responsables y cadencia.
- Un catálogo de métricas con definiciones acordadas.
- Un inventario de fuentes con calidad, histórico y riesgos.
- Una matriz de consumo por rol.
- Un modelo de acceso y un criterio de publicación.
Con esos documentos puedes decidir alcance con criterio: qué entra en una primera versión, qué queda fuera y qué condiciones deben cumplirse para que el proyecto sea viable. También puedes comparar propuestas de distintos proveedores sobre una base común, en lugar de sobre promesas.
Si prefieres ver cómo se ve este trabajo aplicado a una empresa real, con ejemplos de decisiones, métricas y gobierno sobre Microsoft Fabric, mira la demo gratuita: ahí se recorre cómo un diagnóstico bien hecho se convierte en un sistema que la dirección puede usar.
Acción concreta
Antes de tu próxima reunión con un proveedor, escribe en una sola página las tres decisiones de negocio más importantes que hoy no tienen un dato confiable detrás, y para cada una anota quién decide, con qué frecuencia y de qué fuente saldría el número. Lleva esa página a la conversación: si el proveedor no puede convertirla en un plan de fuentes, métricas y gobierno, todavía no estás contratando un proyecto, estás comprando pantallas.
Preguntas relacionadas
¿Cuánto tiempo debería tomar un diagnóstico de datos antes de un proyecto de IA?
No hay una duración universal: depende del número de decisiones a cubrir, de cuántas fuentes existen y de la disponibilidad de responsables para validar definiciones. Lo relevante no es la velocidad, sino que al cerrar existan entregables concretos (mapa de decisiones, catálogo de métricas, inventario de fuentes, matriz de consumo y modelo de acceso) que permitan decidir alcance.
¿El diagnóstico sirve para comparar propuestas de distintos proveedores?
Sí. Al producir documentos comunes (decisiones, métricas, fuentes, consumo y gobierno), cada proveedor cotiza sobre la misma base en lugar de sobre promesas. Eso hace comparables el alcance, los riesgos y los supuestos, y reduce los sobrecostos que aparecen cuando el consumo por rol o la escritura operativa se descubren tarde.
¿Puedo hacer el diagnóstico internamente sin contratar a nadie?
Puedes avanzar mucho por tu cuenta: listar decisiones, documentar métricas en disputa e inventariar fuentes con su calidad e histórico. El límite suele estar en gobierno y capacidad, donde conviene contrastar contra la documentación oficial de la plataforma para no fijar supuestos equivocados sobre permisos, concurrencia o costos.
¿Qué señal indica que un proyecto todavía no es viable?
Cuando una decisión importante depende de un dato que nadie captura hoy, o cuando una métrica clave no tiene una definición acordada ni propietario. Esas brechas no se resuelven con más herramientas: se resuelven ordenando primero la captura, la definición y la responsabilidad, y ese es justamente el resultado de un diagnóstico previo.
¿En qué se diferencia diagnosticar el consumo por rol de solo pedir informes?
Pedir informes asume lectura pasiva. Diagnosticar el consumo distingue quién solo lee de quién necesita escribir de vuelta al sistema (aprobar, clasificar, cargar). Esa diferencia cambia el alcance y el costo, porque una capa operativa que escribe datos es un proyecto distinto a un informe de consulta.