3D-Produktkonfigurator und Shop für Yido Performance

Sie kennen den Punkt, an dem die Pflege kippt, wenn Ihr Sortiment aus Teilen besteht, die nur für bestimmte Fahrzeuge oder Anlagen freigegeben sind: Im Shop steht der Artikel, die Freigabe dazu steht in einem Dokument, und mit jeder Aktualisierung liegen beide Stände ein Stück weiter auseinander.

Yido Performance handelt mit Felgen und Fahrzeugteilen. Verkauft wird dabei selten das Produkt allein, sondern die Kombination aus Rad, Fahrzeugtyp, Reifengröße und den Auflagen, die im Gutachten dazu stehen. Ein Rad, das an einem Modell zulassungsfähig ist, ist es am nächsten nur mit Bördelung oder gar nicht.

Diese Angaben kommen von den Herstellern, in Form von Gutachtendaten: Fahrzeugschlüssel, zulässige Größen und Einpresstiefen, erlaubte Reifenkombinationen, Auflagentexte. Pro Felgenmodell steht dahinter eine lange Liste an Fahrzeugvarianten, jede mit eigenen Bedingungen.

Von Hand gepflegt ist dieser Bestand immer ein wenig veraltet, weil jede Gutachtenaktualisierung Arbeit auslöst, die niemand gern übernimmt. Teurer wird, dass er im Shop nicht abfragbar ist: Die Frage, ob das Rad an dieses Auto darf, landet beim Innendienst und wird im PDF nachgeschlagen. Ein Fehler in der Zuordnung fällt dann erst beim Kunden auf, mit Retoure und Zulassungsfrage im Gepäck.

Der Aufwand in diesem Projekt steckt nicht in der Darstellung, sondern in den Daten dahinter. Gebaut wurde deshalb zuerst die Datenpipeline, die Gutachten-XML in Artikel, Varianten und Fahrzeugfreigaben übersetzt. Konfigurator, Warenwirtschaft und Onlineshop setzen darauf auf.

Import und Normalisierung

Die Herstellerdateien sind formal XML, inhaltlich aber unterschiedlich geschnitten: andere Feldnamen, andere Schreibweisen für dieselbe Auflage, andere Tiefe bei den Fahrzeugangaben. Jede Quelle wird über einen eigenen Adapter eingelesen und in ein internes Zwischenformat überführt. Erst dieses Zwischenformat kennt die Begriffe des Shops: Artikel, Ausführung, Größe, Fahrzeugfreigabe, Auflage.

Der Abgleichslauf

Der Lauf lässt sich beliebig oft wiederholen und vergleicht den eingelesenen Stand mit dem Stand im System. Jeder Datensatz bekommt eine Einordnung: unverändert, neu, geändert oder abgewiesen. Abgewiesen wird, was sich nicht eindeutig zuordnen lässt, etwa ein Fahrzeugschlüssel, den der Bestand nicht kennt, oder eine Größenangabe, zu der keine Ausführung passt.

Entscheidend ist, was mit diesen Fällen passiert. Sie landen in einer Klärliste, die nach dem Lauf einsehbar ist. Ein abgewiesener Datensatz erscheint nicht im Shop, und ein Artikel wird erst sichtbar, wenn Pflichtangaben, Bildmaterial und Preis vorliegen. Ein halb importiertes Produkt lässt sich damit nicht bestellen.

Der 3D-Konfigurator

152 Felgen liegen als 3D-Modelle vor. Der Kunde wählt sein Fahrzeug, und der Konfigurator zeigt die Räder, die dafür freigegeben sind, mit den zulässigen Größen und Einpresstiefen. Die Auflagen zur gewählten Kombination stehen vor dem Bestellabschluss auf dem Bildschirm. Die Freigaben stammen aus derselben Datenbasis wie der Shop, ein zweiter gepflegter Bestand daneben existiert nicht.

Warenwirtschaft und Onlineshop

