Demos que hablan tu idioma: datos sintéticos para Fabric y Power BI

¿Cuántas veces viste una demo con Adventure Works o con Contoso?

Yo también. Demasiadas.

En el Global Power Platform Bootcamp 2025, en San José, Costa Rica, me tocó una sesión con nombre exigente: “Analista a Leyenda”. El nombre no dejaba margen. Quería una demo que la sala no hubiera visto antes.

Así que inventé La Posada del Lago: un hotel ficticio con reservas, tipos de habitación, canales de distribución, ocupación y RevPAR. Un juego de palabras con Lakehouse (el mismo Lakehouse de Fabric donde hoy corre la herramienta) que además era un modelo de datos completo.

Tardé 16 horas en armarlo. Para una demo de 15 minutos.

¿Valió la pena? La sala se mantuvo atenta de principio a fin. No porque yo hablara mejor que nadie, sino porque nadie sabía qué iba a aparecer en la siguiente pantalla. Los datos tenían sorpresa.

Dieciséis horas por demo no escala. Y ese es exactamente el problema que quiero resolver acá.

El problema que nadie dice en voz alta

Los que hacemos demos en comunidades de Microsoft Fabric y Power BI tenemos un problema que rara vez se menciona: los datos.

No el modelo. No los visuales. Los datos.

Cuando el público ve “Sales by Category” en Contoso por décima vez, el cerebro desconecta antes de que arranque la demo. No porque el speaker no sepa de lo que habla, sino porque esos datos no le hablan a nadie en la sala.

Y va más profundo de lo que parece. “Albarán” es un término perfectamente válido en España; en Costa Rica no existe: decimos “nota de entrega” o “remisión”. Cuando alguien presenta en un evento latinoamericano con “albaranes” en sus datos, la demo deja de ser “esto resuelve mi problema” y pasa a ser “esto es un ejemplo teórico”. El asistente la archiva junto con la PPT: algo conceptual, no algo aplicable. Los datos correctos no se notan; los incorrectos rompen el hechizo.

Hay un segundo filo, menos obvio: la predecibilidad. Cuando decís “si filtran por región, el modelo va a mostrar X”, y X aparece, la credibilidad se consolida. Cuando no aparece, o el dataset tarda dos minutos en cargar, se derrumba. El que diseñó sus datos sabe exactamente qué va a pasar en pantalla. El que usa Contoso, cruza los dedos.

El dilema del consultor

El problema no es que los speakers sean descuidados. Es que hay dos salidas, y las dos son malas.

Opción 1: los datasets de Microsoft: Contoso, Northwind, Adventure Works. Genéricos, orientados a retail, y que todos conocen de memoria.

Opción 2: datos reales de un cliente, que no podés mostrar en público.

Armar un dataset realista desde cero (las relaciones correctas, el vocabulario correcto, los eventos de negocio que corresponden) te cuesta un fin de semana. Yo pagué 16 horas por La Posada del Lago. Por eso casi todos terminan en Contoso, y el ciclo se repite.

La herramienta

Para no volver a pagar esas 16 horas, construí GeneradorDatosSinteticos: un par de notebooks que corrés dentro de Microsoft Fabric y que escriben los datos directo a un Lakehouse, como Delta tables listas para conectar a Power BI.

Vos describís tus tablas en YAML (columnas, tipos, distribuciones, relaciones entre tablas, vocabulario específico) y los notebooks las materializan.

Un ejemplo mínimo para una tabla de empleados:

tabla: empleados
filas: 1000
columnas:
  - nombre: departamento
    tipo: categorica
    valores: [Ventas, RRHH, Tecnología, Operaciones, Finanzas]
    pesos: [0.25, 0.15, 0.20, 0.25, 0.15]
  - nombre: estado
    tipo: categorica
    valores: [Activo, En_proceso_de_salida]
    pesos: [0.92, 0.08]
  - nombre: antiguedad_anos
    tipo: numerico
    distribucion: normal
    media: 4.2
    desviacion: 2.8
    min: 0
    max: 25

Veinte líneas de YAML. Fijate en el detalle: el campo estado dice En_proceso_de_salida, no “Inactivo”, porque en RRHH los procesos tienen nombre. Y antiguedad_anos usa una distribución normal calibrada para que el dataset se comporte como una empresa real, no como filas aleatorias.

