Möbel-Visualisierung im Großmaßstab: Die Datenarchitektur, die den Unterschied macht

Ein klarer Geschäftsfall

Möbel gehören zu den wenigen Produktkategorien, in denen Kunden regelmäßig vierstellige Beträge ausgeben – und das für etwas, das sie vorher nie in ihrem eigenen Zuhause gesehen haben. Rund zwei Drittel der Kaufinteressierten geben an, dass sie sich das Möbelstück in ihren eigenen vier Wänden nicht ausreichend vorstellen können. Dieses Vorstellungsproblem schlägt sich unmittelbar in Zahlen nieder: hohe Retourenquoten, verhaltene Konversionsraten und ein struktureller Vorteil für den stationären Handel, den der Online-Kanal trotz jahrelanger Investitionen nicht vollständig ausgleichen konnte.

Interaktive Visualisierungslösungen verschieben diese Gleichung – und zumindest die verfügbaren Zahlen sprechen eine klare Sprache. Händler, die 3D-Konfiguratoren und AR-Tools einsetzen, erzielen bei rund 40 % mehr Besuchern einen Abschluss und verzeichnen Retourenquoten, die um bis zu 80 % sinken. Aus dem laufenden Betrieb liegen belastbare Zahlen vor: Ein großer europäischer Möbelhändler verzeichnete bei Kunden, die seinen 3D-Konfigurator nutzten, 112 % mehr Konversionen, 106 % mehr Umsatz pro Besuch und einen 22-fachen Return on Investment.

Und dennoch: 2024 boten weniger als 8 % der Möbel-Websites einen 3D-Produktkonfigurator an. Zwischen belegtem Potenzial und tatsächlicher Umsetzung klafft noch immer eine große Lücke. Der Grund liegt fast nie in der Frontend-Technologie.

Was unterhalb der Oberfläche liegt

Ein 3D-Konfigurator ist die sichtbare Spitze eines sehr viel größeren Eisbergs. Was Kunden erleben – ein Sofa in ihrem gewählten Bezugsstoff, das sie in Echtzeit drehen und per AR in ihrem Wohnzimmer platzieren können – setzt eine Systemarchitektur voraus, die in den meisten Projekten erheblich unterschätzt wird.

Diese Architektur gliedert sich in drei Schichten, und jede hält ihre eigenen Fallstricke bereit:

1. Lieferantendaten-Integration und Normalisierung – Produktkatalogdaten von hunderten Lieferanten – heterogen, oft schlecht dokumentiert – in ein einheitliches, maschinenlesbares Produktmodell überführen
2. Konfigurationsregelwerk – die Kodierung der physischen und kaufmännischen Logik, welche Kombinationen gültig, verfügbar und korrekt bepreist sind
3. 3D-Asset-Pipeline – Produktion und Verwaltung von Assets, die nicht nur fotorealistisch sind, sondern sich nahtlos in Rendering-, Echtzeit- und AR-Kontexte einfügen

Viele Visualisierungsprojekte stecken das meiste Budget in die dritte Schicht – das sichtbare Ergebnis – und behandeln die ersten beiden als gelöste Probleme. Tatsächlich sind beide ungelöst – und genau dort beginnen die meisten Projekte zu stocken.

Allein die Lieferantenlandschaft stellt für einen großen Möbelhändler eine erhebliche datentechnische Herausforderung dar. Katalog-Feeds kommen in Dutzenden von Formaten an: Excel-Tabellen, proprietäre XML-Schemata, PDFs, ERP-Exporte, gelegentlich handgepflegte CSV-Dateien. Die Benennung von Attributen ist inkonsistent – was ein Lieferant „Bezugsstoff” nennt, heißt beim nächsten „fabric code” und beim übernächsten ist es eine numerische Material-ID ohne Beschreibung. Maßangaben erscheinen in verschiedenen Einheiten, mit unterschiedlicher Präzision und nach unterschiedlichen Konventionen. Farb- und Oberflächenbeschreibungen, die identisch klingen, können sich auf physisch unterschiedliche Materialien beziehen.

