Komplexe Produkte verkaufen

Konfigurierbare Produkte verkaufen

Länge, Material, Beschichtung, Anschluss: Produkte, die erst eine Spezifikation brauchen, bevor ein Preis existiert.

Ein konfigurierbares Produkt hat keinen Preis, bevor jemand es spezifiziert. Eine Schlauchleitung ist 2,4 Meter lang, trägt an einem Ende einen BSP-Anschluss und am anderen einen JIC, hat ein Edelstahlgeflecht und eine Schutzhülle, und der Preis folgt aus diesen fünf Antworten. Heute kommen diese Antworten per Telefon: Der Einkäufer beschreibt die Anwendung, jemand im Innendienst entscheidet, ob das baubar ist, schlägt die Zuschläge nach und meldet den Preis zurück. Dieses Gespräch ist die einzige Bestellschnittstelle des Produkts, und es läuft im Tempo eines einzelnen Arbeitstags.

Warum das schwerer ist, als es klingt

Der erste Fehler passiert, bevor irgendetwas modelliert ist, und er ist ein Modellierungsfehler: drei verschiedene Mechanismen wie einen zu behandeln. Sie verhalten sich im Katalog, in der Suche, in der Bestellposition und in Ihrem ERP unterschiedlich, und der falsche Griff kostet einen Neubau.

Mechanismus	Einsatz, wenn	Was der Einkäufer bekommt
Varianten	Die Kombinationen sind endlich, bekannt, und jede hat eine eigene Artikelnummer	Eine Produktseite mit wenigen Auswahlfeldern; jede Wahl ist eine echte SKU mit eigenem Bestand und Preis
Konfigurator	Die Kombinationen gehen in die Tausende, oder ein Wert ist stetig (Länge, Bohrung, Hub)	Eine geführte Spezifikation; der Preis wird berechnet, der Artikel entsteht mit der Bestellung
Bundle	Mehrere einzeln bestellbare Artikel werden meist zusammen verkauft	Ein vorbefüllter Warenkorb, den der Einkäufer noch ändern kann

Die meisten technischen Sortimente brauchen alle drei, Familie für Familie. Ein Bereich mit 14 Längen × 6 Druckstufen × 3 Beschichtungen sind 252 Varianten: viele, aber endlich. Wenn jede davon im ERP eine Artikelnummer hat, ist das ein Variantenproblem. Als Konfigurator modelliert wird Ihr Katalog schlechter durchsuchbar und Ihre Bestandszahlen werden bedeutungslos. Ein Zuschnittprodukt ist das Gegenteil: Keine SKU-Liste kann es ausdrücken.

Das zweite Hindernis: Die Regeln stehen nirgends. Sie sitzen in den Köpfen von zwei, drei Leuten, die dieses Produkt seit fünfzehn Jahren anbieten. Dieser Anschluss geht nicht über 250 bar, diese Beschichtung braucht eine Mindestlänge, dieser Motor und jenes Getriebe brauchen einen Adapter, den keiner dazulegt. Diese Regeln herauszuholen, aufzuschreiben und zu klären, welche davon harte Grenzen sind und welche Gewohnheit, ist der Hauptteil des Projekts. Das ist keine Softwareaufgabe, und Sie können sie nicht auslagern.

Ein Konfigurator, der Konfigurationen erzeugt, die Sie nicht bauen können, ist schlimmer als kein Konfigurator. Jede ungültige Kombination, die die Produktion erreicht, ist eine gestoppte Bestellung, ein Anruf und meist eine Gutschrift. Anders als bei einem falschen Preis merkt der Einkäufer es erst, wenn er um einen Liefertermin herum geplant hat. Modellieren Sie weniger Optionen mit vollständigen Regeln statt des ganzen Bereichs mit ungefähren.

