Herausforderung Produkt Konfigurator (Teil 2): Architektur eines Konfigurators

auto_blueprint_blogNachdem im ersten Teil der Beitragsserie “Herausforderungen Produktkonfiguratoren” die Anforderungsanalyse als Herausforderung bei Fahrzeugkonfiguratoren beschrieben hat, soll in diesem Beitrag die Softwarearchitektur bzw. die einzelnen Module eines Konfigurators näher betrachtet werden. Dabei spielt vor allem die Geschäftslogik des Konfigurators eine zentrale Rolle.

Die nachfolgende Trennung der Konfigurator Module deckt sich mit der klassischen Trennung von Anzeigeebene, Geschäftslogikebene und Persistenz (3-Schichten-Architektur). Unsere Projekterfahrung hat gezeigt, dass dieser Ebenenschnitt auch für Konfigurator-Komponenten sehr gut geeignet ist.

Frontend (Anzeigeebene) beim Konfigurator

Die Interaktion mit dem Kunden findet bei einem Konfigurator über das Frontend statt. Die größte Herausforderung hierbei ist, die Inhalte für die unterschiedlichsten Frontends plattformgerecht anzuzeigen. Je nach eingesetztem Frontend muss hierbei unter anderem die Größe des Bildschirms, die unterstützten Webtechnologien (kein Flash, kein JavaScript), die Leistungsfähigkeit der Hardware oder das zugrundeliegende Betriebssystem berücksichtigt werden.

Geschäftslogik und Daten (Persistenzebene)
Für den Konfigurator sind verschiedene Datenquellen relevant, die an den Konfigurator angebunden werden müssen.

Produktdaten:

Bei den Produktdaten handelt es sich beispielsweise um technische Daten, Stücklisten oder Marketing Beschreibungen. Die klassischen Produktdaten werden für den Konfigurationsprozess zusätzlich um Mediainformationen wie Bilder, Videos etc. angereichert.

Gerade 360°-Grad Drehungen bzw. 3D-Modelldarstellungen, Tag/Nacht Animationen oder freie Zoommöglichkeiten stellen hierbei hohe Anforderungen an die zugrunde liegende Hardware. Zudem ergeben sich unterschiedliche Anforderungen bezüglich der Dateiformate und Bilder in verschiedenen Größen und Darstellungsformen, was zu einer großen Anzahl an bereitzustellendem Datenvolumen führt.

Durch dieses große Datenvolumen wird auch der Standort des Servers wichtig um unnötige, Netzwerk basierte, Wartezeiten zu vermeiden welche durch einzelne Knotenpunkte erzeugt werden können. Dies kann dazu führen, dass die Server global verteilt werden müssen, um die Anforderungen bezüglich Performance und Ansprechzeit erfüllen zu können. Zu den Produktdaten zählen auch die Regeln und Limitierungen. Sie liefern die Basis für die spätere Baubarkeitsprüfung der Konfiguration. Über die Regeln werden zwingende Kombinationen oder Exklusionen festgelegt, welche automatisch im Konfigurationsprozess herangezogen werden, wenn eine gewisse Bedingung erfüllt wird.

So könnte beispielsweise das Auswählen des Hauptprozessors automatisch dazu führen, dass ein bestimmter (passender) Prozessorkühler selektiert wird, da dieser zwingend benötigt wird. Weitere Beispiele wären, ob der Standardlack als blau definiert wird oder ein Sportpaket nicht in Kombination mit der Luxuslinie verbaut werden darf.

Bildquelle Markus Beller
Bildquelle Markus Beller

 

Preisdaten:

Für den Konfigurator müssen alle Preise zur Verfügung stehen, die im Konfigurationsprozess benötigt werden, d. h. alle Fahrzeug- und Ausstattungspreise müssen vorliegen, falls diese im Konfigurator angezeigt werden sollen. Dies können auch Paketpreise, Kombinationspreise oder Rabattsätze sein.

Benutzerdaten und Accounts:

Um eine Speicherung einer Konfiguration für einen Benutzer zu ermöglichen, ist ein User Management System notwendig. Durch die Authentifizierung eines Benutzers können Konfigurationen benutzerspezifisch gespeichert, Empfehlungen über soziale Netzwerke verschickt, aber auch Kundendaten wie Adresse oder vorliegende Zahlungsdaten hinterlegt werden. Unsere Erfahrung hat gezeigt, dass hier zwingend geprüft werden sollte, ob im Unternehmen an anderer Stelle ein solches System bereits existiert, auf welches zurückgegriffen werden kann.

