SAP SKU

Wenn du schon einmal ein SAP-Angebot gesehen hast, kennst du das Gefühl: Da steht eine Liste aus kryptischen Codes, Editionen, Usern, Engines, Add-ons – und irgendwo dazwischen die Wahrheit, was du eigentlich kaufst. Genau hier kommt die SAP SKU ins Spiel.

SKU steht für Stock Keeping Unit – also eine eindeutige Artikelnummer, mit der ein Anbieter Produkte identifiziert, bepreist, bestellt und abrechnet. In SAP-Angeboten ist eine SAP SKU der kaufmännische „Baustein“ in Angebot oder Order Form: eine präzise definierte Position, an der Nutzungsrechte, Metriken, Laufzeit, Voraussetzungen und Abrechnungslogik hängen.

Ja: Das ist „nur eine Nummer“. Aber in der Praxis ist es der Unterschied zwischen steuerbarer Lizenzierung und Kosten-/Audit-Chaos.

Eine SAP SKU ist eine eindeutige Bestell- und Abrechnungsposition in einem SAP-Angebot. Sie definiert:

• Was du kaufst (z. B. ein Cloud-Paket, eine User-Kategorie, ein Add-on, eine Engine, Kapazität)

• Wie abgerechnet wird (pro User/Monat, pro Jahr, nutzungsbasiert, volumetrisch etc.)

• Welche Bedingungen gelten (Mindestmengen, Abhängigkeiten, Bundles, Laufzeitregeln)

• Welche Nutzungsrechte/Entitlements damit verbunden sind

Du kannst dir die SKU als kleinste kaufmännische Einheit vorstellen, aus der dein Vertrag aufgebaut wird.

Ein häufiger Fehler: Teams sprechen über „SAP S/4HANA“ oder „SAP Integration Suite“, aber im Vertrag steht eine SKU-Liste, die nicht wie Marketing klingt. Genau diese Lücke erzeugt Missverständnisse.

Produktname = so nennt das Business die Lösung
SKU = so wird sie bestellt, lizenziert, gemessen und abgerechnet

Ein Produkt kann aus mehreren SKUs bestehen (z. B. Basis-Paket + Premium-Option + zusätzliche Kapazität + Support-Level). Und umgekehrt kann eine SKU ein Bundle sein, das mehrere Leistungen umfasst.

Weil an der SKU meistens die Preis- und Messlogik hängt. Drei typische Muster:

„Wir kaufen erstmal – Details klären wir später.“

Übersetzung: „Wir klären das, wenn das Projekt schon läuft und niemand Zeit hat.“ SKU-Entscheidungen gehören in die Designphase, nicht in die Aufräumphase nach dem Go-live.

„SKU-Liste ist Einkaufssache.“

Einkauf verhandelt Preise. Aber IT und Fachbereich müssen die Nutzungs- und Metriklogik verstehen – sonst wird das falsche bestellt, auch mit Top-Rabatt.

„Wir haben das Produkt – also ist alles drin.“

Nicht zwingend. Viele Leistungen sind separate SKUs (Child SKUs, Add-ons, zusätzliche Kapazität, Premium-Pläne). Wenn du das nicht prüfst, bekommst du Überraschungen: fehlende Rechte oder unnötige Kosten.

„Wir tracken nur die großen Positionen.“

Die kleinen SKUs sind oft die gefährlichen: Premium-Pläne, Capacity Add-ons, Engine-Erweiterungen. Genau diese Positionen beißen bei Audits oder Renewals.

Wenn du Angebot oder Order Form vor dir hast, geh diese Checkliste durch:

1. SKU-Typ klären
   User? Paket? Engine? Add-on? Support? Kapazität?

2. Metrik verstehen
   Pro User/Monat? Pro Jahr? Pro Dokument? Pro GB? Pro Core?

3. Laufzeit und Verlängerung prüfen
   12 Monate? 36 Monate? Auto-Renewal? True-up-Klauseln?

4. Abhängigkeiten identifizieren
   Mindestmengen? Bundle-Regeln? Base/Premium-Kombinationen?

5. Entitlements sichtbar machen
   Was ist enthalten vs. optional vs. Premium-only?

6. Owner definieren
   Wer stellt sicher, dass die Nutzung zur SKU passt (Service Owner / License Owner)?

Das ist kein Overengineering. Das ist Mindesthygiene, wenn du Lizenzierung steuerbar halten willst.

Wenn du über Länder und Einheiten skalierst, brauchst du weniger „perfekte Excel“ und mehr Wiederholbarkeit:

• SKU-Katalog: Approved SKUs + wofür sie genutzt werden dürfen

• Freigabeprozess: Wer darf Premium oder zusätzliche Kapazität bestellen?

• Kostenstellen-Logik: Zuordnung je Team/BU (Showback/Chargeback light)

• Review-Rhythmus: monatlich (Cloud/Consumption) oder quartalsweise (On-Prem/Perpetual)

• Entitlement-Ownership: jedes „inkludierte“ Feature bekommt Owner + Use Case + KPI

So wird aus der SKU-Liste ein steuerbarer kaufmännischer und operativer Rahmen.

Eine SAP SKU ist mehr als eine Artikelnummer. Sie ist die Einheit, über die SAP-Leistungen bestellt, lizenziert, abgerechnet und geprüft werden. Wenn du SKUs ignorierst, diskutierst du später über Kosten, Audits und „unerklärliche“ Abweichungen. Wenn du SKUs früh strukturierst – Metrik-Klarheit, Abhängigkeiten, Entitlement-Ownership und Review-Rhythmus – wird SAP-Lizenzierung ruhig und steuerbar.