Das ist kein einmaliges Datenqualitätsproblem. Lieferantenkataloge ändern sich mit jeder Saison: Neue Produkte kommen hinzu, Konfigurationen entfallen, Materialien werden umbenannt oder eingestellt. Eine Visualisierungsplattform, die diese Änderungen nicht zuverlässig einlesen und weiterpropagieren kann, läuft zunehmend auseinander mit dem tatsächlich lieferbaren Sortiment.

Schicht 1 – Lieferantendaten-Integration und Normalisierung

Am Anfang jeder ernsthaften Visualisierungsplattform steht ein kanonisches Produktdatenmodell: ein intern klar definiertes Schema, auf das alle Lieferantendaten abgebildet werden – egal in welchem Format sie ankommen. Auf diesem Fundament basieren alle nachgelagerten Funktionen: Produkte suchen und filtern, konfigurieren, visualisieren und Preise berechnen.

Dieses Modell aufzubauen und aktuell zu halten ist keine einmalige Integrationsaufgabe, sondern kontinuierliche Ingenieursarbeit. Die zentralen Entwurfsentscheidungen haben langfristige Konsequenzen:

Schemata-Design. Das kanonische Modell muss ausdrucksstark genug sein, um den vollständigen Konfigurationsraum jedes Produkts abzubilden – einschließlich Produkte, die noch nicht existieren. Möbel haben besonders komplexe Attributgraphen: Ein modulares Sofasystem kann Dutzende Grundmodule haben, jedes kompatibel mit einer Teilmenge von Armlehnenvarianten, Rückenoptionen, Fußausführungen und Stoffkollektionen, wobei Verfügbarkeitsbeschränkungen je nach Markt variieren. Ein flaches Attributschema wird dem nicht gerecht. Ein hierarchisches oder graphbasiertes Modell, von vornherein auf Erweiterbarkeit ausgelegt, ist der richtige Ansatz.

Automatisierte Normalisierung. Bei hunderten von Lieferanten-Feeds in heterogenen Formaten ist manuelles Zuordnen langfristig keine tragfähige Strategie. Moderne Pipelines transformieren Lieferantendaten regelbasiert, extrahieren per ML Attribute aus unstrukturierten Quellen und leiten unsichere Zuordnungen zur menschlichen Prüfung weiter. KI-gestützte Werkzeuge haben dabei aufgeholt – Sprachmodelle extrahieren mittlerweile strukturierte Attribute direkt aus Lieferanten-PDFs und Produktbeschreibungen, wenngleich die Validierungsschicht dadurch nicht überflüssig wird. Ohne eine belastbare Validierungsschicht, die Fehler erkennt und markiert, bevor sie in Produktion gelangen, nützt die beste Normalisierung wenig.

Änderungsmanagement. Lieferantendaten ändern sich kontinuierlich. Eine gut konzipierte Verarbeitungspipeline behandelt jeden Lieferantenfeed als versionierten Datenstrom, verfolgt Änderungen auf Attributebene und leitet wesentliche Änderungen – eine neue Stoffkollektion, eine eingestellte Konfiguration, eine Preisanpassung – durch geeignete Prüf- und Freigabeprozesse. Ohne das wächst die Lücke zwischen dem, was der Konfigurator zeigt, und dem, was tatsächlich geliefert werden kann, unbemerkt.

Der Zusammenhang mit dem Digital Product Passport. Ab 2027 greift der EU Digital Product Passport für Möbel – Pflicht im Rahmen der ersten Umsetzungswelle der Ökodesign-Verordnung. Der DPP verlangt strukturierte, maschinenlesbare Produktdaten zu Materialien, Reparierbarkeit und Recyclingfähigkeit. Wer das kanonische Produktdatenmodell jetzt sauber aufbaut – mit strukturierten Attributen, nachverfolgbarer Herkunft und lieferantenbezogenen Materialdaten –, hat die wesentliche technische Vorarbeit für die DPP-Pflicht damit bereits erledigt. Wer Produktdaten hingegen als reine Visualisierungsvoraussetzung betrachtet, steht später vor einem zweiten, kostspieligen Daten-Engineering-Projekt unter Zeitdruck.

Schicht 2 – Das Konfigurationsregelwerk

