En nuestro último artículo de Microsoft Fabric Planning dejamos pendiente una de las preguntas que inevitablemente aparecen cuando empezamos a hablar de esta nueva funcionalidad de Fabric:
Hoy toca responderla.
En el ámbito del EPM (Enterprise Performance Management) estamos acostumbrados a modelos en los que cada persona necesita una licencia: una para quien construye el presupuesto, otra para quien introduce información y, muchas veces, otra para quien simplemente consulta los resultados. En Fabric Planning el planteamiento es distinto: el coste depende de cómo participa cada usuario en el proceso y se consume directamente sobre nuestra capacidad de Microsoft Fabric, sin necesidad de contratar ninguna licencia adicional.
Fabric Planning distingue tres perfiles: Viewer, Stakeholder y Planner, pero no tenemos que decidir de antemano qué “licencia” asignamos a cada persona. El propio servicio determina dinámicamente el rol en función de las acciones que realiza cada usuario.
Consultar información tiene un coste. Participar en el proceso tiene otro. Y construir el propio modelo de planificación, otro diferente.
La forma más sencilla de entender el modelo es olvidarnos por un momento de las licencias y pensar en qué hace realmente cada persona.
Un Viewer consulta. Puede abrir el plan, analizar la información, filtrar datos o comparar escenarios, pero no introduce ni modifica información. Es el perfil natural para responsables de área, directivos o cualquier usuario que necesita conocer el presupuesto o el forecast sin participar directamente en su elaboración.
Un Stakeholder participa. Puede introducir datos, hacer writeback, trabajar con escenarios, comentar, colaborar o intervenir en aprobaciones. Y desde hace poco también puede crear y editar PowerTables e informes de Intelligence sin convertirse por ello en Planner.
El Planner es quien construye el modelo de planificación. Aquí es donde normalmente encontraremos a los equipos de FP&A y a aquellas personas responsables de diseñar y mantener el sistema.
Como veremos más adelante, cada uno de estos roles mantiene reservada una parte diferente de la capacidad mientras su sesión está activa:
Y estos números nos cuentan bastante bien cómo está pensado el producto: hacer relativamente barato participar y concentrar el mayor consumo en las pocas personas que realmente construyen el modelo, ya que la mayoría de las personas que participan en un proceso de planificación no necesitan ser Planner.
Pensemos en un proceso presupuestario cualquiera. Podemos tener cinco personas diseñando y manteniendo el modelo, cien responsables introduciendo sus previsiones y otras quinientas consultando el resultado. Son 605 usuarios.
Pero no tendría mucho sentido pagar como si todos hicieran lo mismo.
El consumo de Fabric Planning no funciona como un contador que empieza a sumar CUs mientras estamos dentro de la aplicación y se detiene cuando salimos.
Cuando un usuario realiza una acción en Planning, se abre una sesión de 30 días asociada a su rol. Durante ese periodo, el usuario mantiene reservada la parte de capacidad que le corresponde: 0,05 CUs si es Viewer, 0,23 CUs si es Stakeholder o 1,16 CUs si es Planner. Da igual que entre una vez o que trabaje todos los días.
Esto tiene una consecuencia importante: el coste no depende de cuántos datos introduzcamos ni del tiempo que pasemos dentro de una de las hojas de Planning, sino de haber activado la sesión. Un Stakeholder que introduce diez valores y otro que realiza cientos de modificaciones a la semana mantienen el mismo consumo asociado al rol durante esos 30 días.
En cambio, cuando termina la sesión, si el usuario deja de utilizar Planning, no se inicia otra. Es decir, los periodos sin actividad no generan nuevas sesiones.
Esto encaja bastante bien con la propia naturaleza de la planificación. Pensemos en un presupuesto anual: podemos tener unos meses de mucha actividad y otros en los que buena parte de los usuarios apenas entra en la herramienta. No necesitamos mantener activa durante todo el año una licencia nominal para cada uno de ellos.
Hay otro detalle que conviene conocer. Durante esos 30 días, si un usuario realiza una acción de un nivel superior, su rol se eleva automáticamente: un Viewer que empieza a introducir información pasa a Stakeholder, y un Stakeholder que toca el modelo pasa a Planner. Al elevarse, la sesión anterior se cierra y se factura solo por la parte proporcional consumida hasta ese momento; a partir de ahí el consumo pasa al rol superior.
Lo que no podemos hacer es bajar el rol mientras la sesión está activa. Solo se sube. El rol vuelve a evaluarse cuando expira la ventana y el usuario realiza una nueva acción.
Una vez entendido lo anterior, estimar la capacidad necesaria es bastante sencillo.
Las capacidades de Fabric se expresan en CUs por segundo: una F2 dispone de 2 CUs, una F4 de 4 CUs, una F8 de 8 CUs, y así sucesivamente. Para dimensionar Planning tenemos que sumar el consumo sostenido de todos los usuarios que esperamos tener activos simultáneamente dentro de una ventana de 30 días.
Veámoslo con un ejemplo sencillo.
Imaginemos un proceso con:
El consumo asociado a esos usuarios sería:
1 × 1,16 + 10 × 0,23 + 50 × 0,05 = 5,96 CU
Con 5,96 CU, una F4 se nos queda corta: necesitaríamos una F8, y sin contar todavía el resto de cargas de trabajo de Fabric que consumen de la misma capacidad.
Hay que tener en cuenta que un solo Planner ya ocupa 1,16 de las 2 CUs disponibles en una F2, un 58 % de toda la capacidad. Por eso una F2 puede servir para probar, pero se queda muy justa en cuanto empezamos a hablar de un escenario real.
La calculadora de costes de la comunidad nos permite precisamente jugar con estas combinaciones de Planners, Stakeholders y Viewers y ver qué capacidad encaja mejor con nuestro escenario. Lo interesante es que podemos dimensionar el entorno pensando en quién va a estar realmente activo durante el ciclo de planificación, no simplemente en cuántas personas tienen acceso.
Las CUs que utiliza Planning no viven en una bolsa separada. Forman parte de la misma capacidad de Fabric que utilizan el resto de cargas de trabajo, tus notebooks, pipelines, modelos semánticos…
Eso significa que, si ya utilizamos Microsoft Fabric y nuestra capacidad tiene margen disponible, incorporar Planning no implica necesariamente escalar o comprar otra capacidad. Planning utilizará una parte de la que ya tenemos.
Pero también funciona al revés: no podemos dimensionar Planning ignorando lo que ya consume nuestro entorno. Si durante el cierre presupuestario coincide el pico de actividad de Planning con refrescos, procesos de datos y reporting, tenemos que contemplarlo.
Por eso no conviene dimensionar al límite.
Aparte del resto de cargas de Fabric, el propio módulo de Planning tiene, además del consumo asociado a las personas, procesos de cálculo, writeback y otras operaciones que también consumen capacidad. La recomendación práctica es sencilla: dejemos margen y midamos el comportamiento real durante un piloto. La propia calculadora permite añadir ese porcentaje de seguridad al dimensionamiento.
Fabric Planning también puede ejecutar procesos en segundo plano sin que haya una persona trabajando en ese momento: sincronizaciones entre planes, actualizaciones desencadenadas desde PowerTable y otros procesos automáticos.
Aquí el modelo cambia. Estos trabajos no mantienen una sesión de 30 días, sino que se contabilizan por ejecución realizada con éxito y consumen capacidad del mismo F-SKU.
La calculadora utiliza actualmente como referencia unas 2 CU/hora por ejecución, pero este dato, al igual que lo que cuenta como trigger, todavía está pendiente de confirmación definitiva. Por eso nosotros no lo tomaríamos todavía como una tarifa cerrada, sino como una variable que conviene medir durante una prueba de concepto.
En muchos proyectos su peso será pequeño frente al consumo de usuarios, pero si tenemos cientos o miles de automatizaciones al mes, merece la pena incluirlas desde el principio.
Y llegamos probablemente a la parte más importante de todo el modelo.
Optimizar el coste de Fabric Planning no consiste en perseguir al usuario para que cierre la aplicación después de introducir el presupuesto. Como hemos comentado, una vez abierta la sesión, esa ventana de 30 días ya está comprometida, y su correspondiente parte de la capacidad queda reservada.
La clave está en diseñar correctamente quién necesita hacer qué.
Si tenemos unas pocas personas construyendo el modelo, un grupo mayor de responsables introduciendo y validando información y una base mucho más amplia de usuarios que simplemente consulta los resultados, el modelo empieza a resultar especialmente interesante.
No se trata, por tanto, de limitar quién puede participar para controlar el coste.
Se trata de conseguir justo lo contrario: que muchas más personas puedan participar sin tener que pagar por todas ellas como si fueran quienes construyen el modelo de planificación.
Como hemos visto, Fabric Planning cambia bastante la conversación cuando hablamos de costes respecto a las herramientas de EPM/CPM tradicionales. En lugar de partir de un catálogo de licencias por usuario, partimos de cómo queremos organizar nuestro proceso de planificación y de quién necesita hacer qué dentro de él.
Eso no significa que no tengamos que dimensionar bien la solución. Las sesiones de 30 días, el número de usuarios activos, las automatizaciones y, sobre todo, el consumo que ya tengamos en nuestra capacidad de Fabric son factores que debemos tener en cuenta.
Pero lo que cambia de verdad no es solo la flexibilidad: es quién puede permitírselo.
Hasta ahora, una herramienta de planificación en condiciones ha sido un proyecto reservado a empresas grandes: licencias anuales por usuario, un coste por asiento que apenas distingue entre quien construye el modelo y quien solo lo consulta, y un umbral de entrada que deja fuera a buena parte de las empresas medianas. El resultado lo hemos visto muchas veces: compañías que llevan años planificando en Excel no porque no conozcan las alternativas, sino porque no pueden permitirse una herramienta específica.
Y ahí está, para nosotros, lo más interesante del producto: la planificación profesional deja de ser cosa de unas pocas organizaciones grandes, y pasa a estar al alcance de todos.
Y al final, más que saber cuánto cuesta un Planner o un Stakeholder, la pregunta que realmente nos interesa responder es otra:
¿Cuánto costaría profesionalizar nuestro proceso de planificación con Fabric Planning?
Si estás valorando dar este salto, estaremos encantados de ayudarte a aterrizarlo en un escenario real, explorando contigo cómo enfocarlo, qué capacidad necesitarías y cómo encajaría este modelo en tu entorno actual de Microsoft Fabric.
Nos vemos en el próximo capítulo para seguir profundizando en todo el potencial de Fabric Planning.
