Komplexe Produkte verkaufen

Kundeneinkauf per Punchout anbinden

Verkaufen Sie in den Beschaffungssystemen Ihrer großen Kunden, dort, wo deren Einkäufer ohnehin arbeiten.

Ab einer bestimmten Größe besuchen die Einkäufer Ihrer Kunden keine Lieferanten-Websites mehr. Sie arbeiten in SAP Ariba, Coupa, JAGGAER, Onventis oder einem SAP-ERP, weil ihr Unternehmen jeden Euro Ausgaben an einer Stelle sehen und an Lieferanten mit verhandelten Verträgen lenken will. Ein Lieferant, der aus diesem System heraus nicht erreichbar ist, wird zur Ausnahme, die jemand von Hand bearbeiten muss, und Ausnahmen werden wegorganisiert. Punchout ist der Weg, im Standardpfad zu bleiben.

Warum das schwerer ist, als es klingt

Punchout wird oft als eine Integration beschrieben. Es ist eine Integration pro Kunde, und jeder Konzern kommt mit seinem eigenen Dialekt: welcher Standard in welcher Version, welche Felder im zurückgegebenen Warenkorb Pflicht sind, welche Codeliste für Mengeneinheiten gilt, ob eine Klassifikation wie eCl@ss oder UNSPSC verlangt wird, wie Steuer und Währung erwartet werden, und was das System mit einer Beschreibung macht, die ihm zu lang ist. Nichts davon verhandeln Sie. Der Kunde gibt vor, Sie liefern.

Das ist der erste Punkt, den Sie verinnerlichen sollten: Den Standard bestimmt Ihr Kunde. OCI kommt aus der SAP-Welt und ist im deutschen Mittelstand der häufigste Fall, mit OCI 4 und OCI 5 parallel im Einsatz. cXML kommt aus der Ariba-Welt und deckt aufwendigere Beschaffungsabläufe ab. openTRANS deckt die Belege in der Gegenrichtung ab: Bestellung, Auftragsbestätigung, Lieferavis, Rechnung. Wer alle drei bedienen kann, muss diese Diskussion nie wieder führen.

Punchout-Projekte scheitern an Preisen, nicht am Protokoll. Die Verbindung selbst ist vergleichsweise mechanisch. Liegen kundenspezifische Konditionen in einer Tabelle oder in einer Ecke des ERP, die die Plattform im Moment des Seitenaufbaus nicht erreicht, zeigt der Punchout die falsche Zahl, im eigenen System des Einkäufers, neben seinem Vertrag. Das fällt bei der ersten Bestellung auf und ist teuer zu reparieren. Ein Punchout-Projekt beginnt mit der Preisfindung und kommt später zu OCI.

Die zweite verlässliche Unterschätzung ist die Strenge der Daten. Eine Webseite stellt unvollkommene Daten unschön dar; ein Beschaffungssystem lehnt sie ab. Eine fehlende Mengeneinheit, ein Einheitencode, den das Kundensystem nicht kennt, eine fehlende Klassifikation, eine Menge, die kein ganzzahliges Vielfaches der Bestelleinheit ist: Jedes davon ist eine abgelehnte Position, kein Layoutfehler. Die Katalogarbeit hinter einem Punchout ist strenger als die hinter einem Shop, und es ist derselbe Katalog.

Drittens liegt das Terminrisiko nicht bei Ihnen. Der Test braucht Zugang zur Testumgebung des Kundensystems, und das heißt ein Slot in der Warteschlange einer Konzern-IT. Wer einen Go-live-Termin verspricht, bevor dieser Slot existiert, reißt ihn, aus Gründen, die er nicht beeinflusst.

Zwei kleinere Denkkorrekturen. Das Sortiment gilt je Vertrag. Zeigen Sie einem Punchout-Einkäufer Ihr gesamtes Sortiment, legt er Artikel in den Korb, die sein System ablehnt, und die Beschwerde landet bei Ihnen. Und Design spielt hier kaum eine Rolle. Der Einkäufer sieht Ihren Shop innerhalb seiner Beschaffungssitzung, kurz, mit einer Aufgabe. Suchqualität, Tempo und korrekte Preise sind alles; Markenauftritt und Marketinginhalte sind nahezu unerheblich.

Es gibt im Cockpit keinen einzelnen Bildschirm „Punchout". Ein Punchout wird zusammengesetzt: ein Kanal vom Typ Punchout in Commerce Studio für den Katalogausschnitt dieses Kunden, Zugangsdaten in Integration Studio, und ein Connector oder Workflow für den Hin- und Rückweg. Die Anleitungen unten führen durch diese Reihenfolge.

