Welcher Produktkonfigurator passt zu meinen Produkten?

Auch bei logisch ähnlich aufgebauten Produkten lohnt es sich aus vertrieblichen, didaktischen oder auch technischen Gründen über unterschiedliche Herangehensweisen beim Aufbau eines Produktkonfigurators nachzudenken. Je nach benötigter Handhabung, dem Aufbau des Produktes aber auch wegen der vorhandenen Grunddaten zum Produkt empfiehlt sich die Nutzung unterschiedlicher Konfigurationssysteme. Wir möchten in diesem Artikel die verschiedenen Typen von Produktkonfiguratoren näher beschreiben.

Grundsätzlich unterscheiden wir:

Produktfilter
Entscheidungsbaum
Variantenkonfigurator
Variantenkette (Variant Chain Configurator)
Variantenmatrix
Kompatibilitätsfinder

In diesem Beitrag werden wir die Besonderheiten jedes dieser Systeme erklären.

1 Produktfilter: Filter auf Attribute

Hierbei handelt es sich nur um Produktkonfiguration im erweiterten Sinne. Da Produktfilter jedoch in der Praxis häufig im Zusammenhang mit Produktkonfiguration genannt werden, führen wir auch diesen Typ des “Konfigurators” hier auf.

Er funktioniert wie folgt:

Am Produkt gespeicherte indizierte Werte werden gefiltert.
Der Filter schränkt sich dynamisch auf die Werte in der Treffermenge ein (Facettensuche).

Der Produktfilter ist ein auf Massendatenfilterung ausgerichtete Typ der Produktkonfiguration. Ein Benutzer erreicht dabei das optimale Ergebnis durch Setzen von Filtern auf Produkteigenschaften. Diese Form der Produktkonfiguration funktioniert naturgemäß nur für eine begrenzte Zahl von Produktvariationen.

Die Voraussetzung für einen solchen Produktfilter ist zudem ein möglichst standardisierter Datenstamm, das bedeutet: a) eindeutige, saubere Attribute und Werte am Produkt b) zweideutige Attribute oder Werte erfordern die Bereinigungs- oder Mappinginformationen. d) erforderlich ist auch ein sehr schneller Zugriff auf die zu filternden Informationen. Häufig eingesetzt wird dafür die spezielle auf superschnelle Filterergebnisse ausgerichtete Softwarebibliothek “Lucene”. Lucene hat besondere Funktionen zur Indizierung von Objekteigenschaften und für die Suche per Facettenfilterung. Lucene ist u.a. in die Softwarelösungen Elasticsearch und Solr verbaut.

Dieser Typ des Konfigurators ist geeignet für: Webshop-Systeme mit einem Produktstamm, bei dem die Produkte mit standardisierten Eigenschaften aufwarten. Gutes Beispiel Bekleidung. Hier kommt man mit einem kleinen Set von Attributen und darin wiederum wenigen Werten aus, um das passende Produkt zu finden. Beispiel: Typ: T-Shirt, Marke: adidas/nike/noname, Geschlecht: m/w, Größe: S/M/L/XL/XXL, Farbe: Weiß/Schwarz/Rot.

2 Entscheidungsbaum (Decision Tree): Navigieren zur optimalen Konfiguration

Traversieren eines Graphen zum Sammeln von Konfigurationselementen
Nachträgliche Änderung möglich durch das Wechseln der Segmente
Beispiel: https://pim.test.alterra.sepia.de/decision_graph/
Video: https://www.sepia.de/public/videos/wsf-sales-configurator/wsf-sales-configurator.mp4

Der Entscheidungsbaum ist eine sehr flexible Möglichkeit auch komplexere Konfigurationsszenarien abzubilden. Zusammen mit einer Funktion zur Segment-Sammlung (Segment Collection) kann er ein sehr mächtiges Werkzeug zum Realisieren eines Produktkonfigurators sein. Es können beliebig tiefe und beliebig breite Baumstrukturen abgebildet werden.

Über den Graphen können Entscheidungen definiert werden, die aufeinander aufbauen: “…Sie haben Option A gewählt, dazu müssen Sie sich noch für Sub-Option A oder B entscheiden…” u.s.w..

Entscheidungssegmente können jederzeit verlassen werden, indem man an jedem Segment immer auch eine Ausstiegs-Option definiert.

Es können beliebig viele parallel aufgesetzte Entscheidungssegmente nacheinander abgearbeitet werden.

Häufig eingesetzt wird hier die spezielle Softwarebibliothek Alterra:GraphPicker. Diese Bibliothek ermöglicht das Sammeln und Protokollieren von aus einem Entscheidungsbaum gewählten Segmenten.

