Produktkonfigurator einführen: Phasen, Zeitplan und Erfolgsfaktoren für B2B-Projekte

Die Einführung eines Produktkonfigurators ist kein klassisches IT-Projekt. Sie verändert:

Vertriebsprozesse,
Produktlogik,
Angebotsabläufe,
Datenstrukturen,
und häufig sogar die Rollen im Unternehmen.

Genau deshalb scheitern viele Projekte nicht an der Software, sondern an:

fehlender Vorbereitung,
schlechter Datenqualität,
unrealistischen Zeitplänen,
oder mangelndem Change Management.

Wer einen realistischen Überblick über Grundlagen, Technologien und Einsatzbereiche sucht, findet diesen im
B2B-Produktkonfigurator Leitfaden.

Bevor das Projekt startet:
Die drei häufigsten Fehler vor Phase 1

Viele Probleme entstehen lange vor dem eigentlichen Projektstart.

PIM-Datenbasis unterschätzt

Ein Produktkonfigurator macht schlechte Daten nicht besser.

Typische Probleme:

inkonsistente Variantenlogik,
doppelte Produktdaten,
fehlende technische Attribute,
widersprüchliche Preisregeln.

Gerade im Mittelstand wird häufig unterschätzt, wie stark der Projekterfolg von der Datenqualität abhängt.

In vielen Projekten wird die PIM- und Stammdatenarbeit zum eigentlichen Gating-Faktor.

Vertriebs- und Anwendungstechnik nicht eingebunden

Viele Konfigurator-Projekte werden zu stark:

von IT,
oder ausschließlich vom Management

getrieben.

Die eigentlichen Wissensinhaber sitzen jedoch oft:

im Vertrieb,
in der Anwendungstechnik,
oder im Produktmanagement.

Wenn diese Stakeholder nicht früh eingebunden werden, fehlen später:

Sonderregeln,
Ausnahmen,
Angebotslogik,
oder Freigabeprozesse.

Vendor-Entscheidung vor Anforderungsklärung

Einer der häufigsten Fehler: Zuerst Software auswählen, danach Anforderungen definieren.

Das führt oft zu:

Vendor-Lock-in,
unnötiger Komplexität,
oder überdimensionierten Lösungen.

Die Auswahl der richtigen Plattform sollte erst erfolgen, wenn:

Variantenlogik,
Integrationsanforderungen,
und Zielprozesse

klar definiert sind.

Einen Marktüberblick bietet der Artikel
die richtige Konfigurator-Software auswählen.

Phase 1 – Anforderungsklärung und Use Case Definition (4–6 Wochen)

Die wichtigste Projektphase ist häufig die erste.

Hier entscheidet sich, ob der Konfigurator später:

Akzeptanz findet,
skalierbar bleibt,
und wirtschaftlich funktioniert.

Variantenmodell-Workshop mit Produktmanagement

In dieser Phase wird geklärt:

Welche Varianten existieren?
Welche Regeln gelten?
Welche Kombinationen sind ausgeschlossen?
Welche Parameter beeinflussen Preis und Fertigung?

Gerade im Maschinenbau entstehen hier oft:

100+ Konfigurationsparameter,
technische Abhängigkeiten,
oder komplexe Ausschlussmatrizen.

Vertriebsprozess-Mapping (Wo greift der Konfigurator ein?)

Der Konfigurator muss in reale Prozesse passen.

Typische Fragen:

Wird direkt bestellt oder zuerst angeboten?
Welche Genehmigungen existieren?
Wann greift der Außendienst ein?
Welche Rolle spielt der Händler?

Viele Projekte scheitern, weil der Konfigurator isoliert gedacht wird, statt als Teil des Vertriebsprozesses.

Make-or-Buy-Entscheidung (Enterprise / SaaS / Headless)

Jetzt wird entschieden:

SaaS,
Enterprise-CPQ,
oder Headless-/Custom-Ansatz?

Die Entscheidung hängt ab von:

Variantenkomplexität,
Teamgröße,
Integrationsbedarf,
und gewünschter UX-Differenzierung.

Phase 2 – Vendor-Auswahl und Pilot-Modellierung (6–10 Wochen)

Erst jetzt beginnt die eigentliche Software-Auswahl.

RFP-Erstellung mit Variantenmuster

Ein gutes Lastenheft enthält:

reale Produktvarianten,
konkrete Regelwerke,
echte Preislogik,
und Integrationsanforderungen.

Vendor-Demos mit simplen Beispielprodukten sind wenig aussagekräftig.

Proof-of-Concept mit drei realen Produkten — Pflicht, nicht Kür

Ein Pilotprojekt ist nicht optional.

Mindestens drei reale Produkte sollten:

vollständig modelliert,
konfiguriert,
und integriert werden.

Nur so zeigt sich:

ob die Regelengine skaliert,
ob Preislogik funktioniert,
und wie performant das System wirklich ist.

In DACH-Projekten kommt es laut Branchenerfahrung bei etwa 15 % der Projekte nach dem Pilot noch zum Vendor-Wechsel.

Phase 3 – Vollständige Modellierung und Integration (3–6 Monate)

Jetzt beginnt die eigentliche Umsetzung.

Datenmodell und Regelwerk in der Engine abbilden

Diese Phase umfasst:

Variantenlogik,
Preisregeln,
Ausschlusslogik,
Stücklisten,
und technische Validierung.

Gerade komplexe Industrieprodukte benötigen oft:

mehrere hundert Regeln,
dynamische Abhängigkeiten,
oder modulare Konfigurationslogik.

