Procurement-Anbindung im Mittelstand: OCI und CXML in Klartext — was Procurement-Abteilungen vom Lieferanten wirklich verlangen

„Unser Großkunde verlangt von uns OCI-Anbindung — was bedeutet das und was kostet uns das?“ Diese Frage tauchte zuletzt in zwei Erstgesprächen kurz hintereinander auf, jeweils ausgelöst durch einen konkreten Großkunden, der den Lieferanten vor die Wahl stellte: Anbindung oder Aus. Für Mittelständler, die in den Großkunden-Markt wollen, ist das eine typische Situation — und eine, die ohne Vorbereitung schnell in Stress kippt.

Dieser Artikel erklärt OCI und CXML in Klartext, beschreibt den Anbindungs-Ablauf, sortiert die Aufwände realistisch und benennt die Loyalitäts-Wirkung, die diese Anbindung erzeugt. Substanz aus Projekten der letzten Monate mit Procurement-Anbindungen an mehrere Konzern-Systeme.

Was Procurement-Systeme tun

Ein Procurement-System ist in mittelständischen und großen Firmen die Schaltzentrale für alle Einkäufe. Dort werden:

• Bedarfe gemeldet (von Mitarbeitern in Abteilungen).
• Lieferanten verwaltet (mit verhandelten Konditionen, Verträgen, Zertifikaten).
• Bestellungen freigegeben (über interne Workflows).
• Wareneingänge gebucht (Abgleich mit Bestellung).
• Rechnungen geprüft (Abgleich mit Wareneingang).
• Buchungen in die Kostenstellen-Welt geführt.

Der Procurement-Käufer arbeitet ausschließlich in diesem System. Er will nicht den Lieferanten-Shop manuell besuchen, sich einloggen, sein Konto pflegen — er will im Procurement-System nach dem Lieferanten suchen, dort ein „Bestell-Fenster“ öffnen, Artikel auswählen, und alles weitere automatisch zurück ins Procurement-System spielen lassen.

Punch-Out: das Grundmuster

Der Mechanismus, mit dem das funktioniert, heißt „Punch-Out“. Wörtlich: Aus dem Procurement-System „durchstoßen“ in den Lieferanten-Shop, dort einkaufen, mit dem Warenkorb zurückkommen. Die Schritte:

1. Aufruf: Der Käufer wählt im Procurement-System „neue Bestellung bei Lieferant X“. Das System sendet einen Login-Aufruf an den Lieferanten-Shop, mit Authentifizierungs-Daten und Rückkehr-URL.
2. Übergabe: Der Lieferanten-Shop empfängt den Aufruf, identifiziert den Käufer (welche Firma, welche Konto-Rechte, welche Preis-Logik), öffnet eine Session und zeigt dem Käufer den Shop in seinem Browser.
3. Einkauf: Der Käufer stöbert, sucht, füllt den Warenkorb. Aus seiner Sicht ist es ein normaler Web-Shop — nur, dass die Preise schon kunden-spezifisch sind und der Checkout-Knopf nicht „bestellen“, sondern „in Procurement-System übernehmen“ heißt.
4. Rückgabe: Wenn der Käufer den Warenkorb übernimmt, sendet der Lieferanten-Shop die Artikel-Liste samt Preisen, Mengen und Konditionen zurück an das Procurement-System (über die vorher übergebene Rückkehr-URL).
5. Weiterverarbeitung: Im Procurement-System landet der Warenkorb als „Bestell-Anforderung“. Sie geht durch den internen Workflow (Vorgesetzten-Freigabe, Einkaufs-Prüfung, eventuell Geschäftsführer-Freigabe) und wird erst dann verbindlich als Bestellung an den Lieferanten geschickt.

Wichtig: Der Punch-Out endet mit der Übergabe des Warenkorbs ans Procurement-System. Die Bestellung wird nicht automatisch verbindlich — erst nach dem internen Workflow geht die echte Bestellung raus. Für den Lieferanten heißt das: Der Warenkorb ist eine Anfrage, keine Bestellung. Die Bestellung kommt später (manchmal Stunden, manchmal Tage später) als eigener Auftrag, oft per EDI oder als Order-Mail.