Die im Rahmen der Konfiguration gesammelten Segmente können nachträglich gelöscht oder geändert werden. Praktischer Anwendungsfall: eine Produktkonfiguration bestehend aus diversen Bauelementen ist abgeschlossen, aber es soll nachträglich ein Bauteil getauscht werden. Dann kann per GraphPicker der Koten angesprungen werden, um den es geht und von dort der Graph neu traversiert werden.

Zusätzlich können per Alterra:GraphPicker auch komplexere logische Abhängigkeiten zwischen Teilgraphen abgebildet werden. Beim Einpflegen des Entscheidungsbaums müssen dann an bestimmten Endknoten Regeln für die Gültigkeit weiterer Teilgraphen hinterlegt werden. Beispiel: Zusatzsoftware => MS-Office => Excel ist nur wählbar, wenn Betriebssystem => Windows oder Mac gewählt und Arbeitsspeicherpaket => 8GB oder 16GB.

So kann man ohne zusätzliche Programmlogik implementieren zu müssen, das bedingte Aktivieren und Deaktivieren von Entscheidungspfaden realisieren.

Fazit: per Decision-Tree kann man also auch sehr komplexe Konfigurationen umsetzen, bei der eine Vielzahl von Komponenten zu einem Produktpaket zusammengeführt werden müssen.

Dieser Typ des Konfigurators ist geeignet für: Wenn es das Ziel ist, den Benutzer durch gezielte Fragestellungen zu seiner Wunschkonfiguration zu führen, ist der Entscheidungsbaum die richtige Wahl. Auch kann man über einen Entscheidungsbaum sehr schön Produkte abbilden, die aus eine großen aber endlichen Zahl von Elementen bestehen. Theoretisch können diese Elemente wiederum per Variantenkonfiguration (siehe unten) optimiert werden. Anwendungsfälle aus dem Maschinenbau wären z.B. eine moderne Drehmaschinen, Fräsmaschinen, CNC-Werkzeugmaschinen, Schleifmaschinen, Sägemaschinen, die aus diversen größtenteils optionalen Elementen bestehen.

3 Variantenkonfigurator

Definition von Klassen, Merkmalen und Werten als Maximalstückliste / Maximal-Attribut-Werteliste
Zuweisen von Klasse zu Variantenmaster
Auswählen einer Initial-Konfiguration
Definition von Abhängigkeiten zwischen Attributen/Werten (Konfigurationsregeln)
Definition von Constraints (übergeordnete Regeln für die Validität der Konfiguration)
Testen von Regeln durch Berechnen möglicher Varianten
Interaktives Auswerten der Regeln während der Benutzereingabe
Erzeugen Angebot basierend auf konfigurierter Variante
Auftragsstückliste (für Beschaffung und Produktion) ergibt sich aus der Konfiguration

Die Produktkonfiguration vom Typ “Variantenkonfiguration” (siehe: Alterra::Variantenkonfiguration) ist der Klassiker unter den Konfigurationsszenarien. Dabei wird ein Masterprodukt definiert, das mit der maximalen Zahl möglicher Merkmale/Werte ausgestattet ist. Welche Merkmale/Werte mit welchen anderen Merkmalen/Werten kombinierbar sind, wird über die ebenfalls am Variantenmaster definierten Konfigurationsregeln festgelegt. Dabei gibt es natürlich u.a. Produkte, die vollständig frei konfigurierbar sind, d.h. alle Merkmale/Werte sind mit allen anderen kombinierbar. Aus der Variantenkonfiguration ergibt sich eine exponentielle Menge möglicher Varianten. Beispiel: 7 Merkmale mit je 5 Werten ergeben 5^7=78.125 Variantenartikel. Mittels Variantenkonfiguration lässt sich also eine potenziell gigantische Anzahl von Produkten einfach handhaben, ohne dass dafür extra ein Produktdatensatz pro Artikel geführt werden müsste.

Wegen der hohen Flexibilität und der verhältnismäßig geringen Datenmenge hat ein Variantenkonfigurator Vorteile in mehreren Bereichen:

Vertrieb: der Kunde kann mit geringem Zeitaufwand genau zu der von ihm benötigten Konfiguration hingeleitet werden.
Marketing: der Pflegeaufwand für Produktdaten wird erheblich reduziert. Es können zudem per 3D-Rendering automatisch Produktbilder ausgegeben werden.
Produktion: die Variantenkonfiguration kann Stücklisten für die Produktion und ausgeben. Im Optimalfall wird aus dem Konfigurator direkt ein vollständiger Produktionsauftrag generiert.
Einkauf und Logistik: die in der Produktion und der Auftragsverarbeitung benötigten Teile können über den Konfigurationsprozess ermittelt und in andere Systeme eingespeist werden.