Dann der Preis. Ein konfigurierter Preis wird aufgebaut, nicht nachgeschlagen: Grundpreis, Zuschläge je Option, etwas pro Meter oder Kilogramm, ein Mindestpreis für kurze Längen, eine Mengenstaffel und darüber die Vertragskondition des Kunden. Wo diese Berechnung lebt, im Variantenkonfigurator Ihres ERP oder in der Plattform, entscheiden Sie einmal. Wer sie aufteilt, sodass manche Zuschläge hier und manche dort gepflegt werden, bekommt den Fehler, bei dem Shop und Auftragsbestätigung verschiedene Zahlen zeigen.

Und die Bestellposition. Eine konfigurierte Position ist mehr als eine SKU mit Beschreibung. Die Fertigung braucht die Spezifikation als strukturierte Daten: jede gewählte Option, in einer Form, die das ERP zu Stückliste und Arbeitsplan auflösen kann. In der Plattform reist die Konfiguration mit der Bestellposition. Plättet Ihre Schnittstelle sie zu Freitext, tippt jemand in der Arbeitsvorbereitung sie ab, und Sie haben den manuellen Schritt verschoben statt entfernt.

Eine Erwartung früh zurechtrücken: Konfigurierte Ware wird auf Bestellung gefertigt, also gibt es keinen Bestand. Der Einkäufer braucht stattdessen eine glaubwürdige Lieferzeit, und eine, die die optionsabhängige Beschaffung ignoriert, ist ein Versprechen, das Sie brechen werden.

Der geführte Konfigurator im Storefront ist geplant. Heute liefert die Plattform die Modellierung darunter: Familien, Familienvarianten, Attribute mit Einheiten, Verknüpfungstypen und Preisregeln. Modellieren Sie die endlichen Familien jetzt als Varianten; die Konfiguratorfamilien führen Sie zum Angebot, bis der Bildschirm da ist.

Die Hebel

Entscheiden Sie je Produktfamilie, welchen Mechanismus sie braucht

So sieht es gut aus: Jede Familie in Ihrem Sortiment ist aus einem benannten Grund Varianten, Konfigurator oder Bundle zugeordnet, und die endlichen Familien bleiben endlich.

Wovon es abhängt: Ob die Kombinationen im ERP bereits als Artikelnummern existieren. Diese eine Frage entscheidet die meisten Fälle.

Holen Sie die Regeln aus den Köpfen ins Modell

So sieht es gut aus: Optionsgruppen, Optionen und die Regeln dazwischen sind aufgeschrieben und prüfbar. Eine nicht baubare Kombination lässt sich nicht auswählen, und der Einkäufer erfährt warum, statt vor einer ausgegrauten Liste zu sitzen.

Wovon es abhängt: Zeit der zwei, drei Leute, die das Produkt kennen, im Voraus gebucht. Das ist die längste Vorlaufzeit im Projekt, und sie lässt sich nicht verkürzen.

Lassen Sie den Preis erscheinen, während der Einkäufer noch wählt

So sieht es gut aus: Der Preis aktualisiert sich mit jeder Option, enthält die Vertragskondition des Kunden und stimmt auf den Cent mit der Auftragsbestätigung überein. Wo eine Konfiguration einen Menschen braucht (ein ungewöhnliches Material, eine Projektmenge), ist der Weg zum Angebot ein Klick und keine Sackgasse.

Wovon es abhängt: Festzulegen, wo der Preisaufbau berechnet wird, und Kundenkonditionen aus dem System zu lesen, das sie pflegt.

Tragen Sie die Konfiguration durch den Checkout bis in die Fertigung

So sieht es gut aus: Die Bestellposition trägt jede gewählte Option als Daten, Ihr ERP löst sie ohne Abtippen zur Stückliste auf, und der Einkäufer kann die Konfiguration vom letzten Jahr öffnen und erneut bestellen.

Wovon es abhängt: Eine Feldzuordnung, die die Struktur erhält, und auf der anderen Seite ein Stücklistenmodell, gegen das sich die Konfiguration auflösen lässt.

Eine sinnvolle Reihenfolge