Die Hebel

Verstehen Sie, was der Kunde verlangt

So sieht es gut aus: Vor jeder Konfiguration haben Sie schriftliche Antworten auf eine kurze Liste: Standard und Version, Authentifizierung, die URL, die aufgerufen wird, die Felder, die zurückkommen müssen, Einheiten- und Klassifikationsstandards, ob auch die Belege zurückgewollt werden, und wer auf der Kundenseite testet.

Wovon es abhängt: Den technischen Ansprechpartner zu erreichen, nicht nur den Einkäufer. Der Einkäufer weiß, dass er Punchout will; das Systemteam weiß, was das bedeutet.

Bringen Sie Preise und Sortiment für diesen Kunden in Ordnung

So sieht es gut aus: Der Einkäufer springt hinein und sieht exakt die Artikel, die sein Rahmenvertrag abdeckt, zu exakt den Konditionen, die er nennt, Staffeln eingeschlossen. Können Sie das noch nicht garantieren, haben Sie keinen Punchout begonnen, sondern etwas anderes.

Wovon es abhängt: Konditionen aus dem System zu lesen, das sie pflegt, und das Sortiment je Kunde steuern zu können statt je Storefront.

Bringen Sie die Katalogdaten auf Beschaffungssystem-Niveau

So sieht es gut aus: Jeder Artikel, der in einem Punchout-Warenkorb landen kann, hat eine Mengeneinheit mit gültigem Code, eine Währung, eine Steuerangabe, eine Beschreibung innerhalb der Länge, die der Kunde akzeptiert, und die geforderte Klassifikation. Nichts davon ist optional.

Wovon es abhängt: Die Beschaffungssysteme als eigenen Kanal mit eigenen Vollständigkeitsregeln zu behandeln, statt anzunehmen, die Regeln des Web-Kanals reichten aus.

Einrichten, zuordnen, testen

So sieht es gut aus: Der Einkäufer klickt aus seinem System heraus und ist bereits angemeldet. Er füllt einen Warenkorb, gibt ihn zurück, und jede Position kommt mit den Feldern an, die sein System erwartet. Die anschließende Bestellung erreicht Sie als normale Bestellung und wird wie eine behandelt.

Wovon es abhängt: Testzugang auf der Kundenseite und disziplinierte Feldzuordnung auf Ihrer. Rechnen Sie mit zwei, drei Korrekturrunden am zurückgegebenen Warenkorb; das ist normal.

Eine sinnvolle Reihenfolge

Phase 1: ein Kunde, komplett. Nehmen Sie den Kunden, der am lautesten fragt, holen Sie seine Spezifikation schriftlich ein, bringen Sie zuerst seine Preise und sein Sortiment in Ordnung, dann bauen und testen Sie die Verbindung gegen seine Testumgebung, bevor Sie an die Produktivumgebung gehen. Das Ergebnis ist mehr als eine laufende Verbindung: eine Vorlage, eine dokumentierte Fragenliste, eine Feldzuordnung und ein Testskript zum Wiederverwenden. Voraussetzung: Die Preisfindung ist gelöst. Deshalb lohnt es sich, damit anzufangen, bevor der Kunde überhaupt fragt.

Phase 2: die zweite und dritte Verbindung als Routine. Jeder neue Kunde folgt der Vorlage: Spezifikation, Sortimentsumfang, Preisprüfung, Feldzuordnung, Test, Go-live. Beim dritten ist der Großteil Prüfung statt Aufbau. Voraussetzung: Phase 1 hat eine aufgeschriebene Vorlage erzeugt statt Wissen in einem Kopf, und das entscheiden Sie während Phase 1.

Phase 3: die Belege zurück, und Skalierung. Auftragsbestätigung, Lieferavis und Rechnung elektronisch zurück, damit der ganze Zyklus Maschine zu Maschine läuft statt nur der Warenkorb. Dazu Überwachung je Verbindung und ein definierter Wiederholungstest nach jeder Änderung auf einer der beiden Seiten. In dieser Phase hört Punchout auf, ein Zugeständnis an den Vertrieb zu sein, und wird ein Betriebskanal.

Typische Fehler