Integrationen: PIM, ERP, Shop, ggf. CAD und Eplan

Typische Integrationen:

ERP,
PIM,
Shop-System,
CRM,
CAD,
Eplan,
oder Middleware-Layer.

Der Integrationsaufwand macht häufig: 30–80 % des Gesamtbudgets aus.

3D-Visualisierung und Asset-Pipeline aufbauen

Wenn 3D eingesetzt wird, müssen zusätzlich:

Assets erstellt,
Varianten visualisiert,
und Rendering-Prozesse definiert werden.

Mehr dazu im Artikel
3D-Konfigurator mit ERP verbinden.

Phase 4 – Test, Schulung und Pilot-Rollout (4–8 Wochen)

Viele Projekte unterschätzen diese Phase massiv.

Vertriebs- und Händlerschulung als Erfolgsfaktor

Der beste Konfigurator scheitert, wenn Vertrieb oder Händler ihn nicht akzeptieren.

Deshalb sind wichtig:

Schulungen,
Guidelines,
Pilotgruppen,
und klare Prozesse.

Pilot mit zwei bis drei Power-Usern, dann Skalierung

Ein schrittweiser Rollout reduziert Risiko.

Typischer Ablauf:

Pilotgruppe
Feedback-Schleifen
Optimierung
Skalierung auf weitere Teams/Händler

Change Management – der unterschätzte Erfolgsfaktor

Technik ist selten das größte Problem. Menschen sind es häufiger.

Vertriebsmitarbeiter haben Sorge vor „Wegrationalisierung“

Viele Vertriebsteams befürchten:

Kontrollverlust,
Preistransparenz,
oder sinkende Relevanz.

Erfolgreiche Projekte positionieren den Konfigurator deshalb als: Unterstützung, nicht als Ersatz.

Anwendungstechnik fürchtet Kontrollverlust über die Regeln

Anwendungstechniker besitzen oft:

Sonderwissen,
Variantenlogik,
und Erfahrungswerte.

Wenn dieses Wissen „in Software gegossen“ wird, entsteht häufig Widerstand.

Ownership und Governance müssen deshalb früh geklärt werden.

Kommunikation und Ownership der Konfigurator-Pflege klären

Die wichtigste Frage nach Go-Live lautet: Wer pflegt den Konfigurator?

Typische Owner:

Produktmanagement,
Anwendungstechnik,
oder Digital Commerce Teams.

Ohne klaren Verantwortlichen veraltet die Logik schnell.

Realistische Gesamtdauer und typische Meilensteine

Viele Anbieter versprechen: „Go-Live in 3 Monaten.“

Für komplexe B2B-Projekte ist das unrealistisch.

Realistische Dauer:

9–15 Monate bis produktiver Pilot,
bei Enterprise-Projekten teilweise länger.

Typische Meilensteine:

Workshop & Use Cases
Pilotmodellierung
Integrationskonzept
ERP-/PIM-Anbindung
Testphase
Pilot-Rollout
Skalierung

Studien zeigen: Rund 60 % aller CPQ-/Konfigurator-Projekte überschreiten ursprünglich geplante Zeitrahmen um mehr als 20 %.

Deshalb ist eine realistische Budget- und Zeitplanung entscheidend.

Mehr dazu im Artikel
Kosten und ROI der Konfigurator-Einführung.

Fazit

Ein Produktkonfigurator-Projekt ist:

Datenprojekt,
Vertriebsprojekt,
Architekturprojekt,
und Change-Projekt zugleich.

Die größten Erfolgsfaktoren sind:

saubere Stammdaten,
realistische Zeitplanung,
frühe Stakeholder-Einbindung,
und ein belastbarer Pilot mit echten Produkten.

Nicht die Demo entscheidet über den Projekterfolg, sondern die Fähigkeit, reale Variantenlogik in reale Prozesse zu integrieren.

Sie planen die Einführung eines Produktkonfigurators und wollen vom ersten Workshop bis zum Pilot-Rollout einen erfahrenen Partner an Ihrer Seite? Unit M begleitet B2B-Konfigurator-Projekte seit über 20 Jahren — anbieterunabhängig, ergebnisorientiert.

Projektkurzcheck anfragen

FAQ

Wie lange dauert die Einführung eines Produktkonfigurators?

Für mittelständische B2B-Unternehmen typischerweise 9–15 Monate bis zum produktiven Pilot.

Warum scheitern viele Konfigurator-Projekte?

Häufige Ursachen sind schlechte Stammdaten, fehlendes Change Management und unrealistische Zeitpläne.

Welche Rolle spielt ein PIM-System?

Ein PIM liefert strukturierte Produktdaten und ist oft Voraussetzung für einen skalierbaren Konfigurator.

Warum ist ein Proof-of-Concept wichtig?

Nur ein Pilot mit realen Produkten zeigt, ob Regelwerk, Integrationen und Performance wirklich funktionieren.

Welche Abteilungen müssen eingebunden werden?

Typischerweise Vertrieb, Produktmanagement, Anwendungstechnik, IT und ERP-Verantwortliche.

Wann sollte die Software ausgewählt werden?

Erst nach der Anforderungsklärung und Definition der Zielprozesse.

Wie wichtig ist Change Management?

Sehr wichtig. Widerstände im Vertrieb oder in der Anwendungstechnik sind häufige Projektrisiken.

Wer pflegt den Konfigurator nach Go-Live?

Idealerweise ein klar definiertes Team aus Produktmanagement oder Anwendungstechnik mit festen Verantwortlichkeiten.