Arbeitstitel des Konfigurator-VorhabensEmpfohlen
Ein eindeutiger Name trennt Produktfamilie, Kanal und Version des Briefings.
Kostenloser Produktkonfigurator-Check · lokaler Export
Produktkonfigurator-Anforderungen ordnen. Bevor die Oberfläche sie versteckt.
Ordnen Sie Produktfamilie, Merkmale, Regeln, Preislogik, Darstellung, Systemquellen und Abnahme in 20 prüfbaren Punkten. Das Ergebnis ist ein neutrales Briefing für Plugin-, CPQ-, Plattform- oder Individualsoftware-Vergleiche – ohne E-Mail-Gate und ohne automatische Aufwandsschätzung.
Lokal und ohne Registrierung: Alle Angaben werden ausschließlich im geöffneten Browser-Tab verarbeitet. Das Tool sendet keine Produktdaten oder Regeln an Midnight Motion. Der Check ist eine Arbeits- und Gesprächsgrundlage. Er ist keine Vollständigkeits-, Produktgültigkeits-, Machbarkeits-, Kosten- oder Terminzusage.
01Merkmal
02Bedingung
03Aktion
04Ausgabe
Interaktive Checkliste und exportierbare Vorlage
20 Prüfpunkte für ein nachvollziehbares Projektbriefing
Die Tool-Seite führt im Browser durch alle folgenden Fragen und erzeugt daraus ein gegliedertes Markdown- und Druckdokument. Ein fiktives Beispiel zeigt die erwartete Detailtiefe, ohne fremde Kundendaten zu verwenden. Die Fortschrittsanzeige zählt nur beschriebene Punkte; sie ist ausdrücklich kein Reifegrad, keine Anbieterbewertung und keine Aussage zur technischen Machbarkeit.
Systemgrenze
Nutzer, Kanal und verbindliches Ergebnis
Ein Produktkonfigurator kann beraten, technisch auslegen, einen Preis berechnen, ein Angebot vorbereiten oder eine Bestellung erzeugen. Version eins sollte ein eindeutiges Ergebnis besitzen, statt Shop, CPQ, CAD und ERP gleichzeitig nachzubauen.
Wer konfiguriert in welchem Kanal?Vor Auswahl klären
Beschreiben Sie B2C-Kunde, Vertrieb, Fachhandel, Planer oder interne Technik sowie Website, Shop, Portal oder interne Anwendung.
Welche Produktfamilie bildet der erste Scope ab?Vor Auswahl klären
Nennen Sie reale Produkte, gemeinsame Struktur, Variantenumfang und bewusste Ausschlüsse. Ein Pilot sollte repräsentative Komplexität enthalten.
Welches Ergebnis ist nach einer gültigen Konfiguration verbindlich?Vor Auswahl klären
Auswahl, Preis, Anfrage, Angebot, Warenkorb, Artikelnummer oder Stückliste verlangen unterschiedliche Regeln und Systemübergaben.
Welche realen Fälle muss der Pilot korrekt lösen?Vor Auswahl klären
Definieren Sie typische Konfiguration, ungültige Kombination, Grenzfall, Preis-/Ausgabeprüfung und Übergabe an den Folgeprozess.
Produktmodell
Merkmale, Abhängigkeiten und Preise
Die Oberfläche zeigt nur einen Ausschnitt des Produktmodells. Wartbare Merkmale, eindeutige Werte, gültige Kombinationen und nachvollziehbare Rechenregeln sind die eigentliche Grundlage des Konfigurators.
Welche Merkmale und Werte bestimmen das Produkt?Vor Auswahl klären
Erfassen Sie Datentyp, Einheit, erlaubte Werte, Pflichtangabe, Mehrfachauswahl und fachliche Bedeutung – nicht nur sichtbare Feldnamen.
Welche Abhängigkeiten, Ausschlüsse und Inklusionen gelten?Vor Auswahl klären
Formulieren Sie Regeln als verständliche Wenn-Dann-Aussagen und benennen Sie die fachliche Quelle. Auch ungültige Kombinationen brauchen eine Begründung.
Welche Voreinstellungen, Mengen und Berechnungen werden benötigt?Vor Auswahl klären
Defaults, Formeln, Einheiten, Rundung, Toleranzen und Mengenabhängigkeiten müssen versionierbar und mit Referenzfällen testbar sein.
Wie entstehen Preis, Zuschläge und Konditionen?Vor Auswahl klären
Klären Sie Listenpreis, Optionszuschlag, Menge, Währung, Kundengruppe, Rabattfreigabe, Steuer und ob der angezeigte Wert verbindlich oder indikativ ist.
Wer pflegt Regeln, Quellen und Gültigkeitszeiträume?Vor Auswahl klären
Produktwissen braucht verantwortliche Rollen, Freigabe, Versionsstand, Rückverfolgbarkeit und einen Weg für neue oder auslaufende Varianten.
Interaktion
Führung, Darstellung und verständliche Fehler
Ein korrekter Regelkern genügt nicht, wenn Nutzer die benötigte Eingabe nicht verstehen. Reihenfolge, Hilfen, Visualisierung und Rückmeldung müssen zur Fachkenntnis der Zielgruppe und zum verwendeten Gerät passen.
Wie soll die Auswahl geführt werden?Vor Auswahl klären
Bedarfsorientierte Beratung, schrittweise Merkmalsauswahl und freie Expertenkonfiguration stellen unterschiedliche Anforderungen an Navigation und Regelauflösung.
Welche Visualisierung ist fachlich erforderlich?Vor Auswahl klären
Keine, Bilder, Ebenen, 2D-Zeichnung oder 3D verändern Asset-Produktion, Regelkopplung, Ladezeit, Pflege und Abnahme erheblich.
Müssen Konfigurationen gespeichert, geteilt oder übersetzt werden?Empfohlen
Benennen Sie Login, Entwurf, Link, Vergleich, Favorit, Wiederaufnahme, Angebotsversion, Sprache, Einheit und Währung.
Wie werden Pflichtangaben und ungültige Kombinationen erklärt?Vor Auswahl klären
Eine blockierte Auswahl sollte Ursache und nächsten möglichen Schritt nennen. Legen Sie fest, ob Regeln Optionen verbergen, deaktivieren, korrigieren oder nur warnen.
Welche Geräte, Eingabemethoden und Zugänglichkeitsanforderungen gelten?Empfohlen
Responsive Nutzung, Tastatur, Fokus, Screenreader, Kontrast, Touch, große Tabellen und gegebenenfalls Offline- oder Vor-Ort-Szenarien gehören in den Scope.
Produktion
Datenquellen, Übergabe und kontrollierter Betrieb
Ein Konfigurator ist selten die alleinige Produktquelle. ERP, PIM, CRM, Shop, CAD oder PLM können Stammdaten, Preise, Kundenkontext und Ergebnis übernehmen. Ohne klare Hoheit entsteht schnell doppelte Pflege.
Welche Systeme führen Produkt, Regeln, Preise und Kundenkontext?Vor Auswahl klären
Ordnen Sie ERP, PIM, CRM, Shop, PLM/CAD und weitere Quellen je Objekt zu. Legen Sie auch fest, wo neue Regeln gepflegt und freigegeben werden.
Welche Daten werden wann in welche Richtung übertragen?Vor Auswahl klären
Benennen Sie IDs, Mapping, Frequenz, Volumen, Trigger, API/Import, Fehlerbehandlung, Wiederholung und Verhalten bei nicht verfügbaren Quellsystemen.
Wer darf Produkte, Regeln, Preise und Veröffentlichungen ändern?Vor Auswahl klären
Pflege, Vier-Augen-Freigabe, Vorschau, Mandanten, kundenspezifische Konditionen, Audit-Historie und technische Administration benötigen getrennte Rechte.
Welche Größenordnung und Reaktionszeit muss der Konfigurator tragen?Empfohlen
Produkte, Merkmale, Regeln, Sprachen, Nutzer, gleichzeitige Sessions, mobile Netze und maximale Rechenzeit sollten mit realen Testdaten beschrieben werden.
Wie werden Regelwerk, Ausgabe, Integration und Einführung abgenommen?Vor Auswahl klären
Referenzkonfigurationen, Regression, Preisvergleich, ungültige Fälle, Performance, Browser, Fachfreigabe, Schulung, Monitoring und Support bilden einen gemeinsamen Go-live-Plan.
Vom Produktwissen zum testbaren Regelvertrag
Der Konfigurator ist nur so belastbar wie sein Produktmodell.
Merkmale und Bilder sind sichtbar, doch Gültigkeit entsteht in Abhängigkeiten, Preisformeln, Systemquellen und Versionen. Der Check behandelt deshalb Konfiguration als fachlichen Vertrag: Welche Eingabe ist erlaubt, welche Regel wird ausgelöst, welches Ergebnis entsteht und welches System übernimmt es danach?
Reale Produkte statt Demo-Spielzeug
Ein Pilot sollte mehrere repräsentative Produkte mit echten Sonderfällen enthalten. Ein künstlich einfacher Beispielartikel sagt wenig darüber aus, ob Regelmodell, Pflege und Performance die tatsächliche Variantenkomplexität tragen.
Wenn–Dann mit fachlicher Quelle
Jede kritische Regel braucht eine verständliche Bedingung, Aktion, Begründung, verantwortliche Rolle und Version. Das erleichtert Prüfung, Änderung und Regression stärker als undokumentierte Formeln in einer einzelnen Datei.
Ausgabe bestimmt den Scope
Eine Produktempfehlung, ein Richtpreis, ein verbindliches Angebot und eine produktionsfähige Stückliste sind nicht dieselbe Leistung. Das gewünschte Ergebnis legt fest, welche Daten und Freigaben belastbar sein müssen.
Goldene Fälle vor Go-live
Freigegebene Referenzkonfigurationen prüfen Regeln, Preise und Ausgaben nach jeder Änderung erneut. Ergänzt um ungültige Kombinationen und Systemausfälle entsteht eine kontrollierbare Abnahme statt bloßer Sichtprüfung.
Die Struktur orientiert sich an dokumentierten CPQ-Grundlagen zu Merkmalen, Pflichtwerten, Regeln, Produktstammdaten und Integrationen. Sie ist herstellerneutral und ersetzt weder Produktexpertise noch die technische Prüfung einer konkreten Plattform.
Neutrale Systementscheidung
Shop-Plugin, Produktkonfigurator, CPQ oder individuelle Anwendung?
Ein Anforderungscheck soll keine bestimmte Plattform vorentscheiden. Ein Shop-Plugin kann für wenige unabhängige Optionen und eine normale Warenkorb-Übergabe genügen. Ein Produktkonfigurator wird relevant, wenn gültige Varianten durch Merkmale und Regeln entstehen. CPQ erweitert den Rahmen um kundenspezifische Preise, Freigaben und Angebotsversionen. Individuelle Entwicklung passt dort, wo Produktmodell, Bedienung oder Systemintegration einen eigenen, geschäftskritischen Ablauf bilden. Entscheidend sind reale Referenzkonfigurationen statt ähnlich klingender Funktionslisten.
Export ohne E-Mail-Gate
Ein Briefing für Produktmodell, Plattformvergleich und Pilot.
Der Export trennt gewünschtes Ergebnis, Regelwerk, Bedienung und Systembetrieb. Offene Pflichtpunkte bleiben sichtbar, damit ein Anbieter nicht still von vorhandenen Produktdaten, pflegbaren Regeln oder problemlosen ERP-Zugängen ausgeht.
- Eigene Angaben in vier fachlichen Bereichen erfassen
- Ungeklärte Voraussetzungen sichtbar behalten
- Fiktives Beispiel als Orientierung laden
- Markdown kopieren oder herunterladen
- Dokument drucken und als PDF speichern
- Mit Fachseite, IT und möglichen Anbietern verifizieren
Nächster sinnvoller Schritt: Drei repräsentative Produkte, zehn gültige und fünf ungültige Konfigurationen auswählen. Für jeden Fall Eingaben, erwartete Regelreaktion, Preis beziehungsweise technische Ausgabe und nachgelagerte Systemübergabe dokumentieren. Erst danach Plugin, CPQ, Plattform und Eigenentwicklung vergleichen.
Struktur des Ergebnisdokuments
- 01 · Nutzer, Kanal und verbindliches Ergebnis
- Arbeitstitel des Konfigurator-Vorhabens · Wer konfiguriert in welchem Kanal? · Welche Produktfamilie bildet der erste Scope ab? · Welches Ergebnis ist nach einer gültigen Konfiguration verbindlich? · Welche realen Fälle muss der Pilot korrekt lösen?
- 02 · Merkmale, Abhängigkeiten und Preise
- Welche Merkmale und Werte bestimmen das Produkt? · Welche Abhängigkeiten, Ausschlüsse und Inklusionen gelten? · Welche Voreinstellungen, Mengen und Berechnungen werden benötigt? · Wie entstehen Preis, Zuschläge und Konditionen? · Wer pflegt Regeln, Quellen und Gültigkeitszeiträume?
- 03 · Führung, Darstellung und verständliche Fehler
- Wie soll die Auswahl geführt werden? · Welche Visualisierung ist fachlich erforderlich? · Müssen Konfigurationen gespeichert, geteilt oder übersetzt werden? · Wie werden Pflichtangaben und ungültige Kombinationen erklärt? · Welche Geräte, Eingabemethoden und Zugänglichkeitsanforderungen gelten?
- 04 · Datenquellen, Übergabe und kontrollierter Betrieb
- Welche Systeme führen Produkt, Regeln, Preise und Kundenkontext? · Welche Daten werden wann in welche Richtung übertragen? · Wer darf Produkte, Regeln, Preise und Veröffentlichungen ändern? · Welche Größenordnung und Reaktionszeit muss der Konfigurator tragen? · Wie werden Regelwerk, Ausgabe, Integration und Einführung abgenommen?
FAQ
Häufige Fragen zum Anforderungscheck
Welche Anforderungen braucht ein Produktkonfigurator?
Mindestens Zielgruppe und Kanal, repräsentative Produktfamilie, gewünschtes Ergebnis, Merkmale und Werte, Abhängigkeiten, Berechnungs- und Preislogik, Pflegeverantwortung, Nutzerführung, Visualisierung, Datenquellen, Integrationen sowie reale Abnahmeszenarien.
Was ist der Unterschied zwischen Produktkonfigurator und CPQ?
Ein Produktkonfigurator führt zu einer gültigen oder passenden Variante. CPQ umfasst darüber hinaus Price und Quote, also beispielsweise kundenbezogene Konditionen, Freigaben, Angebotsversionen und Dokumente. Nicht jeder Self-Service-Konfigurator benötigt den vollständigen CPQ-Umfang.
Braucht ein Produktkonfigurator immer 3D?
Nein. Je nach Erklärungsbedarf reichen Text, Bilder, 2D-Ebenen oder eine technische Zeichnung. 3D ist sinnvoll, wenn räumliche Eigenschaften die Entscheidung wesentlich unterstützen und passende Modelle, Pflegeprozess, Performancebudget und Abnahmeregeln vorhanden sind.
Wie wird ein Konfigurator mit ERP oder PIM verbunden?
Zuerst wird je Datenobjekt das führende System festgelegt. Danach folgen stabile IDs, Mapping, Übertragungsrichtung, Aktualität, Zugänge, Testdaten, Fehlerbehandlung und Monitoring. Eine Vollsynchronisation aller Daten ist selten automatisch der beste Weg.
Wie lassen sich Variantenregeln testen?
Mit freigegebenen Referenzfällen für gültige, ungültige und grenzwertige Kombinationen. Jeder Fall enthält Eingaben, erwartete Regelreaktion und Ausgabe. Diese Tests sollten nach Regel- oder Produktdatenänderungen wiederholbar ausgeführt werden.
Werden Produktdaten oder Regeln an Midnight Motion gesendet?
Nein. Eingaben bleiben im Zustand des geöffneten Browser-Tabs und werden nicht an Midnight Motion übertragen oder dauerhaft im Browser gespeichert. Ein Dokument entsteht nur, wenn Sie den Export bewusst kopieren, herunterladen oder drucken.
Mit realen Regelbeispielen weiterarbeiten
Plugin, CPQ oder individueller Konfigurator?
Nennen Sie Beispielprodukt, schwierigste Variantenregel, gewünschte Ausgabe und vorhandene Systemquellen. Im Projekt-Check ordnen wir den nächsten technischen Prüfpfad ein.
Konfigurator-Vorhaben unverbindlich einordnen →