Consumo bajo control
Gobernanza BTP
El problema
El consumo crece sin que nadie sepa qué subcuenta gasta qué, no hay criterio para crear entornos y la factura sorprende a fin de trimestre.
Línea: Consultoría y arquitectura
Señales de que lo necesitas
- Nadie sabe con certeza qué se está consumiendo ni a qué proyecto atribuirlo.
- Las subcuentas se crearon sobre la marcha, sin criterio de nombres ni de estructura.
- Cualquiera con permisos puede crear instancias de servicio sin aprobación.
- Hay entornos de pruebas encendidos desde hace meses.
- La conversación sobre la factura llega siempre después del gasto, nunca antes.
Qué entregamos
- Diseño de subaccounts, directorios y entitlements
- Control y atribución del consumo CPEA
- Políticas de aprovisionamiento y ciclo de vida
- Observabilidad y alertas de plataforma
El gasto en BTP no se dispara por una decisión grande. Se dispara por veinte decisiones pequeñas que nadie revisó: un entorno de pruebas que sigue encendido, una instancia creada para un piloto que terminó hace un año, una base de datos dimensionada “por si acaso”.
Cómo lo abordamos
Estructura antes que herramientas. Definimos la jerarquía de global account, directorios y subcuentas en función de cómo quieres atribuir el consumo y separar los entornos. Es la decisión más difícil de revertir: reorganizar subcuentas después implica migrar aplicaciones y suscripciones.
Entitlements como mecanismo de control. Distribuir cuotas por directorio y subcuenta convierte el control de gasto en algo estructural en lugar de una norma que alguien debe recordar. Lo que no está asignado no se puede consumir.
Atribución del consumo. Establecemos cómo se imputa cada gasto a un proyecto o a un área, de modo que la conversación presupuestaria ocurra con datos y antes de que termine el trimestre.
Ciclo de vida explícito. Cada entorno tiene dueño, propósito y fecha de revisión. Los entornos temporales dejan de ser permanentes por omisión.
Observabilidad y alertas. Configuramos avisos sobre consumo y sobre el estado de la plataforma para que las desviaciones se detecten cuando aún se pueden corregir.
Qué recibes
- Diseño documentado de la estructura de cuentas, con la justificación de cada decisión.
- Modelo de entitlements y de atribución de consumo.
- Políticas de aprovisionamiento y de ciclo de vida de entornos, listas para aplicar.
- Alertas configuradas y un cuadro de seguimiento del consumo.
- Plan de migración si la estructura actual necesita reorganizarse.
Así se ve
La gobernanza se puede automatizar con la CLI de BTP: inventariar subcuentas y asignar cuotas de forma explícita.
# Subcuentas de la cuenta global y sus entitlements
btp list accounts/subaccount
btp list accounts/entitlement --subaccount "$SUBACCOUNT_ID"
# Asignar una cuota a una subcuenta concreta
btp assign accounts/entitlement --to-subaccount "$SUBACCOUNT_ID" \
--for-service hana-cloud --plan hana --amount 1Tecnologías
SAP BTP Cockpit, directorios y subaccounts, entitlements y quotas, modelo CPEA, SAP Alert Notification Service, SAP Audit Log, SAP Cloud Transport Management.
Preguntas frecuentes
¿Qué es el modelo CPEA en SAP BTP?
El Cloud Platform Enterprise Agreement es un modelo comercial de consumo: en lugar de contratar cada servicio por separado, se compromete un importe anual que se va consumiendo según el uso real de los servicios habilitados. Aporta flexibilidad para probar servicios sin renegociar el contrato, pero exige disciplina: sin control de atribución, el saldo se consume sin que nadie sepa en qué.
¿Cómo se estructuran las subcuentas en SAP BTP?
La global account puede organizarse en directorios, y dentro de estos se crean las subcuentas. Un patrón habitual es separar por entorno (desarrollo, calidad, producción) y, cuando hay varias unidades de negocio o proyectos independientes, agrupar por directorio para poder distribuir entitlements y atribuir consumo a cada uno. La estructura debe decidirse antes de crear la primera subcuenta: reorganizarla después implica migrar aplicaciones y suscripciones.
¿Por qué crece el consumo de BTP sin que nadie lo note?
Las causas más frecuentes son entornos de pruebas que nadie apaga, instancias de servicio creadas para un piloto y nunca eliminadas, bases de datos dimensionadas por encima de lo necesario y suscripciones activas de aplicaciones que ya no se usan. Ninguna es grande por separado; el problema es que se acumulan y no hay ningún proceso que las revise.
¿Tienes este problema ahora mismo?
Reserva 30 minutos de análisis y te llevas una propuesta técnica formal con la estimación del esfuerzo. Descontable del proyecto si seguimos adelante.
Reservar sesión 1:1