Sobald ein kanonisches Produktmodell vorliegt, stellt sich die nächste Herausforderung: die Logik zu kodieren, die bestimmt, welche Konfigurationen tatsächlich gültig sind. Genau hier geraten Projektteams ins Stocken, die bis dahin sorgfältig geplant haben.

Das Problem klingt zunächst überschaubar: Für ein Produkt mit N konfigurierbaren Dimensionen und je M möglichen Werten soll definiert werden, welche Kombinationen zulässig sind. In der Praxis ist der kombinatorische Raum groß, die Gültigkeitsregeln zahlreich und unregelmäßig – und sie ändern sich mit dem Sortiment.

Ein typisches Polstermöbel der mittleren Preislage lässt sich konfigurieren nach Modulanzahl und -anordnung, Armlehnenstil, Rückentyp, Sitztiefe, Fußausführung, Stoffkollektion und Stoffqualitätsstufe. Diese Dimensionen stehen untereinander in vielfältigen Abhängigkeiten. Nicht jeder Stoff ist für jede Modulkonfiguration verfügbar. Bestimmte Fußausführungen sind nur mit bestimmten Gestelloptionen kombinierbar. Wendearmlehnen passen nur zu bestimmten Modultypen. Allein für eine einzige Produktfamilie können Zehntausende von Gültigkeitsregeln zusammenkommen.

Für dieses Problem gibt es zwei grundlegende Architekturansätze:

Constraint-basierte Engines modellieren den Konfigurationsraum als Menge von Constraints über Variablen und lösen diese zur Laufzeit – typischerweise mit SAT- oder CSP-Solvern. Dieser Ansatz skaliert gut bei großen Konfigurationsräumen und beantwortet natürlicherweise die Frage „Was ist bei den aktuellen Auswahlen noch möglich?”, die Echtzeit-Konfiguratoren laufend stellen müssen. Er erfordert sorgfältige Modellierung, ist bei Produktfamilien mit vielen Abhängigkeiten zwischen den Dimensionen aber in der Regel die richtige Wahl.

Regeltabellen-Ansätze kodieren die Gültigkeit als explizite Nachschlagetabellen oder Entscheidungsbäume. Sie sind leichter nachvollziehbar und prüfbar, gut geeignet für Produktfamilien mit wenigen und weitgehend unabhängigen Dimensionen. Bei wachsender Zahl dimensionsübergreifender Abhängigkeiten stoßen sie schnell an Grenzen.

Große Händler benötigen in der Praxis meist beides: eine Constraint-Engine für komplexe konfigurierbare Familien, Regeltabellen für einfachere Produkte. Die Integration der Preisberechnung erhöht die Komplexität zusätzlich – nicht alle gültigen Konfigurationen haben denselben Preis, und Preisregeln (Basispreis, Aufpreise für Optionen, Stoffqualitätsstufen, marktspezifische Anpassungen) müssen konsistent neben der Gültigkeitsprüfung ausgewertet werden.

Ein häufig unterschätzter Punkt ist das Pflegewerkzeug für die Regellogik. Die Regeln müssen von Category-Managern und Produktteams gepflegt werden, nicht nur von Entwicklern. Eine Konfigurationsengine ohne brauchbare Pflege- und Testwerkzeuge häuft technische Schulden an, sobald sich das Sortiment weiterentwickelt – Ausnahmen werden als Sonderregeln ergänzt, die Logik wird undurchsichtig, und irgendwann kennt das Modell nur noch der Entwickler, der zuletzt daran gearbeitet hat.

Schicht 3 – Die 3D-Asset-Pipeline

Erst wenn Produktdatenmodell und Konfigurationsregelwerk stehen, kann die Frontend-Technologie auf einem tragfähigen Fundament aufsetzen. Doch auch die Asset-Pipeline selbst birgt Herausforderungen, die regelmäßig unterschätzt werden.

Das zentrale Problem ist Portabilität. Ein fotorealistisches 3D-Modell eines Sofas, das ein CGI-Studio für eine Marketingkampagne erstellt hat, ist typischerweise auf eine bestimmte Kameraperspektive und Lichtumgebung optimiert. Es kann Millionen Polygone enthalten, gebackte Beleuchtung nutzen, die nur aus einer Richtung stimmt – und enthält keinerlei strukturelle Metadaten: welche Flächen konfigurierbar sind, wie Materialien dem kanonischen Modell entsprechen, welche Abmessungen gelten. All das braucht ein Echtzeit-Konfigurator.

