Punchout erklärt

Irgendwann sagt die Einkaufsleitung eines Ihrer großen Kunden Ihrem Innendienst, dass die Bestellungen ab Januar über Coupa laufen, und fragt, ob Sie Punchout unterstützen. Übersetzt lautet die Frage: Können wir weiter bei Ihnen kaufen, ohne dass jemand unser System verlassen muss? Lautet die Antwort Nein, wandert der Vertrag.

Was Punchout ist

Punchout ist eine Verbindung zwischen dem Beschaffungssystem Ihres Kunden und Ihrem Shop. Betrachten Sie es von der Seite des Einkäufers, denn diese Seite entscheidet.

Ein Einkäufer in einem Unternehmen mit ein paar tausend Beschäftigten öffnet keinen Browser und sucht nach Lieferanten. Er öffnet SAP Ariba, Coupa, JAGGAER, Onventis oder das Einkaufsmodul seines SAP ERP, weil dort sein Budget, seine Kostenstellen und sein Freigabe-Workflow liegen. Dort sieht er eine Liste freigegebener Lieferanten, und er klickt auf Ihren.

In diesem Moment „springt“ das Beschaffungssystem heraus, daher der Name: Es öffnet Ihren Shop in einem Frame oder einem neuen Fenster, und der Einkäufer ist bereits angemeldet. Seine Identität kam im Aufruf mit, ein Passwort tippt niemand. Er sieht das Sortiment, das sein Unternehmen verhandelt hat, zu seinen Vertragspreisen, mit Ihren aktuellen Beständen. Er sucht, vergleicht und füllt einen Warenkorb wie in jedem anderen Shop.

Dann übergibt er den Warenkorb, statt zur Kasse zu gehen. Der Warenkorb wandert zurück ins Beschaffungssystem und wird dort zur Bedarfsanforderung, in der SAP-Welt die BANF. Freigabe, Kostenstellenzuordnung, Budgetprüfung und die Bestellung selbst passieren dort. Die Bestellung erreicht Sie anschließend als eigene Nachricht, auf dem Weg, den Sie mit dem Kunden für Bestellungen vereinbart haben.

Der Einkäufer hat sein System nie verlassen. Aus seiner Sicht ist Ihr Katalog eine Funktion von Coupa.

Warum große Kunden darauf bestehen

Einkaufsorganisationen ab einer gewissen Größe haben ein Ziel: alle Ausgaben an einer Stelle sehen und auf Lieferanten mit verhandelten Verträgen lenken. Dafür haben sie ein Beschaffungssystem gekauft, und jede Bestellung außerhalb dieses Systems ist Ausgabe, die sie nicht sehen, zu Konditionen, die sie nicht verhandelt haben.

Für Sie ist die Konsequenz hart. Ein Lieferant, der aus dem System heraus erreichbar ist, liegt auf dem Standardweg. Ein Lieferant, der es nicht ist, wird zur Ausnahme, die jemand von Hand abwickelt: ein PDF-Angebot, eine manuelle Bedarfsanforderung, eine E-Mail an den Einkauf. Der Einkauf räumt Ausnahmen auf. Über ein, zwei Einkaufszyklen ist ein Lieferant ohne Punchout aussortiert, und selten kündigt das jemand als Entscheidung über Sie an.

Deshalb sind die meisten Punchout-Projekte Verteidigungsprojekte, mit einem Datum daran.

Die drei Standards

In der Praxis begegnen Ihnen drei. Ihr Kunde entscheidet, welchen Sie brauchen: Er ergibt sich aus dem Beschaffungssystem, das er bereits betreibt.

OCI ist bewusst schlicht. Die Katalogdaten kommen als gewöhnliche HTML-Formularfelder zurück: NEW_ITEM-DESCRIPTION[1], NEW_ITEM-MATNR[1], NEW_ITEM-QUANTITY[1], NEW_ITEM-UNIT[1], NEW_ITEM-PRICE[1], NEW_ITEM-CURRENCY[1], NEW_ITEM-VENDORMAT[1], NEW_ITEM-MANUFACTMAT[1]. Diese Schlichtheit hat OCI verbreitet, und sie ist der Grund, warum fast jeder SAP-Kunde seine eigene kleine Abweichung davon pflegt.

