GAEB, SAP Ariba und der Konverter-Mythos: Warum Konvertierung keinen Sourcing-Prozess ersetzt

Viele Unternehmen im Bau- und Projekteinkauf arbeiten heute mit einer ähnlichen Systemlandschaft: SAP S/4HANA als zentrales ERP-System, dem Datenmodell Lean Services with Item Hierarchies zur Abbildung komplexer Leistungen und SAP Ariba für den Ausschreibungsprozess.

Sobald jedoch Bau- oder projektorientierte Beschaffung ins Spiel kommt, stellt sich eine zentrale Frage: Wie lassen sich Leistungsverzeichnisse im GAEB-Format in diese Architektur integrieren?

Die häufigste Antwort lautet: „Wir nutzen einfach einen GAEB-Konverter.“ Technisch ist das durchaus möglich. Doch damit stellt sich eine entscheidende Frage: Welche Rolle übernimmt ein solcher Konverter tatsächlich im Sourcing-Prozess?

Beschaffung im Bauprojekt: Anforderungen in der Praxis

Im Bau- und Projekteinkauf arbeitet der Einkauf regelmäßig mit Leistungsverzeichnissen im GAEB-Format. Diese bilden die Grundlage für Ausschreibungen, Angebotsvergleiche und Vergabeentscheidungen.

In der Praxis umfasst der Beschaffungsprozess eine Vielzahl von Aufgaben: Leistungsverzeichnisse werden ausgeschrieben, Angebote mehrerer Anbieter verglichen und Verhandlungen geführt. Hinzu kommen mehrere Anfrage- und Angebotsrunden, die Versionierung der Ausschreibung, die Vergabe von Losen sowie das Management von Nachträgen und Budgets.

Gerade bei Bauprojekten gilt dabei eine einfache Realität:
Nachträge sind eher die Regel als die Ausnahme.

Damit Controlling und Projektsteuerung zuverlässig funktionieren, müssen Änderungen bei Mengen und Preisen jederzeit nachvollziehbar bleiben. Wenn SAP das führende System im Unternehmen (Digital Core) ist, sollte diese Transparenz und Nachvollziehbarkeit idealerweise auch dort abgebildet werden.

GAEB ist mehr als ein Austauschformat

Ein GAEB-Leistungsverzeichnis ist kein einfaches Dokument. Es enthält eine strukturierte Logik aus Losen, Titeln, Positionen, Hierarchien sowie verschiedene Positionsarten wie z.B. Alternativ- und Eventualpositionen. Ergänzt wird diese Struktur durch Mengen, Einheitspreise und – ganz zentral – die Ordnungszahlen (OZ), die die eindeutige Zuordnung von Positionen im Leistungsverzeichnis ermöglichen.

Diese Informationen sind entscheidend für zentrale Einkaufsfunktionen wie Angebotsauswertung, Preisspiegel, Vergabeentscheidungen und Budgetkontrolle.

Damit stellt sich in jeder Systemarchitektur eine zentrale Frage:

❓ Wo wird diese fachliche Struktur mit den Ordnungszahlen des Leistungsverzeichnisses im Beschaffungsprozess tatsächlich verarbeitet und verstanden?

Typische Architektur mit GAEB-Konverter

Der Konverter übernimmt mehrere technische Schritte: Er liest die Struktur des GAEB-Leistungsverzeichnisses ein (Parsing), ordnet die Positionen den Datenstrukturen des Sourcing-Systems zu (Mapping) und konvertiert eingehende Angebote anschließend wieder zurück in das GAEB-Format.

Datenfluss mit GAEB-Konverter:

▶️ GAEB-Datei ➡️ GAEB-Konverter ➡️ SAP Ariba 🛑 S/4HANA

Der Datenaustausch funktioniert. Allerdings liegt die fachliche Logik des Leistungsverzeichnisses dadurch außerhalb des eigentlichen Sourcing-Systems – nämlich im Konverter selbst. Und dies hat erhebliche Konsequenzen.

Da SAP Ariba die GAEB-Struktur nicht nativ versteht, endet der eigentliche Sourcing-Prozess in dieser Architektur im Ariba-System. Eine durchgängige Weiterverarbeitung der strukturierten Leistungsverzeichnisdaten in SAP S/4HANA ist nicht vorgesehen.

