Ein Kunde wählt Motor, Gehäuse und Steuerung. Der Preis sieht korrekt aus, aber der Motor passt nicht in das gewählte Gehäuse. Das ist kein Rechenfehler. Es fehlt ein Produktmodell. Genau an dieser Stelle endet der Angebotsrechner und beginnt der Produktkonfigurator

Zwei Denkmaschinen

Ein Angebotsrechner beantwortet vor allem die Frage: „Welche Kosten sind bei diesen Parametern zu erwarten?“. Ein Produktkonfigurator beantwortet vorher: „Welche Kombination ist überhaupt zulässig?“. Der erste braucht Preisformeln. Der zweite braucht Einschränkungen, Abhängigkeiten und ein Ergebnis, das nachgelagerte Systeme verwenden können

Bei Dienstleistungen kann die Grenze fließend sein. Ein Rechner für Reinigungskosten verwendet Fläche und Häufigkeit. Ein Konfigurator für einen technischen Wartungsvertrag kann prüfen, ob die gewählte Reaktionszeit in der Region und für den Anlagentyp verfügbar ist

Einschränkungen statt Ausnahmeliste

Ein schwacher Konfigurator sammelt Regeln wie „wenn A und B, dann C ausschalten“. Nach einigen Dutzend Optionen weiß niemand mehr, welche Regel gewinnt. Ein besseres Modell beschreibt Eigenschaften und Grenzen: Eine Leistung benötigt eine bestimmte Spannung, die Masse darf die Gehäusegrenze nicht überschreiten und ein Zertifikat ist nur für festgelegte Materialien verfügbar

Die Regelengine kann dann eine Kombination ablehnen, eine kompatible Alternative vorschlagen und den Grund erklären. Diese Erklärung ist geschäftlich wichtig. „Option nicht verfügbar“ wirkt wie ein Fehler der Website. „Für 32 A ist Gehäusegröße M oder L erforderlich“ hilft bei der Entscheidung

Das Ergebnis braucht ein weiteres Leben

Ein farbiges Bild am Ende genügt nicht. Die Produktion braucht eine Stückliste, der Vertrieb Angebotspositionen und der Kunde einen Konfigurationscode. Dieser Code sollte auf die Version von Katalog und Regeln verweisen. Nach einem halben Jahr kann dieselbe Konfiguration nicht mehr verfügbar sein; die historische Bestellung muss trotzdem rekonstruierbar bleiben

Wenn der Konfigurator das Ergebnis an ERP oder CPQ übergibt, müssen Kennungen stabil sein. Ein sichtbarer Name darf sich ändern, die technische Identität einer Variante darf dadurch aber nicht versehentlich auf ein anderes Produkt zeigen

Beispiel: ein Schaltschrank

  1. Der Nutzer wählt Anwendung und erforderliche Umgebung
  2. Das System grenzt Gehäusematerial und Schutzart ein
  3. Die gewählte Leistung bestimmt Komponenten, Kühlung und Mindestgröße
  4. Kommunikationsoptionen ergänzen Module und Lizenzen
  5. Kompatibilitätsregeln erzeugen eine technische Variante
  6. Die Preisengine berechnet Preis, Lieferzeit und Zuschläge
  7. Das Ergebnis erzeugt Code, Spezifikation und Angebotsdaten

Die Schritte zwei bis fünf sind Konfiguration. Schritt sechs ist Kalkulation. Beide können zusammenarbeiten, sind aber nicht dasselbe Problem

Den Kombinationsraum testen

Zehn Optionen mit je fünf Werten ergeben bereits Millionen von Kombinationen. Niemand kann sie alle manuell anklicken. Tests decken jede Regel, Grenzwerte und häufig kollidierende Optionspaare ab. Zusätzlich werden zufällige gültige Konfigurationen erzeugt und anhand unabhängiger Eigenschaften wie Leistung, Masse und Zertifizierung geprüft

Vor einer Katalogänderung läuft ein Satz historischer Konfigurationen erneut. Verschwindet eine bisher bestellbare Variante, sieht das Team dies vor der Veröffentlichung und kann entscheiden, ob die Änderung beabsichtigt ist

Wann ein Rechner genügt

Wenn jede angebotene Kombination lieferbar ist und sich hauptsächlich Menge, Zeit oder Umfang ändern, ist ein Angebotsrechner einfacher und verständlicher. Führt eine falsche Kombination zu einem unmöglichen Produkt, einem falschen Bauteil oder einem Sicherheitsrisiko, wird ein Konfigurator benötigt

Bei sehr komplexen Produkten muss die erste Version nicht den ganzen Katalog abdecken. Es ist besser, eine Produktfamilie vom Start bis zum gültigen Bestellcode zu konfigurieren, als jede Familie nur bis zu einer hübschen Zusammenfassung zu führen. Das professionelle Ergebnis ist kein Auswahlbildschirm. Es ist eine geprüfte, versionierte Spezifikation