Dieses Asset in einem Echtzeit-Kontext wiederzuverwenden ist selten trivial. Mindestens muss die Mesh-Topologie für Echtzeit-Rendering korrigiert werden. Häufiger muss das Asset grundlegend neu modelliert werden: Polygonzahlen um Größenordnungen reduziert, Materialien durch physikalisch basierte Rendering-Materialien ersetzt, die auf beliebige Beleuchtung reagieren, und die strukturelle Zerlegung neu aufgebaut, um konfigurierbare Teile zu unterstützen. Bei einem Katalog mit Tausenden von SKUs ist das kein überschaubares Nachbesserungsprojekt – sondern ein umfangreiches Asset-Produktionsprogramm.

Die praktische Konsequenz: Die Asset-Strategie muss festgelegt werden, bevor Assets erstellt werden – nicht danach. Wesentliche Entscheidungen dabei:

Format und Portabilität. glTF hat sich als De-facto-Standard für Echtzeit-Rendering und Web-Auslieferung durchgesetzt; USD (Universal Scene Description, ursprünglich von Pixar entwickelt) gewinnt für AR und Pipeline-Interoperabilität zunehmend an Bedeutung. Assets, die von Beginn an in diesen Standards erstellt werden, lassen sich in Rendering-Engines, AR-Frameworks und Commerce-Plattformen gleichermaßen einsetzen – ohne Konvertierungsaufwand.

Level-of-Detail-Strategie. Ein Raumplaner, der zwanzig Produkte gleichzeitig darstellt, hat völlig andere Anforderungen an das Polygon-Budget als ein nahsichtiger Produktkonfigurator. Eine ausgereifte Pipeline erzeugt für jedes Asset automatisch mehrere LOD-Varianten und wählt beim Laden je nach Kontext und Geräteleistung die passende aus.

Materialbibliotheken. Stoffkollektionen und Oberflächenoptionen sollten als wiederverwendbare Material-Ressourcen modelliert werden, die mit dem kanonischen Produktmodell verknüpft sind – nicht in einzelne Produkt-Assets eingebettet. Wenn ein Stoff aktualisiert wird oder eine neue Kollektion eines Lieferanten eintrifft, propagiert sich die Änderung auf alle Produkte, die dieses Material referenzieren, statt individuelle Asset-Updates quer durch den Katalog zu erfordern.

Lieferantenseitige Asset-Standards. Der skalierbarste Ansatz ist, früher in der Lieferkette anzusetzen: Lieferanten auf verbindliche Asset-Lieferstandards zu verpflichten, sodass 3D-Inhalte bereits in einer Form ankommen, die nah an der Pipeline-Bereitschaft liegt. Das erfordert Investitionen in die Lieferantenanbindung, rechnet sich aber, sobald die Stückzahlen stimmen. Einige große europäische Möbelhersteller liefern bereits in glTF oder USD; viele liefern noch in proprietären Formaten oder gar nicht.

Drei Schichten, ein System

Diese drei Schichten – Datenintegration, Konfigurationslogik und Asset-Pipeline – sind keine unabhängigen Arbeitsstränge, die sequenziell entworfen und gebaut werden können. Sie teilen Datenmodelle, setzen Annahmen über die Ausgaben der jeweils anderen Schichten voraus – und die Entwurfsentscheidungen in Schicht 1 schränken die Spielräume in den Schichten 2 und 3 unmittelbar ein.

Das kanonische Produktmodell muss nicht nur die Attribute für Suche und Filterung enthalten, sondern den vollständigen Konfigurationsgraphen, den das Regelwerk benötigt, sowie die Asset-Verknüpfungsmetadaten, auf die die Rendering-Pipeline angewiesen ist. Wird das Datenmodell vom Team entworfen, das die Katalogsuche entwickelt, wird es die Anforderungen der Konfigurationsengine, die sechs Monate später entdeckt werden, höchstwahrscheinlich nicht abdecken.

