S/4HANA-Kosten verstehen — die Kostenlogik hinter dem SAP-Flaggschiff.
Kaum ein ERP-System entzieht sich pauschalen Preisangaben so sehr wie SAP S/4HANA: Die Kosten hängen von der Betriebsvariante, dem Programmzuschnitt und der eigenen Ausgangslage ab. Diese Seite erklärt die Struktur dahinter — welche kommerziellen Modelle es gibt, was den Einführungsaufwand treibt und wie eine mehrjährige Gesamtkostenbetrachtung aufgebaut sein sollte.
Wie das Lizenz- und Subscriptionmodell funktioniert.
Die kommerzielle Logik von SAP S/4HANA unterscheidet sich je Betriebsvariante grundlegend: In der Public-Cloud-Variante wird per Subscription lizenziert, deren Umfang von Nutzerprofilen und aktivierten Funktionsumfängen abhängt. Die Private-Cloud-Variante kombiniert eine Subscription mit dediziertem Betrieb und mehr Spielraum für Anpassungen. Bei On-Premises-Betrieb kommen klassische Lizenz- und Wartungsmodelle zum Tragen, ergänzt um eigene oder gehostete Infrastruktur. Zusätzlich beeinflussen Branchenlösungen und die Frage bestehender SAP-Verträge (etwa bei einer Umstellung von einem Altsystem) die Vertragsgestaltung erheblich.
Für die Budgetplanung folgt daraus: Vor jeder Kostenbetrachtung steht die Entscheidung über die Betriebsvariante, denn sie bestimmt nicht nur die Zahlungsstruktur (laufende Subscription versus Anfangsinvestition plus Wartung), sondern auch den späteren Anpassungs- und Betriebsaufwand. Erfahrungsgemäß lohnt es sich, die Varianten mit identischem Anforderungszuschnitt gegenüberzustellen und bestehende Vertragsverhältnisse mit SAP frühzeitig in die Verhandlung einzubeziehen.
Was den Implementierungsaufwand treibt.
S/4HANA-Einführungen sind in aller Regel mehrjährige Programme. Typische Aufwandstreiber sind der Umstellungsansatz (Neuaufbau, Systemkonvertierung oder selektive Migration), die Zahl der Länder und Gesellschaften, die Ablösung historisch gewachsener Eigenentwicklungen, die Integration in die bestehende Systemlandschaft, Branchenanforderungen sowie der Umfang an Prozess-Harmonisierung, den das Unternehmen anstrebt. Auch die gewählte Betriebsvariante wirkt auf den Projektaufwand: Die Public Cloud erzwingt Standardnähe, während Private Cloud und On-Premises mehr Freiheitsgrade mit entsprechendem Mehraufwand eröffnen.
In der Projektgrößenrelation bewegen sich S/4HANA-Programme typischerweise am oberen Ende des ERP-Marktes — vergleichbar mit großen Finance-&-Operations-Programmen und deutlich oberhalb von Suite-Einführungen wie NetSuite oder Business Central. Die Laufzeit hängt vom Umstellungsansatz, der Rollout-Strategie über Länder und Gesellschaften sowie der Verfügbarkeit erfahrener Berater und interner Schlüsselpersonen ab.
Die laufende Kostenlogik.
Die laufende Kostenlogik folgt der Betriebsvariante: In den Cloud-Varianten dominiert die Subscription, ergänzt um Application-Management-Leistungen eines Partners und die Begleitung der regelmäßigen Release-Zyklen; bei On-Premises treten Wartungsgebühren, Infrastruktur- oder Hosting-Kosten und eigenverantwortliche Upgrade-Projekte an diese Stelle. Über alle Varianten hinweg erfordert die Pflege von Eigenentwicklungen, Schnittstellen und Berechtigungskonzepten eine dauerhafte interne oder externe Betreuungsorganisation, die in der Praxis einen wesentlichen Teil der laufenden Kosten ausmacht.
Worauf eine 5-Jahres-Betrachtung achten sollte.
- Betriebsvarianten über den gesamten Zeitraum vergleichen: Subscription-Modelle und Lizenz-plus-Wartung-Modelle verteilen dieselbe Substanz unterschiedlich über die Jahre — entscheidend ist die Gesamtsicht, nicht das erste Jahr.
- Den Umstellungsansatz einpreisen: Systemkonversion und Neuaufbau unterscheiden sich nicht nur im Projekt, sondern auch in den Folgekosten für Altlasten und technische Schulden.
- Upgrade- beziehungsweise Release-Aufwand je Variante ansetzen — von zentral eingespielten Cloud-Releases bis zu eigenverantwortlichen Upgrade-Projekten im On-Premises-Betrieb.
- Die interne SAP-Kompetenzorganisation (Basis, Entwicklung, Berechtigungen, Key User) als dauerhaften Kostenblock berücksichtigen, dessen Umfang mit der gewählten Variante variiert.
Wann es typischerweise teurer wird
- Umfangreiche historisch gewachsene Eigenentwicklungen aus einem Altsystem, die analysiert, abgelöst oder neu gebaut werden müssen.
- Viele Länder und Gesellschaften mit Branchenanforderungen, die über den Standard hinausgehen und eigene Lokalisierungs- und Testzyklen erfordern.
- Parallelbetrieb von Alt- und Neusystem über lange Rollout-Zeiträume mit doppelten Betriebs- und Schnittstellenkosten.
Wann das Projekt typischerweise schlank bleibt
- Konsequente Entscheidung für die Public-Cloud-Variante mit diszipliniertem Verzicht auf Modifikationen und Nutzung des SAP-Standards.
- Ein klar geschnittener Erstumfang — etwa eine Kerngesellschaft mit Kernprozessen — und ein Template-basierter Rollout in Etappen.
- Frühzeitige Bereinigung von Datenbeständen und Eigenentwicklungen vor Programmstart, statt Altlasten in das Neusystem zu tragen.
Alternativen, die in dieser Konstellation geprüft werden.
Dynamics 365 Finance & Operations
Wird typischerweise parallel geprüft, wenn ein Enterprise-Programm ansteht und die Organisation stark im Microsoft-Ökosystem verankert ist.
Oracle NetSuite
Kommt in Betracht, wenn internationale Strukturen abzubilden sind, aber eine schlankere Cloud-Suite mit kleinerer Programmrelation ausreicht.
Dynamics 365 Business Central
Wird geprüft, wenn die Anforderungsanalyse zeigt, dass ein Mittelstandssystem den Bedarf ohne Enterprise-Programmstrukturen deckt.
Neutrale redaktionelle Einordnung der Kostenstruktur — bewusst ohne Preisangaben, da Konditionen individuell verhandelt werden und sich laufend ändern. Keine bezahlten Platzierungen; wie wir arbeiten, steht in der Methodik.
Was würde ein passendes ERP in Ihrer Konstellation bedeuten?
Der kostenlose ERP-Fit-Check nimmt Ihre Ausgangslage strukturiert auf — mit sofortiger Ersteinordnung inklusive System-Shortlist, ohne Anmeldung.