cXML transportiert mehr: Lieferanten-Artikelnummern mit einer Auxiliary ID, Klassifikationscodes, Mengeneinheiten-Codes nach UN/CEFACT Recommendation 20 (C62 für Stück, EA für „each“, MTR für Meter) und ein BuyerCookie, das die Sitzung zusammenhält.

IDS funktioniert anders als die beiden anderen, weil seine Nutzer anders arbeiten. Die Handwerkersoftware eines Heizungsbauers fragt Ihren Shop über Aktionscodes an: WKE öffnet einen Einkaufsbesuch, dessen Warenkorb zurück in die Software geht. WKS schickt einen Warenkorb in Ihren Shop: Der Betrieb hat ihn in seiner Software vorbereitet und will Ihre Preise und Ihre Verfügbarkeit darauf sehen. ADL springt direkt zu einem Artikel, AS öffnet eine Suche. Mit LI und SV fragt die Software, welche Zugangsdaten und welche Schnittstellenversionen Ihr Shop erwartet, noch bevor irgendetwas eingerichtet ist.

Der Rundlauf, Schritt für Schritt

1. Setup-Aufruf. Das Beschaffungssystem ruft Ihren Punchout-Endpunkt mit Zugangsdaten auf: bei OCI eine URL mit Benutzername und Passwort als Parameter, bei cXML ein PunchOutSetupRequest mit Identity und Shared Secret.
2. Sitzungs-URL. Sie prüfen die Zugangsdaten, lösen auf, welcher Kunde das ist, legen eine Sitzung an und antworten mit einer URL. Bei cXML ist das eine PunchOutSetupResponse mit einer browserFormPost-Adresse; bei OCI leiten Sie direkt in den Shop um.
3. Der Einkäufer kauft ein. In Ihrem Storefront, in seiner Sitzung: sein Sortiment, seine Preise, Ihre aktuelle Verfügbarkeit. Dieser Teil sieht aus wie ein normaler Shop, und er ist der Grund, warum sich Punchout lohnt.
4. Warenkorbrückgabe. Der Einkäufer übergibt den Warenkorb. OCI postet die Positionen als Formularfelder zurück; cXML postet eine PunchOutOrderMessage. In beiden Fällen wechselt der Warenkorb die Seite, und Ihre Sitzung endet.
5. Freigabe in seinem System. Aus den Positionen wird eine Bedarfsanforderung. Kostenstellen, Budgets und Freigeber greifen. Positionen werden hier geändert oder gestrichen, und das passiert oft.
6. Bestellübertragung. Die freigegebene Bedarfsanforderung wird zur Bestellung und geht an Sie: als cXML OrderRequest, als EDI-Nachricht, als BME-Dokument oder, häufiger als irgendwer zugibt, als E-Mail. Das ist eine eigene Nachricht, getrennt vom Punchout. Wer die Schritte 1 bis 5 baut und Schritt 6 vergisst, bekommt Bestellungen als PDF, die jemand abtippt. Das war das Problem, das Sie lösen wollten.

Warum Punchout-Projekte scheitern

Fast nie am Protokoll. Das Protokoll ist eine Woche Arbeit. Das hier sind die Dinge, die Projekte stoppen, ungefähr in der Reihenfolge, wie oft sie es tun:

Preise. Kundenspezifische Konditionen liegen im ERP, manchmal in einer Tabelle im Vertrieb. Kommt der Shop nicht an denselben Preis, den das ERP berechnen würde, zeigt das Punchout Zahlen, die nicht zum Vertrag passen. Das fällt jemandem bei der ersten Bestellung auf, und es kostet Vertrauen, das über Jahre aufgebaut wurde. Ein Punchout-Projekt beginnt bei der Preisfindung, lange vor OCI.

Datenqualität. Beschaffungssysteme sind strenger als eine Webseite. Fünf Felder verursachen die meisten abgelehnten Positionen:

Das sind Katalogprobleme, keine Integrationsprobleme. Beheben Sie sie im Katalog; siehe Maße und Einheiten und Vollständigkeit und Bereitschaft.

