Regeln im Produktkonfigurator: wie Options-Abhängigkeiten Produktlogik fehlerfrei machen
Regeln im Produktkonfigurator: wie Benötigt- und Ausgeschlossen-Regeln ungültige Kombinationen verhindern, statt sie erst im Auftrag zu finden.
· 8 Min. Lesezeit
Regeln im Produktkonfigurator legen fest, welche Optionen einander voraussetzen und welche sich gegenseitig ausschließen. Sind sie als Benötigt- und Ausgeschlossen-Regeln je Option hinterlegt, lässt sich eine ungültige Kombination gar nicht erst eingeben, statt erst in Angebot oder Auftrag aufzufallen. Zwei Regeltypen reichen dafür bei den meisten Produkten aus.
Jeder Hersteller variantenreicher Produkte kennt diesen Moment: Ein Auftrag kommt herein, die Fertigung schaut auf die Stückliste und ruft im Vertrieb an. Diese Kombination gibt es nicht. Die Hochtemperatur-Ausführung mit der Standarddichtung, der lange Hub mit dem kurzen Gehäuse, die Edelstahlvariante mit dem lackierten Anbauteil. Der Vertriebler hat nichts falsch gemacht, er konnte es nur nicht wissen: Die Regel stand in keinem Katalog, sie lebte im Kopf eines Kollegen, der an diesem Tag nicht gefragt wurde. Solche Fälle sind kein Ausrutscher, sie sind das erwartbare Ergebnis eines Systems, in dem Produktlogik nirgends verbindlich hinterlegt ist.
Warum reicht nachträgliches Prüfen nicht aus?
Weil es den Fehler erst findet, nachdem er entstanden ist, und dabei jedes einzelne Angebot Zeit kostet. Der klassische Umgang mit ungültigen Kombinationen ist die Kontrolle im Nachgang: Die Auftragsprüfung, die Konstruktion oder der erfahrene Kollege schauen über jedes Angebot, bevor es rausgeht. Das funktioniert, hat aber drei eingebaute Schwächen. Erstens kostet es bei jedem einzelnen Angebot Zeit, auch bei der großen Mehrheit, die fehlerfrei ist. Zweitens hängt es an Verfügbarkeit: Ist der Prüfer im Urlaub, geht das Angebot ungeprüft raus oder bleibt liegen. Drittens, und das wiegt am schwersten: Es findet den Fehler erst, nachdem er entstanden ist. Im besten Fall bedeutet das eine interne Korrekturschleife, im schlechtesten steht die ungültige Kombination schon im unterschriebenen Auftrag.
Das Alternativprinzip ist so einfach wie wirksam: Der Fehler darf gar nicht erst eingebbar sein. Genau das leisten Options-Abhängigkeiten in einem Konfigurator.
Wie funktionieren Regeln im Produktkonfigurator?
Über zwei Regeltypen, benötigt und ausgeschlossen, die je Option hinterlegt werden. Fast die gesamte Produktlogik variantenreicher Produkte lässt sich darauf zurückführen.
- Benötigt: Option A setzt Option B voraus. Die Hochtemperatur-Ausführung benötigt die verstärkte Lagerung. Wählt der Nutzer A, ist B gesetzt oder wird eingefordert, A ohne B ist nicht wählbar.
- Ausgeschlossen mit: Option A und Option C können nicht gemeinsam bestehen. Die Edelstahlvariante schließt das lackierte Anbauteil aus. Ist A gewählt, wird C gesperrt, sichtbar und mit Begründung.
- Kombinationen daraus decken auch komplexere Fälle ab: Eine Option kann mehrere Voraussetzungen haben und gleichzeitig mehrere andere ausschließen. Aus wenigen einfachen Regeln entsteht so ein vollständiges Regelnetz.
Ein Detail der Nutzerführung macht dabei viel aus: Gesperrte Optionen sollten sichtbar bleiben und den Grund nennen, etwa: nicht verfügbar in Verbindung mit Edelstahlausführung. Eine kommentarlos verschwundene Option verwirrt und erzeugt Rückfragen. Eine sichtbar gesperrte Option mit Begründung erklärt das Produkt nebenbei mit, der Konfigurator wird zum Produkttrainer für Interessenten und neue Mitarbeiter gleichermaßen.
Was passiert bei Presets und geteilten Konfigurationen?
Ein sauberes System prüft sie beim Laden gegen das aktuelle Regelwerk und korrigiert, was nicht mehr zusammenpasst. Denn ein Regelwerk muss mehr abdecken als die Klickreihenfolge eines einzelnen Nutzers. In der Praxis kommen Konfigurationen auch von außen ins System: als gespeicherter Schnellstart, als geteilter Link vom Kollegen, als alte Konfiguration aus der Zeit vor einer Regeländerung. Ein sauberes System prüft jede hereinkommende Auswahl gegen das aktuelle Regelwerk und bereinigt sie automatisch: Was heute nicht mehr zusammen geht, wird korrigiert, statt einen ungültigen Zustand anzuzeigen. Ohne diese Prüfung ist das Regelwerk eine Fassade, die nur den direkten Klickweg absichert.
Aus demselben Grund gehören auch Preise in dasselbe Regelwerk: Eine ausgeschlossene Option darf weder wählbar sein noch in einer Preisberechnung, einem Angebots-PDF oder einer Anfrage auftauchen. Systeme, die Auswahl-Logik und Preislogik getrennt pflegen, produzieren genau an dieser Naht die nächste Fehlerquelle: Die Oberfläche sperrt die Option, die Kalkulation rechnet sie trotzdem mit. Ein durchgängiges Regelwerk hält beides in einem einzigen konsistenten Zustand.
Warum ist das Regelwerk eine Antwort auf den Fachkräftemangel?
Weil es Erfahrungswissen aus einzelnen Köpfen in ein System überführt, das auch nach deren Ruhestand weiterarbeitet. Dieser Effekt hat mit Technik wenig zu tun. In vielen Maschinenbauunternehmen liegt das Wissen, welche Kombinationen gehen und welche nicht, bei einer Handvoll Mitarbeiter mit zwanzig oder dreißig Jahren Erfahrung. Diese Generation geht in den kommenden Jahren in Rente, und der Nachwuchs, der dieses Wissen über Jahre aufsaugen könnte, ist schwer zu finden. Jede Regel, die aus einem Kopf in ein System wandert, ist konservierte Erfahrung: Sie arbeitet weiter, wenn der Wissensträger nicht mehr da ist, und sie macht neue Vertriebsmitarbeiter vom ersten Tag an handlungsfähig, weil das System sie vor den Fehlern schützt, für die früher Jahre Erfahrung nötig waren.
Rechnen wir ein Beispiel: Wenn eine ungültige Kombination im Schnitt erst im Auftrag auffällt und dort Klärung, Umplanung und Kundenkommunikation im Umfang von zwei Personentagen auslöst, kostet jeder dieser Fälle schnell einen vierstelligen Betrag, den Vertrauensschaden beim Kunden nicht eingerechnet. Ein Regelwerk, das solche Fälle strukturell ausschließt, muss nicht viele davon verhindern, um sich zu rechnen.
Worauf sollten Sie bei der Umsetzung achten?
Auf drei Dinge: Regeln werden als Daten gepflegt, sodass eine Regeländerung keine Programmierung erfordert. Gesperrte Optionen bleiben sichtbar und nennen ihren Grund. Und auch Presets, geteilte Links und gespeicherte Konfigurationen werden gegen das aktuelle Regelwerk geprüft. Bei Configro ist die Logik genau so gebaut: Benötigt- und Ausgeschlossen-Regeln werden je Option in der Produkt-Konfiguration hinterlegt, keine Programmierung nötig. Der geführte Konfigurator zeigt gesperrte Optionen deaktiviert mit Begründung, und jede von außen kommende Auswahl, ob Schnellstart-Preset oder geteilter Konfigurations-Link, wird automatisch konsistent gehalten. Wie sich das anfühlt, lässt sich in der Live-Demo unter configro.de/demo direkt ausprobieren.
Unterm Strich: Fehlerfreie Produktlogik entsteht nicht durch gründlicheres Prüfen, sondern durch ein System, in dem ungültige Kombinationen nicht eingebbar sind. Zwei einfache Regeltypen, benötigt und ausgeschlossen, reichen dafür in den meisten Fällen aus. Der eigentliche Gewinn liegt über die Fehlervermeidung hinaus in der Konservierung von Erfahrungswissen, und das ist im Maschinenbau der knappste Rohstoff überhaupt.
Häufige Fragen
Was sind Options-Abhängigkeiten in einem Produktkonfigurator?
Regeln, die festlegen, welche Optionen einander voraussetzen oder ausschließen. Beispiel aus dem Maschinenbau: Die Hochtemperatur-Ausführung benötigt die verstärkte Lagerung und schließt die Standarddichtung aus. Der Konfigurator setzt diese Regeln bei jeder Auswahl automatisch durch, sperrt unzulässige Optionen sichtbar und nennt den Grund, sodass niemand eine technisch unmögliche Variante anfragen kann.
Wie viele Regeln braucht ein typisches Produkt im Konfigurator?
Meist weniger als befürchtet. Nach unserer Projekterfahrung kommen viele Produkte mit einigen Dutzend Benötigt- und Ausgeschlossen-Regeln aus, weil sich Abhängigkeiten an wenigen Schlüsselmerkmalen wie Baugröße, Werkstoff oder Antriebsart festmachen. Deutlich mehr Regeln sind oft ein Zeichen dafür, dass Fertigungsdetails im Konfigurator gelandet sind, die eigentlich ins ERP gehören.
Müssen Regeln in einem Produktkonfigurator programmiert werden?
Nicht zwingend. In konfigurationsgetriebenen Systemen werden Benötigt- und Ausgeschlossen-Regeln als Daten je Option hinterlegt, ähnlich wie Einträge in einer Tabelle. Eine neue Regel oder ein geänderter Ausschluss braucht dann keinen Entwickler. Bei fest programmierten Konfiguratoren dagegen wird jede Sortimentsänderung zum Änderungsauftrag, und die Regeln veralten, weil niemand die Kosten dafür auslösen will.
Sollen gesperrte Optionen im Konfigurator ausgeblendet werden?
Besser nicht. Eine Option, die kommentarlos verschwindet, verwirrt Nutzer und erzeugt Rückfragen, weil sie im Katalog steht und im Konfigurator fehlt. Bleibt sie sichtbar, ausgegraut und mit Begründung wie nicht verfügbar mit Edelstahlausführung, versteht der Kunde das Produkt besser. Neue Vertriebsmitarbeiter lernen die Produktlogik auf diesem Weg gleich mit.
Wie verhindert ein Konfigurator Preisfehler durch ausgeschlossene Optionen?
Indem Auswahl und Preis aus demselben Regelwerk gerechnet werden. Wird eine Option ausgeschlossen, fällt sie gleichzeitig aus Preis, Angebots-PDF und Anfrage heraus. Systeme, die Auswahllogik und Kalkulation getrennt pflegen, erzeugen an dieser Naht Fehler: Die Oberfläche sperrt die Option, die Preisberechnung zählt sie trotzdem mit, und der Kunde erhält ein falsches Angebot.