Fazit: Diese Vorteile gelten unisono oder zum Teil natürlich auch für die anderen Arten der Produktkonfiguration. In der Gesamtschau kann man davon ausgehen, dass ein intelligent aufgesetztes Variantenkonfigurator-Projekt diverse Synergieeffekte bis hin zur durchgängigen Lieferkette rund um ein Unternehmen haben kann. Die “digitale Fabrik” bzw. das digitale Unternehmen muss damit also keine Utopie bleiben.

Dieser Typ des Konfigurators ist geeignet für: Variantenkonfiguration ist höchstwahrscheinlich die am häufigsten vorkommende Form der Produktkonfiguration. Sie ist geeignet für: Produkte, die eine endliche Menge von Attribut/Value Paaren haben. Durch die Verkettung von Variantenkonfigurationen (siehe unten) ist sogar eine nahezu beliebige Produktkomplexität abbildbar.

4 Varianten-Kette (Variant Chain Configurator): Variantenkonfigurator mit Verkettung kompatibler Varianten

einrichten vieler Variantenmaster (siehe Variantenkonfiguration)
superkomplexe Konfigurationen möglich
basiert auf Bauteilen, die selbst auch Variantenmaster sein können
Bauteil wird variantenkonfiguriert und währenddessen geprüft, ob es passende andere Variantenmaster dazu gibt
Verkettung von Bauteilen prinzipiell endlos fortsetzbar
konfigurieren einer Variante, finden passender Teil- bzw. komplett konfigurierter Varianten

Diese Softwarekomponente standardisiert erstmals bis dato nur per Individualprogrammierung lösbare Konfigurationsaufgaben. Bisher in der Praxis genutzt wurden Variantenkonfiguratoren, die auf einer Maximalstückiste basieren und die Konfiguration als Zerlegungsproblem nach dem Top-Down-Ansatz auffassen.

Der “Variant Chain Configurator” funktioniert so, dass einzelne Bauteile eines Gesamtsystems definiert werden. Diese Bauteile bestehen jeweils aus einer Maximalstückliste und wählbaren Attributen. Das Gesamtsystem entsteht dabei aus Einzelkomponenten, die nacheinander zusammengefügt werden. Jede Einzelkomponente kann per Variantenkonfiguration konfiguriert werden. Am Ende einer jeden Komponentenauswahl (oder auch währenddessen) prüft das System, ob theoretisch passende weitere Komponenten an das Elemente “angedockt” werden können. Wenn ja, wird die Komponente mit den für das Andocken relevanten gesetzten Optionen aufgerufen und kann dann weiter “variantenkonfiguriert” werden. Ist auch dies erledigt, geht es in gleicher Weise weiter bis keine passenden Elemente verfügbar sind oder eine Regel greift, die das Gesamtsystem als finalisiert erkennt (Constraint).

Dieser Typ des Konfigurators ist geeignet für: Überall wo variantenkonfigurierte Elemente zusammen ein Produkt ergeben, kann die Variant Chain Configuration eingesetzt werden. Beispielsweise, wenn ein Arbeitsplatz bestehend aus einem variablen Tisch (Holzart, Tiefe, Breite, höhenverstellbar: ja/nein) und einem Stuhl (Rollen: ja/nein, Rollen: Teppich/Parkett, Stofffarbe, Armlehnen: ja/nein) auskonfiguriert werden soll.

5 Variantenmatrix

Erzeugen einer Variantenmatrix durch das Ausmultiplizieren der möglichen Artikel über Attribute und Werte unter Berücksichtigung von Regeln (Constraints)
Filtern der möglichen Varianten auf Basis der Werte aus der Matrix in Echtzeit
Look and Feel wie beim Variantenkonfigurator (siehe oben)
Beispiel: https://www.team7-home.com/de/de/schlafen/betten/light-bett/#config_anchor

Eine Variantenmatrix ist eine Artikeltabelle, die durch das regelbasierte Ausmultiplizieren von Attributen und Werten aus einem Variantenkonfigurator erzeugt wird. Konfiguratoren wie z.B. Alterra:Variantmatrix können diese Tabellen nutzen, um daraus einen Echtzeitkonfigurator zu realisieren. Die besondere Herausforderung dabei ist es, extrem große Datenmengen sehr schnell filtern zu können. Bei einem Tisch des Herstellers TEAM7 kann eine Variantenmatrix für ein Bett mit 5-8 Merkmalen mit je 7 bis 10 Ausprägungen eine Menge von 8^6 = 262.144 Artikeln bedeuten. Hier ist ein sehr effizienter Umgang mit diesen relativ großen Datenmengen gefragt, damit der Benutzer schnell Ergebnisse sieht und so ein angenehmes Konfigurationserlebnis genießen kann.