Insbesondere können auf Basis der Angebotsauswertung keine Bestellungen oder Kontrakte mit „Lean Services with Item Hierarchies“ direkt in SAP S/4HANA erzeugt werden, da die dafür erforderliche hierarchische LV-Struktur im SAP-System nicht vollständig verfügbar ist.

Der Prozess wirkt damit zwar technisch integriert, ist jedoch faktisch eher ein „End-to-Stopp“-Prozess: Die Ausschreibung und Angebotsauswertung finden in SAP Ariba statt – wenn überhaupt möglich –, während die operative Beschaffung und das Controlling anschließend getrennt in SAP S/4HANA weitergeführt werden müssen.

Im Bau- und Projekteinkauf ist der Preisspiegel das zentrale Analysewerkzeug. Er bildet die Grundlage für strukturierte Angebotsvergleiche und unterstützt Einkäufer dabei, fundierte Vergabeentscheidungen zu treffen.

Typischerweise ermöglicht ein Preisspiegel:

• strukturierte Angebotsvergleiche
• Nutzwertanalysen
• Budgetkontrolle
• Szenariovergleiche

In SAP Ariba stehen dafür grundsätzlich Funktionen wie Bid Comparison oder Bid Analysis zur Verfügung.

Damit ein Preisspiegel Angebote im GAEB-Format korrekt darstellen kann, muss das System die fachliche Struktur des Leistungsverzeichnisses verstehen. Dies ist aus folgenden Gründen in SAP Ariba nicht der Fall:

• keine Verwaltung der Ordnungszahlen (OZ)
• keine Abbildung von mehrstufigen, GAEB konformen LVs
• keine Unterstützung der GAEB konformen Positionsarten
• Performanceprobleme bei größeren Leistungsverzeichnissen
• etc.

Wenn der Preisspiegel in SAP Ariba nicht zur Verfügung steht, dann muss auch dieser im Konverter abgebildet werden. Insofern übernimmt der Konverter damit immer mehr Logik.

In der Praxis erwarten viele Einkaufsorganisationen zudem zusätzliche Möglichkeiten. Häufig wird verlangt, dass ein Preisspiegel nach Excel exportiert werden kann – inklusive der zugrunde liegenden Formeln. Nur so lassen sich komplexe Szenarien, Nutzwertanalysen oder Budgetvergleiche flexibel weiterverarbeiten.

Denn ein Excel ohne Formeln ist letztlich kein Preisspiegel. Es ist nur eine Tabelle.

3️⃣ Versionierung von Angebotsrunden

Im Bau- und Projekteinkauf sind mehrere Anfragerunden üblich. Ein typischer Ablauf umfasst ein Erstangebot, eine oder mehrere Klärungs- und Verhandlungsrunden sowie schließlich ein finales Angebot.

Damit Einkäufer Angebote sinnvoll vergleichen können, muss der Preisspiegel über diese Runden hinweg versioniert werden. Nur so lässt sich nachvollziehen,

• wie sich Preise zwischen den Angebotsrunden verändern
• welche Positionen angepasst wurden
• wie sich Angebote im Zeitverlauf entwickeln

Dabei spielt die Strukturkonstanz des Leistungsverzeichnisses eine entscheidende Rolle. Nur wenn die Struktur stabil bleibt, können Preisänderungen korrekt analysiert und miteinander verglichen werden.

In Konverter-Architekturen stellt sich deshalb eine zusätzliche Frage:

❓Wo werden die Versionen der Leistungsverzeichnisse eigentlich verwaltet?

Wenn ein GAEB-Konverter die Struktur des Leistungsverzeichnisses verarbeitet und verwaltet, muss er zwangsläufig auch weitere Aufgaben übernehmen – etwa das Speichern von LV-Versionen, die Synchronisation von Angebotsrunden und die Nachvollziehbarkeit von Änderungen zwischen den einzelnen Runden.

Damit übernimmt der Konverter nicht mehr nur eine technische Funktion, sondern faktisch auch Teile der fachlichen Prozesslogik des Beschaffungsprozesses. Mit anderen Worten, Einkäufer arbeiten dann zukünftig in SAP Ariba und zusätzlich im Konverter, und immer mit dem Restrisiko, dass es Datenschiefstände gibt, weil die Struktur der Angebote nicht zum ausgeschriebenen Leistungsverzeichnis passt.

