60% benutzerdefinierte Konfiguratoren ohne Domänenkenntnisse enden in einem Fehlschlag. 95 % der CPQ-Systeme sind für RevOps-Administratoren konzipiert, während 95 % der echten Benutzer Verkäufer sind. Laut Standish CHAOS Report sind nur 31 % der IT-Projekte erfolgreich – 19 % sind Totalfehlschläge.
Wenn Sie seit mehreren Monaten mit Softwarehäusern sprechen oder bereits einen Konfigurator implementiert haben, der nicht funktioniert, ist dieser Artikel genau das Richtige für Sie. Fünf Dinge, die Konfiguratorprojekte zum Scheitern bringen, mit Branchendaten und realen Beispielen aus unseren Implementierungen. Und konkrete Empfehlungen, wie man sie vermeidet.
60% Probleme sind Prozesse, nicht TechnoProtokollee. Ihr Konfigurator wird nicht wegen des Codes abstürzen. Er wird abstürzen wegen dessen, was um ihn herum passiert.
|
Hast du bereits einen Konfigurator, der nicht funktioniert? Audit 1-2 Tage, kostenlos. Wir sagen Ihnen direkt, ob es zu retten ist. |
Auditorik bestellen |
Zu lang; nicht gelesen · 30 SEKUNDENEN
- Die 5 häufigsten ImplementierungsProbleme: 1) Preisregeln leben im Kopf des Verkäufers, nicht im System; 2) Scope Creep („mehr hinzufügen…“); 3) Integration mit ERP, das sich an 2011 erinnert; 4) Verkäufer nutzen es nicht, sie greifen zurück zu Excel; 5) Keine Wartungsplanenung, der Konfigurator lebt 12 Monate und lügt.
- 60 % der Probleme sind Prozesse, nicht TechnoProtokollee. Der häufigste Fehler ist nicht der Kodex, sondern das Fehlen eines Eigentümers von Preisregeln im Unternehmen und das Fehlen eines Einführungsplanens bei den Vertriebsmitarbeitern.
- Regel Nr. 1: Führen Sie vor der Umsetzung einen Workshop mit Verkäufern durch und klären Sie alle Preisregeln, Varianten, Rabatte und Ausnahmen aus dem Kopf. Ohne dies ist der Konfigurator eine „Attrappe für 60.000“.
- Regel Nr. 2: Planen Sie Ihre Wartung, BEVOR Sie den Vertrag unterzeichnen. Ein Konfigurator ohne Eigentümer auf Kundenseite stirbt innerhalb von 12 Monaten und beginnt, über neue Produkte zu lügen.
Implementierung des Produktkonfigurators ist ein Prozess, der Folgendes umfasst: Erstgespräch (Workshop mit Vertriebsmitarbeitern und Produktmanagern, Zuordnung von Preisregeln), Spezifikation (Dokument mit allen Varianten, Integrationen, Randfällen), Entwicklung (8–12 Wochen für MVP), Integration mit ERP/CRM/PIM, Tests (UAT mit echten Vertriebsmitarbeitern und Kunden), Rollout (Teamschulung) und Wartung (wer neue Produkte hinzufügt, Preise aktualisiert, Fehler behebt).
Warum bleiben Preisregeln im Kopf des Verkäufers und nicht im System?
Prüfe, ob der Konfigurator bei dir Sinn ergibt
Umfrage 15 Fragen (3 Min.). Nach dem Ausfüllen wissen wir beide, ob es Gesprächsstoff gibt.
Checkliste ausfüllen →Problem 1 · Der häufigste Grund für Verzögerungen
Preisliste im PDF, Ausschlussregeln im Kopf des Designers, 15 Jahre Vertriebserfahrung, nirgendwo niedergeschrieben. Das Softwarehaus erhält unvollständige Regeln, codiert, was es hat, und Tests machen das Projekt zunichte.
Das ist der häufigste Grund, warum Konfiguratorprojekte monatelang ohne sichtbare Fortschritte dahindümpeln. Ein Unternehmen wendet sich an ein Softwarehaus, sagt: „Wir haben eine Preisliste, wir haben Varianten, wir wollen das Automatisieren”. Beim ersten Treffen stellt sich heraus, dass die Preisliste 136 Seiten PDF (realer Fall aus unserer Implementierung für Akpil), Varianten sind 16 Basisversionen mal 30+ zusätzliche Optionen, und die Ausschlussregeln („Reifenwalze erfordert Transportdeichsel, aber Transportdeichsel ist inkompatibel mit Hydrauliksystem X”) leben im Kopf des Konstrukteurs, der seit 15 Jahren im Unternehmen arbeitet.
Forschung Kickflip auf der Entwicklung eines kundenspezifischen Konfigurators zeigen: Implementierungen ohne Fachkenntnisse haben eine%höhere Ausfallrate. Warum? Denn ein Ingenieur, der noch nie einen Grubber-Sähkombinator verkauft hat, ahnt nicht, dass das GPS einen Industrie-PC erfordert und hydraulische Markierungen nicht mit einer Maschine unter 3 Metern Breite kompatibel sind.
Was geschieht im Projekt: Ein Softwarehaus erhält unvollständige Regeln. Es Codeiert, was es erhalten hat. In der Testphase stellt sich heraus, dass das System die Konfiguration einer Maschine ermöglicht, die nicht produziert werden kann. Umschreiben der Regeln = weitere 2-4 Wochen. Scope Creep ist fertig.
Inzwischen erhält der Projektleiter auf Kundenseite einen Anruf vom CTO: „Wann wird das fertig sein?”. Die Antwort lautet: „wenn wir die vollständigen Regeln vom Händler erhalten”. Zwei Wochen später dieselbe Frage, dieselbe Antwort. Einen Monat später derselbe Dialog, aber bereits mit einem Anflug von Frustration.
Wie kann man das vermeiden
Wöchentliches Einführungsgespräch VOR der ersten Codezeile. Für unsere Kunden beginnen wir mit 5-7 Tagen Sitzungen mit Verkäufern und Designern. Wir bilden nicht das Produkt, sondern den Kundenpfad ab: wie der Kunde fragt, was er am häufigsten fragt, wie der Verkäufer die Preise setzt, welche Abhängigkeiten Automatisch aktiviert werden. Das Ausgabedokument besteht aus 15–40 Seiten mit Regeln in einer Geschäftssprache (kein Code), der Kunde liest und korrigiert es selbst. Erst nach der Annahme des Dokuments berühren wir die Tastatur.
Problem 2: Scope Creep: „und hinzufügen…“
PROBLEM 2 · „FEW MONTHS” → 12–24 Monate
Der Vorstand sieht einen funktionierenden Konfigurator und will mehr: ein Händlerpanel, CRM, eine mobile App. Jedes „noch eins” bedeutet eine neue Kostenschätzung und einen neuen Zeitplanen. Ein Projekt für 60.000/10 Wochen endet nach 9 Monaten für 180.000.
Ihr Konfigurator funktioniert. Nach drei Wochen präsentieren Sie ihn dem Management. Das Management sagt: „Super, aber vielleicht fügen wir ein Händler-Panel hinzu? Und wenn wir schon dabei sind, dann ein CRM-Modul. Und die Integration mit der Buchhaltung? Und noch eine mobile App, denn die Verkäufer fahren ja zu den Kunden.”.
Herzlichen Glückwunsch, Sie haben das Projekt gerade verdoppelt.
Recherche Kickflip zeigt ein typisches Szenario: Der Mitbegründer geht von „ein paar Monaten Entwicklungszeit“ aus, reale Umsetzungen erstrecken sich auf 12–24 Monate. Nicht, weil das Team es nicht kann. Sondern weil Scope Creep real und fast unvermeidlich ist.
Was geschieht im Projekt: Jedes „Fügen wir hinzu“ ist eine neue Bewertung, ein neuer Begriff, eine neue Validierung der Regeln. Das Projekt, das 60.000 PLN kosten und in 10 Wochen abgeschlossen sein sollte, endet nach 9 Monaten für 180.000 PLN, und niemand kann sich erinnern, wer darüber entschieden hat.
Die schlimmsten Fälle, die wir gesehen haben: Ein Unternehmen wählte einen billigeren Anbieter, der Scope lief aus dem Ruder, der Anbieter stieg mitten im Projekt aus. Der Kunde rief uns nach zwei Monaten Funkstille von der vorherigen Mannschaft an. Das System funktionierte teilweise, die Vertriebsmitarbeiter waren längst wieder zu Excel zurückgekehrt, die Geschäftsleitung wollte den Kopf des IT-Direktors, der diesen Anbieter empfohlen hatte. Die Kosten für die Reparatur? Üblicherweise das Zwei- bis Dreifache des ursprünglichen Budgets, Plus Monate verschwendeter Zeit auf dem umkämpften Markt.
Wie kann man das vermeiden
Festpreis für MVP, Time & Materials erst in Phase 2. Der MVP-Umfang ist in dem Vertrag festgehalten, bevor die erste Codezeile geschrieben wird. Alles außerhalb dieses Umfangs ist ein „Change Request” mit einer separaten Kalkulation. Klingt das starr? Genau darum geht es.
MVP sollte minimal und bereit zur Produktion, nicht „Teil der Lösung, die wir später hinzufügen werden.“ Sie haben die Richtung bestätigt, erst dann investieren Sie in die Expansion. Es funktioniert nicht wie es sollte, man macht Phase 2 nicht.
Problem 3: Integration mit einem ERP aus dem Jahr 2011
PROBLEM 3 · JEDNY PUNKT INTEGRACJI = TRYB AWARYJNY
Altes SAP oder Comarch aus 2011 hat keine API. Der Entwickler, der es konfiguriert hat, ist vor 5 Jahren gegangen. Der Konfigurator zeigt alte Preise, der Handelsvertreter verkauft unter Preisliste.
Ihr Konfigurator muss mit dem ERP-System kommunizieren, denn dort befinden sich die Preislisten, Lagerbestände und Kundendaten. Problem: Ihr ERP ist Comarch XL in der Version von 2011 oder SAP mit Anpassungen, die ein Entwickler vorgenommen hat, der vor fünf Jahren gegangen ist. Es gibt keine API. Es gibt keine Dokumentation. Die einzige Person, die das DatenModellll versteht, ist die Buchhalterin, die in einem halben Jahr in Rente geht.
Recherchieren Sie DigiCommerce na eine B2B-Konfigurator-Implementierung identifiziert: Jeder Integrationspunkt ist ein potenzielles Fehlerprofil, was die gesamte UX ruinieren wird. In der Praxis bedeutet dies, dass eine fehlerhafte Preislistensynchronisierung zwischen ERP und Konfigurator dem Kunden den falschen Preis anzeigt, und das ist keine Hypothese. Wir haben ein Projekt gesehen, bei dem ein Verkäufer eine Maschine 15 % unter dem tatsächlichen Listenpreis verkauft hat, weil im Konfigurator die alte Version vom März angezeigt wurde.
Wie kann man das vermeiden
ERP-Audit vor der Implementierung. In der ersten Diskussionswoche geht es nicht darum, „wie der Konfigurator aussehen soll“, sondern „wie Ihr ERP aussieht, wo die Preisliste liegt, wer sie aktualisiert, welche Felder die Quelle der Wahrheit sind“. Wenn das ERP über eine API verfügt, synchronisieren wir in Echtzeit. Wenn nicht, schreiben wir maßgeschneiderte Middleware.
Alternativ: Wir bauen Konfiguratoren mit nativer Integration in JSON-Hub, unsere Plattform, die drei Tools (CRM + Angebotserstellung + Händlerpanel) durch eines ersetzt. Dann reduziert sich das Problem der ERP-Integration auf einen Konnektor und nicht auf fünf.
Problem 4: Salespeople do not use it. They go back to Excel.
PROBLEM 4 · 95% VERWENDUNG = WIEDERHOLUNGEN, DESIGN = ADMINISTRATOREN
Sie haben 80-150.000 ausgegeben, das System funktioniert wunderbar. Nach 3 Monaten rechnen Verkäufer immer noch in Excel. Für RevOps entwickeltes System, das von Vertriebsmitarbeitern verwendet wird, grundlegende Fehlausrichtung.
Das ist der schlimmste Fall. Sie haben 80.000-150.000 PLN ausgegeben, der Konfigurator funktioniert, die Benutzeroberfläche sieht schön aus. Drei Monate nach dem Start stellt sich heraus, dass die Verkäufer immer noch Angebote in Excel kalkulieren. Warum?
Anbieter in der Analyse „Why CPQ implementations fail” zeigt ein KernProblem an: „CPQ ist für RevOps-Administratoren konzipiert, aber 95% der täglichen Nutzung stammt von Vertriebsmitarbeitern”. Das für den Vertriebsleiter (der Margen und Berichte kontrollieren möchte) entwickelte System wird vom Verkäufer (der dem Kunden schnell ein Angebot senden möchte) genutzt. Grundlegende Fehlausrichtung.
Ein Verkäufer, der Excel seit 8 Jahren verwendet, hat alles aufgeschrieben: seine Tastenkombinationen, seine Makros, seine Art, den Kunden zu bewerten. Der Konfigurator erfordert ein erneutes Einlernen, aber Excel funktioniert. In meinem Kopf: „Dies ist ein IT-Tool, nicht mein Verkaufstool”. Wenn niemand aus der Geschäftsleitung erklärt, warum wir umziehen und nicht zeigt, „was für mich drin ist“, wird der Verkäufer es ignorieren.
Wie kann man das vermeiden
Kaufleute im Projektteam vom ersten Tag an. Nicht am Ende. Vom ersten Interview selbst. Zwei oder drei Verkäufer setzen sich zu uns und erzählen uns, was sie am aktuellen Prozess nervt. Dann schauen sie sich bei jedem Sprint den Prototypen an und kommentieren ihn.
Anreizabstimmung Wenn der Konfigurator die Angebotszeit von 3 Stunden auf 15 Minuten verkürzt, zeigen Sie dem Verkäufer, dass er statt 2 Angeboten pro Tag 8 verschicken kann und seine Provision sich nach der Anzahl der abgeschlossenen Angebote richtet. Dann ist es sein Werkzeug, nicht ES.
Problem 5: Niemand hat die Wartung geplanent. Der Konfigurator ist 12 Monate haltbar und lügt.
PROBLEM 5 · „WIR BAUEN UND FERTIG”
Kein Wartungsplanen = nach 12-18 Monaten zeigt der Konfigurator alte Preise, fehlende Varianten, kaputte Integrationen. Der Vertriebsmitarbeiter verliert das Vertrauen. Er kehrt zu Excel zurück.
Der Mitgründer unterzeichnet einen Implementierungsvertrag. Der Konfigurator geht in Produktion. Annahme im Hinterkopf: „Wir werden es bauen und fertig, jetzt wird es funktionieren”. Einen Monat später fügen Sie eine neue Produktvariante hinzu, der Konfigurator weiß es nicht. Ein Viertel später aktualisieren Sie die Preisliste, der Konfigurator zeigt die alten Preise. Ein halbes Jahr später funktioniert die Integration mit der API des Lieferanten nicht mehr, weil der Lieferant den Endpunkt geändert hat.
Recherche Kickflip: „Jede Stunde, die Sie mit der Wartung von benutzerdefiniertem Konfiguratorcode verbringen, ist eine Stunde, die Sie nicht für Wachstumsinitiativen aufwenden.”. Dies gilt jedoch nur, wenn Sie KEINEN Wartungsplanen haben. Wenn Sie eines haben, sind die Wartungskosten wie bei einem CRM-Abonnement vorhersehbar.
Typisches Muster: Ein Konfigurator funktioniert die ersten 6 Monate super. Dann erweitert das Unternehmen sein Angebot, Preise ändern sich, Integrationen verrosten. Ohne Wartung hat man nach 12-18 Monaten ein System, das lügt, zeigt alte Preise, fehlende Varianten, defekte Optionen. Der Händler vertraut ihm nicht mehr. Es geht zurück zu Excel (siehe Problem 4).
Reales Beispiel: Ein Kunde kam 18 Monate nach dem Launch mit einer Frage zurück „Der Konfigurator zeigt alte Preise, die Verkäufer nutzen ihn nicht, was nun?”. Die Prüfung ergab, dass die Preisliste nicht mit den neuen Produkten synchronisiert war, die im Laufe des Jahres hinzugefügt wurden, und der Ansprechpartner auf Kundenseite schied drei Monate nach dem Start aus, ohne dass jemand die Koordination übernommen hatte. Die Kosten für die Korrektur: zwei Monate Arbeit + die Überarbeitung der Preisliste, die niemand mehr im Unternehmen auswendig kannte.
Wie kann man das vermeiden
Wartungsplanen VOR Unterzeichnung des Implementierungsvertrags. Nie po premierze. Nie „wenn będzie potrzeba”. Vor. Typowy roczny koszt: ~20% Projektwerte.
Hierfür brauchst du Besitzer auf Kundenseite, eine Person, die Feedback sammelt. Ohne diese erhält der Lieferant 15 E-Mails mit „Hier funktioniert etwas nicht“ von 15 verschiedenen Verkäufern. Einzelheiten zu den Lebenshaltungskosten finden Sie im Artikel über nach Konfigurator.
Wie vermeidet man Fehler bei der Implementierung des Konfigurators? 5 Kontrollpunkte
Bevor Sie einen Vertrag mit einem Softwarehaus unterzeichnen, überprüfen Sie diese fünf Dinge:
| Kontrollpunkt | Rote Fahne, wenn... | |
| 1 | Dokument der Bewertungsvorschriften | SH sagt „Wir legen das später fest” |
| 2 | Festpreis + klarer Umfang in der Vereinbarung | Umfang im „orientierenden” Dokument” |
| 3 | ERP-Audit in der ersten Woche | SH geht davon aus: „Wir werden die Integration bewältigen” |
| 4 | Handelsvertreter im Team seit dem 1. | SH möchte nur mit IT sprechen |
| 5 | Wartungsplanen in Hauptvertrag | Vertrag nach dem Start„ |
Wenn sich ein Softwarehaus auf einen dieser Punkte verlässt, ist das ein Warnzeichen. Ein guter Partner hat keine Angst vor Transparenz in diesen fünf Bereichen, denn er weiß, dass sie über den Erfolg entscheiden und nicht der TechnoProtokollee-Stack.
Wie machen wir das bei der JSON Crew
Unser Implementierungsprozess für den Konfigurator basiert vom ersten Tag an auf diesen fünf Kontrollpunkts.
- Woche 0-1 (Einführungsgespräch): Wir sitzen mit Verkäufern und Ingenieuren zusammen, erarbeiten Preisregeln, prüfen das ERP-System, bilden den Kundenpfad ab. Ergebnis: Ein 15-40 Seiten umfassendes Dokument mit Geschäftsregeln, das der Kunde vor der Kodierung abzeichnet.
- Woche 1-6 (Aufbau): zweiwöchige Sprints. Nach jedem Sprint schaut sich der Vertriebsbotschafter den Prototypen an und kommentiert ihn. Der Umfang ist ein Festpreis. Jede Änderung außerhalb des Umfangs ist eine separate Änderungsanforderung.
- Woche 6-10 (Implementierung + Tests): Konfigurator auf der Seite, wir testen mit den Händlern des Kunden an realen Konfigurationen. Hier kommen Dinge zum Vorschein, die im Dokument anders aussahen als in der Realität.
- Nach dem Start Wartungspaket mit Jahresplanen. Der Owner auf Kundenseite sammelt Feedback, wir liefern alle 2-4 Wochen ein Release.
Portfolio: Akpil (Landmaschinen, 57 Typen, Hunderte von Parametern), Sumpf (Jagdwaffe, Konfiguration von Modelll + Schaft + Kaliber + Zubehör) Plus ein Projekt aus der Baubranche. Zehn Produktionsfirmen nutzen unsere Plattform JSON-Hub, das Konfigurator, CRM und Angebotserstellung an einem Ort vereint, ohne das Problem der Integration mit ERP.
Die am häufigsten gestellten Fragen
„Wir haben bereits einen Konfigurator, der nicht funktioniert. Was nun?”
Audit des bestehenden Konfigurators – 1-2 Tage, kostenlos. Wir prüfen: Welche Regeln stehen im Code, was im Kopf des Verkäufers, was Verkäufer tatsächlich nutzen, wo es Integrationen gibt, was kaputt ist, was gerettet werden kann. Ergebnis: ein Bericht mit einer Empfehlung, entweder „Wir sparen für X“ oder „Es ist besser, es zu pflügen, deshalb“. Wir verkaufen die Immobilie nicht, wenn eine Rettung realistischerweise nicht möglich ist.
„Wir haben es implementiert, aber die Verkäufer benutzen es nicht. Lässt sich das beheben?”
Ja, aber wir fangen mit Problem Nr. 4 an, nicht mit TechnoProtokollee. Zwei bis drei Workshops mit den Vertriebsmitarbeitern, um zu verstehen, warum sie es nicht nutzen. Normalerweise ist es eines von drei Dingen: Eine Benutzeroberfläche, die für Administratoren entwickelt wurde, mangelnde interne Kommunikation über den Wert oder fehlende Anreizangleichung. Jedes erfordert eine andere Lösung.
„Führt JSON Crew Projekte durch, die einen ERP-Austausch erfordern?”
Wir machen kein ERP, arbeiten aber mit Partnern in diesem Bereich zusammen. Sollte Ihr ERP ein Hindernis für die Implementierung des Konfigurators sein, empfehlen wir Ihnen einen Partner und implementieren den Konfigurator parallel zur ERP-Migration. Es ist teuer, aber manchmal der einzig sinnvolle Weg.
Was tun, wenn Sie erwägen zu implementieren
|
Ein diagnostisches Gespräch vereinbaren 30 Minuten, kostenlos. Kommen Sie mit zwei Antworten: 1. Wo lebt Ihre Preisliste (PDF, Excel, ERP, Kopf des Vertriebsmitarbeiters)? 2. Wie viele Angebote legen Ihre Verkäufer monatlich vor und mit welchem Werkzeug? |
Füllen Sie das Formular aus |
Auf dieser Grundlage werden wir sagen: Welches der fünf Probleme Sie getroffen haben (oder treffen werden), welche Softwarefirma es wert ist, nach Details zu fragen, und von welcher Sie fliehen sollten.
PS. Die häufigste Reaktion nach der Prüfung eines bestehenden Konfigurators lautet: „Ich dachte, das Problem liegt im Code, aber es stellt sich heraus, dass es im Prozess liegt.” Immer. Deshalb 60% Probleme sind Prozesse, nicht TechnoProtokollee. Eine gute Nachricht: Prozesse lassen sich schneller und kostengünstiger beheben, als das System von Grund auf neu zu schreiben.
Häufig gestellte Fragen
Was sind die häufigsten Probleme bei der Implementierung des Konfigurators?
Die fünf häufigsten: 1) Preisregeln leben im Kopf des Verkäufers, nicht im System (der Verkäufer weiß, dass Kunde X einen Rabatt von 5 % erhält, „weil er ein strategischer Kunde ist“, das System jedoch nicht); 2) Scope Creep („Variante Y hinzufügen“) verlängert das Projekt von 8 auf 18 Wochen; 3) Integration mit ERP aus dem Jahr 2011, Fehlen moderner APIs; 4) Verkäufer nutzen den Konfigurator nicht, sie kehren zu Excel zurück; 5) Kein Wartungsplanen, der Konfigurator stirbt innerhalb von 12 Monaten.
Warum schlägt die Implementierung des Konfigurators fehl?
Am häufigsten aus nichttechnischen Gründen. 60 % der Probleme sind Prozesse: kein Eigentümer von Preisregeln auf Kundenseite, kein Engagement des Top-Managements, kein Einführungsplanen bei den Vertriebsmitarbeitern (Schulung, Anreize zur Nutzung). Nur ca. 40 % entfallen auf TechnoProtokollee, ERP-Integration, 3D-Leistung und Randfälle in Regeln. Rotes Signal: Wenn der Kunde im ersten Gespräch keinen Verantwortlichen für den Konfigurator auf Unternehmensseite nennen kann, ist das Projekt nach dem Start zum Scheitern verurteilt.
Wie vermeidet man Fehler bei der Implementierung des Konfigurators?
Fünf Kontrollpunkts vor dem Start: 1) Workshop mit 3-5 Verkäufern und Aufschreiben aller Preisregeln (sollte 2-3 Tage dauern); 2) Benennung einer für den Konfigurator verantwortlichen Person auf Kundenseite (Product Owner, nicht IT); 3) geschlossener Geltungsbereich in der Spezifikation, neue Anforderungen = formelle Vertragsänderung, nicht „Oh, füge mehr hinzu“; 4) Einführungsplanen für Verkäufer (Schulung + Nutzungs-KPIs in den ersten 90 Tagen); 5) Wartungsplanen (wer fügt Produkte hinzu, wer behebt Fehler, wie viele Stunden/Monatsbudget).
Wie lange dauert die Implementierung des Konfigurators?
MVP-Brauch-Konfigurator in JSON Crew: 8 Wochen von der Vertragsunterzeichnung bis zur Produktion. Erste funktionsfähige Version nach 3 Wochen (40 % Funktionalität). Ready CPQ SaaS (TaCTOn, Konfigurieren Sie eins): 8–16 Wochen Implementierung (die Konfiguration selbst ist schneller, aber Integrationen mit ERP/PIM nehmen die gleiche Zeit in Anspruch). Vorlage (WP-Plugin): 1-3 Wochen. Die Hauptursache für Verzögerungen ist nicht die Entwicklung, sondern die Bereitstellung von Daten durch den Kunden (Stückliste, Preisliste, Ausnahmen) und interne Entscheidungen.
Wer sollte im Konfigurator-Implementierungsteam sein?
Auf Kundenseite: 1 Product Owner (Produktentscheidungen, Datenbereitstellung, Genehmigung von Meilensteinen), 1 IT-Mitarbeiter für ERP/CRM-Integration, 2-3 Verkäufer für Werkstatt und UAT, 1 Vorstandsmitglied als Sponsor (strategische Entscheidungen, Lösung von Blockaden). Auf Lieferantenseite (z. B. JSON Crew): technischer Leiter, Frontend-Entwickler (Three.js für 3D), Backend-Entwickler (Integrationen), Qualitätssicherung. Ohne einen Product Owner auf Kundenseite gerät das Projekt ins Stocken und es gibt keine Entscheidung.
Was tun, wenn das Team den Konfigurator nach der Implementierung nicht nutzt?
Drei Interventionen. Erstens: Wenden Sie sich an die Vertriebsmitarbeiter und fragen Sie sie direkt, warum sie zu Excel zurückkehren, in der Regel ein bestimmter Fehler („legt keinen Wert auf einen strategischen Kundenrabatt“) oder UX („zu viele Klicks für ein einfaches Angebot“). Zweitens: Fügen Sie den KPI der Verwendung des Konfigurators zur Quartiermeisterbewertung des Verkäufers hinzu (% der Bewertungen über den Konfigurator vs. Excel). Drittens: Wenn das Problem systemisch ist und der Konfigurator tatsächlich keine Fälle abdeckt, kehren Sie zur Spezifikation zurück und fügen Sie die fehlenden Funktionen hinzu. Keine Lösung = Investition von 60.000 PLN. PLN liegt brach.
Über den Autor
Jędrzej Siewierski. CEO und Mitbegründer JSON Crew. Seit 2024 erstellt das Unternehmen Produktkonfiguratoren für B2B-Unternehmen (Hersteller von Landmaschinen, Jagdwaffen, Modulhäusern, Internet der Dinge-Elektronik) und JSON-Hub, ein eigenes SaaS, das CRM, Automatische Angebotserstellung und Projektmanagement kombiniert. MitAutor der Methodik zur digitalen Vertriebstransformation: Verkürzung des Weges vom Interesse bis zum Kauf durch einen Konfigurator + Automatisches Angebot + CRM. Stapel: Next.js, Three.js, Nest.js, React Native. Kontakt: contact@jsoncrew.com · LinkedIn.
Sehen Sie sich den funktionierenden Konfigurator an – bevor Sie diese Fehler begehen
Der einfachste Weg, diese 5 Probleme zu vermeiden, ist, sich anzusehen, wie ein gut gestalteter Konfigurator aussieht. Klicken Sie darauf und probieren Sie es selbst aus – ohne Anmeldung, ohne Registrierung. JSON Crew Ausstellungsraum bietet eine funktionierende Demo-Version, die für verschiedene Branchen entwickelt wurde:
- 3D-Waffenkonfigurator — Das GLB-Modelll im Browser, Zubehör, Gehäuseausführung. Ein Vorbild für Waffen- und Zubehörhersteller.
- 3D-Autokonfigurator — Lack, Felgen, Spoiler, Ausstattungspakete. Die von BMW, Audi und ŠCodea bekannte Benutzererfahrung (UX) – ein Vorbild für die Automobilbranche.
- Modularer Hauskonfigurator — Baukörper, Transport, Installationen, Automatische Kostenkalkulation als PDF. Mechanik für Hersteller von Modulhäusern.
- Konfigurator für BlechGaragen — Schrittweise Auswahl von Struktur, Größe, Tor. Umsetzung ~4 Wochen. Der polnische Markt fragt nach diesem Produkt +160% YoY.
- Konfigurator Kostenkalkulator - PLN-Bereich für Ihr Unternehmen in 3 Minuten. EINFACH/MITTEL/SCHWIERIG + TCO 3 Jahre + ROI berechnet.
