7 min. de lectura

Un logístico del norte de Alemania ha reducido su factura de multi-nube en un 31 por ciento. No a través de un nuevo proveedor, no a través de una migración, sino a través de tres cuartos de disciplina FinOps, un equipo con responsabilidad real de presupuesto y una etiquetado que no ganaría aplausos en ninguna conferencia.

Lo más importante en resumen

• La multi-nube no se paga por sí misma: Quien ejecuta tres hiperescaladores en paralelo sin costo de asignación en el nivel de carga de trabajo, financia principalmente la falta de transparencia. Los contratos, instancias reservadas y niveles de almacenamiento corren en contra de sí mismos.
• La inteligencia de costos es un equipo, no una herramienta: Las estrategias de etiquetado fallan rara vez por la software. Fallan porque nadie decide con responsabilidad qué dimensión recibe dinero y cuál no.
• La logística hace que el estrés se vea más temprano: Las picos de carga de trabajo estacionales y los márgenes bajos no permiten un camino FinOps medio. Lo que los transportistas deben aprender en semanas, otros sectores desplazan años.

Relacionado:38 por ciento menos costos de nube en la fabricación de maquinaria  /  FinOps Estudio 2026: Brokerage como ruta predeterminada

Donde la factura de multi-nube explota sin embargo

El logístico al que me refiero, ejecuta cargas de trabajo en AWS, Azure y una plataforma europea menor para datos de proveedores regulados. Tres contratos, tres períodos de facturación, tres semánticas de etiquetado diferentes. La factura se encontraba a finales de 2024 en alrededor de 4,2 millones de euros al año, tendencia al alza, ya que más envíos producen más telemetría.

El problema no era el precio de las instancias individuales. El problema era que nadie podía asegurar con seguridad qué departamento causaba cuánto. Las instancias reservadas se acabaron sin que alguien reaccionara. El almacenamiento en una región crecía un 6 por ciento cada mes sin que alguien preguntara si la clase de datos era correcta. Un equipo ordenó durante seis semanas de dupla capacidad de proceso para un proyecto de migración, ya que la responsabilidad de la desactivación no era clara.

Las brechas concretas del estado real se enumeraron: 27 por ciento de las instancias de proceso en ejecución no tenían un tag útil para la ubicación de costos o producto. 14 por ciento de los volúmenes de almacenamiento estaban sin acceso en la clase más cara durante más de 90 días. 1,9 millones de euros correspondían al año al costo de salida y cross-región que nadie podía asignar a una aplicación. Esto no son estimaciones, esto fue la situación inicial en los primeros informes.

Cómo el equipo Cost-Intelligence se estructuró sin un nuevo tool

La primera idea en la casa fue comprar un nuevo tool. Hay proveedores cuyos pitches en este segmento son muy efectivos. El equipo evaluó dos de ellos y finalmente decidió conscientemente no adquirir ninguno. No porque los tools fueran malos, sino porque no resolvían el problema fundamental: quién toma decisiones en el grupo de manera obligatoria sobre qué dimensión se etiqueta.

En lugar de eso, siguieron tres pasos. Primero, una página de etiquetado con cuatro tags obligatorios (ubicación de costos, producto, entorno, propietario), más tres opcionales para cargas de trabajo de cumplimiento. Todo lo demás se eliminó. Quien quería crear un nuevo tag necesitaba la aprobación de la relación financiera. Dos páginas de documentación, aprobadas por el CIO y acceptadas por la dirección.

Segundo, el principio del cuenta de recopilación. Un job de Cron marca desde el cuarto trimestre todas las recursos sin tags obligatorios. Después de siete días, se cargarían los costos de esas recursos en un cuenta de recopilación interna, que es el responsabilidad del equipo de plataforma. De repente, el equipo de plataforma tenía un incentivo para llamar a las divisiones detrás de ellas, en lugar de solicitar amablemente.

Tercero, revisiones de costos mensuales con propietarios, no con tools: cada division vería en un PDF único sus costos del último 60 días, segmentados por producto y región. No hay paneles, no hay análisis detallados. Reducido conscientemente, ya que el debate es más importante que la visualización.

Parece simple. Es así. El impacto no se encontraba en la metodología, sino en que la metodología persistió después de cinco meses.

Lo que el etiquetado no resuelve solo

El etiquetado es la entrada. Aporta transparencia a la medición de inventario, pero no mucho si las decisiones sobre compromiso y reserva permanecen en el departamento de compras, que no conoce la carga de trabajo. En nuestro ejemplo, esto fue la segunda ola de reforma: las instancias reservadas y los planes de ahorro se transferieron a los propietarios de la plataforma, no al departamento de compras central. Motivo: quien asume el riesgo técnico también debe poder evaluar el riesgo comercial.

Esto tiene dos efectos. Primero, se llevó a cabo la primera vez una discusión honesta sobre cuáles cargas de trabajo son realmente planificables y cuáles no. Segundo, se cancelaron las instancias reservadas que un comprador anterior había renovado por motivos de conformidad, aunque la division había descontinuado el producto.