Mit dem Protokoll anfangen. OCI ist der mechanische Teil. Fangen Sie mit den Preisen an.
Einen Go-live-Termin versprechen, bevor die Kunden-IT einen Testslot vergeben hat. Deren Warteschlange bestimmt Ihren Zeitplan.
Ein Sortiment für alle Punchout-Kunden. Rahmenverträge unterscheiden sich. Artikel außerhalb des Vertrags erzeugen abgelehnte Positionen und verärgerte Einkäufer.
Einheiten und Klassifikation ignorieren. Die zwei Felder, die am häufigsten aus einer funktionierenden Verbindung abgelehnte Bestellpositionen machen, und beides ist Katalogarbeit, keine Integrationsarbeit.
Keine Überwachung nach dem Go-live. Ein kaputter Punchout ist stumm: Der Einkäufer meldet ihn nicht, er wählt den nächsten Lieferanten aus derselben Liste. Behandeln Sie einen unerklärten Rückgang der Punchout-Bestellungen als Störung.
In das Design der Punchout-Sitzung investieren. Der Einkäufer will eine Teilenummer finden und gehen.

Woran Sie erkennen, dass es funktioniert

Laufende Verbindungen, namentlich, mit Standard und Version je Verbindung. Ein Punchout-Programm ohne diese Liste wird nicht gesteuert.
Bestellungen und Bestellpositionen pro Monat, je Verbindung. Je Verbindung ist wichtig: Ein einzelner kaputter Kunde verschwindet in einer Summe vollständig.
Abgelehnte oder korrigierte Warenkorbpositionen, je Verbindung. Ziel ist null, und jede wiederkehrende Ursache gehört in den Katalog-Backlog.
Umsatzanteil über Punchout, im Zeitverlauf. Die Zahl, die weitere Verbindungen rechtfertigt.
Zeit von der Kundenanfrage bis zur laufenden Verbindung, für jede gemessen. Sie sollte zwischen der ersten und der dritten deutlich fallen; tut sie es nicht, hat Phase 1 keine wiederverwendbare Vorlage erzeugt.
Katalogpositionen, die die Prüfung des Beschaffungskanals nicht bestehen. Prüfen Sie selbst, bevor das Kundensystem es für Sie tut; siehe Vollständigkeit und Bereitschaft.

Was Sie bauen

Eine Verbindung je Konzernkunde: Sein Einkäufer startet in Ariba, Coupa oder seinem SAP, landet bereits angemeldet in Ihrem Storefront, sieht nur das Sortiment und die Konditionen seines Rahmenvertrags, füllt einen Warenkorb und gibt ihn als Bedarfsanforderung in sein eigenes System zurück. Die daraus entstehende Bestellung kommt als normale Bestellung an und geht in Ihr ERP. Jede Verbindung wird aus einem Punchout-Kanal, Zugangsdaten und einem Workflow zusammengesetzt; die Belege zurück (Auftragsbestätigung, Lieferavis, Rechnung) laufen ebenfalls über Integration Studio.