Nachteile: Variantenmatrizen eignen sich nur für Produkte, bei denen die Anzahl der möglichen Varianten begrenzt ist. Zwar kann mit Spezialtools wie der Alterra:VariantMatrix Matrizen von mehreren Mio. Varianten ansteuern und Ergebnisse in akzeptabler Zeit liefern, ab einer gewissen Produktkomplexität steigt die Anzahl der Varianten jedoch so rapide an, dass eine Variantenmatrix hier keinen Sinn mehr ergibt. Beispiel: 15 Attribute mit je 8 Eigenschaften = 8^15 also 35 Billionen Varianten in einer Matrix. Diese Datenmenge ist mit vertretbarem Aufwand nicht mehr einfach zu handhaben.

Vorteile: Einige Unternehmen haben sei es für Ihre Produktion, sei es für den Vertrieb legacy ERP-Systeme im Einsatz, die bereits mit einem Variantenkonfigurator arbeiten. Wenn es dann aus technischen, organisatorischen oder monetären Gründen nicht möglich ist, diesen Konfigurator ins Internet zu bringen, dann kann man auf die Lösung verfallen, dass man über den Konfigurator die möglichen Verkaufsprodukte generiert und daraus die Variantenmatrix für einen externen (Internet) Konfigurator bildet. Solange die Datenmenge dabei überschaubar bleibt, ist der Weg eine absolut gangbare Option für viele IT-Entscheider, zumal die generierten Daten dann an allen Stellen im Unternehmen garantiert Deckungsgleich sind. Zudem muss man dann nicht mehrfach Konfigurations- und Preislogik parallel vorhalten.

Dieser Typ des Konfigurators ist geeignet für: In Fällen, in denen Unternehmen das Regelwerk in zentralen Systemen abgebildet haben, die aber keine ausreichenden Services bereitstellen, um diese direkt für eCommerce nutzen zu können, sei es aus software-architektonischen Gründen, aus Performanz-Gründen oder, weil eine direkte Verbindung zu diesen Systemen aus Sicherheitsgründen unerwünscht ist. Hier können dann Produktlisten aus dem System extrahiert werden, die der Konfigurator dann nutzt.

6 Kompatiblitätsfinder - Kompatibilitätsmanagement

Finden kompatibler Produkte oder Bauteile per Regelwerk
Passende weitere Produkte zu einem gewählten Produkt finden.
Auswerten der Regeln an einer Produktklasse und finden passender Objekte
Daten: Definition von Abhängigkeiten zwischen Produktklassen.

Beispiele:

Compatibility Rule Editor: Definition von Abhängigkeiten zwischen Produktklassen

Was auch geht: Definition von Abhängigkeiten von Eigenschaften und Werten über den kompletten Produktstamm. In diesem Fall werden statt der Attribute der Produktklassen die Attribute und Werte direkt ohne Bezug auf eine Produktklasse verwendet - Beispiel: Blau passt zu Rot und Weiß aber nicht zu Grün.

Kompatiblitätmanagement (siehe: Alterra::Compatiblity-Management) eignet sich zum Auffinden kompatibler Produkte, wo anhand von Eigenschaften Regeln definiert werden können, die das Auffinden passender Teile ermöglichen. Dabei kann man an mehreren Stellen ansetzen, um die Regeln zu definieren. Entweder man erstellt Regeln die für einen kompletten Produktstamm gelten. Hier bietet man dann per Compatibility-Rule-Editor alle verwendeten Eigenschaft/Wertepaare des Produktpools zur Regeldefinition an. Beispiel: Kompatibel sind alle Produkte, die die Eigenschaft Innendurchmesser mit Wert 10mm haben mit allen anderen Produkten, die die Eigenschaft Außendurchmesser mit Wert 9.9 mm haben. Der Kompatibilitäts-Finder muss dann über den gesamten Produktstamm gehen, um mögliche Objektpaare zu finden. Etwas weniger rechenintensiv bei der Suche ist es, die Anzahl der in Frage kommenden Objekte direkt per Klassen-Auswahl zu begrenzen. Man wählt also bei der Definition der Kompatibilitätsregel für beide Seiten des Vergleichs zuerst einmal eine Produktklasse aus und danach dann die Eigenschaften und Werte dieser Klasse. Beim Ermitteln der Ergebnismenge kann dann die Menge der zu durchsuchenden Elemente auf die gesetzten Klassen begrenzt werden.

