Gerdau, una empresa cotizada en la Bolsa de Nueva York con 13 unidades industriales en Norteamérica, no se detuvo ahí.
Las iniciativas de FinOps suelen comenzar con el gasto en nube pública, que a menudo es el primer ámbito en experimentar un fuerte crecimiento de costes. Sin embargo, después de seis a doce meses suele aparecer una discrepancia: el coste reflejado en el dashboard de FinOps no coincide con los registros financieros del equipo de Finanzas.
Al investigar esta diferencia, suelen aparecer costes asociados a plataformas como Databricks, Kafka, MongoDB y OpenShift, que operan clusters compartidos entre diferentes equipos, además de gastos de SaaS que no están adecuadamente modelados.
La transformación de FinOps de Gerdau: de un gasto fragmentado a una responsabilidad basada en datos
Gerdau opera con un entorno tecnológico amplio y complejo. Su infraestructura abarca entornos multi-cloud —AWS, Azure y GCP— y numerosas plataformas gestionadas, como Databricks, OpenShift/ROSA, MongoDB y Kafka. Cada una cuenta con sus propios modelos de facturación, métricas de consumo y desafíos de asignación de costes.
Antes de iniciar su iniciativa de FinOps, Gerdau se enfrentaba a un panorama de costes altamente fragmentado:
- Costes de plataformas no visibles: los gastos de SaaS y de plataformas gestionadas quedaban fuera del modelo de responsabilidad y aparecían únicamente en las facturas, sin una asignación adecuada.
- Cierre financiero manual y propenso a errores: el cierre mensual requería un importante trabajo manual para extraer datos de diferentes fuentes, conciliar formatos distintos y aplicar reglas de asignación que no siempre estaban documentadas o se aplicaban de forma consistente.
- Pérdida de confianza en el chargeback: la credibilidad de la asignación de costes era limitada, ya que los equipos cuestionaban su equidad debido a la falta de una lógica auditable y repetible.
- Alcance limitado: la práctica de FinOps estaba centrada principalmente en la nube pública, dejando una parte significativa del gasto tecnológico fuera del modelo de gobierno.
El objetivo de Gerdau iba mucho más allá de simplemente “corregir los informes”. El objetivo principal era establecer un modelo operativo de responsabilidad financiera fiable tanto para Finanzas como para Ingeniería, capaz de escalar a aproximadamente 100 proyectos e iniciativas.
El insight: Cloud+ requiere una nueva arquitectura
Ampliar FinOps para incluir SaaS y plataformas gestionadas no es simplemente un desafío de integración de datos. El equipo descubrió que este modelo requiere cuatro elementos interconectados para funcionar de forma eficaz:
1. Jerarquía de costes unificada
Un modelo de costes coherente requiere una única taxonomía que abarque todas las plataformas.
Esta estructura debe funcionar con diferentes convenciones de nomenclatura, desde tags de AWS y namespaces de Kubernetes hasta labels de Databricks y nombres de bases de datos de MongoDB.
Sin una estructura común, la asignación de costes termina convirtiéndose en una serie de soluciones específicas para cada plataforma, en lugar de un sistema consistente y lógico.
2. Métricas específicas basadas en el consumo
Uno de los principales puntos de fallo es utilizar una métrica técnica incorrecta.
La métrica debe reflejar el uso real y no simplemente aquello que resulta más fácil de medir. Por ejemplo, el número de topics de Kafka por sí solo no es suficiente.
La métrica seleccionada debe representar de forma precisa el consumo real de cada plataforma.
3. Tratamiento explícito de los costes compartidos
La infraestructura compartida es inevitable.
Ignorar estos costes genera brechas en la asignación, mientras que distribuirlos de forma arbitraria puede generar conflictos internos.
Por ello, el modelo requiere reglas claras, repetibles y auditables para gestionar los costes compartidos.
4. Adopción transversal
FinOps no puede ser una iniciativa gestionada exclusivamente por Finanzas o Tecnología.
Su éxito depende de una responsabilidad compartida sobre el modelo, incluida la gobernanza continua y la gestión del backlog, por parte de ambos equipos.
Cómo se construyó: plataforma por plataforma
“Nuestra estrategia se centra en tres capacidades principales. Primero, Integración: unificamos SaaS y plataformas de datos directamente en Pier Cloud, nuestra plataforma de FinOps. Segundo, Escala: ampliamos nuestro modelo más allá de la nube pública para incorporar los costes de SaaS y de plataformas bajo un único framework, haciendo que la visibilidad sea consistente y accionable. Tercero, Automatización financiera: al integrar Pier Cloud con SAP Ariba, transformamos la asignación de costes de una tarea mensual y manual en un proceso completamente automatizado de principio a fin.”
— Thais Minelvino, Global IT Infrastructure & Operations Manager
ROSA / OpenShift
La asignación de costes de OpenShift se gestiona a nivel de namespace e incorpora metadatos basados en tags.
Uno de los principales desafíos era el coste de los workers no asignados, que representa infraestructura que no puede atribuirse fácilmente a un equipo o proyecto específico.
La solución consistió en establecer reglas claras de distribución tanto para los costes compartidos como para los costes no asignados.
Además, se automatizó un backlog de gobernanza para identificar y poner de manifiesto los recursos sin tags y facilitar su corrección operativa, pasando de una simple visualización en dashboards a una gestión activa.
Kafka
Gerdau evolucionó su modelo de asignación de costes de Kafka, pasando de un proxy sencillo a un enfoque basado en el consumo real.
Inicialmente, los costes se asignaban en función del número de topics, lo que ofrecía una visibilidad limitada sobre el consumo real de cada equipo.
Gerdau sustituyó este enfoque por un modelo volumétrico basado en el volumen de mensajes y el throughput de los topics y clusters.
El resultado fue una asignación más precisa y transparente de los costes de la infraestructura de Kafka, proporcionando a los equipos una visión clara de su consumo real y reduciendo significativamente las discrepancias relacionadas con la atribución de costes.
MongoDB
MongoDB presentaba un desafío habitual en entornos con clusters compartidos: numerosos proyectos utilizaban la misma infraestructura, lo que hacía imposible separar claramente los costes a nivel de facturación.
Para resolverlo, se desarrolló una metodología que integra los datos de facturación con métricas de consumo de las bases de datos.
Esto permitió calcular porcentajes de coste específicos para cada proyecto, creando un modelo técnicamente sólido y completamente auditable.
Resultado: los costes de MongoDB se redujeron aproximadamente un 42 % tras mejorar la visibilidad y aplicar acciones de optimización específicas.
Databricks
La introducción de diferentes precios de DBU según el tipo de servicio y el nivel de descuento añadió complejidad que una simple asignación basada en el gasto bruto no podía resolver.
Para abordarlo, se desarrolló un nuevo modelo que proporciona visibilidad a nivel de DBU conectando los datos de consumo con proyectos específicos y teniendo en cuenta las diferencias de precio según el nivel de servicio.
De forma especialmente relevante, estos datos de consumo y costes se vincularon con la economía unitaria, permitiendo a los equipos de Ingeniería comprender el coste real de los productos que están desarrollando.
Resultado: los costes de Databricks se redujeron aproximadamente un 49 % tras mejorar la visibilidad y aplicar acciones de optimización específicas.
Qué cambió: resultados que realmente importan
Ampliar el alcance de FinOps para incluir Cloud+ —multi-cloud, SaaS y plataformas gestionadas— generó resultados significativos en tres dimensiones principales:
1. Gobernanza
- Las reglas de asignación se formalizaron como procesos explícitos, documentados y repetibles.
- El proceso de cierre mensual pasó de la conciliación manual a la distribución automatizada.
- La gestión de recursos sin tags pasó de una corrección reactiva a un backlog operativo proactivo.
2. Confianza
- Las discrepancias disminuyeron porque los equipos podían comprender la lógica utilizada para asignar los costes y los costes compartidos se distribuían según reglas definidas, en lugar de criterios subjetivos.
- Comenzó a establecerse un consenso entre los costes reportados por Finanzas y la visión de esos costes por parte de Ingeniería.
3. Valor
- Conectar señales de consumo técnico —como DBU consumidas, volumetría de Kafka y utilización de namespaces— directamente con la asignación de costes cambió el nivel de las conversaciones.
- El foco pasó de preguntar simplemente “¿por qué está aumentando nuestra factura de cloud?” a analizar estratégicamente “¿cuál es el coste real de cada iniciativa y está generando suficiente valor?”.
4. Escalando el chargeback mediante automatización
Gerdau transformó su proceso de chargeback de una operación altamente manual a un workflow de FinOps automatizado y escalable.
- 78 % menos esfuerzo operativo
336 horas → 72 horas - 28 % más proyectos gestionados
302 → 386 proyectos - 100 % de automatización del proceso
20 hojas de cálculo → 0
Al automatizar de principio a fin la asignación y conciliación de costes, Gerdau redujo significativamente el esfuerzo operativo necesario para ejecutar su ciclo de FinOps, al mismo tiempo que aumentó el número de proyectos que podía gestionar.
“Una parte importante del cambio vino de la automatización. Lo que antes era un trabajo manual de asignación y conciliación ahora se gestiona de principio a fin mediante el modelo, reduciendo significativamente el tiempo necesario para ejecutar todo nuestro ciclo de FinOps.”
— Thais Minelvino, Global IT Infrastructure & Operations Manager
Lo que no funciona: lecciones que merece la pena conservar
Estas son algunas de las principales lecciones aprendidas —en muchos casos, de la forma más difícil— sobre cómo construir un modelo eficaz de asignación de costes.
Reglas fundamentales para un chargeback eficaz
- Las métricas precisas no son negociables: Nunca se debe implementar un chargeback de SaaS sin una métrica de asignación que refleje con precisión el consumo real. Las métricas inexactas serán rechazadas, con razón, por los equipos que consumen los servicios. Definir correctamente la métrica técnica es la base fundamental del modelo.
- Reglas explícitas para los costes compartidos: Los enfoques no documentados o inconsistentes para distribuir los costes de infraestructura compartida generan conflictos. Las reglas claras y explícitas para los costes compartidos son necesarias para evitar problemas que puedan comprometer todo el modelo de asignación. La gobernanza y el backlog operativo son críticos
- Los dashboards no son suficientes: El valor de un dashboard de asignación disminuye cuando existen problemas de gobernanza sin resolver, como una baja adherencia a las políticas de tagging. Un informe visualmente completo pierde valor si pone de manifiesto una brecha de credibilidad. El trabajo operativo —identificar recursos sin tags, asignar responsables y garantizar su resolución— es tan importante como la propia capa de reporting.
El siguiente paso: ampliar el alcance
La expansión del modelo Cloud+ continúa, con varias iniciativas clave en el roadmap:
- GitLab: la siguiente fase contempla implementar chargeback, partiendo del modelo de gobierno de licencias ya establecido.
- Datadog: se está revisando la automatización de la asignación de costes después de las limitaciones iniciales provocadas por las restricciones de la API.
- Microsoft 365: el foco está en la optimización de licencias y en garantizar una visibilidad continua a medida que el alcance incorpora herramientas de productividad.
Pier Cloud colaboró con Gerdau en el desarrollo e implementación del modelo operativo Cloud+.
La solución integra capacidades de la plataforma para la ingesta de datos, la asignación automatizada de costes y el reporting de economía unitaria, junto con la experiencia necesaria para hacer operativo el modelo de forma simultánea en múltiples plataformas SaaS y gestionadas.
La arquitectura técnica subyacente —basada en una taxonomía unificada, modelos de métricas específicos por plataforma, tratamiento de costes compartidos y automatización de la gobernanza— está impulsada por el Agentic AI for FinOps de Pier Cloud.
La plataforma está diseñada para gestionar la complejidad que aparece cuando FinOps va más allá de la nube pública.
Este caso demuestra que Cloud+ no es simplemente una cuestión de ampliar la ingesta de datos. Para lograr una responsabilidad financiera a escala se necesitan tanto una plataforma como un partner capaces de gestionar modelos de costes robustos y adaptados a la complejidad real de los entornos tecnológicos modernos.