flowchart LR
  PROC["Beschaffungssystem des Kunden: Ariba, Coupa, SAP"]
  ERP["Ihr ERP"]
  subgraph CS["Commerce Studio"]
    CH["Kanal: Punchout, je Kunde"]
    ORG["Organisationen und Segmente"]
    PR["Preislisten: Vertragskonditionen"]
    P["Produkte: Einheiten, Klassifikation"]
    O["Bestellungen"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront in der Punchout-Sitzung"]
  end
  subgraph IS["Integration Studio"]
    CRED["Zugangsdaten"]
    WF["Workflows: OCI / cXML Hin- und Rückweg"]
    DOC["Workflows: Auftragsbestätigung, Lieferavis, Rechnung"]
  end
  PROC -- "Punchout-Anmeldung" --> CRED
  CRED --> SF
  CH --> SF
  ORG --> SF
  PR --> SF
  P --> SF
  SF -- "Warenkorb zurück" --> WF
  WF -- "Bedarfsanforderung" --> PROC
  PROC -- "Bestellung" --> WF
  WF --> O
  O --> ERP
  ERP -- "Bestätigung, Versand, Rechnung" --> DOC
  DOC --> PROC
  ERP -- "Konditionen" --> PR

Was Sie brauchen

Die schriftliche Spezifikation des Kunden: Standard, Version, Authentifizierung, Pflichtfelder, Einheiten- und Klassifikationscodes, Testkontakt — Punchout erklärt
Die Konditionen dieses Kunden lesbar aus dem ERP, Staffeln eingeschlossen, Zeile für Zeile geprüft — Vertragspreise für einen Kunden
Der Kunde als Organisation mit den Kontakten, die hineinspringen — Organisationen
Ein Kanal für den Sortimentsausschnitt dieses Kunden — Kanäle
Vollständigkeitsregeln für den Beschaffungskanal: Einheitencode, Währung, Steuer, Beschreibungslänge, Klassifikation — Vollständigkeit und Bereitschaft
Klassifikation, wo der Kunde sie verlangt (eCl@ss, ETIM, UNSPSC) — Klassifikationsstandards
Ein Testslot in der Testumgebung des Kundensystems, mit Datum — Einen Punchout einrichten
Bestellweg und Nummernkreis mit dem ERP-Verantwortlichen abgestimmt — Der Lebenszyklus einer Bestellung

So bauen Sie es

Dem Kunden die Fragenliste schicken und die Antworten schriftlich vom Systemteam einholen — Punchout erklärt
Seine Vertragskonditionen laden und zwanzig Artikel gegen seine letzten Rechnungen prüfen — Prüfen, welchen Preis ein Einkäufer sieht
Die Organisation und die hineinspringenden Kontakte anlegen — Organisationen
Einen Kanal vom Typ Punchout für diesen Kunden anlegen und das Vertragssortiment zuweisen — Kanäle
Die Vollständigkeitsregeln des Kanals definieren und die Prüfung laufen lassen; Einheiten und Klassifikation zuerst beheben — Vollständigkeit und Bereitschaft
Zugangsdaten und Endpunkt des Kunden hinterlegen — Zugangsdaten
Den Punchout-Rundweg aufbauen: Anmeldung, Sitzung, Warenkorbrückgabe — Einen Punchout einrichten
Die Felder des zurückgegebenen Warenkorbs auf das zuordnen, was das Kundensystem verlangt — Feldzuordnung
Gegen die Testumgebung testen; mit zwei, drei Korrekturrunden rechnen — Eine Integration durchgängig testen
Die erste echte Bestellung bis ins ERP führen und Zeile für Zeile abgleichen — Mit dem ERP abgleichen
Die Vorlage schreiben: Fragenliste, Feldzuordnung, Testskript, an einem Ort, den der nächste Kollege findet — Ein System anbinden
Vor dem zweiten Kunden die Überwachung je Verbindung einrichten — Synchronisationen überwachen
Die Rückbelege ergänzen: Auftragsbestätigung, Lieferavis, Rechnung — Einen Workflow bauen

Entscheidungen, die Sie treffen müssen

Entscheidung	Die Abwägung	Wohin die meisten Kunden gehen
Preise: live aus dem ERP lesen oder als Preislisten in der Plattform pflegen?	Live lesen ist exakt und hängt davon ab, dass das ERP während der Sitzung antwortet. Preislisten in der Plattform sind schnell und brauchen einen disziplinierten Abgleich, sonst laufen sie vom Vertrag weg.	Das ERP besitzt sie, der Abgleich in Preislisten läuft in kurzem Takt, und vor dem Go-live wird gegen den Vertrag geprüft. Wo das ERP unter einer Sekunde antwortet, live. Die falsche Antwort ist die Tabelle.
Ein Sortiment für alle Punchout-Kunden oder ein Kanal je Kunde?	Ein Sortiment ist weniger Pflege und zeigt Artikel außerhalb des jeweiligen Vertrags, die das Kundensystem ablehnt. Ein Kanal je Kunde ist exakt und vervielfacht die Konfiguration.	Ein Kanal je Kunde. Rahmenverträge unterscheiden sich, und eine abgelehnte Position landet auf Ihrem Tisch. Die Kanaldefinition wird die Vorlage.
Welche Standards bedienen Sie? Nur OCI, oder OCI, cXML und die openTRANS-Belege.	OCI deckt die meisten Mittelstandskunden ab und nichts aus der Ariba-Welt. Alle drei zu bedienen heißt, die Diskussion nie wieder zu führen, und jeder hat eigenen Testaufwand.	OCI zuerst, weil so zuerst gefragt wird; cXML mit dem ersten Ariba-Kunden; openTRANS-Belege in Phase 3. Je Kunde entscheiden, nicht im Voraus.
Klassifikation: Ihre Attribute einmal auf den Standard abbilden oder je Kunde befüllen?	Einmal abbilden ist ein Modellierungsprojekt und wiederverwendbar. Je Kunde ist beim ersten schneller und hört nie auf.	Einmal abbilden, je Standard, und die Version aktuell halten. Der zweite Kunde auf demselben Standard kostet nichts.
Wer verantwortet die Verbindung nach dem Go-live?	Ein Verantwortlicher mit wöchentlichem Blick auf die Laufliste kostet eine Stunde. Kein Verantwortlicher heißt, der Kunde wählt einen anderen Lieferanten aus derselben Liste, und niemand merkt es.	Eine benannte Person je Verbindung, und ein Rückgang der Monatsbestellungen gilt als Störung. Diese Entscheidung wird am häufigsten übersprungen.