OCI in Klartext

OCI (Open Catalog Interface) ist das von einem großen ERP-Anbieter aus dem deutschen Raum entwickelte Standard-Protokoll für Punch-Out. Es ist im DACH-Markt das dominante Protokoll, weil viele Mittelständler und Konzerne dieses ERP einsetzen.

Technisch ist OCI ein HTTP-basierter Protokoll-Standard. Die Aufruf-Daten kommen als Form-Post oder URL-Parameter zum Lieferanten-Shop. Der Warenkorb wird zurück als Form-Post im OCI-Format gesendet, mit definierten Feldern für Artikelnummer, Beschreibung, Menge, Preis, Maßeinheit, Hersteller-Artikelnummer.

OCI hat mehrere Versionen (3.0, 4.0, 5.0). Welche Version der Käufer verlangt, klärt sich in der Anbindungs-Sitzung. Die Versionen unterscheiden sich in der Detail-Tiefe der Felder — neuere Versionen können mehr Konditions-Daten transportieren (z.B. Lieferzeit pro Position, Konditions-Hinweise).

CXML in Klartext

CXML (Commerce XML) ist das von einem amerikanischen Procurement-System entwickelte Protokoll. International und in Konzernen mit US-Bezug verbreitet, im DACH-Mittelstand seltener, aber regelmäßig anzutreffen.

Technisch ist CXML — wie der Name sagt — XML-basiert. Der Aufruf kommt als XML-Dokument („PunchOutSetupRequest“), die Antwort geht zurück als XML („PunchOutOrderMessage“). Strukturell ist es etwas reichhaltiger als OCI — kann mehr Meta-Daten transportieren, hat klarere Standards für Versions-Management.

Welches Protokoll der konkrete Großkunde verlangt, hängt von seinem Procurement-System ab. Wer sowohl OCI als auch CXML unterstützt, kann den größtmöglichen Teil des Marktes bedienen. Wer nur eines unterstützt, schließt einen Teil aus. Wir empfehlen, mit OCI zu starten (im DACH-Markt häufiger) und CXML als zweite Stufe nachzuziehen, wenn der erste Großkunde mit CXML-System auftaucht.

Was die Anbindung wirklich verlangt

Eine Procurement-Anbindung ist kein einfaches Plug-in. Sie verlangt:

• Technische Implementierung im Shop. Empfang des Aufrufs, Authentifizierung, Session-Verwaltung, Warenkorb-Rückgabe im richtigen Format. Bei sauberer Architektur ein definierter Aufwand (typisch zwischen 5 und 15 Personentagen für die erste Anbindung).
• Abstimmung mit der IT des Käufers. Welche OCI-Version, welche Authentifizierungs-Methode, welche Test-URL, welche Produktiv-URL. Hier kann es zu Verzögerungen kommen, weil IT-Abteilungen unterschiedliche Antwort-Zeiten haben.
• Test-Phase mit beiden Seiten. Mehrere Test-Punch-Outs mit dem Käufer durchspielen — verschiedene Artikel-Kategorien, verschiedene Mengen, Sonderfälle (z.B. Artikel mit Mengen-Staffel, Artikel mit Vertragspreis).
• Sortiments-Pflege. Im Procurement-System des Käufers gibt es einen Katalog des Lieferanten — entweder als „statischer Katalog“ (CSV/BMEcat-Import) oder als „dynamischer Katalog“ (Live-Aufruf zum Lieferanten). Bei statischen Katalogen ist regelmäßige Aktualisierung Pflicht, sonst veralten die Daten.
• Preis-Synchronität. Im Procurement-System können sich Preise unterscheiden vom Live-Shop. Saubere Implementierung: Live-Aufruf für aktuelle Preise, mit Vertrags-Logik berechnet pro Käufer-Identität.
• Order-Bestätigung als zweite Schnittstelle. Wenn die echte Bestellung später kommt (nach internem Workflow), muss der Lieferant sie mit Eingangs-Bestätigung quittieren und im Status-Update den weiteren Verlauf rückmelden.