Dieses Koordinationsdefizit ist es, das große Visualisierungsvorhaben zum Stillstand bringt. Die technischen Komponenten mögen jeweils für sich funktionieren – Lieferanten sind angebunden, Regeln sind definiert, Assets sind produziert – doch das Gesamtsystem versagt, weil niemand die Schnittstellen zwischen den Schichten gemeinsam entworfen hat.

Für Händler mit langjährig gewachsenen ERP-Systemen verschärft Legacy-Integration das Problem zusätzlich. Produktstammdaten sind oft über mehrere Systeme verstreut: ERP, ein älteres PIM, eine eigenständige E-Commerce-Plattform, diverse Lieferantenportale – jedes mit eigenem Datenmodell, eigenem Aktualisierungsrhythmus und eigener Zuständigkeit. Eine Visualisierungsplattform auf dieser Fragmentierung aufzubauen, ohne zuvor die Produktdatenarchitektur zu bereinigen, erzeugt ein System, das teuer im Betrieb und anfällig gegenüber Änderungen ist.

itestra arbeitet mit einem der größten deutschen Möbelhändler an genau dieser Aufgabe: Mehr als 15 Ingenieure modernisieren die Kernsysteme, auf denen Produktkatalog, Konfiguration und Commerce-Plattform aufsetzen. Die Arbeit ist bewusst inkrementell angelegt: Datenflüsse werden rationalisiert, kanonische Modelle eingeführt, Punkt-zu-Punkt-Integrationen durch robuste Anbindungen nach API-first-Prinzip ersetzt – mit messbaren Verbesserungen in jeder Phase, statt den gesamten Nutzen auf einen fernen Go-live zu verschieben.

Wo man beginnt

Die häufigste Ursache für gescheiterte Visualisierungsvorhaben: Man begreift sie als Frontend-Initiative, der eine Datenbereinigungsphase vorausgeht. Die Reihenfolge sollte umgekehrt sein: zuerst die Datenarchitektur, dann das Konfigurationsmodell, dann die visuelle Erfahrung auf einem Fundament, das sie tragen kann.

Für die meisten Unternehmen beginnt der richtige Einstieg mit einer strukturierten Bestandsaufnahme des aktuellen Zustands über alle drei Schichten hinweg:

• Produktdatenlandschaft: Wie viele Lieferanten-Feeds sind im Scope? Wie ist der aktuelle Stand des kanonischen Produktmodells? Wo liegen Lücken in Attributvollständigkeit und -konsistenz?
• Konfigurationslogik: Wo lebt die Konfigurationslogik heute – im ERP, in eigenem Anwendungscode, in Tabellen, die Kategorieteams pflegen? Wie vollständig und nachvollziehbar ist sie?
• Asset-Bestand: Welche 3D-Assets existieren heute, in welchen Formaten, und wie groß ist die Lücke zu dem, was ein Echtzeit-Konfigurator benötigen würde?

Eine gezielte Zustandsanalyse über diese drei Dimensionen – erfahrungsgemäß in ein bis zwei Wochen zu leisten – verschafft die nötige Klarheit: für ein realistisches Scope-Bild, für die Identifikation früher Gewinne und für eine Reihenfolge der Arbeit, die schrittweise Nutzen liefert, statt alle Risiken am Ende zu bündeln.

Wer bei der Visualisierung heute den Vorsprung hält, hat nicht zwingend das größte Technologiebudget. Es sind die Unternehmen, die früh erkannt haben, dass das eigentliche Problem die Daten sind – und die in die richtige Architektur investiert haben, bevor das Frontend gebaut wurde. Heute können sie neue Lieferantenprodukte, neue Konfigurationsoptionen und neue Darstellungsformate – AR, Raumplanung, Außenbereichs-Rendering – auf einer Plattform einführen, die genau dafür gebaut ist.

Der DPP-Termin 2027 macht aus der ohnehin sinnvollen Investition in die Datenarchitektur eine mit festem Fälligkeitsdatum. Wer jetzt die richtige Architektur legt, bekommt beides aus einer Hand: eine belastbare Visualisierungsplattform und die Produktdatenbasis, die der DPP ohnehin einfordern wird – ohne ein zweites Daten-Engineering-Projekt unter Zeitdruck.