Optimierung bei Regeln für den gesamten Produktpool: wenn man nicht Produktklassen zum Einschränken der Datenmenge nimmt, so kann man per Alterra::Compatiblity-Management auch Prioritäten für Regeln definieren. Also beispielsweise den Datenstamm nur auf alle Produkte mit Durchmesser > 8mm und < 11 mm reduzieren, um danach dann die Regel "kompatibel sind alle Produkte, die die Eigenschaft Innendurchmesser mit Wert 10mm haben mit allen anderen Produkten, die die Eigenschaft Außendurchmesser mit Wert 9.9 mm haben, anzuwenden. Dies führt dann natürlich zu erheblich schnelleren Suchergebnissen.

Dieser Typ des Konfigurators ist geeignet für: In der Praxis findet sich diese Art von Konfiguratoren zum Beispiel im Bereich Sanitärinstallation bzw. für die Konfiguration von Warm- und Kaltwasserkreisläufen. Gut geeignet ist ein solches System überall, wo eine unübersichtliche Zahl von Normteilen miteinander verbaut werden kann, so zum Beispiel auch im Bereich Fahrradteile.

Preiskalkulation über ein separates Regelwerk

Die hier aufgeführten Konfiguratoren können relativ einfach auch zur Preiskalkulation verwendet werden, ohne dass eine komplexe Preisbildungsfunktion implementiert werden müsste. Der Variantenkonfigurator kann beispielsweise seine Preise aus den gewählten Produkteigenschaften beziehen, und der Produktpreis wird dann über einfaches Summieren gebildet. Jedoch gibt es für die Preisfindung im Wirtschaftsalltag meist noch weitere davon unabhängige Faktoren, über die die Preisfindung stattfindet. So kann beispielsweise ein übergreifender Aufpreis erhoben werden, wenn besonders viele Konfigurationsoptionen im Vergleich zum angebotenen Standard verändert werden. Oder umgekehrt wird ein Rabatt gewährt, wenn man möglichst nah am Standart-Angebot bleibt. Dazu kommen noch zeitliche, regionale oder von der Kundengruppe abhängige Faktoren. Um eine solche differenzierte Preiskalkulation in Kombination mit der Produktkonfiguration umsetzen zu können, sollte ein Konfigurator über ein Preisfindungsmodul verfügen, dass diese zusätzlichen nicht produktionsabhängigen Faktoren pflegbar und nutzbar macht. Konfigurationssoftware wie Alterra::CPQ bringt dafür ein spezielle Preisfindungsmodul mit, das logisch oberhalb des eigentlichen Produktkonfigurators arbeitet. Die Preisfindung operiert also als Funktion, die Teile der Konfiguration oder auch die komplette Konfiguration wie auch externe Variablen als Argumente aufnimmt.

Ein PIM-System für die solide Stammdatenbasis

Bei allen Unterschieden in Darstellung und Funktion gibt es doch eine Gemeinsamkeit, die alle Konfigurations-Typen teilen: ohne eine sehr akkurate Produktdatenbasis kann keines der Systeme vernünftige Ergebnisse liefern. Daher empfiehlt es sich in den meisten Fällen neben dem ERP-System eine spezielles auf Produktkonfiguration ausgerichtetes PIM-System (siehe: Alterra:PIM) einzusetzen. Hier können dann Konfigurator spezifische Informationen effizient eingepflegt werden. Bei der Integration eines Konfigurators sollten Sie nie den Fokus auf den PIM-Datenstamm verlieren und nach Möglichkeit im Projektteam Spezialisten mit Expertise in PIM und Produktkonfiguration einsetzen.

Fazit und Ausblick

Je nach eingesetzter Konfigurationsmethode ergibt sich meist auch eine unterschiedliche Datenmodellierung und Datenhaltung der Grunddaten des Konfigurators. Darauf ist also bei der Einführung eines Konfigurators besonderes Augenmerk zu legen. Je nach dem ob ich einen einfachen Produktfilter benötige oder eine komplexe Variant-Chain konfigurieren möchte, muss mich meine Daten unterschiedlich pflegen - und später dann natürlich auch unterschiedlich viel Aufwand in die Definition von Konfigurationsregeln stecken. Beim einfachen Produktfilter, ist der Aufwand eher bei der Produktpflege der Einzelartikel zu sehen, bei den meisten anderen Konfigurationstypen ist der Hauptaufwand ein optimales Regelwerk zur Auflösung der Konfiguration zu erstellen.

Weiter zu Alterra::Variantenkonfiguration