SAP Lizenz-Bill-of-Material für SAP Cloud ERP Public oder Private

Wenn du von SAP ECC oder SAP S/4HANA On-Prem in die Cloud wechselst, entscheidet nicht nur die technische Migration über Erfolg oder Kosten. In der Praxis kippen Business Cases sehr oft an der BOM – der „Lizenz-Stückliste“, die sauber beschreibt, welche Cloud-Subskriptionen, Nutzungsmetriken (z. B. FUE), Umgebungen und Zusatzbausteine du wirklich brauchst. Eine falsche BOM führt zu unnötigen Subskriptionskosten, Lizenz-Compliance-Risiken und Ärger im Rollout („Warum hat Team X keinen Zugriff?“ / „Warum zahlen wir doppelt?“).
Dieser Artikel hilft dir, eine belastbare BOM für SAP Cloud ERP aufzubauen – egal ob du auf Public Edition oder Private Edition zielst. Du bekommst ein klares Vorgehen, typische Fehler und Best Practices, damit deine BOM nicht nur „irgendein Excel“ ist, sondern ein steuerbares Governance-Asset.

Im Lizenzkontext steht BOM für eine strukturierte „Bill of Material“ deiner SAP-Subskriptionen: Welche Produkte/Editionen, welche Nutzungsmetriken, welche User-Kategorien, welche Systemlandschaft (Prod/Non-Prod) und welche Erweiterungs-Services gehören in deinen Vertrag – und warum. Eine gute BOM ist dabei transparent, prüfbar und versioniert (wie technische Stücklisten): Was ist Scope, was ist optional, was ist Annahme, was ist verpflichtend.

Die Wahl zwischen Public und Private wirkt direkt auf die BOM:

• Public Edition (stärker standardisiert): Du planst stärker entlang von Standardprozessen und Rollen. Die BOM fokussiert auf sauberes Rollenmodell, FUE-Logik, Berechtigungen und notwendige Extensions „side-by-side“.

• Private Edition (mehr Freiheitsgrade): Die BOM muss typischerweise mehr Landscape- und Betriebsaspekte berücksichtigen (z. B. zusätzliche Umgebungen, mehr Integrations-/Erweiterungsthemen, Übergangsszenarien aus bestehenden Add-ons).

Merke: Public vs. Private ist keine Geschmacksfrage, sondern eine BOM-Entscheidung. Je unschärfer die Zielarchitektur, desto unpräziser (und teurer) wird deine BOM.

Eine praxistaugliche BOM enthält mindestens diese Blöcke:

Die häufigste Fehlannahme: „Wir haben 800 User, also brauchen wir 800 Cloud-User.“ So funktioniert eine moderne BOM selten sinnvoll. Du brauchst ein Rollenmodell, das Nutzungsintensitäten abbildet:

• Power/Advanced Use: Abschluss, Disposition, Produktionsplanung

• Core Use: operative Sachbearbeitung

• Self-Service: Freigaben, Abfragen, einfache Interaktionen

• IT/Dev/Admin: Betrieb, Erweiterungen, Berechtigungen

Wenn du das in deiner BOM sauber trennst, kannst du:

• Kosten realistisch dimensionieren,

• Zugriffe sauber steuern (Least Privilege),

• Wachstum kalkulieren (neue Standorte, M&A, neue Prozesse).

• Rollen nach Organigramm statt Nutzung → zu viele „Power“-Zuordnungen, unnötig hohe Kosten.

• Non-Prod ignoriert → Projektbudget wird gerissen.

• Integrationen vergessen → späterer Vertrags-/Kostenstress.

• Public/Private gemischt ohne Scope-Regeln → Erwartungschaos und eine unprüfbare BOM.

• Keine Governance → jeder ändert die BOM, niemand verantwortet sie.

Setze Ownership klar:

• IT + Einkauf + Finance als Steuerkreis

• SAM/Lizenzmanagement als Owner der BOM

• Security/IAM für Rollen und Zugriff

• Enterprise Architecture für Zielbild und Scope-Disziplin

Best Practice: BOM-Review quartalsweise (Nutzung, neue Rollen, neue Integrationen, neue Standorte).

Wenn du deine BOM für SAP Cloud ERP belastbar machen willst: Baue nicht nur „Lizenzmengen“, sondern eine prüfbare Lizenz-Architektur. Fink IT-Solutions kann dich dabei unterstützen – von der Rollenmodellierung über die BOM-Kalkulation bis zur Governance im Betrieb (inkl. Cloud-Readiness und Lizenz-Compliance).

Eine saubere BOM ist beim Wechsel zu SAP Cloud ERP Public oder Private dein stärkster Hebel gegen Kostenüberraschungen und Compliance-Risiken. Entscheidend sind Rollenmodell, FUE-/Metrik-Logik, Non-Prod-Planung und Integrationen. Wenn du deine BOM wie ein Produkt behandelst (Versionierung, Ownership, Quality Gates), wird sie vom „Excel“ zum echten Steuerungsinstrument.