B2B ist kein D2C mit Login
Der Satz klingt nach Agenturformel, hat aber sehr konkrete Folgen. Im technischen Handel ist der Preis keine Eigenschaft des Artikels, sondern eine Eigenschaft der Geschäftsbeziehung: kundenindividuelle Konditionen, Staffelpreise, Rahmenverträge, Nettodarstellung, Bestellung auf Rechnung. Ein Shop, der einen Listenpreis zeigt, während der Vertrieb einen anderen Preis zugesagt hat, produziert genau das Ergebnis, das ihn überflüssig macht: Der Einkäufer ruft an, klärt den Preis und bestellt danach wieder per E-Mail. Deshalb ist die Preislogik in diesen Projekten kein Konfigurationspunkt am Ende, sondern eine der ersten Fragen im Konzept.
Die zweite Abweichung betrifft die Rollen. Der Besteller ist häufig nicht der Entscheider. Es gibt Zentralen und Niederlassungen unter einem Kundenkonto, mehrere Besteller pro Standort, Budgetgrenzen und Freigabeprozesse, bei denen eine Bestellung erst nach interner Genehmigung rausgeht. Wer diese Kette nicht abbildet, zwingt den Kunden in einen Umweg — und Umwege im Einkauf enden im alten Prozess. Eine Sache gehört dabei vor das Angebot und nicht in die Projektmitte: Kundengruppen, kundenindividuelle Preise und Staffeln bringt Shopware 6 im offenen Kern mit, Kundenhierarchien mit Zentrale und Niederlassungen, Bestellfreigaben und Budgets liefert Shopware als B2B Components in den kostenpflichtigen Plänen oder wir bauen sie als eigenes Plugin. Welcher Weg günstiger ist, rechnen wir vorher durch.
Und drittens ist der Einstieg ein anderer. Der Einkäufer sucht nicht Inspiration, er sucht Wiederbeschaffung. Er hat das Teil vor drei Monaten schon einmal bestellt und will es ohne Suchvorgang nachordern. Bestellhistorie, Nachbestellung aus einem alten Auftrag, Merklisten für wiederkehrende Positionen: Das sind im B2B keine Komfortfunktionen, sondern der eigentliche Nutzwert. Bei M&S Armaturen ist genau diese Verschiebung das Projektziel gewesen — wiederkehrende Beschaffungsvorgänge laufen über den Shop, Anfragen mit Auslegungsbedarf gehen weiter an den Vertrieb.
Merkmale, nach denen wirklich gesucht wird
Ein Filter, der Werkstoff, Nennweite und Druckstufe nicht kann, ist im technischen Handel kein Filter. Die Merkmale müssen als eigene Attribute im Datenmodell liegen, mit definierten Werten und Einheiten, nicht als Satz im Beschreibungstext. Das klingt selbstverständlich und ist es nicht: Datenübernahmen aus Altsystemen liefern diese Werte regelmäßig als Textblock, weil sie dort nie anders gebraucht wurden. Die Modellierung dieser Attribute ist in Projekten dieser Art ein eigener Arbeitsschritt und häufig der, der über die Qualität des Ergebnisses entscheidet — nicht das Frontend-Design.
Dazu kommt die Suche. Sie muss Artikelnummern mit Sonderzeichen treffen, Kurzbezeichnungen kennen und mit unvollständigen Eingaben umgehen. Im Magento-Shop von Manotura läuft die Produktsuche deshalb über Elasticsearch und nicht über die Datenbankabfrage. Bei M&S Armaturen greift die Suche ebenfalls auf einen Index zu, der Artikelnummern und Kurzbezeichnungen mit einbezieht. Der Unterschied ist im Betrieb messbar an einer einfachen Größe: Wie oft endet eine Suche ohne Treffer, obwohl der Artikel im Katalog liegt.
Zum Datenmodell gehören die Dokumente. Datenblätter, Maßzeichnungen, Werkstoffangaben, Normen und Zulassungen sind Teil des Artikels, nicht Inhalt eines Ablageordners neben dem Katalog. Wer eine Zulassung sucht, sucht sie zu einem Bauteil. Und er kommt dabei selten über die Startseite: Der industrielle Einkauf steigt über die Suchmaschine direkt auf der Produkt- oder Werkstoffseite ein. Bei FRANKSA ist der Auftritt genau darauf ausgelegt — einzeln adressierbare Produkt- und Werkstoffseiten mit flacher Klickstruktur, statt eines Sortiments, das sich hinter einer Ebene aus Oberbegriffen versteckt. Wie eng Dokument und Artikel verbunden sein müssen, hängt vom Fall ab: Im Shop-Katalog gehört das Datenblatt an den Artikeldatensatz; auf einer Website wie der von Manotura sind Downloadbereiche an der Produktgruppe die pragmatischere Form, weil dort die Redaktion pflegt und nicht die Schnittstelle.
Das ERP führt, der Shop folgt
Bestand, Preise und Kundenkonditionen liegen in der Warenwirtschaft. Der Shop ist Anzeige- und Bestellkanal, nicht Datenherr. Diese Rollenverteilung klingt banal, wird aber häufig verletzt — meist weil in der Anfangsphase eine Preisliste schneller im Shop gepflegt ist als im ERP. Danach existieren zwei Wahrheiten, und die Differenz zwischen ihnen erzeugt Nacharbeit im Vertrieb. Bei M&S Armaturen und bei Manotura läuft es deshalb in beide Richtungen definiert: Artikelstamm, Preise und Verfügbarkeiten kommen aus dem führenden System in den Shop, Bestellungen den umgekehrten Weg strukturiert zurück, statt als E-Mail im Postfach zu landen.
Die Qualität dieser Anbindung entscheidet sich nicht am Datenformat, sondern am Verhalten im Fehlerfall. Ein Abgleich bricht irgendwann ab — wegen eines Netzausfalls, eines gesperrten Datensatzes, eines Feldes, das im ERP plötzlich leer ist. Die Übertragungen sind bei uns deshalb als wiederholbare Jobs mit Protokoll je Lauf und Wiederholungslogik gebaut, sodass ein abgebrochener Abgleich ohne Datenschaden erneut startet und ein einzelner Fehlschlag nicht die ganze Synchronisation blockiert. Wie das im Detail aussieht, steht auf der Seite zur Schnittstellen- und API-Entwicklung.
Umgekehrt gilt: Nicht alles gehört ins ERP. Marketingtexte, Bilder in mehreren Auflösungen, Übersetzungen, Zubehör- und Alternativverweise sind dort meist fehl am Platz. Dafür ist entweder ein PIM zuständig oder der Shop selbst. Diese Grenze früh zu ziehen ist billiger, als sie später zu korrigieren — sonst wird die Warenwirtschaft zum Redaktionssystem, und jede Textänderung braucht einen ERP-Zugang. Wo die Grenze verläuft, hängt vom Haus ab und ist eine Frage, die vor dem Angebot geklärt wird, nicht danach.
Wenn der Einkauf des Kunden das Bestellsystem vorgibt
OCI steht für Open Catalog Interface, einen von SAP etablierten Standard für die elektronische Beschaffung. Systeme wie Ariba oder Coupa arbeiten stattdessen mit cXML PunchOut — technisch anders, im Prinzip dasselbe. Der Ablauf ist in beiden Fällen: Absprung aus dem Beschaffungssystem in Ihren Shop, Zusammenstellung des Warenkorbs mit den Konditionen des Kunden, strukturierte Rückübertragung. Der Vorteil gegenüber einer statischen Katalogdatei ist, dass Preise und Sortiment an einer Stelle gepflegt werden: in Ihrem Shop. Kein Katalogexport, kein Versionsstand, der beim Kunden veraltet.
Wie das konkret aussieht, zeigt der Shopware-Shop von Lijnco für Formular- und Drucklösungen im Bankenumfeld. Der Einkäufer startet in seinem Beschaffungssystem, wird per Punch-out mit den übergebenen Zugangsdaten am Shop angemeldet und sieht sein freigeschaltetes Sortiment zu den für ihn gültigen Preisen. Der fertige Warenkorb löst keine Bestellung aus, sondern geht im OCI-Feldformat an die Hook-URL des Beschaffungssystems zurück — mit Artikelnummer, Beschreibung, Menge, Preis und Einheit. Unterstützt wird dort der Punch-out-Standard OCI 4.0. Jede Anbindung wird gegen das jeweilige Kundensystem getestet, weil sich Feldbelegungen, Zeichensätze und Rückgabeverfahren in der Praxis unterscheiden.
Die eigentliche Arbeit steckt also in der Rückübertragung und in der Abstimmung. Jedes Beschaffungssystem erwartet den Warenkorb in einer bestimmten Struktur — Materialnummern, Warengruppen, Mengeneinheiten, teils Klassifikationen wie eCl@ss. Fertig ist die Anbindung erst, wenn das E-Procurement-Team Ihres Kunden sie abgenommen hat. Für die Praxis heißt das zwei Dinge: Ein bestehender Shop wird punch-out-fähig gemacht, es braucht keinen zweiten Shop für den Einkauf. Und ein Shop kann viele Großkunden bedienen — bei sauberer Umsetzung ist der zweite Kunde Konfiguration, nicht ein neues Projekt. Details dazu auf der Leistungsseite zu OCI und Punch-out.
Shop, Website und Anfragestrecke sind drei Aufgaben
Viele Häuser in dieser Branche betreiben Shop und Unternehmenswebsite getrennt, und das ist meist eine richtige Entscheidung, keine gewachsene Unordnung. M&S Armaturen fährt einen B2B-Shop auf Shopware 6 und die Unternehmenswebsite auf TYPO3. Manotura betreibt den Magento-Shop und den Fachhandelsauftritt auf TYPO3 als zwei Systeme. Die Gründe sind praktisch: unterschiedliche Zielgruppen, unterschiedliche Pflegerhythmen, unterschiedliche Releasezyklen. Ein Shopware-Update soll die Karriereseite nicht anfassen, und eine Redaktion, die Nachhaltigkeits- und Karriereinhalte pflegt, muss dafür nicht in einem Shop-Backend arbeiten. Redaktionell verweisen die beiden Auftritte aufeinander, technisch bleiben sie entkoppelt.
Wo gar kein Warenkorb sinnvoll ist, verlagert sich das Projekt auf die Erschließung des Sortiments und die Anfrage. Bei Wehry Regale — WordPress mit eigenem Theme statt Baukasten — hängt die Auswahl an Traglast, Höhe, Lagergut und Fläche; wer sucht, weiß meist, was er lagern will, aber nicht, wie die passende Bauart heißt. Die Aufgabe der Seite ist dann, Varianten verständlich zu sortieren und den Weg zur Anfrage kurz zu halten. Bei Littwin Systemtechnik, ebenfalls WordPress mit schlankem Theme statt Plugin-Stapel, geht es darum, Leistungsspektrum und Referenzen mit technischer Tiefe zu erklären, weil Anfragen erst entstehen, wenn ein Interessent erkennt, dass jemand seine Branche kennt.
Zwischen Katalog und Anfrage liegt die Maßware. Bei Max Glas entsteht der Preis erst, wenn Maße, Glasart, Stärke, Kantenbearbeitung und Beschläge festgelegt sind — vorher gibt es bestenfalls eine Spanne. Der Konfigurator ist dort eine Eigenentwicklung und übernimmt die Aufgabe, die im Ladengeschäft das Beratungsgespräch hätte: führen, zulässige Kombinationen begrenzen, unmögliche Eingaben abfangen. Die Regel- und Preisberechnung läuft serverseitig, damit die Kalkulation nicht im Browser manipulierbar ist, und die Versandlogik unterscheidet Paket von Spedition, weil eine großformatige Scheibe kein Paket ist. Fehler, die erst in der Fertigung auffallen, sind bei geschnittenem Glas nicht korrigierbar.
Was für alle drei Fälle gilt: Welcher davon zu Ihnen passt, sagen wir vor dem Angebot. Wenn ein Shop in Ihrem Fall den Aufwand nicht rechtfertigt — weil das Sortiment zu beratungsintensiv ist oder die Datenlage im ERP dafür noch nicht trägt — sagen wir das und schlagen den kleineren Schritt vor.