Capacidad y rendimiento de Microsoft Fabric: cómo dimensionar sin pagar de más
Una capacidad sobredimensionada quema presupuesto. Una capacidad mal gobernada quema la paciencia de los usuarios.
Elegir una F64 porque “parece segura” o culpar a la capacidad de cualquier informe lento son dos atajos caros. La decisión correcta exige entender CUs, concurrencia, bursting, smoothing, throttling, diseño de cargas y comportamiento real de cada workspace.
La idea clave
Más capacidad no arregla automáticamente un mal diseño.
Primero identifica qué operación consume, cuándo lo hace y por qué. Después decide si optimizar, aislar, reprogramar o escalar.
Fabric unifica datos y analítica. También unifica la factura del cómputo.
Microsoft Fabric reúne experiencias de integración, ingeniería, almacenamiento, ciencia de datos, tiempo real y Power BI sobre una plataforma común. Esa convergencia simplifica arquitectura y colaboración, pero hace que cargas muy distintas compartan recursos: un pipeline nocturno, un notebook, una consulta de warehouse, un modelo semántico y cientos de usuarios interactivos pueden competir dentro de la misma capacidad.
La conversación sobre rendimiento no puede quedarse en “va lento”. Hay que distinguir saturación de capacidad, diseño ineficiente, mala distribución de cargas, consultas pesadas, modelos sobredimensionados, refrescos coincidentes o expectativas que no corresponden al SKU. Si no se separan estas causas, la respuesta habitual es comprar más. Y comprar más antes de entender el consumo es una manera muy elegante de financiar el problema.
Síntoma: todo funciona en las pruebas
Un entorno pequeño, pocos usuarios y cargas controladas ocultan la concurrencia real. Cuando producción añade refreshes, pipelines, notebooks y consumo ejecutivo a la misma hora, aparece la contención.
Decisión: medir antes de ampliar
La aplicación Microsoft Fabric Capacity Metrics permite observar consumo, operaciones y eventos de throttling. La evidencia debe conducir a una acción sobre la carga o sobre la capacidad.
Una SKU no es solo una talla: es potencia disponible a lo largo del tiempo
Las capacidades F de Microsoft Fabric se adquieren como recursos de Azure. Cada SKU aporta un número de Capacity Units o CUs: F2 ofrece 2, F4 ofrece 4, F8 ofrece 8 y así sucesivamente. La capacidad es el fondo común de cómputo al que se asignan workspaces. Microsoft factura las capacidades F por segundo, con un mínimo de un minuto, y permite reservar capacidad anual para reducir costes en escenarios estables.
Pero el número de CUs por sí solo no responde cuántos usuarios, informes o pipelines soportará. Dos organizaciones con el mismo SKU pueden tener resultados radicalmente diferentes según complejidad, frecuencia, volumen, concurrencia, arquitectura y eficiencia de sus elementos.
Fabric puede dejarte correr más… y cobrar ese esfuerzo a tu capacidad futura
Fabric incorpora dos mecanismos que explican por qué una operación puede terminar rápidamente aunque supere momentáneamente la potencia nominal, y por qué el impacto puede aparecer después. Entenderlos evita interpretar una fotografía puntual como si fuera toda la película.
Bursting: potencia temporal
Una operación puede utilizar temporalmente más cómputo que el disponible de forma nominal en la SKU. Esto permite que cargas grandes terminen con rapidez en lugar de quedar limitadas desde el primer segundo.
No significa que el exceso sea gratuito ni infinito. Su consumo se registra y debe absorberse en el comportamiento posterior de la capacidad.
Smoothing: consumo distribuido
Fabric distribuye el consumo de las operaciones sobre intervalos futuros. Microsoft documenta una suavización mínima de cinco minutos para operaciones interactivas y de 24 horas para operaciones en segundo plano.
Una carga nocturna puede, por tanto, seguir ocupando parte de la capacidad durante el día. Mirar únicamente la hora de ejecución conduce a conclusiones equivocadas.
Traducción para negocio
Fabric permite absorber picos y terminar trabajos con rapidez, pero una sucesión continua de excesos acumula deuda de capacidad. El problema no es un pico aislado: es vivir permanentemente de la capacidad futura.
Cuando la deuda de cómputo crece, Fabric empieza a proteger la capacidad
El throttling aparece cuando las operaciones consumen más CU seconds de los que permite la capacidad. Fabric no bloquea inmediatamente al superar el 100 %. Existe una protección de exceso que permite consumir aproximadamente diez minutos de capacidad futura antes de aplicar limitaciones.
Después, el control progresa. En el primer nivel se retrasan veinte segundos las nuevas operaciones interactivas. Si la deuda alcanza una hora, pueden rechazarse nuevas operaciones interactivas. Si supera el equivalente a 24 horas, pueden rechazarse también operaciones en segundo plano. La capacidad se recupera cuando la capacidad no utilizada reduce el consumo acumulado.
Esto explica un patrón desconcertante: la carga que originó el exceso pudo terminar bien, pero los usuarios reciben retrasos o rechazos después. La causa y el síntoma no siempre ocurren a la vez.
Escalera de protección
Seis preguntas antes de subir de SKU
Escalar puede ser la decisión correcta. Pero solo después de demostrar que el límite es estructural y no el resultado de unas pocas operaciones corregibles. Este recorrido evita comprar a ciegas.
¿Cuándo ocurre?
Identifica horas, días, concurrencia y duración. Separa picos ocasionales de una utilización sostenida.
¿Qué operación consume?
Localiza elemento, workspace, experiencia, usuario, duración y CUs. Evita culpar a Fabric en abstracto.
¿Es interactiva o de fondo?
El tipo de operación determina su suavización y su impacto sobre la experiencia posterior.
¿Está bien diseñada?
Revisa consulta, modelo, partición, volumen, transformación, refresco y dependencias antes de añadir potencia.
¿Puede moverse o aislarse?
Distribuye horarios, separa dominios críticos o asigna workspaces a otra capacidad cuando tenga sentido.
¿El crecimiento es permanente?
Si optimización y reparto no bastan y la demanda seguirá creciendo, escala con evidencia y un umbral de revisión.
El panel no está para admirarlo: está para decidir
La aplicación Microsoft Fabric Capacity Metrics ofrece visibilidad sobre utilización y operaciones. Su utilidad real aparece cuando el equipo convierte cada patrón en una hipótesis verificable y una acción. Un pico rojo sin contexto no es un diagnóstico.
Vista ejecutiva
Revisa utilización, tendencia, eventos de throttling, disponibilidad, crecimiento y efecto sobre usuarios o acuerdos de servicio. La pregunta es si la capacidad acompaña la demanda con un coste razonable.
No necesita detalle de cada operación, pero sí saber qué dominio causa el riesgo, qué plan existe y cuándo se tomará una decisión de inversión.
Vista operativa
Profundiza por workspace, elemento, tipo de carga, operación, hora y usuario. Compara CU seconds, duración y recurrencia. Una operación cara pero mensual puede ser menos crítica que miles de consultas pequeñas mal diseñadas.
Registra cambios y comprueba su efecto. Sin una línea base y una fecha, optimizar se convierte en una sucesión de opiniones.
No existe una tabla universal de “usuarios por SKU”
Un usuario que consulta un informe optimizado varias veces al día no equivale a un analista que lanza consultas intensivas. Un pipeline incremental no equivale a una recarga completa. Un modelo semántico bien preparado no equivale a uno que recalcula volumen innecesario. Por eso dimensionar solo por usuarios, terabytes o número de informes produce una falsa precisión.
El punto de partida debe combinar inventario de cargas, ventana de ejecución, frecuencia, tamaño, concurrencia, criticidad y crecimiento. Después conviene realizar una prueba con datos y patrones representativos, observar la métrica de capacidad y aplicar margen para picos razonables.
La prueba gratuita puede orientar, pero no debe usarse como equivalencia automática de producción. Microsoft documenta que la capacidad Trial es equivalente a F64; una solución que funciona en la prueba puede necesitar una evaluación específica antes de pasar a un SKU menor.
Inventario previo
Ocho palancas para recuperar capacidad
Microsoft recuerda que la lentitud suele deberse al diseño de un elemento y solo algunas veces al throttling. Esto obliga a comprobar ambas cosas. Optimizar no significa perseguir cada milisegundo, sino actuar sobre las cargas que más consumo, frecuencia o impacto aportan.
1. Evita recargas completas innecesarias
Aplica patrones incrementales cuando el origen y el caso lo permitan. Mover cada noche todo el histórico por comodidad puede convertirse en la mayor carga del sistema.
2. Reduce concurrencia accidental
Dependencias mal coordinadas hacen que varias tareas pesadas arranquen juntas. Ordena el flujo por necesidad real, no solo por una hora redonda compartida.
3. Revisa consultas y modelos
Filtra pronto, limita columnas, evita transformaciones redundantes y diseña modelos semánticos que respondan a preguntas reales sin duplicar lógica.
4. Ajusta frecuencias
No todo dato necesita refresco cada quince minutos. Alinea frecuencia con la decisión: operar, supervisar, cerrar o analizar tendencias.
5. Archiva o corrige lo que nadie usa
Informes, modelos y flujos huérfanos siguen consumiendo aunque nadie los consulte. El inventario y la propiedad reducen desperdicio silencioso.
6. Distribuye workspaces
Separa cargas críticas, desarrollo o dominios con perfiles incompatibles cuando el aislamiento mejore disponibilidad, gobierno o imputación.
7. Diseña para el cierre
Fin de mes, campañas, auditorías o temporadas altas necesitan escenarios de carga específicos. La media anual no protege una ventana crítica.
8. Escala cuando la evidencia lo pida
Si la demanda útil y optimizada supera de forma sostenida el recurso, subir de SKU no es un fracaso: es acompañar el crecimiento con control.
Controlar coste no es apagar la plataforma: es vincular consumo y valor
Las capacidades F se gestionan como recursos de Azure, lo que permite incorporar presupuestos, etiquetas, responsables y seguimiento financiero. En determinados escenarios pueden pausarse cuando no se necesitan y escalarse. Esa flexibilidad es útil, pero necesita automatización controlada y conocimiento de dependencias: pausar una capacidad detiene el acceso a los elementos asignados.
Un modelo FinOps razonable reparte visibilidad sin convertir cada consulta en una disputa. Coste por capacidad, dominio o producto de datos ayuda a decidir; imputar céntimos a usuarios sin contexto suele crear ruido. Combina consumo con criticidad, adopción y decisión habilitada.
La reserva anual puede reducir precio frente al consumo continuo bajo demanda, pero solo encaja cuando existe una base estable. Para picos, pruebas o cargas variables, la flexibilidad puede tener más valor que el descuento aparente.
Cuadro de control mensual
Consumo: utilización media y máxima, CU seconds, operaciones dominantes y tendencia.
Servicio: throttling, fallos, tiempos críticos y experiencia del usuario.
Valor: productos activos, usuarios, decisiones soportadas y procesos dependientes.
Cambio: nuevas cargas, crecimiento de datos, campañas, cierres y proyectos próximos.
Acción: optimizar, retirar, reprogramar, aislar, reservar, pausar o escalar con responsable y fecha.
Una capacidad única simplifica. Varias capacidades aíslan. Ninguna opción es gratis.
Microsoft permite crear varias capacidades y asignar workspaces a cada una. Separar puede proteger cargas críticas, regiones, unidades o entornos, pero también fragmenta recursos: una capacidad ociosa no presta automáticamente sus CUs a otra saturada. La topología debe responder a riesgo, gobierno y economía.
Capacidad compartida
Ventajas: mayor aprovechamiento del fondo común, administración sencilla y menos fragmentación.
Riesgos: una carga agresiva puede afectar a otras áreas; imputar consumo y prioridad resulta más complejo.
Encaja: cuando los perfiles son compatibles, existe gobierno central y la organización puede coordinar cargas.
Capacidades separadas
Ventajas: aislamiento de rendimiento, facturación diferenciada, autonomía y límites claros.
Riesgos: recursos ociosos, más administración y posible sobredimensionamiento de cada isla.
Encaja: para cargas críticas, regiones, clientes, cumplimiento o dominios con demanda incompatible.
Fabric necesita ingeniería, gobierno y conocimiento del negocio
Ayesa conecta arquitectura de datos, Azure, Microsoft Fabric, Power BI, seguridad, IA y aplicaciones empresariales. Esto permite dimensionar desde los procesos y decisiones que consumen el dato, no desde una calculadora aislada.
De la prueba a producción sin el clásico salto de fe
Prioriza casos
Selecciona decisiones de negocio y productos de datos con propietario, audiencia y valor reconocible.
Inventaría cargas
Documenta volumen, frecuencia, concurrencia, transformaciones, consultas, modelos y ventanas críticas.
Prueba con realidad
Utiliza datos, usuarios y patrones representativos; simula cierres y picos, no solo una demostración tranquila.
Mide y corrige
Observa Capacity Metrics, localiza operaciones dominantes y optimiza diseño, frecuencia y reparto.
Dimensiona con margen
Elige SKU y topología para la carga útil, crecimiento previsto y tolerancia al riesgo demostrados.
Opera y revisa
Asigna alertas, responsables, presupuestos y revisión periódica. La capacidad cambia con cada nueva carga.
Lo que no deberías hacer con una capacidad Fabric
Copiar el tamaño de otra empresa
La misma plantilla tecnológica puede tener volumen, concurrencia y calidad de diseño completamente distintos. La referencia externa orienta; tu telemetría decide.
Usar la F64 por defecto
F64 tiene implicaciones útiles para visualización de Power BI por usuarios Free, pero eso no la convierte automáticamente en el tamaño correcto de cómputo.
Mirar solo el porcentaje máximo
Bursting y smoothing hacen que el tiempo importe. Analiza duración, acumulación, tipo de operación y efecto posterior.
Escalar cada vez que algo va lento
La lentitud puede estar en el diseño del elemento. Confirma throttling y revisa la carga antes de aumentar coste recurrente.
Dejar la capacidad sin propietario
Cuando cualquiera crea cargas y nadie responde por consumo, la saturación se convierte en una sorpresa colectiva. Cada workspace, producto y capacidad necesita responsabilidad técnica y de negocio.
El coste correcto es el coste por resultado fiable
Comparar únicamente precio mensual de SKU puede favorecer una capacidad pequeña que genera esperas, fallos y horas de soporte, o una grande que oculta ineficiencias. El caso económico debe sumar capacidad, almacenamiento, transferencia cuando corresponda, licencias de usuario, implantación, operación y mejora continua.
Calcula primero el coste de continuidad: la capacidad necesaria todos los días para sostener cargas recurrentes y consumo interactivo. Sobre esa base modela picos conocidos, como cierres financieros, campañas, nuevas fuentes, entrenamiento de modelos o ampliación de usuarios. La media puede esconder periodos breves en los que el servicio resulta especialmente valioso y la tolerancia al fallo es mínima.
Después separa consumo productivo de desperdicio. Una operación intensa puede estar plenamente justificada si alimenta una decisión crítica; una carga pequeña repetida miles de veces puede consumir sin aportar nada. Relacionar workspace, propietario, producto de datos y audiencia permite discutir valor sin caer en el recorte indiscriminado.
Incluye también el coste humano. Una capacidad inestable genera reintentos, investigación, incidencias, explicaciones a usuarios y trabajo fuera de horario. Una capacidad enorme pero sin gobierno permite que el desperdicio crezca hasta ocupar el nuevo margen. Presupuesta observabilidad, soporte y optimización como parte del servicio, no como una sorpresa posterior.
Finalmente, acuerda umbrales: cuándo optimizar una operación, separar un workspace, probar una SKU superior o considerar una reserva. Deben combinar utilización sostenida, throttling, crecimiento, criticidad y coste. Así la decisión deja de depender de la queja más ruidosa o del miedo a quedarse corto.
Trabaja con tres escenarios. El conservador mantiene el crecimiento actual y solo reconoce ahorros demostrables. El probable incorpora nuevas cargas ya aprobadas y mejoras de eficiencia validadas. El escenario de tensión simula cierre, picos de usuarios, retrasos de origen o ejecución simultánea de trabajos. Compararlos ayuda a elegir margen sin convertir el peor caso imaginable en la factura permanente. Revisa las hipótesis cada trimestre y cuando entre un dominio importante.
Evita además justificar la inversión con beneficios que la plataforma no controla por sí sola. Fabric puede acelerar disponibilidad y reutilización del dato, pero la decisión mejorará únicamente si existen definiciones comunes, responsables y adopción. Vincula cada beneficio a un proceso, una audiencia, una línea base y una forma de comprobarlo.
Frente a ese coste coloca valor: consolidación de plataformas, menor mantenimiento, reducción del tiempo para disponer de datos, automatización, decisiones más rápidas, reutilización del dato y retirada de sistemas. Mantén separados ahorro, capacidad liberada e ingresos para evitar contar dos veces el mismo beneficio.
Modelo de coste anual
Capacidad F bajo demanda o reservada.
Licencias Power BI necesarias según SKU y rol.
Almacenamiento, red y servicios Azure relacionados.
Diseño, migración, integración, seguridad y gobierno.
Administración, FinOps, soporte y optimización.
Añade: coste de indisponibilidad, informes lentos, duplicación y decisiones tardías del modelo anterior.
No optimices Fabric como si todos los motores hicieran el mismo trabajo
La capacidad es común, pero los patrones no. Para tomar decisiones útiles hay que analizar cómo ingiere, transforma, almacena, consulta y presenta datos cada experiencia. Una receta aplicada indiscriminadamente puede ahorrar CUs en un punto y trasladar el coste o la latencia a otro.
Data Factory y pipelines
Revisa si las cargas son completas o incrementales, cuántas actividades se ejecutan en paralelo, qué esperas y reintentos existen y si varias canalizaciones replican la misma extracción. La orquestación debe seguir dependencias reales. Lanzar todo a medianoche porque siempre se ha hecho así crea concurrencia artificial y dificulta localizar el origen de un exceso.
Agrupa procesos por criticidad y ventana. Una carga regulatoria con hora límite no debe competir sin control con una actualización exploratoria. Documenta qué sucede si falla una etapa: reanudar desde un punto seguro suele ser más eficiente que repetir todo el recorrido.
Data Engineering y notebooks
Los trabajos Spark pueden variar mucho según volumen, particionado, transformaciones, librerías y configuración. Identifica lecturas completas, movimientos evitables y operaciones que fuerzan cálculos amplios. Un notebook que funcionó con la muestra inicial puede cambiar de comportamiento cuando crece el histórico.
Separa experimentación de producción y establece límites para ejecuciones ad hoc. Las opciones específicas de autoscale para Spark deben evaluarse por separado porque cambian el comportamiento económico de esa carga.
Warehouse y consultas SQL
Analiza consultas por frecuencia, duración, datos leídos y valor. Una consulta ejecutiva crítica merece prioridad; una exploración que recorre todo el histórico cada pocos minutos necesita límites o rediseño. Los filtros, relaciones, agregaciones y la concurrencia afectan al consumo.
No confundas rapidez ocasional con eficiencia. Bursting puede hacer que una consulta termine deprisa mientras acumula consumo que se manifestará después. Compara patrones durante varios días e incluye cierres y picos.
Power BI y modelos semánticos
El tamaño del modelo, modo de conexión, refrescos, medidas y concurrencia condicionan la experiencia. Un informe lento no demuestra saturación; puede contener visuales excesivos, cálculos costosos o interacciones que disparan numerosas consultas.
Relaciona las métricas con momentos concretos de uso. Reduce duplicidad y acuerda dimensiones y medidas compartidas. El autoservicio funciona mejor cuando reutiliza una base gobernada.
Real-Time Intelligence y cargas continuas
Los flujos continuos exigen observar volumen, retención, consultas y picos. La pregunta no es solo cuánto dato entra, sino qué latencia necesita el negocio. Llevar todo a tiempo real sin una decisión que lo justifique encarece la plataforma.
Define niveles: alertas que requieren segundos, supervisión que admite minutos y análisis que puede esperar. Así reservas la capacidad rápida para el dato que cambia una acción.
La decisión cambia según el problema que estés intentando resolver
No es igual dimensionar una primera plataforma que corregir una capacidad saturada o absorber un crecimiento previsto. En cada caso, la evidencia y el tipo de actuación son distintos.
ESCENARIO 1
Primera implantación
Todavía no existe telemetría de producción. Dimensiona mediante inventario, prueba representativa y supuestos explícitos. Prioriza pocos productos de datos y evita migrar todo el legado sin demostrar necesidad.
Incluye una revisión temprana: la capacidad inicial es una hipótesis que se valida con uso, no una talla grabada en piedra.
ESCENARIO 2
Saturación recurrente
Capacity Metrics muestra deuda y throttling en franjas repetidas. Localiza el pequeño conjunto de operaciones dominante, corrige diseño y concurrencia y observa el efecto durante un periodo comparable.
Si la carga útil sigue superando el recurso, escala o separa. Retrasar una inversión necesaria también tiene coste.
ESCENARIO 3
Crecimiento programado
Nuevas áreas, fuentes o casos de IA aumentarán la demanda. Modela escenarios con volumen, frecuencia y usuarios, y prueba cargas críticas antes del lanzamiento.
Decide si ampliar la capacidad común o aislar el nuevo dominio. Incluye coste operativo y gobierno, no solo precio de SKU.
La capacidad se administra todos los días, no cuando llega el error
El administrador necesita umbrales y alertas, pero no puede ser el único responsable. Los propietarios de producto deciden frecuencia, alcance y prioridad; ingeniería corrige el diseño; seguridad controla accesos y ciclo de vida; finanzas entiende el coste; y negocio confirma qué carga aporta valor.
Una revisión semanal se centra en anomalías: operaciones dominantes, throttling, fallos, crecimientos abruptos o elementos sin propietario. La revisión mensual observa tendencia, presupuesto, capacidad, adopción y próximos cambios. Trimestralmente conviene revisar topología, reservas y retirada de cargas.
La disciplina evita el acceso sin límites y también la burocracia que frena cualquier exploración. Permite experimentar en espacios controlados y promover a producción solo aquello que cumple criterios de calidad, seguridad, eficiencia y soporte.
Responsabilidades mínimas
Administrador: disponibilidad, asignación, alertas y actuación ante saturación.
Ingeniería: rendimiento, dependencias, pruebas y corrección.
Propietario: utilidad, calidad, audiencia, frecuencia y ciclo de vida.
Finanzas: presupuesto, reserva, previsión y lectura coste-valor.
Dirección: prioridades, conflictos entre dominios e inversión.
Dudas sobre capacidad y rendimiento de Fabric
¿Qué son las Capacity Units?
Son la medida de potencia de cómputo disponible en cada SKU Fabric. El consumo de las operaciones se expresa mediante CU seconds.
¿Una capacidad al 100 % está bloqueada?
No necesariamente. Fabric incorpora bursting, smoothing y protección frente a exceso. El throttling depende de la deuda acumulada en las ventanas documentadas.
¿Por qué el problema aparece después?
El smoothing distribuye consumo sobre periodos posteriores. Una carga terminada puede seguir contribuyendo a la utilización y afectar a operaciones nuevas.
¿Subir de SKU siempre mejora?
Aporta más cómputo, pero no corrige consultas, modelos o cargas ineficientes. Debe hacerse después de confirmar que el límite es de capacidad.
¿F64 es obligatoria?
No para usar todas las experiencias Fabric. F64 o superior permite que usuarios Free con rol Viewer consuman contenido Power BI; por debajo necesitan Pro, PPU o prueba individual.
¿Se puede tener más de una capacidad?
Sí. Puede ser útil para aislar regiones, dominios o cargas críticas, aunque puede reducir el aprovechamiento conjunto de recursos.
¿Cómo sé si existe throttling?
Capacity Metrics muestra eventos y niveles. También pueden aparecer mensajes como CapacityLimitExceeded. La lentitud por sí sola no lo demuestra.
¿Cuál es el primer paso?
Inventariar cargas y decisiones, medir un patrón representativo y localizar las operaciones que explican consumo y experiencia antes de elegir o cambiar SKU.
Continúa desde la arquitectura o desde el proceso
Fabric y Dynamics 365
Cómo integrar datos de Finance y Business Central en una plataforma analítica común.
ERP e inteligencia artificial
El papel del dato conectado para Copilot, agentes y decisiones empresariales.
Power Platform y ERP
Automatización, aplicaciones y procesos conectados con el núcleo empresarial.
Fuentes oficiales Microsoft consultadas
La información se ha contrastado con la documentación pública de Microsoft sobre licencias y capacidades Fabric, bursting, smoothing y throttling, la aplicación Capacity Metrics, la optimización de capacidad y la planificación del tamaño. Las políticas, precios y funcionalidades pueden cambiar; conviene validar la configuración vigente de cada tenant y región.
¿Tu capacidad Fabric está ajustada o simplemente sigue funcionando?
Podemos analizar telemetría, arquitectura, cargas, licencias y coste para identificar optimizaciones y dimensionar el crecimiento con evidencia.
Cuéntanos qué SKU utilizas, qué experiencias están activas y dónde aparece la fricción. Prepararemos una conversación centrada en decisiones concretas, prioridades operativas y oportunidades de ahorro verificables.
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)