Este fue uno de estos victorias silenciosas que no aparecen en ninguna nota de prensa. Suma ahorrada: alrededor de 380.000 euros al año. No tecnología nueva, no cambio de arquitectura. Solo alguien que finalmente asumió la responsabilidad.

Los tres trade-offs que nadie aborda de manera transparente

Multi-Cloud FinOps se vende en muchos decks como un programa de eficiencia. En realidad, es una consecuencia de trade-offs que un grupo deja de manera consciente. La primera es la estandarización contra la velocidad: quien pasa por la etiquetado política y la gestión de compromiso centralmente retrasa a los equipos individuales. Quien quiere velocidad, acepta pérdidas de precisión. No hay un camino que proporcione ambas cosas. Quien los promete, nunca ha logrado hacerlo.

El segundo trade-off es la cobertura de tools contra la autonomía. Los tools de FinOps especializados alivian al equipo, pero transfieren el conocimiento al tool en lugar de al cerebro. Si el contrato con el proveedor de tools termina, la Cost-Intelligence se pierde rápidamente. El tercero: el compromiso reservado contra la flexibilidad. Un plan de ahorro de tres años reduce costos, pero ata al grupo a una arquitectura que puede estar equivocada en tres años. Quien corre agresivamente con reservas debe calcular honestamente lo que cuesta una cancelación anticipada.

Estos trade-offs no se pueden automatizar. Una práctica de FinOps que los aborda de manera transparente es mucho más sostenible que una que promete todos tres al mismo tiempo.

¿Qué queda después del hype?

FinOps ha estado siendo el tema de moda en cada conferencia sobre nube durante los últimos dos años. Mucho de esto es justificado, pero algunos aspectos son exagerados. Lo que sigue siendo relevante después del ejemplo del logístico es, de manera inesperada, poco metódico y, de manera inesperada, mucho más organizativo. Una política de etiquetado que no se ha desarrollado. Un equipo de plataforma que se ha convertido en el responsable de recursos no etiquetados. Responsabilidad de propietario para compromiso. Revisiones mensuales con personas, no con paneles de control.

El resultado al cabo de tres cuartos: costos multi-nube 31% más bajos, una mejor precisión en el pronóstico y una discusión significativamente más cercana a la realidad sobre nuevas iniciativas de nube. Si alguien propone un proyecto ahora, debe responder a la pregunta de quién llevará el compromiso reservado en caso de que la adopción no se mantiene. Esta pregunta no existía antes.

Quien espera encontrar una solución única y efectiva (silver bullet) aquí no lo encontrará. Quien reconoce que la inteligencia financiera es principalmente una cuestión de responsabilidad, tiene un camino realista y práctico.

Preguntas frecuentes

¿Cuándo vale la pena un herramienta de FinOps dedicada frente a herramientas integradas?

Cuando se cumplen tres condiciones: más de dos Hyperscalers, más de 50 propietarios responsables y un presupuesto de nube de más de cinco millones de euros al año. Bajo estas circunstancias, una solución propia con exploradores de costos nativos y una administración de etiquetado disciplinada suele ser más económica y sostenible.

¿Cuánto tiempo tarda una administración de etiquetado en mostrarse efectiva?

Las primeras reducciones en costos se pueden observar después de ocho a doce semanas, ya que el modelo de cuenta de recopilación obliga a los propietarios de la plataforma a asignar rápidamente recursos sin etiquetar. Los efectos estructurales sobre Instancias Reservadas y clases de almacenamiento se producen generalmente después de dos a tres cuartos.

¿Quién debe asumir la responsabilidad de los propietarios de Instancias Reservadas?

Los responsables de la plataforma o producto que conocen técnicamente la carga de trabajo. Un ejecutivo de TI sin contexto de la carga de trabajo suele tomar decisiones defensivas y extiende contratos con áreas no operadas. Esto es el error más costoso en la práctica.

¿Cuántos tags obligatorios son útiles?

Cuatro a cinco tags obligatorios son suficientes para la mayoría de las empresas. Más tags pueden causar lagunas, ya que nadie mantiene todos los campos de manera consistente. Los tags más útiles suelen ser centro de costos, producto, entorno y propietario, además de uno para la clase de cumplimiento si se incluyen cargas de trabajo reguladas.

¿Qué pasa con los costos de salida y transregionales?

Los costos de salida son la posición más incomoda, ya que suelen tener dos propietarios: el sistema que envía y el que recibe. La práctica recomendada es cargar los costos de salida al trabajo que envía y llevarlos explícitamente como una línea propia en los revisiones mensuales. De lo contrario, desaparecen como un gasto invisible en el presupuesto general.

Más del MBF Media Netzwerk

Fuente de la imagen: generada por IA (Mayo 2026), C2PA certificado en la imagen