Phase 1: eine Familie, jede Regel. Wählen Sie die Familie mit den meisten Spezifikationsanrufen, nicht die mit dem größten Umsatz. Modellieren Sie ihre Optionen vollständig, einschließlich der Regeln, die heute Stammeswissen sind, und prüfen Sie jede Konfiguration, die das Modell zulässt, gegen das, was die Fertigung akzeptiert. Voraussetzung: die Regelextraktion, die am ersten Tag beginnt. Das Ergebnis ist ein funktionierendes Modell für einen schmalen Bereich und, ebenso wertvoll, ein aufgeschriebenes Verfahren, wie Sie die Regeln der nächsten Familie herausholen.

Phase 2: Preisaufbau und der Angebotsausweg. Erweitern Sie auf zwei, drei weitere Familien und schließen Sie den Preis an: Zuschläge, Längenkomponenten, Staffeln, Vertragskonditionen. Bauen Sie gleichzeitig den Ausgang. Konfigurationen, die Sie nicht automatisch bepreisen, gehen mit angehängter Spezifikation ins Angebot, statt eine falsche Zahl oder gar keine zu zeigen. Voraussetzung: Phase 1 hat gezeigt, dass die Regeln halten. Eine unzuverlässige Konfiguration zu bepreisen heißt, einen Fehler zu bepreisen.

Phase 3: die harten Fälle. Optionen, die von der Wahl in einer anderen Familie abhängen, Zeichnungs- oder CAD-Ausgabe für den konfigurierten Artikel, Lieferzeiten, die die optionsabhängige Beschaffung abbilden, und der Abgleich mit dem Variantenkonfigurator Ihres ERP, damit beide dasselbe für baubar halten. Jeder Punkt ist ein Projekt. Sie kommen, wenn die klaren Familien Geld verdienen.

Typische Fehler

Einen endlichen Bereich als Konfigurator modellieren. Wenn jede Kombination schon eine Artikelnummer hat, sind es Varianten. Ein Konfigurator darüber kostet Sie Bestand, Suche und Nachbestellung.
Den Konfigurator bauen, bevor die Regeln existieren. Das Modell wird zu dem Ort, an dem niemandes Annahmen stehen, und es erzeugt nicht baubare Bestellungen.
Den Preisaufbau auf zwei Systeme verteilen. Shop und Auftragsbestätigung werden sich widersprechen, und der Kunde findet es zuerst.
Einen Bestand für auftragsgefertigte Ware zeigen. Zeigen Sie stattdessen eine Lieferzeit, die Sie halten können.
Kein Weg zu einem Menschen. Manche Konfigurationen müssen angeboten werden. Ein Konfigurator ohne diesen Ausgang schickt den Einkäufer zurück ans Telefon, wo er angefangen hat.

Woran Sie erkennen, dass es funktioniert

Anteil der Bestellungen konfigurierbarer Produkte, die der Kunde selbst spezifiziert hat, ohne Anruf im Innendienst. Die Leitkennzahl.
Begonnene Konfigurationen gegen bestellte. Eine große Lücke heißt, das Modell stellt Fragen, die der Einkäufer nicht beantworten kann, oder endet ohne Preis.
Bestellungen, die die Fertigung als nicht baubar zurückgibt. Nach Phase 1 null; jede wiederkehrende Ursache ist eine fehlende Regel und gehört ins Modell statt ins Gedächtnis eines Kollegen.
Abweichungen zwischen angezeigtem und bestätigtem Preis. Jede einzelne heißt, der Aufbau ist geteilt oder veraltet.
Zeit von der Anfrage bis zum Angebot für die Konfigurationen, die Sie noch von Hand anbieten. Das soll Phase 2 bewegen.
Spezifikationsanrufe pro Woche, vor dem Start nach Produktfamilie kategorisiert, damit Phase 2 eine Prioritätenliste hat statt einer Meinung.

Was Sie bauen