Seamos claros con lo que la herramienta hace y lo que no. Te ahorra el tiempo mecánico: generar volumen, mantener las relaciones consistentes, tener las tablas listas antes de empezar. No te ahorra, todavía, pensar el modelo: qué entidades importan, cómo se relacionan, qué vocabulario usa tu audiencia. Eso lo seguís poniendo vos. La herramienta es el torno; el diseño de la pieza sigue siendo tuyo.

“¿Y por qué no uso Faker directamente, o un script con random?” De hecho, por debajo usa Faker (y faker-commerce). La diferencia está en lo que Faker no hace: te da valores columna por columna, pero el Python que arma las relaciones entre tablas, calibra las distribuciones, respeta el vocabulario de la industria y escribe el resultado en tu Lakehouse lo seguís poniendo vos. La herramienta convierte todo eso en algo declarativo: describís el modelo en YAML y listo. El trabajo aburrido nunca fue inventar valores: es que el conjunto se comporte como un negocio real.

¿Y si no das charlas en comunidades? Igual te sirve. Si sos consultor y armás demos para prospectos, o si un cliente necesita datos de prueba que se parezcan a los suyos sin usar los suyos, el problema es el mismo, y la solución también.

El spin-off: modelos que hablan cada idioma

La herramienta resuelve el tiempo. No resuelve el vocabulario.

Yo puedo construir la máquina. Lo que no puedo saber es que en agroindustria el rendimiento se mide por hectárea y cada cosecha se rastrea por lote. O que en banca un cliente no es una cuenta: un cliente puede tener cinco cuentas, y una cuenta, dos dueños. Si el modelo no distingue eso, ningún reporte cuadra. Nadie conoce todos los dominios. Pero entre todos, sí.

Por eso quiero abrir una colección de modelos construida por la comunidad, para la comunidad: un YAML por industria, con el vocabulario real de quien la vive. La etiqueta para encontrarla y aportar es #ModelosComunitariosDemos.

Los ejemplos que trae el repositorio hoy son un punto de partida: empleados, catálogo de productos, tickets de soporte, lecturas de sensores. Útiles, pero genéricos. Lo que falta son modelos con idioma propio.

Horizontales (sirven en cualquier industria):

• RRHH (contrataciones, despidos, evaluaciones, estructura organizacional, nómina)
• Cadena de suministro (proveedores, órdenes de compra, inventario, entregas, trazabilidad)
• Finanzas / presupuesto (centros de costo, partidas, ejecución presupuestaria, cierres mensuales)

Verticales (vocabulario específico de industria):

• Hotelería (habitaciones, reservas, tarifas, canales de distribución, ocupación)
• Retail Latinoamérica (puntos de venta, SKUs, temporadas, devoluciones)
• Manufactura (órdenes de producción, calidad, proveedores, turnos)
• Agroindustria (fincas, cultivos, cosechas, rendimiento por hectárea, trazabilidad de lote)

¿Trabajás en salud, logística, gobierno, educación, banca, seguros? Ese modelo es todavía más valioso, porque nadie lo tiene.

Cada modelo es un archivo de YAML con 5-15 entidades. Con tu conocimiento de la industria y un LLM de apoyo, el trabajo real no es la sintaxis: es el vocabulario. Saber que en hotelería manda el RevPAR, o que en RRHH los eventos se llaman contrataciones y no “entradas”. Eso es lo que ningún LLM inventa solo.

Yo arranco con La Posada del Lago: el modelo de hotelería que debí haber tenido antes del Bootcamp, ahora convertido en el primer aporte del repositorio.

Empezá acá

Repositorio: https://github.com/JavierSQL/GeneradorDatosSinteticos

Usá la herramienta. Cloná el repo, corré los notebooks con los ejemplos y conectá las tablas a un reporte. Si la usás en una demo o un proyecto, contame cómo te fue. Eso es lo que la mejora.

Contribuí un modelo. Si usás GitHub, abrí un issue o un PR con tus YAMLs y etiquetalo #ModelosComunitariosDemos. Si no, escribime por LinkedIn y lo coordinamos desde ahí, sin repositorios de por medio.