Anforderungen an das Sourcing-System

Die bisherigen Aspekte zeigen vor allem die Rolle eines GAEB-Konverters. Daraus ergibt sich eine weitergehende Frage:

❓Welche Anforderungen ergeben sich eigentlich für das Sourcing-System selbst – etwa für Lösungen wie SAP Ariba?

Gerade im Bau- und Projekteinkauf müssen solche Systeme in der Lage sein, umfangreiche Leistungsverzeichnisse, und elementar wichtig die Ordnungszahlen (OZ) zu verarbeiten und gleichzeitig mit den Datenstrukturen des ERP-Systems zusammenzuarbeiten.

Dabei spielen insbesondere zwei Aspekte eine Rolle:

✴️ Größe und Komplexität von Leistungsverzeichnissen

GAEB-Leistungsverzeichnisse können sehr umfangreich sein. In vielen Projekten sind an die 1.000 Positionen üblich, in größeren Bauvorhaben sind fünfstellige Positionsanzahlen keine Seltenheit.

Damit entstehen komplexe hierarchische Strukturen aus Losen, Titeln und Positionen, die im Sourcing-System verarbeitet und analysiert werden müssen. Besonders bei Angebotsvergleichen und Preisspiegeln stellt dies hohe Anforderungen an Performance, Datenstruktur und Analysefunktionen.

Die praktische Frage:

❓Bis zu welcher Größe und Komplexität lassen sich Leistungsverzeichnisse innerhalb eines Sourcing-Tools effizient verarbeiten und auswerten?

✴️ Das SAP-Datenmodell: Lean Services with Item Hierarchies

Im SAP-Umfeld kommt ein weiterer Aspekt hinzu. Mit Lean Services with Item Hierarchies hat SAP in S/4HANA ein hierarchisches Service-Datenmodell eingeführt, das für die Abbildung komplexer Leistungen gedacht ist.

Dieses Modell ist jedoch nicht direkt GAEB-kompatibel. GAEB-Leistungsverzeichnisse verwenden eine andere Struktur- und Positionslogik. Insofern müssen GAEB-Leistungsverzeichnisse zusätzlich in Item Hierarchies transformiert werden.

Damit entsteht eine weitere Transformationsebene innerhalb der Systemarchitektur – und potenziell auch zusätzliche Fehlerquellen im Zusammenspiel zwischen GAEB, Sourcing-System, Konverter und ERP-System.

Fazit: Entscheidend ist nicht die Konvertierung – sondern die Systemarchitektur

Ein GAEB-Konverter kann den Austausch von GAEB-Dateien ermöglichen.

Er ersetzt jedoch kein System, das:

• Leistungsverzeichnisse strukturell versteht
• Änderungen und Nachträge verarbeitet
• Angebote systemseitig validiert
• Preisspiegel versioniert
• und diese Informationen direkt mit dem Controlling in SAP verbindet.

Damit wird deutlich: Die entscheidende Architekturfrage lautet nicht:
„Kann ein System GAEB-Dateien austauschen?“

Die eigentliche Frage ist vielmehr:
Wo wird die fachliche Logik des Leistungsverzeichnisses verarbeitet?
Im Sourcing-System? Oder im GAEB-Konverter?

Aus diesem Grund verfolgt die Sourcing-Lösung FUTURA Smart den Ansatz, GAEB-Leistungsverzeichnisse werden nicht außerhalb des Beschaffungsprozesses zu behandeln, sondern direkt in den Sourcing-Workflow einzubinden. Dadurch bleibt die fachliche Struktur der Leistungsverzeichnisse vollständig erhalten und kann systemseitig interpretiert und ausgewertet werden.

Nur so lässt sich ein durchgängiger End-to-End-Prozess zwischen Ausschreibung, Angebotsauswertung, Vergabe und Controlling im SAP-System realisieren. Statt isolierter Datenkonvertierungen entsteht eine integrierte Prozesskette, in der GAEB-Strukturen, Beschaffungsentscheidungen und Budgetinformationen konsistent innerhalb von S/4HANA zusammengeführt werden.

Gerade im Bau- und Projekteinkauf entscheidet diese Architekturfrage darüber, wie transparent Angebote bewertet werden können und wie eng Beschaffung und Controlling im SAP-System zusammenarbeiten.