Beschaffungsintegration im E-Commerce: So bestellen Großkunden über ihre eigenen Systeme
Von Robin Laseur
Ihre größten Kunden stöbern nicht in Ihrem Shop. Ein Einkaufsleiter in einem Unternehmen, das jährlich einen sechsstelligen Betrag bei Ihnen ausgibt, öffnet SAP Ariba oder Coupa, wählt Ihren Namen aus der Liste freigegebener Lieferanten und landet in Ihrem Katalog. Die Sitzung dafür hat sein eigenes System geöffnet. Er füllt einen Warenkorb und schickt ihn zurück. Danach wird die Bestellung zu einer Bedarfsanforderung in einem Freigabeprozess, den Sie nie zu sehen bekommen. Kann Ihr Shop in diesem Ablauf nicht mitspielen, kämpfen Sie um den Teil des Budgets, der ein Ausnahmeverfahren übersteht.
Das nennt sich Punchout, und die meisten E-Commerce-Teams haben es noch nie eingeplant. Die Technik ist erprobt und nicht besonders exotisch. Was ein Projekt Zeit kostet, ist selten das Protokoll.
Was in einer Punchout-Sitzung wirklich passiert
Sechs Schritte. Lesen Sie sie der Reihe nach, denn jeder stellt eine Anforderung an Ihren Shop.
Der Einkäufer wählt Sie aus seiner Liste freigegebener Lieferanten. Das passiert in seiner Beschaffungsplattform. Dort entdeckt Sie niemand. Sie werden aus einer Liste abgerufen, auf die Sie erst einmal kommen mussten.
Sein System schickt eine Setup-Anfrage an Ihren Endpunkt. Sie enthält Identität und Authentifizierung: welche Organisation, welcher Nutzer, manchmal welche Kostenstelle oder welcher Vertrag.
Ihr Endpunkt prüft die Anfrage und gibt eine Sitzung zurück. Die Antwort ist eine URL, die Ihren Shop in einem Zustand öffnet, der nur für diesen Einkäufer gilt.
Der Einkäufer kauft in Ihrem Shop ein, ohne sich anzumelden. Er sieht den Katalog, den Sie für diese Organisation festgelegt haben, zu den mit ihr vereinbarten Preisen und ohne weitere Zugangsdaten.
Der Warenkorb geht zurück in sein System, im dort verwendeten Protokoll, Position für Position, mit den Kennungen, die das System für die Verarbeitung braucht.
Freigabe und Bestellung laufen auf seiner Seite. Ihr Auftrag kommt danach an, bereits freigegeben und einem Budget und einem Vertrag zugeordnet.
Achten Sie darauf, was Schritt drei und vier verlangen. Ihr Shop muss eine eingehende Maschinenidentität einer konkreten Geschäftsbeziehung zuordnen. Dann muss er auf Abruf genau den Katalog und die Preise anzeigen, die für diesen Kunden gelten, ohne dass sich ein Mensch anmeldet. Darin steckt das gesamte technische Problem.
Erstens: Die Lieferantenliste entscheidet, wer infrage kommt
Beschaffung gibt es, um Ermessensspielräume zu verkleinern. Hat eine Kategorie freigegebene Lieferanten, muss jeder Kauf außerhalb dieser Liste begründet werden. Eine Begründung ist Aufwand, und den investieren die meisten Einkäufer nicht in einen Lieferanten, der bloß bequem ist.
Daraus folgt etwas, das man deutlich sagen sollte: Bei Großkunden wirkt Ihr Katalog in deren System wie ein Vertriebskanal. Ein Lieferant mit Punchout ist im Moment des Kaufs da. Ein Lieferant ohne wird zur manuellen Ausnahme: per E-Mail angeboten, von Hand erfasst und von jemandem geprüft, dessen Aufgabe es ist, genau solche Ausnahmen zu reduzieren.
Der Hebel ist zuerst kaufmännisch und erst dann technisch. Auf die Liste zu kommen heißt Lieferanten-Onboarding, Vertragsbedingungen und oft eine Registrierung im Netzwerk des Kunden. Die Integration folgt auf dieses Gespräch, nicht umgekehrt. Deshalb ist Punchout auf Verdacht zu bauen selten die richtige Reihenfolge.
Zweitens: Die Protokolle und was sie leisten
Punchout ist ein Ablauf, kein Standard. Zwei Formate transportieren ihn, und ihre Unterschiede bestimmen, was Ihre Integration kann und was nicht.
Wer das schon öfter umgesetzt hat, rät einheitlich: Bauen Sie zuerst cXML. Moderne Beschaffungsplattformen unterstützen es, und es reicht über die Punchout-Sitzung hinaus in die Dokumente, die danach folgen. OCI setzen Sie um, wenn ein bestimmter Kunde mit SAP es verlangt. In einigen europäischen Handelsbranchen taucht ein drittes Format auf, IDS Connect. Gut zu wissen, dass es existiert, aber kein Grund, die Planung danach auszurichten.
Innerhalb von cXML gibt es einen Unterschied, der jede Aufwandsschätzung verändert. Level 1 deckt die Punchout-Sitzung und die Rückgabe des Warenkorbs ab. Level 2 ergänzt eine tiefere Interaktion mit dem Katalog, und ob der Kunde das unterstützt, sollten Sie erfragen statt voraussetzen. Klären Sie vor der Schätzung, welches Level und welche Dokumente ein Kunde tatsächlich braucht. Damit fällt die häufigste Ursache für Nacharbeit weg.
Drittens: Die eigentliche Integration ist das Berechtigungsmodell
Alles bisher ist Transport. Was eine Beschaffungsintegration zum Projekt statt zum Plug-in macht: Ihr Commerce-System muss für eine anonyme eingehende Sitzung eine Kette von Fragen beantworten, die sich den meisten Shops nie stellt.
Welche Organisation ist das, wenn nur eine Maschinenkennung vorliegt und kein Login? Welcher Vertrag gilt für sie? Welche SKUs darf diese Organisation sehen? Rahmenverträge decken oft nur einen Teil Ihres Sortiments ab. Welcher Preis gilt, pro SKU und pro Organisation, eventuell pro Staffel und Vertragslaufzeit? Welche ihrer Nutzer dürfen was bestellen, und bis zu welchem Betrag? Und welche Kennungen braucht ihr System im zurückgegebenen Warenkorb? Das Beschaffungssystem eines Kunden verlangt häufig dessen eigene Artikelnummern, nicht Ihre.
Jede dieser Fragen betrifft Ihr Datenmodell. Entweder bildet Ihre Plattform Berechtigungen auf Firmenebene selbst ab, oder die Punchout-Schicht muss sie nachbauen. Und im Nachbauen verschwindet das Budget.
Die Frage nach den Artikelnummern verdient besondere Aufmerksamkeit. Man übersieht sie leicht in der Planung und entdeckt sie teuer im Test. Das System eines Großkunden arbeitet womöglich mit dessen interner Materialnummer. Kann Ihr Katalog keine kundenspezifische Artikelnummer pro SKU und Organisation speichern, lässt sich der zurückgegebene Warenkorb dort nicht abgleichen. Die Integration ist dann technisch fertig und kaufmännisch unbrauchbar.
Der Engpass ist Ihr Datenmodell, nicht das Protokoll
Hier laufen Ursache und Wirkung zusammen. Die Protokolle sind dokumentiert, stabil und schon von vielen Lieferanten vor Ihnen umgesetzt. Ob eine Integration sechs Wochen oder zwei Quartale dauert, hängt an einer Frage: Führt Ihre Commerce-Plattform Firmenkonten, Vertragspreise, kundenspezifische Kataloge und kundeneigene Artikelnummern bereits als vollwertige Daten?
Unterstützt eine Plattform B2B-Strukturen auf Firmenebene von Haus aus, wird Punchout zu einer Übersetzungsschicht über vorhandene Funktionen. Tut sie das nicht, wird die Punchout-Schicht zu einem zweiten Commerce-System im Schatten, das die Berechtigungslogik hält. Jede Preisänderung müssen Sie dann an zwei Stellen pflegen. Dieses zweite Szenario sollten Sie schon im Entwurf ausschließen, denn es macht aus einmaligen Integrationskosten dauerhafte Betriebskosten.
Das hängt direkt mit dem größeren Integrationsbild zusammen. Vertragspreise entstehen meist im ERP und nicht im Shop, Produktkennungen meist im PIM. Unsere Leitfäden zu Shopify-Anbindungen an ERP und PIM und zur API-Dokumentation für die ERP-Integration behandeln die Ebene darunter. Dort stellt sich dieselbe Frage: Welches System ist für welche Daten maßgeblich? Punchout zwingt Sie, sie ausdrücklich zu beantworten.
Wo Punchout scheitert
Der Mechanismus selbst ist stabil. Die Überraschungen ergeben sich aus dem Ablauf, und jede davon ist günstiger, wenn Sie sie einplanen, statt sie im Abnahmetest zu entdecken.
Die Lücke zwischen Warenkorb und Bestellung. Die Freigabe erfolgt, nachdem der Warenkorb Ihren Shop verlassen hat, und sie kann Tage dauern. Haben sich Preise, Bestand oder Aktionen in dieser Zeit geändert, passt die eingehende Bestellung nicht zu dem, was der Kunde freigegeben hat. Legen Sie vorab fest, ob ein zurückgegebener Warenkorb einen Preis für einen bestimmten Zeitraum hält. Machen Sie diese Regel dem Kunden gegenüber klar, statt die Abweichung erst über eine abgelehnte Bestellung zu bemerken.
Steuern und Versand. Viele Beschaffungssysteme berechnen nach der Rückgabe des Warenkorbs ihre eigenen Steuern und Frachtkosten. Die Summen in Ihrem Shop können daher von dem abweichen, was das System des Kunden erfasst. Klären Sie früh, welche Seite für welchen Betrag maßgeblich ist. Schon wenige Prozent Differenz auf die Gesamtsumme reichen, damit eine Bestellung in der Prüfung hängen bleibt.
Positionen, die das System des Kunden ablehnt. Ein zurückgegebener Warenkorb wird gegen Katalogregeln, Budgetcodes und erwartete Kennungen geprüft. Eine Position ohne Artikelnummer, mit unbekannter Mengeneinheit oder mit einer Kategorie, die das System nicht akzeptiert, kann stillschweigend wegfallen. Der Einkäufer sieht eine unvollständige Bedarfsanforderung und meldet das als Ihr Problem.
Abgelaufene Sitzungen und Wiedereinstieg. Punchout-Sitzungen laufen ab, und Einkäufer unterbrechen oft mitten im Warenkorb. Ob eine abgelaufene Sitzung weiterläuft, leer neu startet oder einen Fehler zeigt, ist eine Designentscheidung. Ein leerer Neustart bei einer Anforderung mit hundert Positionen: Daran erinnern sich Einkäufer.
Artikel außerhalb des Katalogs und konfigurierbare Produkte. Einkäufer wollen regelmäßig etwas, das nicht im freigegebenen Katalog steht, oder ein Produkt, dessen Preis von gewählten Optionen abhängt. Beides braucht einen festgelegten Weg. Ohne ihn lässt sich ein solcher Artikel gar nicht über die Integration bestellen und wird wieder zur manuellen Ausnahme. Genau das sollte die Integration abschaffen.
Kunden mit mehreren Gesellschaften. Ein einzelner Kunde kann aus mehreren juristischen Einheiten heraus per Punchout bestellen, jede mit eigenem Vertrag, eigener Währung, eigenen Lieferbedingungen und eigener Freigabekette. Ist die Gesellschaft nicht Teil Ihres Berechtigungsmodells, merken Sie es spätestens bei der zweiten.
Keiner dieser Punkte ist ein Protokollproblem. Es sind kaufmännische Regeln, die irgendwo existieren müssen, und Punchout zeigt oft, dass es sie nie gab.
Eine Beschaffungsintegration planen
Sechs Entscheidungen, am besten getroffen, bevor die Entwicklung beginnt.
Welcher Kunde, welche Plattform, welches Protokoll. Planen Sie für einen namentlich bekannten Kunden mit einer konkreten Anforderung. Generisch gebautes Punchout wird meist neu gebaut, sobald der erste echte Kunde kommt.
Welche Dokumente dazugehören. Punchout-Sitzung und Warenkorb-Rückgabe sind das Minimum. Bestellungen, Auftragsbestätigungen, Lieferavis und Rechnungen erweitern jeweils die Integration, und jedes davon ist ein eigenes Gespräch mit dem Team des Kunden.
Wo die Berechtigungen liegen. Entscheiden Sie, ob Firmenkonten, Vertragspreise und kundenspezifische Kataloge in Ihrer Commerce-Plattform oder in der Middleware abgebildet werden. Diese eine Entscheidung erklärt den größten Teil der Kostenunterschiede zwischen Implementierungen.
Wie Kennungen zugeordnet werden. Klären Sie, ob der Kunde seine eigenen Artikelnummern im zurückgegebenen Warenkorb braucht und wo diese Zuordnung gespeichert und gepflegt wird.
Was Ihre Plattform kann. Manche Commerce-Plattformen bringen Punchout von Haus aus mit, andere brauchen dafür Middleware oder eine App. Shopify hat kein eingebautes Punchout. Lieferanten setzen es über Connector-Apps oder eine eigene Middleware-Schicht um. Die öffentlich genannten Preise für Punchout-Connectoren im Shopify App Store reichen bis zu mehreren hundert Dollar pro Monat und Anbindung, weitere Anbindungen und Dokumenttypen kosten extra. Die laufenden Kosten wachsen also mit der Zahl der Großkunden und bleiben nicht konstant.
Wer testet. Beschaffungsintegrationen werden im System des Kunden geprüft, nach dessen Zeitplan und von dessen Team. Handeln Sie den Testzugang früh aus. Ein Lieferant, der testbereit ist, und ein Kunde ohne Testfenster: So bleiben Projekte häufig stehen.
Das Entwicklungsteam von Flatline plant Beschaffungsintegrationen als Teil von Enterprise-Commerce-Projekten. Dabei wiederholt sich immer dasselbe Muster: Die Protokollarbeit ist planbar, das Berechtigungsmodell bestimmt den Zeitplan.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Punchout und EDI?
Punchout deckt den Einkaufsvorgang ab: Der Einkäufer durchsucht Ihren Katalog aus seinem Beschaffungssystem heraus und schickt einen Warenkorb zurück. EDI deckt den strukturierten Austausch von Dokumenten zwischen Systemen ab, typischerweise Bestellungen, Bestätigungen, Lieferavis und Rechnungen. Oft laufen beide nebeneinander: Punchout übernimmt die Auswahl, eine Dokumentenschicht alles nach der Freigabe. cXML kann beide Teile abdecken, und das ist ein Grund, warum es meist der bessere Startpunkt ist.
Unterstützt Shopify Punchout?
Nicht von Haus aus. Lieferanten auf Shopify setzen Punchout über Connector-Apps oder eigene Middleware um. Diese verarbeitet die Setup-Anfrage, die Authentifizierung der Sitzung und die Rückgabe des Warenkorbs, während der Shop den freigegebenen Katalog anzeigt. Es geht also, aber die Kosten fallen laufend an und nicht einmalig. Das gehört in Ihren Business Case.
Wie lange dauert eine Punchout-Integration?
Die Protokollarbeit ist der planbare Teil, oft eine Sache von Wochen. Offen ist, ob Ihre Plattform Firmenkonten, Vertragspreise und kundenspezifische Kataloge bereits abbildet. Wenn ja, rechnen Sie in Wochen. Muss die Punchout-Schicht die Berechtigungen nachbauen, rechnen Sie mit Quartalen und mit dauerhafter Pflege in zwei Systemen.
Lohnt sich Punchout, bevor ein Kunde danach fragt?
Meistens nicht. Die Anforderungen hängen an Plattform, Protokoll, Dokumenten und Artikelnummern des jeweiligen Kunden, und eine generische Umsetzung wird meist beim ersten echten Bedarf umgebaut. Was sich vorab lohnt, ist das Datenfundament: Firmenkonten, Vertragspreise und saubere Produktkennungen. Die brauchen Sie ohnehin, egal welche Beschaffungsplattform zuerst kommt.
Das Wichtigste in Kürze
Über Punchout erreichen Großkunden Ihren Katalog: ausgewählt aus einer Liste freigegebener Lieferanten, als Sitzung geöffnet von ihrem Beschaffungssystem, ohne Login durchsucht und als Warenkorb in ihren Freigabeprozess zurückgegeben.
Zwei Protokolle tragen es. cXML ist der breitere Startpunkt und reicht bis in Bestellungen, Bestätigungen, Lieferavis und Rechnungen. OCI ist das SAP-nahe Format, das Sie umsetzen, wenn ein bestimmter Kunde es verlangt.
Das Protokoll ist nicht der schwierige Teil. Die eigentliche Arbeit besteht darin, eine Maschinenidentität einer Organisation, einem Vertrag, einem freigegebenen Katalog, den passenden Preisen und kundeneigenen Artikelnummern zuzuordnen. Das ist eine Frage des Datenmodells.
Bildet eine Plattform B2B-Strukturen auf Firmenebene von Haus aus ab, ist Punchout eine Übersetzungsschicht. Wenn nicht, wird der Connector zu einem zweiten Commerce-System mit eigener Preislogik, und die Kosten werden dauerhaft statt einmalig.
Beschaffungsintegration wirkt wie ein technisches Thema und verhält sich wie ein kaufmännisches. Wer im Moment des Kaufs im System des Kunden auftaucht, ist Teil eines Prozesses, der den Einkauf bewusst auf eine kurze Liste beschränkt. Auf dieser Liste zu stehen ist mehr wert als fast jede Shop-Optimierung, die man für dasselbe Budget kaufen könnte.
Verwandte Artikel