Bestände, Preise und Bestellungen laufen über einen gemeinsamen Artikelstamm. Der Innendienst sieht denselben Stand wie der Kunde im Shop, inklusive der Fahrzeugzuordnung. Die telefonische Auskunft ist damit dieselbe Auskunft, die der Konfigurator gibt.

Aus einer wiederkehrenden Pflegeaufgabe ist damit ein Kontrollvorgang geworden. Wer den Lauf startet, arbeitet anschließend die Fälle ab, die die Regeln nicht auflösen konnten, und weiß, dass alles Übrige übernommen wurde. Die Aussage, ob ein Rad an ein Fahrzeug darf, ist auf den Gutachtenstand zurückführbar, aus dem sie stammt.

Die Grenze der Pipeline liegt bei der Quelle. Wo ein Hersteller seine Gutachten nur als PDF oder auf Papier herausgibt, hilft kein Import, und diese Artikel bleiben Handarbeit. Uneindeutige Fahrzeugschlüssel lassen sich ebenfalls nicht automatisch auflösen. Solche Fälle stehen in der Klärliste, bevor der Artikel im Shop erscheint.

Das Muster ist an keine Felge gebunden. Es passt dort, wo ein Produkt erst in Verbindung mit fremden Freigabedaten verkäuflich ist und diese Daten regelmäßig als Datei ins Haus kommen.

• Handel mit Fahrzeug- und Ersatzteilen, bei denen die Kompatibilität zum Fahrzeug über den Kauf entscheidet
• Hersteller und Distributoren, die Katalog- oder Zulassungsdaten von Lieferanten übernehmen und daraus einen eigenen Shop speisen
• Technische Bauteile mit Prüf- oder Zulassungsdokumenten, deren Auflagen im Bestellprozess auftauchen müssen
• Sortimente, bei denen dieselbe Information heute zweimal gepflegt wird, im Warenwirtschaftssystem und im Shop

Ebenso deutlich ist, wo sich der Aufwand nicht trägt. Bei einem überschaubaren Sortiment ohne Regelwerk ist eine gepflegte Tabelle die ehrlichere Antwort. Und wer 3D erwartet, sollte einkalkulieren, dass jedes Modell produziert werden muss. Diese Modellierung fällt pro Artikel an und gehört als eigener Posten in die Planung, unabhängig von der Software.

Ein Punkt betrifft die Reihenfolge. Der Konfigurator ist der sichtbare Teil und trotzdem der zweite Schritt. Solange Produkt und Zulassung nicht sauber aus einer Quelle zusammenkommen, zeigt eine 3D-Ansicht die Fehler nur größer an.

Brauchen wir wirklich eine 3D-Darstellung?

Sie trägt, wenn die Optik am Fahrzeug die Kaufentscheidung bestimmt. Liegt das Problem bei der Frage nach der Eignung, löst die Datenpipeline mit einer Fahrzeugauswahl den größeren Teil davon, und die 3D-Ansicht kann später dazukommen.

Was passiert, wenn ein Hersteller sein Datenformat ändert?

Jede Quelle hat ihren eigenen Adapter. Eine Formatänderung betrifft diesen einen Adapter, der Rest der Pipeline bleibt unberührt. Der nächste Lauf zeigt außerdem eine auffällige Menge abgewiesener Datensätze, wodurch die Änderung auffällt, bevor sie in den Shop durchschlägt.

Können wir mit dem Shop anfangen und den Konfigurator später ergänzen?

Ja, und in dieser Reihenfolge ist es meist sinnvoll. Der Datenteil ist die Voraussetzung für beides. Ein Konfigurator, der auf einem geprüften Freigabebestand aufsetzt, ist ein überschaubarer Aufbau darauf.

Wer pflegt die Daten nach dem Go-live?

Läufe und Klärliste sind für die Bedienung durch Ihre Leute gebaut, dafür ist die Oberfläche da. Für Formatänderungen an den Quellen und für Erweiterungen bleibt bei uns ein benannter Ansprechpartner zuständig.

• Produktkonfigurator
• Schnittstellen und Datenpipelines
• Weitere Projekte