SAP BTP
SAP BTP erfolgreich einführen: fünf typische Stolperfallen
Warum Zielbild, Governance, Integration und Betriebsverantwortung vor der Produktauswahl geklärt werden sollten.
Die SAP Business Technology Platform kann Erweiterung, Integration und Innovation sinnvoll unterstützen. Sie löst aber kein ungeklärtes Architekturproblem von selbst. Wer mit Services und Implementierung beginnt, bevor Ziel, Verantwortlichkeiten und Betriebsmodell geklärt sind, verschiebt die schwierigen Entscheidungen lediglich nach hinten.
1. „One size fits all“ als Zielarchitektur
Zwei Unternehmen mit vergleichbarer SAP-Landschaft können unterschiedliche Anforderungen an Verfügbarkeit, Datenhaltung, Entwicklung und Governance haben. Ein übernommenes Referenzbild ist deshalb ein Ausgangspunkt, keine fertige Architektur.
Vor dem Aufbau sollten mindestens diese Fragen beantwortet sein:
- Welche fachlichen Fähigkeiten sollen außerhalb des SAP-Kerns entstehen?
- Welche Systeme und Datenflüsse sind tatsächlich betroffen?
- Welche Anforderungen bestehen an Verfügbarkeit, Datenschutz und Nachvollziehbarkeit?
- Wer trägt Entwicklungs-, Betriebs- und Kostenverantwortung?
2. Technologieauswahl vor dem Anwendungsfall
CAP, RAP, SAP Build, Java, Node.js oder ein vorhandener Dienst: Die richtige Wahl hängt nicht davon ab, welches Werkzeug gerade sichtbar ist. Entscheidend sind fachliche Komplexität, vorhandenes Know-how, Lebensdauer, Integrationsbedarf und Betriebsmodell.
Eine Architekturentscheidung beginnt mit dem Problem und endet beim Betrieb – nicht beim Produktnamen.
Ein kleiner Prototyp kann Annahmen prüfen. Er sollte aber bereits die entscheidenden Systemgrenzen und Datenflüsse berühren. Sonst beweist er nur, dass eine Demo funktioniert.
3. Governance als nachträgliche Aufräumaktion
Ohne gemeinsame Leitplanken entstehen Subaccounts, Rollen, Namensräume, Services und Kostenstellen schneller, als sie später konsolidiert werden können. Governance muss die Arbeit ermöglichen, nicht verhindern. Dafür braucht es wenige, klare Regeln:
- Verantwortlichkeit je Umgebung und Anwendung
- Namens- und Strukturkonventionen
- Rollen- und Berechtigungskonzept
- Freigabe- und Transportweg
- Kosten- und Nutzungsüberwachung
4. Integration nur als technische Schnittstelle betrachten
Eine API oder ein Event verbindet Systeme technisch. Noch nicht geklärt sind damit fachliche Semantik, Fehlerbehandlung, Wiederholbarkeit, Monitoring und Ownership.
Synchron, asynchron, ereignisgesteuert oder zeitgesteuert sind keine Qualitätsstufen. Es sind unterschiedliche Muster. Die Wahl muss zu Antwortzeit, Datenvolumen, Kopplung und Fehlerfolgen passen.
5. Der Betrieb beginnt nach dem Go-live
Dieser Fehler ist besonders teuer. Eine Anwendung ist nicht betriebsfähig, nur weil sie deployt wurde. Vor der Produktivsetzung müssen mindestens geklärt sein:
- Monitoring und Alarmierung
- Support- und Incident-Verantwortung
- Wiederanlauf und Fehlerbehandlung
- Release- und Rollbackverfahren
- Kostenkontrolle
- Dokumentation und Übergabe
Fazit
SAP BTP entfaltet ihren Wert, wenn sie eine klar definierte Rolle in der Unternehmensarchitektur erhält. Ein belastbares Zielbild, pragmatische Governance und ein von Beginn an gedachter Betrieb reduzieren nicht nur Risiken. Sie verhindern auch, dass aus einem schnellen Einstieg eine dauerhaft schwer beherrschbare Plattform wird.