Konfigurator Backend (Geschäftsebene)

 

Der Konfigurationsmanager stellt das Herzstück des Konfigurators dar. Hier werden die Konfigurationsvorgänge bearbeitet und die einzelnen Teilkomponenten/Module (z. B. in Form von Business Services) gesteuert und koordiniert. Er stellt zudem die Schnittstelle zwischen Frontend und Persistenzebene dar.

Die einzelnen Komponenten des Konfigurationsmanagers werden nachfolgend detaillierter beschrieben. Die Baubarkeitsprüfung / Komponentenvalidierung muss gewährleisten, dass eine Konfiguration in der vorliegenden Form „baubar“ ist und keine Produktkonfigurationen erzeugt werden können, die nicht produzierbar sind. Die große Herausforderung ist, dem Kunden die teils komplexen Produktregeln mit den Folgen und Wirkungen verständlich im Konfigurationsprozess darzustellen. Das kann über unterschiedliche Strategien erreicht werden:

  • Soll der Kunde aus allen Möglichkeiten eine Lösungsoption auswählen?
  • Soll die Änderung automatisch im Hintergrund passieren?
  • Oder soll dem Kunden eine Lösung präsentiert werden, die er noch aktiv auswählen muss?

 
 
Media Exporte

Sobald der Kunde den Konfigurationsvorgang abgeschlossen hat, soll er die Möglichkeit haben, sich das Ergebnis zusammengefasst anzeigen zu lassen. Dazu kann er sich zumeist die Konfiguration mit weiterführenden Informationen (z. B. technische Daten) ausdrucken, als PDF ausgeben lassen oder weiterführende Informationen zu seiner Konfiguration (z. B. Produktkatalog) herunterladen.

Speicherung der Konfiguratoren

Nachdem der Kunde sein Wunschprodukt konfiguriert hat, muss ihm die Möglichkeit gegeben werden diese zu speichern, um sie zu einem späteren Zeitpunkt wieder aufzurufen und weiterbearbeiten zu können. Hier handelt es sich um einen zentralen Bestandteil des Konfigurators. Unsere Erfahrung hat gezeigt, dass die Datenhaltung für gespeicherte Konfigurationen im Konfigurator selbst und nicht in ausgelagerten Systemen stattfinden sollte.

Recommandation Module / Sales Support

Über gezielte Fragen und Auswahlmöglichkeiten werden dem Kunden die für ihn am besten passenden Produkte empfohlen, die er in der späteren Konfiguration weiter individualisieren kann. Gerade bei beratungsintensiven Diensten stellt das einen großen Mehrwert dar, der den späteren Kauf sowohl für den Kunden als auch für den Anbieter erleichtert.

So können beispielsweise bei Lebensmittel-Konfiguratoren über die gezielte Abfrage von Allergenen verhindert werden, dass ein für den Kunden gefährliches Produkt zur Konfiguration präsentiert wird. Anhand verschiedener Faktoren ist es möglich die zur Verfügung stehenden Varianten zielgruppengerecht bereits vor der Konfiguration durch einen Selektor zu filtern. Innerhalb des Konfigurationsprozesses selbst können Cross- und Up-Selling-Potentiale genutzt werden. So kann beispielsweise dem Kunden zu seinem Elektrofahrzeug

  • zusätzlich die passende Ladestation angeboten werden (Cross-Selling)
  • oder das Paket aus Ladestation plus Photovoltaikzellen plus Carport angeboten werden, wenn dieses nur unwesentlich teurer ist (Up-Selling).

 
Zudem stellt der Konfigurator einen einfachen Weg dar, eine direkte Echtzeit-Verbindung beispielsweise per Chat oder Telefon zwischen Service/Vertrieb und potentiellem Kunden, dem Konfigurator- Nutzer, aufzubauen. Hier ist es von Vorteil, wenn die Berater die gleiche Konfiguration vor Augen haben wie der Kunde, und ihn so durch den Konfigurationsprozess leiten können. Das wird ebenfalls durch die Trennung von Backend, Frontend und Speichermöglichkeit der Konfiguration ermöglicht..

