Madurez FinOps: dónde está la mayoría de las empresas (y dónde deberían estar)
El FinOps Foundation define tres niveles de madurez: Crawl (empezar a medir), Walk (optimizar activamente) y Run (predecir y optimizar de forma continua). En nuestra experiencia con clientes de sectores variados, la mayoría están en Crawl avanzado o Walk inicial: tienen visibilidad de costes agregados, algún nivel de tagging, y algún proceso de revisión mensual. Pero muy pocas organizaciones tienen costes atribuidos a unidades de negocio con precisión suficiente para que los responsables de producto tomen decisiones de arquitectura basadas en coste unitario.
El salto de Walk a Run requiere que el coste cloud deje de ser un problema de infraestructura y se convierta en una variable del product backlog. Cuando el equipo de producto sabe que la feature que están diseñando tendrá un coste de X euros por usuario activo mensual, las decisiones de arquitectura cambian. Se evalúan alternativas. Se cuestiona si la funcionalidad justifica el coste. Eso es FinOps maduro — y requiere un cambio cultural que ninguna herramienta puede sustituir.
La trampa más frecuente en la madurez FinOps es confundir actividad con progreso. Un equipo puede generar un informe de costes semanal, tener una reunión de revisión mensual y haber implementado un dashboard de Grafana muy detallado — y seguir sin haber tomado una sola decisión de optimización relevante en seis meses. La madurez se mide en acciones tomadas con impacto cuantificado, no en procesos establecidos.
Cultura de costes: por qué el problema no es técnico
El mayor obstáculo para implementar FinOps en una organización no es la herramienta ni la taxonomía de tagging — es la falta de accountability real. En la mayoría de las empresas, el coste cloud aparece en una única línea del P&L de IT, sin desagregación por producto, equipo o feature. Los ingenieros que toman las decisiones técnicas que determinan el gasto no ven el impacto económico de esas decisiones. No por negligencia — porque el sistema no está diseñado para que lo vean.
Construir cultura de costes requiere cambiar ese sistema. Implica hacer que cada equipo de producto tenga visibilidad de su gasto cloud como parte de su dashboard operativo habitual, no en un informe separado que revisa alguien de finanzas. Implica que en las retrospectivas de sprint se revise el impacto en coste unitario de los cambios del ciclo, igual que se revisan la velocidad y los defectos. Implica que los arquitectos incluyan estimaciones de coste en sus propuestas técnicas desde el principio, no como nota al pie.
El cambio más efectivo que hemos visto en organizaciones que han dado el salto es crear la figura del FinOps practitioner embebido en los equipos de producto, no en un equipo central de infraestructura. Alguien que entiende tanto el negocio como la nube, que puede traducir entre coste técnico y valor de negocio, y que tiene presencia en los rituales del equipo (planificación, refinamiento, retrospectiva). Esa proximidad es lo que hace que la conversación sobre costes ocurra en el momento correcto.
ROI real del cloud: desmontando el mito del ahorro automático
La promesa de que la nube reduce costes IT se ha simplificado hasta convertirse en un mito que complica las conversaciones reales de valor. La nube no reduce costes por defecto — los transforma. El gasto en capex de hardware pasa a ser opex en servicios, con una flexibilidad de escala que puede reducir el coste total si la organización sabe aprovecharlo, o incrementarlo si opera en nube con los mismos patrones de consumo que tenía on-premise.
El ROI real del cloud se construye en tres dimensiones que a menudo no se calculan juntas: eficiencia económica (coste por unidad de capacidad o transacción, comparado con la alternativa), velocidad de negocio (time-to-market de nuevas capacidades, habilitado por la elasticidad de la nube) y resiliencia (reducción del coste de incidentes por disponibilidad mejorada y disaster recovery más accesible). Las empresas que calculan solo la primera dimensión suelen concluir que la nube es cara. Las que calculan las tres tienen una perspectiva radicalmente diferente.
Un ejercicio útil que hacemos con clientes: calcular el coste de las horas de ingeniería invertidas en gestionar infraestructura on-premise (patching, hardware failures, capacity planning, cabling) que en nube se eliminan o reducen radicalmente. Para empresas medianas con equipos de infraestructura pequeños, ese coste de gestión frecuentemente supera el diferencial de precio de los recursos. La comparación honesta de TCO incluye el coste del tiempo humano, no solo la factura del proveedor.
Los errores más comunes: lo que vemos en proyectos reales
El primer error es el tagging tardío. Las organizaciones suelen empezar a pensar en la estrategia de etiquetado cuando ya tienen cientos de recursos en nube sin tag, o con tags inconsistentes que hacen imposible la atribución de costes. Retroactivar el tagging es posible pero costoso — requiere inventariar recursos, definir la taxonomía, actualizar IaC existente y convencer a equipos que ya tienen otros proyectos en marcha de que es una prioridad. Implementado desde el principio, como parte de los módulos de IaC base, cuesta una fracción de ese esfuerzo.
El segundo error es overprovisioning por defecto. En nube, la tendencia natural de los ingenieros que vienen de on-premise es aprovisionar con margen amplio porque "si nos quedamos cortos es peor que pasarnos". En nube esa lógica tiene un coste: instancias sobredimensionadas que corren al 15% de utilización son dinero perdido cada mes. Las recomendaciones de rightsizing de los propios proveedores (AWS Compute Optimizer, Azure Advisor) son puntos de partida válidos, pero requieren contexto de negocio (¿hay picos de carga estacionales? ¿cuál es el coste real de una degradación?) para aplicarse con criterio.
El tercer error — y el más costoso — es no comprometer en Reserved Instances o Savings Plans cuando el consumo base está estabilizado. Las organizaciones que corren cargas predecibles 100% en on-demand por no querer comprometerse con el proveedor están pagando un premium del 30-60% sobre lo que pagarían con compromisos de 1 año. El miedo a comprometerse es comprensible en organizaciones que han vivido migraciones o reestructuraciones, pero en la práctica la mayoría tiene una base de consumo estable que hace que el coste de no comprometer sea más alto que el riesgo de sobresuscribirse.
¿Sabes cuánto te cuesta realmente cada producto en la nube?
Hacemos un diagnóstico FinOps completo: visibilidad de costes, análisis de desperdicio, estrategia de compromisos y roadmap de cultura de costes para tu organización.