Sitzungen und Authentifizierung. Zugangsdaten je Kunde, Sitzungen, die mitten im Warenkorb ablaufen, Einkäufer, die zwei Punchouts gleichzeitig öffnen, ein Warenkorb, der an ein System zurückgeht, das schon in den Timeout gelaufen ist. Unspektakulär, und verantwortlich für die meisten Support-Tickets im ersten Jahr.

Tests gegen das echte System. Dass Ihr Endpunkt gegen Ihre eigene Testumgebung besteht, beweist wenig; jede Beschaffungsinstallation ist angepasst. Testen Sie gegen das System des Kunden, mit seinen Zugangsdaten und seinem Einkäufer, bevor Sie es live nennen. Dieser Test braucht einen Slot in seiner IT-Warteschlange, ein Terminrisiko, das Sie nicht steuern. Versprechen Sie kein Go-Live-Datum, bevor dieser Slot steht.

Das Sortiment ist kundenspezifisch. Ein Punchout ist ein Vertrag, und der Vertrag nennt ein Sortiment. Wer einem Punchout-Einkäufer den ganzen Katalog zeigt, bricht die Vereinbarung und legt Artikel und Preise offen, die für diesen Kunden nie verhandelt wurden.

Was Punchout ersetzt

Die Alternative ist der statische Katalogaustausch: Sie exportieren Ihr Sortiment als BMEcat-Datei oder Excel-Tabelle, der Kunde importiert sie in sein System, und seine Einkäufer kaufen aus dieser Kopie.

Statische Kataloge sind für kleine Sortimente und für Kunden, deren System kein Punchout kann, nach wie vor üblich. Aber jeder Zyklus ist Handarbeit auf beiden Seiten, und zwischen den Zyklen sind die Daten falsch. Punchout schafft den Zyklus ab.

So funktioniert es in der Revenue Cloud

Zwei Teile greifen ineinander: Ein Kanal bestimmt, was der Einkäufer sieht, und ein Punchout-Konto bestimmt, wer hereinkommt und was wieder hinausgeht.

Der Kanal trägt Sortiment und Darstellung:

• Unter Configuration › Kanäle legen Sie einen Kanal vom Typ PunchOut mit eigenem Code an: punchout-acme für den einen Kunden, punchout-konzern-x für den nächsten. Ein Kanal je Punchout-Kunde ist die übliche Einrichtung, weil Sortiment und Darstellung je Vertrag verschieden sind.
• Jeder Kanal gehört zu einem Markt, und der bringt Währung, Locales und Steuerklassen mit. Siehe Sprachen und Märkte.
• Nicht zugeordnete Zeilen legt die Sichtbarkeitsregel fest; im Kanal-Detail heißt die Einstellung Produkte ohne Zuordnung zu diesem Kanal sind. Setzen Sie sie auf einem Punchout-Kanal auf Ausgeblendet bis zur Zuordnung (geschlossen), und nur ausdrücklich zugeordnete Produkte erscheinen, genau das, was ein Punchout-Vertrag beschreibt. Ihr Storefront-Kanal kann gleichzeitig offen bleiben.
• Kanalabhängige Attribute halten je Kanal einen eigenen Wert. Die kurze, schmucklose Beschreibung, die ein Beschaffungssystem braucht, ist damit eine andere als der Marketingtext in Ihrem Shop. Siehe Kanäle, Locales und Vollständigkeit.
• Die Vollständigkeit wird je Kanal berechnet. Damit stellen Sie vor dem Go-Live die einzige Frage, die zählt: Wie viele der 2.400 Artikel in diesem Punchout-Kanal tragen eine Mengeneinheit, eine Herstellerteilenummer und eine Steuerklasse?

Das Punchout-Konto liegt unter Procurement › Punchout, eines je Fremdsystem:

Eine Übergabe ist keine Bestellung. Sie reserviert keinen Bestand und bucht nichts. Sie ist der Nachweis dessen, was Sie übergeben haben, und genau den brauchen Sie, wenn der Einkauf des Kunden fragt, warum Position vier ohne Mengeneinheit ankam.

Weiter

• Ein Punchout einrichten: die Verbindung, Schritt für Schritt.
• Feld-Mapping: aus Ihren Feldern seine machen.