Zusatzmodule für spezielle Berechnungen

Je nach konfiguriertem Produkt ist es nötig, komplexe Berechnungen durchzuführen, die von der einzelnen Konfiguration abhängig sind und aufgrund der Permutationsmenge/Kombinationsmöglichkeiten nicht vorab berechnet werden können. Bei Fahrzeug-Konfiguratoren ist dies zum Beispiel das Effizienz Label.

Quelle: http://www.pkw-label.de/pkw-label-erstellen.html
Quelle: http://www.pkw-label.de/pkw-label-erstellen.html

Welche Effizienzklasse ein Fahrzeug hat, ist abhängig von CO2-Ausstoß und Gewicht. Anhand der vom Gesetzgeber definierten Formel wird ein vom Fahrzeuggewicht abhängiger Referenzwert für den CO2-Ausstoß berechnet. Verändert sich beispielsweise die Felgengröße, kann sich das Gewicht ändern; falls das Automatikgetriebe ausgewählt wird, verändert sich Verbrauch und CO2-Ausstoß. Zudem muss auch die Kombination der Felge und des Automatikgetriebes berücksichtigt werden.

  • All dies kann eine Änderung der Effizienzklasse zur Folge haben.

Im Worst Case (aus Berechnungssicht) muss nicht nur die Effizienzklasse neu berechnet werden, welche beispielsweise durch einen Bonus für ein besonders sparsames Fahrzeug vergeben wurde, sondern auch die Preise, falls CO2-abhängige Steuern anfallen. Das kann durch das Preisberechnungsmodul abgedeckt werden, über das während des Konfigurationsvorgangs der aktuelle Preis angezeigt wird.

Bei der Preisberechnung müssen neben den produktabhängigen Konfigurationsparametern zusätzlich Marktspezifika und geltende Gesetze berücksichtigt werden. Das kann bei der Berücksichtigung von Preisnachlässen für Kundengruppen (z.B. Großfamilien oder Staatsangestellte) oder Unterschieden für einzelne Bundestaaten innerhalb eines Marktes (z.B. unterschiedliche Steuersätze in New York und Texas) für eine erhöhte Komplexität sorgen. Basierend auf dem angezeigten Preis haben die meisten hochpreisigen Produkte die Möglichkeit einer Finanzierungsberechnung oder der Anzeige einer Leasingrate, welche ebenfalls live zur Konfiguration berechnet werden muss und sowohl Laufzeit, Preis der Konfiguration als auch alle weiteren Leasingparameter berücksichtigen muss.

Fazit
Die genannten Beispiele aus unseren gesammelten Erfahrungen in der Begleitung und Entwicklung von Konfiguratoren lassen unserer Meinung nach folgende Schlüssel bezüglich der Konfigurator-Architektur zu:

  • Eine Trennung von Frontend (Anzeige Ebene) und Backend (Geschäft Logik Ebene) ist auch für Konfiguratoren von Vorteil
  • Durch die Modularität
    • können einzelne Komponenten getrennt entwickelt werden.
    • kann der Konfigurator (in vereinfachter Form) schneller eingesetzt werden.
    • kann die Wiederverwendbarkeit, auch außerhalb eines Konfigurators gewährleitet werden.
    • ist es möglich einzelne Module zu tauschen, ohne eine neue Lösung zu implementieren
  • Es sollte ein zentrales Backend geben, welches unternehmensweit die Geschäftslogik für Konfiguratoren bereitstellt.
  • Es sollte ein Standard-Kommunikationsformat für das Frontend bereitgestellt werden.
  • Das Konfigurator Backend muss zwingend Mandantenfähig sein um auf Marktspezifika reagieren zu können.

 

Weitere Informationen zum Thema Produktkonfiguratoren und einen Einblick in das Spektrum der von uns mitgestalteten Konfiguratoren finden Sie unter nachfolgenden Links

https://blog.doubleslash.de/tag/konfigurator/

https://blog.doubleslash.de/online-konfigurator-super-touchpoint-management/

https://blog.doubleslash.de/carconfigurator-produktkonfiguratoren-touchpoint/

https://www.doubleslash.de/referenzen/bmw/produktkonfiguration/

https://www.doubleslash.de/referenzen/festo-produktkonfigurator/

 

doubleSlash-Teaser-Blog_Online-Konfigurator

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*Pflichtfelder

*

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.