Aufwand realistisch einschätzen

Wir sehen in unseren Projekten typische Aufwände in folgenden Bereichen:

• Erste OCI-Anbindung: 10 bis 20 Personentage, inkl. Konfiguration, Test mit dem Kunden, Produktiv-Schaltung.
• Zweite OCI-Anbindung an einen anderen Kunden: 3 bis 7 Personentage, weil die technische Grundlage steht, nur die Authentifizierungs-Daten und Test-Phase mit dem neuen Kunden anfallen.
• CXML-Anbindung (wenn OCI schon läuft): 8 bis 15 Personentage zusätzlich, weil das Protokoll anders strukturiert ist.
• Statischer Katalog (BMEcat): Erst-Erstellung 3 bis 8 Personentage, je nach Sortiments-Komplexität. Aktualisierung pro Quartal: 1 bis 2 Tage.
• Order-Bestätigungs-Schnittstelle: 3 bis 7 Personentage, weil Status-Logik und Datenformat abgestimmt werden müssen.

Diese Zahlen variieren je nach Komplexität deines Sortiments und der Anforderungen des Kunden. Konzerne mit eigenen IT-Standards können den Aufwand verdoppeln, kleinere Mittelständler oft halbieren.

Wann sich die Investition lohnt

Eine Procurement-Anbindung ist eine erhebliche Investition — sowohl in der Erst-Implementierung als auch in der laufenden Pflege. Sie lohnt sich, wenn:

• Mindestens ein substantieller Großkunde es verlangt. Wenn der Kunde sonst wechselt, ist die Rechnung schnell klar.
• Mehrere Bestands-Kunden Procurement-Systeme haben, aber heute manuell bestellen. Anbindung kann den Bestell-Komfort so erhöhen, dass der Anteil bei diesen Kunden steigt.
• Der Vertrieb mit Procurement-Anbindung als USP arbeiten kann. Im Neukunden-Gespräch ist OCI/CXML-Fähigkeit ein Trust-Anker bei größeren Kunden.
• Mindestens 15 Prozent des B2B-Umsatzes bei Kunden mit Procurement-System läuft. Unter dieser Schwelle ist der Aufwand schwerer zu rechtfertigen.

Was die Investition wirklich rechtfertigt, ist die Loyalitäts-Wirkung. Ein Großkunde, der einmal die Anbindung eingerichtet hat, hat erhebliche interne Hürden, wenn er den Lieferanten wechseln will — er müsste die Anbindung neu aufbauen, neu testen, neu in den internen Workflow integrieren. Die Anbindung selbst ist ein Wechsel-Hindernis und damit ein langfristiger Bindungs-Anker.

Was Hannes daraus macht

Wir bauen Procurement-Anbindung als optionales Modul auf der Stufe-3-Architektur des B2B-Shops. Konkret:

• OCI-Anbindung in den gängigen Versionen (3.0, 4.0, 5.0) — als Standard im Modul enthalten.
• CXML-Anbindung als zweite Stufe, wenn der erste Kunden-Fall es verlangt.
• Sortiments-Katalog als statischer BMEcat-Export oder dynamische Live-Aufruf-Anbindung, je nach Kunden-Anforderung.
• Vertragspreis-Logik durchgängig — der Punch-Out zeigt die kunden-spezifischen Preise live, nicht die Listenpreise.
• Order-Bestätigungs-Schnittstelle mit Status-Updates zurück an das Procurement-System.
• Audit-Trail über alle Punch-Outs und Bestellungen — wer hat wann was gepunchout, was wurde als Bestellung verbindlich, welche Differenz gibt es zwischen Punch-Out-Warenkorb und Final-Bestellung.
• Konfigurations-Sitzung pro Kunde, in der wir die Anbindung technisch klären und einen verbindlichen Test-Plan vereinbaren.

Festpreis pro Anbindung (kein pauschales Modul mit unklarem Folge-Aufwand), erste Anbindung als Pilot, weitere Anbindungen mit reduziertem Aufwand auf der Pilot-Grundlage.