Einen Katalog, in dem jede technische Familie entweder ein Satz echter Varianten mit eigenen Artikelnummern ist oder eine Spezifikation mit aufgeschriebenen Regeln und aufgebautem Preis. Der Einkäufer wählt, sieht seinen Preis, und die gewählten Optionen reisen als Daten auf der Bestellposition in Ihr ERP, wo sie sich zur Stückliste auflösen. Konfigurationen, die die Regeln nicht bepreisen können, gehen mit angehängter Spezifikation ins Angebot. Regeln, Preise und Bestellweg gibt es heute; der geführte Konfigurator und die Angebots-App sind geplant.

flowchart LR
  ERP["Ihr ERP: Variantenkonfigurator, Stückliste"]
  subgraph CS["Commerce Studio"]
    F["Familien und Familienvarianten"]
    A["Attribute mit Einheiten"]
    ASSOC["Verknüpfungstypen: kompatibel mit"]
    PR["Preise: Grundpreis, Zuschläge, Staffeln, Vertrag"]
    O["Bestellungen: Optionen auf der Position"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront"]
    FRM["Formulare: Angebotsanfrage"]
  end
  subgraph IS["Integration Studio"]
    WF["Workflows und Feldzuordnung"]
  end
  CFG["Konfigurator-UI (geplant)"]:::planned
  QT["Angebote (geplant)"]:::planned
  ERP -- "Artikelnummern, Konditionen" --> WF
  WF --> F
  WF --> PR
  SF -- "spezifizierte Bestellung" --> O
  O -- "Position mit Optionen" --> WF
  WF -- "Bestellung, Optionen als Daten" --> ERP
  SF -- "nicht bepreisbare Konfiguration" --> FRM
  CFG -.-> SF
  FRM -.-> QT
  classDef planned stroke-dasharray: 5 5

Was Sie brauchen

Jede technische Familie Varianten, Konfigurator oder Bundle zugeordnet, mit Begründung — Konfigurierbare Produkte
Die endlichen Familien als Familienvarianten mit echten Artikelnummern — Varianten und Familienvarianten
Die Regeln der ersten Konfiguratorfamilie aufgeschrieben und mit der Fertigung abgestimmt — Einen Konfigurator aufbauen
Attribute mit Einheiten für jede Option, die ein Maß ist — Maße und Einheiten
Eine Entscheidung, wo der Preisaufbau berechnet wird, ERP oder Plattform — Preise und Ihr ERP
Vertragskonditionen der Pilotkunden lesbar — Vertragspreise für einen Kunden
Eine Feldzuordnung, die Optionen auf der Bestellposition als Daten ins ERP trägt — Feldzuordnung
Ein Weg zu einem Menschen für das, was die Regeln nicht bepreisen — Eine Angebotsanfrage bearbeiten

So bauen Sie es

Die technischen Familien auflisten und jede als Varianten, Konfigurator oder Bundle markieren, je nachdem, ob die Kombinationen schon Artikelnummern haben — Konfigurierbare Produkte
Die Familie mit den meisten Spezifikationsanrufen wählen und die zwei Leute buchen, die ihre Regeln kennen — Einen Konfigurator aufbauen
Zuerst die endlichen Familien modellieren: Familie, Familienvariante, Variantenachsen — Familienvarianten
Die Optionsattribute mit Einheiten und Optionslisten anlegen — Attribute
Die Regeln als Tabelle aufschreiben und von der Fertigung freigeben lassen — Kompatibilität und Passt-zu
Festlegen, wo der Preisaufbau lebt, und es in der Datenhoheitstabelle festhalten — Datenhoheit festlegen
Grundpreis, Zuschläge und Staffeln als Preisregeln oder Preislisten einrichten — Preisregeln
Vertragskonditionen für drei Pilotkunden laden und einen konfigurierten Preis auf den Cent gegen das ERP prüfen — Prüfen, welchen Preis ein Einkäufer sieht
Die Bestellposition so zuordnen, dass Optionen als Felder im ERP ankommen, nicht als Positionstext — Feldzuordnung
Eine Testbestellung aufgeben und bestätigen, dass das ERP sie ohne Abtippen zur Stückliste auflöst — Eine Integration durchgängig testen
Ein Anfrageformular für Konfigurationen außerhalb der Regeln ergänzen — Formulare
Für auftragsgefertigte Familien den Bestand durch eine Lieferzeitangabe ersetzen — Seiten und Blöcke bearbeiten
Den Piloten fahren, nicht baubare Bestellungen wöchentlich zählen und jede Ursache als Regel ergänzen — Konfiguratorprobleme
Familie für Familie erweitern, mit dem aufgeschriebenen Verfahren zur Regelextraktion — Datenmodell planen

Entscheidungen, die Sie treffen müssen

Entscheidung	Die Abwägung	Wohin die meisten Kunden gehen
Varianten oder Konfigurator, je Familie? Endliche Kombinationen mit Artikelnummern, oder eine regelgetriebene Spezifikation.	Varianten liefern Bestand, Suche und Nachbestellung umsonst und enden bei ein paar hundert Kombinationen. Ein Konfigurator kann stetige Werte und Tausende Kombinationen und kostet Sie alle drei.	Varianten überall, wo das ERP die Artikelnummern schon hat, auch bei 250 Stück. Konfigurator nur für Zuschnitt und offene Bereiche. Die gemischte Antwort je Familie ist die normale.
Wo wird der Preis aufgebaut: ERP-Variantenkonfigurator oder Plattform?	ERP-seitig hält eine Berechnung und braucht ein ERP, das antwortet, während der Einkäufer wählt. Plattformseitig ist auf der Seite schneller und heißt Zuschläge an zwei Stellen pflegen, sofern das ERP sie nicht übergibt.	Kommt aufs ERP an. SAP-Häuser mit funktionierendem Variantenkonfigurator lassen ihn dort und lesen das Ergebnis. Alle anderen pflegen den Aufbau in Preisregeln der Plattform und nutzen das ERP zur Bestätigung. Nie beides.
Vollständige Regeln für wenige Optionen oder ungefähre Regeln für den ganzen Bereich?	Wenige Optionen mit vollständigen Regeln heißt, manche Familien bleiben vorerst am Telefon. Der ganze Bereich mit Lücken heißt nicht baubare Bestellungen in der Fertigung.	Wenige und vollständig. Eine nicht baubare Bestellung kostet mehr als ein Anruf, und sie kostet den Kunden einen Liefertermin.
Was passiert mit einer Konfiguration, die die Regeln nicht bepreisen können? Sperren, „auf Anfrage" zeigen, oder mit angehängter Spezifikation ins Angebot geben.	Sperren schickt den Einkäufer ans Telefon. „Auf Anfrage" ohne Spezifikation startet das Gespräch bei null. Ein Angebot mit angehängten Optionen behält die geleistete Arbeit.	Angebot mit angehängter Spezifikation. Bis die Angebots-App da ist, ist das ein Formulareingang, den Ihr Innendienst abarbeitet; sagen Sie das intern, damit es einen Verantwortlichen hat.
Optionen als strukturierte Felder auf der Bestellposition oder als Positionstext?	Strukturierte Felder brauchen eine Feldzuordnung und ein ERP, das sie annimmt. Text ist schnell, und jemand tippt ihn in der Arbeitsvorbereitung ab.	Strukturiert. Kann das ERP sie noch nicht annehmen, dann plattformseitig strukturiert und im ERP übergangsweise als Text, mit dem Abtippen als Kostenposten, den Sie abbauen.
Bestand oder Lieferzeit für auftragsgefertigte Ware?	Ein Bestand ist vertraut und falsch. Eine Lieferzeit ist ehrlich und setzt voraus, dass Sie wissen, welche Optionen die Beschaffung treiben.	Lieferzeit, je Familie, aktualisiert, wenn sich Beschaffungszeiten ändern. Ein haltbares „3 Wochen" schlägt ein „auf Lager", das Sie erklären müssen.