Casos de uso
Esta página muestra algunos casos de uso completos de extremo a extremo. Cada caso parte de una situación real, describe el problema y explica paso a paso cómo resolverlo con Mind One.
Caso 1 — Catálogo de clientes
La situación
El equipo de datos gestiona un catálogo maestro de clientes en un Excel compartido en Teams. El archivo tiene 4 pestañas, 3 versiones distintas circulando por email y nadie sabe cuál es la definitiva. Controlling usa una versión, ventas usa otra. Cada vez que alguien del lakehouse pregunta “¿qué es un cliente activo?”, la respuesta cambia según a quién preguntes.
El objetivo
Tener una única versión de la verdad del catálogo de clientes, con validación automática, propietario claro y sincronización con BigQuery.
Cómo se resuelve con Mind One
Paso 1 — Crear el workspace
Crea un workspace llamado Clientes con el icono correspondiente. Este workspace será el contenedor de todo lo relacionado con el dominio de cliente.
Paso 2 — Definir el schema
En el schema del workspace, define los campos que tendrá todo datagrid de clientes:
| Campo | Tipo | Validación |
|---|---|---|
cod_cliente | string | Único, obligatorio, patrón CLI-[0-9]{6} |
nombre | string | Obligatorio |
segmento | string | Value list segmentos_cliente |
pais | string | Value list paises |
fecha_alta | date | Obligatorio |
fecha_baja | date | Mayor que fecha_alta si existe |
activo | boolean | Obligatorio |
Paso 3 — Crear las value lists
Crea dos value lists:
paises(estática): lista de países en los que opera la empresa.segmentos_cliente(estática): los segmentos que define el equipo de marketing — Enterprise, Mid-Market, SMB.
Paso 4 — Crear el datagrid
Crea un datagrid llamado Clientes maestro dentro del workspace. Al pertenecer al workspace Clientes, hereda automáticamente el schema de campos.
Paso 5 — Importar desde Excel
Descarga la plantilla Excel generada por Mind One (ya tiene las columnas y validaciones), migra los datos del Excel actual y súbelos. Mind One validará celda a celda antes de aplicar y mostrará los errores específicos si los hay.
Paso 6 — Conectar con BigQuery
Crea una conexión a Google BigQuery con las credenciales del Service Account. Asígnala al workspace Clientes como conexión por defecto. A partir de ese momento, cada vez que se guarden cambios en el datagrid, se sincronizarán automáticamente con la tabla correspondiente en BigQuery.
Paso 7 — Asignar roles
- El Data Manager del equipo de datos: rol Modeller (gestiona el schema y aprueba cambios).
- Los analistas que alimentan datos: rol Contributor (pueden editar datos pero no el schema).
- El equipo de controlling que consulta: rol Data Viewer (solo lectura).
Paso 8 — Workflow de aprobación
Establece un proceso: los Contributors editan en Draft, el Modeller revisa y mueve a Approved al final de cada mes. La fecha y el nombre del aprobador quedan registrados.
Resultado
Un único catálogo de clientes, validado, con propietario, sincronizado con BigQuery y con historial completo de cambios. Fin de las versiones del Excel.
Caso 2 — Documentar las métricas de ventas
La situación
El equipo de datos recibe cada semana la misma pregunta de tres áreas distintas: “¿cómo se calcula el MRR?”. La respuesta está en un documento de Notion que nadie actualiza, en la cabeza del data engineer que lo implementó y en un comentario enterrado en el código de dbt. Cada nueva persona que entra al equipo pierde dos días encontrando la definición correcta.
El objetivo
Centralizar las definiciones de las métricas clave del negocio con su fórmula, propietario, fuente de datos y ejemplos, accesibles para todo el equipo.
Cómo se resuelve con Mind One
Paso 1 — Crear el workspace
Crea un workspace llamado Glosario de métricas. Este workspace no sincroniza con el lakehouse — es puramente contextual.
Paso 2 — Definir el schema
| Campo | Tipo | Descripción |
|---|---|---|
nombre_metrica | string | Nombre oficial de la métrica. Único. |
definicion | string | Descripción en lenguaje de negocio. |
formula | string | Fórmula de cálculo. |
area_propietaria | string | Value list areas |
fuente_datos | string | Tabla o modelo dbt de origen. |
granularidad | string | Diaria, semanal, mensual. Value list. |
ejemplo | string | Ejemplo numérico concreto. |
estado | string | Activa / Deprecada / En revisión. Value list. |
Paso 3 — Crear el datagrid
Crea un datagrid Métricas de ventas dentro del workspace. Rellena las métricas clave: MRR, ARR, Churn rate, CAC, LTV.
Paso 4 — Embed del dashboard
Crea un embed con el dashboard de Power BI de ventas y asígnalo al workspace Glosario de métricas. Ahora el equipo puede ver las definiciones y el dashboard en el mismo lugar.
Paso 5 — Workflow de aprobación
Las nuevas métricas se crean en Draft. El Head of Data las revisa y aprueba. Las métricas aprobadas son las oficiales. Las deprecadas se mantienen en el datagrid con estado “Deprecada” para mantener el historial.
Resultado
Una fuente única de verdad para las definiciones de métricas. Cuando alguien pregunta “¿cómo se calcula el MRR?”, la respuesta es: está en Mind One, en el workspace Glosario de métricas, aprobado por el Head of Data el 3 de junio.
Caso 3 — Sincronizar datos maestros de producto con Snowflake
La situación
El equipo de producto gestiona el catálogo de productos en un Excel. El equipo de datos lo importa manualmente a Snowflake cada semana. El proceso es manual, propenso a errores y a veces se importa una versión desactualizada. Cuando hay un error de datos en producción, tardan horas en saber si el origen fue el Excel o la importación.
El objetivo
Que el equipo de producto gestione el catálogo directamente en Mind One, con validación automática y sincronización continua con Snowflake, sin intervención del equipo de datos.
Cómo se resuelve con Mind One
Paso 1 — Crear el workspace
Crea un workspace llamado Productos con conexión por defecto a Snowflake.
Paso 2 — Definir el schema
| Campo | Tipo | Validación |
|---|---|---|
cod_producto | string | Único, obligatorio |
nombre | string | Obligatorio |
categoria | string | Value list categorias_producto |
subcategoria | string | Value list basada en datagrid (depende de categoría) |
precio_base | number | Mayor que 0 |
precio_pvp | number | Mayor que precio_base |
unidad_medida | string | Value list unidades |
activo | boolean | Obligatorio |
fecha_lanzamiento | date | Obligatorio |
Paso 3 — Value list dinámica para subcategorías
Crea un datagrid Subcategorías con los campos cod_subcategoria y nombre. Crea una value list subcategorias_producto basada en ese datagrid. Cuando el equipo de producto añada nuevas subcategorías al datagrid, aparecerán automáticamente como opciones en el campo del catálogo.
Paso 4 — Asignar roles al equipo de producto
- Los product managers: rol Contributor (pueden editar el catálogo pero no el schema).
- El responsable de producto: rol Modeller (puede gestionar el schema y aprobar cambios).
- El equipo de datos: rol Admin (gestión completa de la conexión y auditoría).
Paso 5 — Migración inicial
Descarga la plantilla Excel desde Mind One, migra el catálogo actual y súbelo. Revisa los errores de validación (campos vacíos, precios incoherentes, categorías no existentes) y corrígelos. Esta primera importación ya revela la calidad real de los datos del Excel.
Paso 6 — Sincronización con Snowflake
Una vez configurada la conexión, cada vez que el equipo de producto guarde cambios en el catálogo, Mind One sincroniza automáticamente con la tabla productos_maestro en Snowflake. El estado de sincronización (Synced / Error) es visible en la interfaz.
Paso 7 — Datagroup de producto
Crea un datagroup Catálogo completo que agrupe los datagrids de Productos, Subcategorías y Precios especiales. El equipo de producto accede a todos los datos relacionados desde un único punto.
Resultado
El equipo de producto gestiona el catálogo directamente, sin pasar por el equipo de datos. La sincronización con Snowflake es automática e instantánea. Cada cambio queda registrado con usuario, fecha y versión. Si hay un error en producción, en segundos puedes ver qué cambió, quién y cuándo.
Caso 4 — Gestión de presupuestos por unidad de negocio
La situación
Una empresa con varias unidades de negocio gestiona los presupuestos anuales en un Excel maestro que el equipo de controlling consolida y actualiza manualmente cada mes. Cada unidad de negocio envía su versión por email, controlling las consolida a mano y el resultado es un archivo con 12 pestañas, fórmulas rotas y versiones que no cuadran.
El equipo de datos necesita alimentar el data lakehouse con los presupuestos aprobados para cruzarlos con los datos de ventas reales y calcular la desviación. Hoy ese proceso es manual y tarda dos días cada cierre.
El objetivo
Que cada unidad de negocio cargue su presupuesto directamente en Mind One con validación automática, que controlling lo apruebe, y que el dato aprobado sincronice automáticamente con Snowflake para el cálculo de desviaciones en el dashboard de BI.
Cómo se resuelve con Mind One
Paso 1 — Workspace de presupuestos
Crea un workspace llamado Presupuestos con conexión por defecto a Snowflake. Este workspace centraliza todos los presupuestos de todas las unidades de negocio.
Paso 2 — Value lists de estructura organizativa
Antes de crear el datagrid, define las value lists de referencia:
unidades_negocio(estática): las unidades de negocio de la empresa — Fabricación, Logística, Comercial, I+D.centros_coste(basada en datagrid): vinculada al datagrid maestro de centros de coste que gestiona el equipo de finanzas. Cuando finanzas añade o modifica un centro de coste, el presupuesto lo refleja automáticamente.naturaleza_gasto(estática): Personal, Materiales, Servicios externos, Amortizaciones, Otros.ejercicio(estática): los años fiscales activos — 2024, 2025, 2026. Paso 3 — Schema del workspace
| Campo | Tipo | Validación |
|---|---|---|
unidad_negocio | string | Value list unidades_negocio. Obligatorio. |
centro_coste | string | Value list centros_coste. Obligatorio. |
naturaleza_gasto | string | Value list naturaleza_gasto. Obligatorio. |
ejercicio | string | Value list ejercicio. Obligatorio. |
mes | number | Entre 1 y 12. Obligatorio. |
importe_presupuestado | number | Mayor que 0. Obligatorio. |
moneda | string | Value list monedas. Por defecto EUR. |
comentario | string | Opcional. |
version_presupuesto | string | Value list versiones — Inicial, Revisado Q1, Revisado Q2, Final. |
Paso 4 — Un datagrid por unidad de negocio
Crea un datagrid por unidad de negocio — Presupuesto Fabricación, Presupuesto Logística, etc. Todos heredan el schema del workspace. Esto permite:
- Que cada responsable de unidad solo vea y edite su propio datagrid (permisos granulares).
- Que controlling tenga acceso de Modeller a todos.
- Que el data lakehouse reciba cada tabla por separado y las consolide con SQL.
Paso 5 — Carga inicial desde Excel
Cada unidad descarga la plantilla Excel de Mind One (con las columnas y las value lists ya embebidas como desplegables), rellena su presupuesto y lo importa. Mind One valida:
- Que todos los centros de coste existen en el maestro de finanzas.
- Que los importes son positivos.
- Que no hay combinaciones duplicadas de centro de coste + naturaleza + mes + versión.
Paso 6 — Workflow de aprobación
Proceso mensual:
- Cada responsable de unidad carga los datos en Draft y notifica a controlling.
- Controlling revisa y, si es correcto, mueve a Approved.
- En el momento de aprobación, Mind One sincroniza automáticamente con Snowflake.
- El dashboard de BI calcula la desviación presupuesto vs real en tiempo real.
Paso 7 — Embed del dashboard de desviaciones
Añade un embed del informe de Power BI de desviaciones presupuestarias dentro del workspace Presupuestos. Los responsables de unidad ven sus datos y el resultado en el mismo sitio.
Resultado
El cierre mensual pasa de dos días a menos de dos horas. Cada presupuesto tiene propietario, versión, fecha de aprobación y trazabilidad completa. Controlling deja de ser el cuello de botella y pasa a ser el validador.
Caso 5 — Enriquecimiento de datos hoteleros
La situación
Una cadena hotelera con 15 propiedades gestiona la información descriptiva de cada hotel — categoría, servicios, capacidades, certificaciones, coordenadas, imágenes principales — dispersa entre el PMS (Opera / Mews / Ulysses Cloud), la web, el channel manager y varios Excels del equipo de ventas.
El equipo de datos necesita una única fuente de verdad de los atributos de cada hotel para alimentar el motor de recomendaciones, el sistema de reportes y las integraciones con OTAs. Hoy cada sistema tiene su propia versión y los datos no cuadran.
El objetivo
Centralizar los datos maestros de las propiedades hoteleras en Mind One, enriquecidos con los atributos que el PMS no gestiona, y sincronizarlos con el data lakehouse para analítica y con las integraciones de distribución.
Cómo se resuelve con Mind One
Paso 1 — Workspace de propiedades
Crea un workspace llamado Propiedades hoteleras. Conexión por defecto a Databricks o Snowflake según el stack del cliente.
Paso 2 — Value lists del sector
categoria_hotel(estática): 1 estrella, 2 estrellas, 3 estrellas, 4 estrellas, 5 estrellas, 5 estrellas Gran Lujo.tipo_propiedad(estática): Ciudad, Vacacional, Rural, Resort, Aparthotel, Boutique.servicios_incluidos(estática): Piscina, Spa, Gimnasio, Restaurante, Bar, Parking, Pets allowed, Transfer aeropuerto, Beach club, Golf.certificaciones(estática): ISO 14001, Biosphere, Green Key, Travelife, Q de Calidad.pms_activo(estática): Opera, Mews, Ulysses Cloud, Protel, Otros.estado_propiedad(estática): Operativa, En reforma, Cerrada temporalmente, Pre-apertura.
Paso 3 — Schema del workspace
| Campo | Tipo | Descripción |
|---|---|---|
cod_propiedad | string | Código interno único. Debe coincidir con el ID en el PMS. |
nombre_comercial | string | Nombre tal como aparece en la web y OTAs. |
nombre_legal | string | Razón social. |
pms_activo | string | Value list pms_activo. |
id_pms | string | ID de la propiedad en el PMS activo. |
categoria | string | Value list categoria_hotel. |
tipo_propiedad | string | Value list tipo_propiedad. |
estado | string | Value list estado_propiedad. |
num_habitaciones | number | Total de unidades alojativas. |
num_plantas | number | Número de plantas. |
año_construccion | number | Año de construcción original. |
año_ultima_reforma | number | Último año de reforma significativa. |
latitud | number | Coordenada geográfica. |
longitud | number | Coordenada geográfica. |
direccion | string | Dirección completa. |
ciudad | string | Ciudad. |
pais | string | Value list paises. |
servicios | string | Value list servicios_incluidos (campo múltiple). |
certificaciones | string | Value list certificaciones (campo múltiple). |
url_web | url | URL pública de la propiedad. |
email_reservas | Email de contacto para reservas. |
Paso 4 — Datagrid de propiedades
Crea el datagrid Maestro de propiedades dentro del workspace. Importa los datos base desde el Excel actual o desde una exportación del PMS, y enriquece manualmente los campos que el PMS no gestiona (certificaciones, coordenadas exactas, año de reforma, servicios).
Paso 5 — Validación cruzada
Define una regla cruzada: año_ultima_reforma >= año_construccion. Si alguien introduce una fecha de reforma anterior a la construcción, Mind One lo rechaza.
Paso 6 — Sincronización con el data lakehouse
Una vez sincronizado, la tabla propiedades_maestro en el data lakehouse tiene siempre los atributos actualizados. El motor de recomendaciones, los dashboards de ocupación por categoría y las integraciones con OTAs consumen esa tabla como fuente de verdad.
Paso 7 — Embed del mapa de propiedades
Añade un embed con el dashboard de Google Data Studio que muestra las propiedades en mapa. El equipo de operaciones puede ver el mapa y los datos maestros en el mismo workspace.
Resultado
Una sola fuente de verdad para los atributos de cada propiedad. Cuando se añade una certificación o se reforma un hotel, el cambio está en el data lakehouse en minutos. El motor de recomendaciones recibe datos fiables. Los reportes de categoría y tipo de propiedad dejan de tener inconsistencias.
Caso 6 — Unificación de PMS para tarifas, tipos de habitación y segmentos
La situación
Una cadena opera con tres PMS distintos según la propiedad: Opera en los hoteles de ciudad, Mews en los boutique y Ulysses Cloud en los vacacionales. Cada PMS tiene su propia nomenclatura para los tipos de habitación, las tarifas y los segmentos de cliente. Un mismo tipo de habitación se llama “DBL STD” en Opera, “Double Standard” en Mews y “Hab. Doble Estándar” en Ulysses.
El equipo de datos no puede construir un reporting unificado de ocupación, RevPAR o pick-up porque los datos de los tres PMS no son comparables. Cada semana dedican horas a mapear manualmente las equivalencias.
El objetivo
Crear un diccionario de equivalencias centralizado en Mind One que mapee los códigos de cada PMS a una nomenclatura maestra única, y sincronizarlo con el data lakehouse para que los pipelines de datos puedan hacer el mapeo automáticamente.
Cómo se resuelve con Mind One
Paso 1 — Workspace de maestros hoteleros
Crea un workspace llamado Maestros hoteleros con tres datagroups: Tipos de habitación, Tarifas y Segmentos. Conexión por defecto a BigQuery.
Paso 2 — Value lists comunes
pms(estática): Opera, Mews, Ulysses Cloud.board_basis(estática): Solo alojamiento, Alojamiento y desayuno, Media pensión, Pensión completa, Todo incluido, Ultra todo incluido.canal_venta(estática): Directo web, Directo teléfono, OTA, GDS, TTOO, Corporativo, Grupos.
Paso 3 — Datagrid de tipos de habitación
Schema:
| Campo | Tipo | Descripción |
|---|---|---|
cod_tipo_maestro | string | Código único en la nomenclatura maestra. Ej: DBL_STD. |
nombre_maestro | string | Nombre canónico. Ej: “Doble Estándar”. |
descripcion | string | Descripción comercial del tipo de habitación. |
capacidad_max | number | Número máximo de huéspedes. |
metros_cuadrados | number | Superficie en m². |
vista | string | Value list: Mar, Ciudad, Jardín, Interior, Montaña. |
camas | string | Value list: 1 cama doble, 2 camas individuales, Litera, King size. |
cod_opera | string | Código equivalente en Opera. Ej: DBL STD. |
cod_mews | string | Código equivalente en Mews. Ej: Double Standard. |
cod_ulysses | string | Código equivalente en Ulysses Cloud. Ej: Hab. Doble Estándar. |
activo | boolean | Si el tipo está activo en el portfolio. |
Paso 4 — Datagrid de tarifas
Schema:
| Campo | Tipo | Descripción |
|---|---|---|
cod_tarifa_maestra | string | Código único en nomenclatura maestra. Ej: BAR_2025. |
nombre_tarifa | string | Nombre canónico. Ej: “Best Available Rate 2025”. |
tipo_tarifa | string | Value list: Pública, Privada, Corporativa, Grupo, Promocional. |
board_basis | string | Value list board_basis. |
canal | string | Value list canal_venta. |
cod_opera | string | Código de tarifa en Opera. |
cod_mews | string | Código de tarifa en Mews. |
cod_ulysses | string | Código de tarifa en Ulysses Cloud. |
fecha_vigencia_inicio | date | Inicio de vigencia. |
fecha_vigencia_fin | date | Fin de vigencia. Mayor que fecha_vigencia_inicio. |
activa | boolean | Si la tarifa está activa. |
Paso 5 — Datagrid de segmentos de cliente
Schema:
| Campo | Tipo | Descripción |
|---|---|---|
cod_segmento_maestro | string | Código único. Ej: CORP_NEGOCIADO. |
nombre_segmento | string | Nombre canónico. Ej: “Corporativo negociado”. |
tipo_segmento | string | Value list: Leisure, Business, Groups, MICE, Wholesale. |
canal_principal | string | Value list canal_venta. |
cod_opera | string | Código de segmento en Opera. |
cod_mews | string | Código de segmento en Mews. |
cod_ulysses | string | Código de segmento en Ulysses Cloud. |
activo | boolean | Obligatorio. |
Paso 6 — Poblar los diccionarios
El equipo de revenue o de datos rellena los tres datagrids con las equivalencias. Este trabajo se hace una sola vez: para cada tipo de habitación, tarifa y segmento maestro, se mapean los códigos de los tres PMS.
Para importaciones masivas, se exporta una plantilla Excel desde Mind One, se completa y se importa con validación previa.
Paso 7 — Sincronización (Autosync) con BigQuery
Una vez sincronizados, el data lakehouse tiene tres tablas de mapeo:
dim_tipo_habitacion_mapeodim_tarifa_mapeodim_segmento_mapeo
Los pipelines de datos (dbt, Airflow) usan estas tablas para traducir automáticamente los códigos de cada PMS a la nomenclatura maestra antes de cargar los datos en el modelo analítico unificado.
Paso 8 — Datagroup de maestros hoteleros
Agrupa los tres datagrids en el datagroup Maestros hoteleros para que el equipo de revenue acceda a todo desde un único punto. Añade un embed del dashboard de RevPAR unificado para que puedan ver el resultado del mapeo en tiempo real.
Resultado
Un reporting unificado de ocupación, ADR y RevPAR entre Opera, Mews y Ulysses Cloud. Las horas semanales de mapeo manual se eliminan. Cuando se añade un nuevo tipo de habitación o tarifa en cualquier PMS, el equipo lo registra en Mind One y el pipeline lo incorpora automáticamente.
Caso 7 — Carga de costes estándar para cálculo de margen de ventas (retail)
La situación
El equipo de datos de una empresa de retail quiere calcular el margen neto por línea de factura y por referencia de producto. Tienen el dato de ingresos en el data warehouse (precio de venta por SKU y canal). Pero los costes estándar de producto — coste medio de compra, transporte y aduanas — viven en un Excel que gestiona el equipo de compras y que nadie sabe si refleja los precios actuales del proveedor.
El equipo de datos no puede calcular el margen sin ese dato, y no pueden automatizar el cálculo porque el Excel cambia sin avisar, no tiene historial de versiones y no está conectado al warehouse.
El objetivo
Que el equipo de compras gestione los costes estándar directamente en Mind One con versionado y aprobación, y que el data warehouse los consuma automáticamente para calcular el margen por referencia y por canal en tiempo real.
Cómo se resuelve con Mind One
Paso 1 — Workspace de costes estándar
Crea un workspace llamado Costes estándar con conexión por defecto al data warehouse. Este workspace centraliza todos los costes de producto que intervienen en el cálculo de margen.
Paso 2 — Value lists necesarias
referencias_producto(basada en datagrid): vinculada al datagrid maestro de productos. Cuando el equipo de producto añade una nueva referencia, aparece automáticamente en costes sin intervención manual.proveedor(basada en datagrid): vinculada al datagrid maestro de proveedores.pais_origen(estática): países desde los que se importa mercancía — China, Bangladesh, Portugal, Italia, etc.moneda_compra(estática): EUR, USD, CNY, GBP. La moneda en la que se negocia con el proveedor.incoterm(estática): EXW, FOB, CIF, DDP. Define quién asume el coste de transporte y aduanas en el contrato de compra.temporada(estática): SS25, FW25, SS26, etc. Permite versionar costes por temporada.canal_venta(estática): Tienda física, Online, Marketplace, Wholesale, Outlet.
Paso 3 — Datagrid de coste medio de compra
El coste de compra por referencia y proveedor, en la moneda de negociación:
| Campo | Tipo | Validación |
|---|---|---|
referencia | string | Value list referencias_producto. Obligatorio. |
proveedor | string | Value list proveedor. Obligatorio. |
pais_origen | string | Value list pais_origen. Obligatorio. |
temporada | string | Value list temporada. Obligatorio. |
incoterm | string | Value list incoterm. Obligatorio. |
coste_compra | number | Mayor que 0. Obligatorio. |
moneda_compra | string | Value list moneda_compra. Obligatorio. |
tipo_cambio | number | Mayor que 0. Tipo de cambio a EUR en el momento de la negociación. |
coste_compra_eur | number | Mayor que 0. Coste convertido a EUR. Obligatorio. |
vigencia_inicio | date | Obligatorio. |
vigencia_fin | date | Mayor que vigencia_inicio. |
comentario | string | Opcional. Justificación del precio (negociación, volumen, etc.). |
Validación cruzada: coste_compra_eur > 0 y vigencia_fin > vigencia_inicio.
Paso 4 — Datagrid de costes de transporte y aduanas
Los costes logísticos tienen una lógica distinta: dependen del país de origen, el incoterm y el volumen, no de la referencia individual. Se definen por país de origen y temporada, y se reparten por unidad en el modelo dbt:
| Campo | Tipo | Validación |
|---|---|---|
pais_origen | string | Value list pais_origen. Obligatorio. |
temporada | string | Value list temporada. Obligatorio. |
incoterm | string | Value list incoterm. Obligatorio. |
coste_transporte_unitario | number | Mayor que 0. Coste de transporte estimado por unidad en EUR. |
coste_aduanas_pct | number | Entre 0 y 100. Porcentaje de aranceles sobre el valor de compra. |
coste_aduanas_unitario | number | Mayor que 0. Coste de aduanas estimado por unidad en EUR. |
coste_logistico_total | number | Mayor que 0. Suma de transporte + aduanas por unidad. Obligatorio. |
vigencia_inicio | date | Obligatorio. |
vigencia_fin | date | Mayor que vigencia_inicio. |
comentario | string | Opcional. |
Paso 5 — Carga inicial y mantenimiento
El equipo de compras (rol Contributor) carga los costes estándar en Mind One desde el Excel actual. El responsable de compras o el Controller (rol Modeller) los revisa y aprueba.
A partir de ese momento, cualquier revisión de costes sigue el mismo proceso:
- Compras actualiza en Draft al inicio de cada temporada o cuando cambia un precio de proveedor.
- Controller revisa y aprueba.
- La sincronización se dispara automáticamente al data warehouse.
Paso 6 — Sincronización y cálculo de margen
El data warehouse recibe las tablas:
costes_compra_estandarcostes_transporte_aduanas
El modelo dbt cruza estas tablas con los ingresos de ventas para calcular, por cada línea de factura:
coste_total_producto = coste_compra_eur + coste_logistico_total
margen_bruto = precio_venta_neto - coste_total_producto
margen_pct = margen_bruto / precio_venta_neto * 100El análisis se puede cortar por referencia, categoría, proveedor, país de origen, temporada y canal de venta.
Paso 7 — Embed del dashboard de margen
Añade un embed del dashboard de margen por categoría, proveedor y canal dentro del workspace Costes estándar. El equipo de compras ve los costes que gestiona y el impacto en margen en el mismo lugar, sin salir de Mind One.
Paso 8 — Alertas de vigencia
Los costes tienen fechas de vigencia por temporada. Añade un campo estado_vigencia con una value list estática — Vigente, Próximo a expirar, Expirado — que el equipo de compras actualiza manualmente al inicio de cada temporada. Esto garantiza que el equipo de datos siempre sabe qué costes están activos antes de ejecutar el modelo de margen.
Resultado
El margen por referencia y por canal se calcula en tiempo real en el data warehouse, con costes aprobados, versionados y trazables por temporada. Cuando un proveedor renegocia el precio o cambian los aranceles, compras lo actualiza en Mind One, el Controller lo aprueba y el dashboard refleja el nuevo margen en minutos. Sin Excel. Sin esperar al equipo de datos. Con historial completo de qué costaba cada referencia en cada temporada.