So behalten Sie die Kontrolle über Ihre SAP Business Technology Platform.
In Teil 1 dieser Blogreihe haben wir die SAP BTP in die SAP-Gesamtarchitektur eingeordnet. In Teil 2 ging es um Lizenzierung und Kosten. Jetzt wird es operativ: Wie steuert man die BTP im Alltag?
Die Antwort ist das SAP BTP Cockpit – die zentrale Verwaltungsoberfläche für Accounts, Services, Berechtigungen, Entitlements, Monitoring und Governance. Dabei verwenden wir durchgehend die offiziellen englischen SAP-BTP-Begriffe wie Global Account, Directory, Subaccount, Entitlements, Service Plans und Role Collections.
Was ist das SAP BTP Cockpit?
Das SAP BTP Cockpit ist die Verwaltungskonsole für die SAP Business Technology Platform und bietet Zugriff auf zentrale Administrations- und Governance-Funktionen:
- Account-Verwaltung: Global Accounts, Directories und Subaccounts anlegen und verwalten.
- Service-Management: Entitlements zuweisen, Service-Instanzen erstellen und konfigurieren.
- User-Management: Platform Users und Business Users verwalten, Role Collections zuweisen und Identity Provider konfigurieren.
- Monitoring: Verbrauch und Ressourcennutzung überwachen sowie Alerts konfigurieren.
- Environments: Cloud Foundry Orgs/Spaces, Kyma-Cluster und ABAP-Instanzen verwalten.
Quelle/Hinweis: SAP Help Portal – SAP BTP Cockpit
Quelle: SAP
Das Account-Modell: Global Account, Directory, Subaccount
Das Account-Modell der SAP BTP ist hierarchisch aufgebaut. Das Verständnis dieser Hierarchie ist entscheidend für eine saubere Governance.
Quelle: SAP
Ebene | Beschreibung | Analogie |
Global Account | Oberster Container. Repräsentiert in der Regel den Vertrag bzw. die kommerzielle Beziehung mit SAP und enthält Entitlements, Verbrauchsinformationen und zentrale Account-Strukturen. | Das Unternehmen als Ganzes |
Directory | Optionale Gruppierungsebene unterhalb des Global Accounts. Dient der Organisation nach Geschäftsbereichen, Regionen, Projekten oder Verantwortungsbereichen und kann mit Features wie Entitlements oder Authorizations genutzt werden. | Abteilung / Geschäftsbereich |
Subaccount | Operative Einheit. Hier werden Services instanziiert, Applications subscribed, Environments aktiviert und User berechtigt. Jeder Subaccount ist einer Region zugeordnet. | Projekt / Umgebung, z. B. Dev, Test oder Produktion |
Quelle/Hinweis: SAP Account Model und SAP Help Portal
Quelle: SAP
Best Practices für die Account-Struktur
Die richtige Strukturierung Ihrer Subaccounts ist eine der wichtigsten Entscheidungen bei der BTP-Einführung.
Muster 1: Nach Landschaft
- Subaccount DEV – Entwicklung und Experimente
- Subaccount TEST/QA – Integrations- und Abnahmetests
- Subaccount PROD – produktiver Betrieb
Muster 2: Nach Geschäftsbereich und Landschaft
- Directory Finance → Finance-DEV, Finance-TEST, Finance-PROD
- Directory Supply Chain → SC-DEV, SC-TEST, SC-PROD
Muster 3: Nach Projekt
- Directory Projekt Alpha → Alpha-DEV, Alpha-PROD
- Directory Projekt Beta → Beta-DEV, Beta-PROD
Tipp: Definieren Sie eine Namenskonvention von Anfang an, zum Beispiel [bereich]-[landschaft]-[region], etwa finance-prod-eu10.
Entitlements und Service Plans
Bevor ein Service in einem Subaccount genutzt werden kann, muss er dort berechtigt werden. Entitlements funktionieren wie ein internes Verteil- und Budgetierungssystem.
- Der Global Account erhält Entitlements gemäß Vertrag bzw. kommerziellem Modell.
- Administratoren verteilen Entitlements auf Directories und Subaccounts.
- Im Subaccount können Service-Instanzen oder Subscriptions nur für berechtigte Services erstellt werden.
- Service Plans definieren Leistungsumfang, technische Optionen und kommerzielle Metrik eines Services. Die konkret verfügbaren Pläne sollten im SAP Discovery Center bzw. im BTP Cockpit geprüft werden.
Wichtig: Nicht zugewiesene Entitlements blockieren die Service-Erstellung im Subaccount – ein häufiger Stolperstein, wenn neue Teams starten wollen.
Quelle: SAP
Booster – der Schnellstart für BTP-Services
Booster sind Wizards im SAP BTP Cockpit, die mehrere Konfigurationsschritte bündeln, etwa Subaccounts, Entitlements, Service-Instanzen, Subscriptions oder Role Collections.
Booster sind besonders hilfreich für den Einstieg, für Demos und für standardisierte Erstkonfigurationen. In produktiven Enterprise-Landschaften sollten die erzeugten Einstellungen anschließend geprüft und gegebenenfalls in Governance- oder Infrastructure-as-Code-Prozesse überführt werden.
User-Management und Berechtigungen
Das Berechtigungskonzept der BTP unterscheidet zwei grundlegende Benutzertypen:
Aspekt | Platform Users | Business Users |
Wer? | Administratoren, Entwickler, DevOps-Teams | Endanwender der Anwendungen auf der BTP |
Wo aktiv? | BTP Cockpit, btp CLI, Cloud Foundry CLI, Kyma Dashboard | In Anwendungen wie SAP Analytics Cloud, SAP Datasphere, SAP Build Work Zone oder Custom Apps |
Verwaltung | Cockpit → Security → Users und Role Collections | SAP Cloud Identity Services – Identity Authentication (IAS) bzw. Unternehmens-Identity-Provider plus anwendungsspezifische Rollen |
Beispiele | Global Account Administrator, Subaccount Administrator, Space Developer | Datasphere Space Admin, SAC BI Content Creator, App-spezifische Rollen |
Identity Provider und Trust-Konfiguration
Standardmäßig ist SAP BTP mit dem SAP ID Service vorkonfiguriert. Für produktive Szenarien empfehlen wir den Einsatz von SAP Cloud Identity Services – Identity Authentication (IAS) und die Anbindung an den Unternehmens-Identity-Provider, zum Beispiel Microsoft Entra ID.
- Single Sign-On über SAML 2.0 oder OpenID Connect (OIDC)
- Multi-Faktor-Authentifizierung für kritische Zugriffe.
- Zentrales User-Lifecycle-Management für Onboarding und Offboarding.
- Conditional Authentication mit Regeln je Benutzergruppe oder Anwendung.
Für produktive Szenarien sollte geprüft werden, ob SAP ID Service nur noch für administrative oder Fallback-Zwecke genutzt wird und ob Business User ausschließlich über IAS bzw. den Unternehmens-Identity-Provider authentifiziert werden.
Monitoring und Verbrauchssteuerung
Ein zentraler Mehrwert des Cockpits ist die Transparenz über Ressourcenverbrauch und Kosten. Gerade bei BTPEA und bestehenden CPEA-Verträgen ist Usage Monitoring entscheidend, um Overage oder ungenutzte Commitments zu vermeiden. Bei Pay-As-You-Go ist Monitoring ebenso wichtig, da laufende Instanzen direkt zu monatlichen Kosten führen können.
Usage-Dashboard im Global Account
Das Dashboard zeigt den aggregierten Verbrauch über Subaccounts hinweg. Je nach Modell und Service sind Aufschlüsselungen nach Zeitraum, Service und Subaccount möglich.
Quelle: SAP
Alerts und Schwellenwerte
Wir empfehlen, Schwellenwert-Alerts zu konfigurieren:
- 70 % des Budgets – Information: Review des Verbrauchs einplanen.
- 85 % des Budgets – Warnung: Maßnahmen zur Verbrauchsreduzierung prüfen.
- 95 % des Budgets – Kritisch: sofortige Eskalation und Overage-Risiko prüfen.
Tipp: Kombinieren Sie das BTP Cockpit mit SAP Cloud ALM für ein umfassenderes Operations-Monitoring, etwa Health Monitoring, Job Monitoring und Integration Monitoring.
Labels für Kostenzuordnung und Governance
Labels sind die SAP-BTP-Kategorisierung für Kostenstellen, Owner, Landschaften oder Projekte. Sie können auf Subaccount- und Directory-Ebene gesetzt werden und erleichtern Filterung, Reporting und Governance.
Dimension | Beispiel-Label |
Kostenstelle | cost-center: 4711 |
Verantwortlicher | owner: max.mustermann@firma.de |
Umgebung | landscape: prod |
Projekt | project: alpha |
Automatisierung: BTP CLI und Terraform
Für größere Landschaften ist die manuelle Verwaltung über das Cockpit nicht skalierbar. SAP bietet mit der btp CLI und dem Terraform Provider for SAP BTP zwei wichtige Automatisierungswege.
BTP CLI
Die BTP Command Line Interface ermöglicht die skriptbasierte Verwaltung der Account-Hierarchie. Die konkrete Syntax hängt von der installierten btp-CLI-Version ab. Für produktive Skripte sollten immer btp help und die aktuelle SAP Command Reference verwendet werden.
Beispiel | Zweck |
btp login | Anmeldung am Global Account |
btp target | Zielkontext wechseln, z. B. Global Account, Directory oder Subaccount |
btp list accounts/subaccount | Subaccounts auflisten |
btp create accounts/subaccount | Subaccount anlegen |
btp list accounts/entitlement | Entitlements und Quotas anzeigen |
btp list accounts/label | Labels anzeigen, je nach Kontext und CLI-Version |
Terraform Provider for SAP BTP
Für Infrastructure-as-Code-Ansätze bietet SAP einen Terraform Provider. Damit lassen sich Account-Strukturen und ausgewählte BTP-Ressourcen deklarativ beschreiben und versioniert verwalten.
- Subaccounts, Directories und Entitlements als Terraform-Ressourcen definieren.
- Service-Instanzen und Subscriptions automatisiert provisionieren.
- User-Zuweisungen, Role Collections und Trust-Konfigurationen reproduzierbar ausrollen, soweit vom Provider unterstützt.
- GitOps-Workflow: Konfiguration in Git versionieren, per Pull Request ändern und per Pipeline ausrollen.
Aus unserer Projekterfahrung lohnt sich Infrastructure-as-Code häufig ab etwa 5–10 Subaccounts oder sobald mehrere Teams reproduzierbare Landschaften benötigen.
BTP-Governance: ein Rahmenwerk
Aus unserer Erfahrung bei CubeServ scheitern BTP-Projekte selten an der Technik – aber häufig an fehlender Governance.
Governance-Bereich | Maßnahmen |
Account-Struktur | Klare Hierarchie Global Account → Directories → Subaccounts; Namenskonvention definieren, dokumentieren und implementieren. |
Berechtigungen | Least-Privilege-Prinzip; keine Global-Account-Admin-Rechte für Entwickler. |
Entitlements | Zentrale Verteilung durch ein BTP-Admin-Team, um eine unkontrollierte Self-Service-Zuweisung zu vermeiden. |
Kostensteuerung | Labels für Kostenstellen nutzen, monatliches Usage-Review, Alerts bei 70/85/95 % sowie ungenutzte Instanzen stoppen. |
Automatisierung | BTP CLI oder Terraform für reproduzierbare Setups nutzen. |
Review-Zyklus | Quartalsweise Review von Account-Struktur, Entitlements, Berechtigungen und Verbrauch. |
Typische Fehler und wie man sie vermeidet
Fehler | Konsequenz | Lösung |
Ein Subaccount für alles | Keine saubere Trennung von Dev, Test und Prod. | Mindestens Dev/Test/Prod ab Tag 1 planen. |
Jeder ist Admin | Unkontrollierte Service-Erstellung birgen Sicherheitsrisiken und Kostenexplosion. | Least Privilege: Entwickler z. B. Space Developer statt Subaccount Administrator. |
Keine Namenskonvention | Subaccounts heißen „test“ oder „Projekt-neu-2“. | Konvention definieren und durchsetzen, z. B. [bereich]-[landschaft]-[region]. |
Kein Usage-Monitoring | Überschreitungen werden zu spät erkannt. | Monatliches Review, Alerts und Dashboard-Routine etablieren. |
Terraform/CLI ignoriert | Manuelle Konfiguration ist fehleranfällig und nicht reproduzierbar. | Ab mehreren Subaccounts Infrastructure-as-Code prüfen. |
Sie möchten Ihre SAP BTP-Struktur sauber aufsetzen und Governance, Berechtigungen sowie Monitoring von Anfang an professionell etablieren?
Dann sprechen Sie mit unseren BTP-Expert:innen bei CubeServ. Wir unterstützen Sie dabei, eine skalierbare Account-Struktur zu definieren, Rollen- und Berechtigungskonzepte aufzubauen sowie Kosten und Nutzung transparent zu steuern.
Blog-Serie:
In den nächsten Teilen gehen wir tiefer auf spezielle Themen ein, welche uns bei unseren Kunden immer wieder begegnen.
Teil | Thema |
| Was ist die SAP BTP und wie passt sie ins große Bild? | |
Teil 4 | Services & Environments – Cloud Foundry, Kyma und der Service Marketplace |
Teil 5 | Integration Suite – Datenflüsse zwischen Systemen |
Teil 6 | Erweiterungen in der Praxis – Side-by-Side Extensions mit CAP und RAP |
Teil 7 | AI & Automation – SAP AI Core, Joule |
Vereinbaren Sie jetzt Ihren Expert Call. Wir freuen uns über Ihre Nachricht.
Thomas Krafft
- thomas-krafft
- n.n.
- n.n.
