60% benutzerdefinierte Konfiguratoren ohne Domänenkenntnisse enden in einem Fehlschlag. 95% der CPQ-Systeme sind für RevOps-Administratoren konzipiert, während 95% der tatsächlichen Benutzer Verkäufer sind. Laut dem Standish CHAOS Report sind nur 31% der IT-Projekte erfolgreich – 19% sind ein totaler Fehlschlag.
Wenn Sie nach monatelangen Gesprächen mit Softwarehäusern oder nach der Implementierung eines unerfüllten Konfigurators suchen, ist dieser Artikel genau für Sie. Fünf Dinge, die Konfiguratorprojekte zum Scheitern bringen, mit Branchendaten und realen Beispielen aus unseren Implementierungen. Und konkrete Empfehlungen, wie Sie diese vermeiden.
60% Probleme sind Prozesse, nicht Technologie. 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 |
Problem 1: Die Bewertungsregeln leben im Kopf des Händlers (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.
Problem 1 · Der häufigste Grund für Verzögerungen
Preisliste als PDF, Ausschlussregeln im Kopf des Konstrukteurs, 15 Jahre Erfahrung eines Verkäufers – nirgends aufgeschrieben. Ein Softwarehaus erhält unvollständige Regeln, programmiert das, was es hat, Tests werfen das Projekt über den Haufen.
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 kodiert, 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
Discovery-Woche VOR dem ersten Code. Bei unseren Kunden beginnen wir mit 5-7 Tagen der Zusammenarbeit mit Vertriebsmitarbeitern und Konstrukteuren. Wir bilden nicht das Produkt ab, sondern den Kundenpfad: wie der Kunde fragt, was er am häufigsten fragt, wie der Vertriebsmitarbeiter kalkuliert, welche Abhängigkeiten sich automatisch aktivieren. Das Ausgabedokument besteht aus 15-40 Seiten Regeln in Geschäftssprache (nicht in Code) – der Kunde liest und korrigiert es selbst. Erst nachdem das Dokument akzeptiert wurde, rühren wir die Tastatur an.
Problem 2: Scope Creep – „Könnte man noch 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 Zeitplan. 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 Gründer setzt auf „wenige Monate Entwicklungszeit”, die tatsächliche Implementierung erstreckt sich bis 12–24 Monate. Nicht, weil das Team es nicht kann. Sondern weil Scope Creep real und fast unvermeidlich ist.
Was geschieht im Projekt: Jedes „und fügen wir noch hinzu” bedeutet eine neue Kalkulation, neue Fristen, neue Regelvalidierungen. Ein Projekt, das 60.000 PLN kosten und 10 Wochen dauern sollte, endet nach 9 Monaten für 180.000 PLN – und niemand erinnert sich mehr, wer das 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 dwu- do trzykrotność pierwotnego budżetu – zuzüglich monate verlorener Zeit im Wettbewerbsmarkt.
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 – nie „część rozwiązania, którą potem dopiszemy”. Obymy kierunek – dopiero wtedy inwestujesz w rozbudowę. Nie działa tak, jak zakładano – nie robisz fazy 2.
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 Datenmodell 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, der das gesamte UX ruiniert. In der Praxis bedeutet dies, dass eine fehlerhafte Preis synchronisation zwischen ERP und Konfigurator dem Kunden einen falschen Preis anzeigt – und das ist nicht hypothetisch. Wir haben ein Projekt gesehen, bei dem ein Vertriebsmitarbeiter eine Maschine 15% unter dem realen Preis verkaufte, weil der Konfigurator eine alte Version vom März anzeigte.
Wie kann man das vermeiden
ERP-Audit vor der Implementierung. Die erste Woche der Diskussion dreht sich nicht darum, „wie der Konfigurator aussehen soll”, sondern darum, „wie Ihr ERP aussieht, wo die Preisliste sitzt, wer sie aktualisiert, welche Felder die Single Source of Truth sind”. Wenn das ERP eine API hat – synchronisieren wir in Echtzeit. Wenn nicht – schreiben wir eine benutzerdefinierte Middleware.
Alternativ: Wir bauen Konfiguratoren mit nativer Integration in JSON-Hub – unsere Plattform, die drei Werkzeuge (CRM + Angebotserstellung + Händlerportal) zu einem ersetzt. Dann ist das Problem der Integration mit ERP auf einen Connector reduziert 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 läuft einwandfrei. Nach 3 Monaten rechnen die Vertriebsmitarbeiter immer noch in Excel. Ein System, das für RevOps entwickelt wurde, aber von Vertriebsmitarbeitern genutzt wird – eine 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 Handelsvertreter, der 8 Jahre lang Excel benutzt hat, hat dort alles niedergeschrieben: seine Abkürzungen, seine Makros, seine Art, Kunden zu bewerten. Der Konfigurator verlangt von ihm, neu zu lernen – und Excel funktioniert ja. Im Kopf: „Dies ist ein IT-Tool, nicht mein Verkaufstool”. Wenn niemand aus dem Vorstand erklärt, warum wir uns verändern, und nicht zeigt, „was für mich drin ist” – wird der Händler es ignorieren.
Wie kann man das vermeiden
Kaufleute im Projektteam vom ersten Tag an. Nie na końcu. Od samego początku. Dwóch-trzech handlowców siada z nami i mówi, co ich wkurza w obecnym procesie. Potem, na każdym sprincie, oglądają prototyp i komentują.
Anreizabstimmung Wenn der Konfigurator die Angebotszeit von 3 Stunden auf 15 Minuten reduziert, zeigen Sie dem Verkäufer, dass er statt 2 Angeboten pro Tag 8 versenden kann – und seine Provision hängt von der Anzahl der abgeschlossenen Geschäfte ab. Das ist dann sein Werkzeug, nicht das der IT.
Problem 5: Niemand hat die Wartung geplant. Der Konfigurator ist 12 Monate haltbar und lügt.
PROBLEM 5 · „WIR BAUEN UND FERTIG”
Kein Wartungsplan = nach 12-18 Monaten zeigt der Konfigurator alte Preise, fehlende Varianten, kaputte Integrationen. Der Vertriebsmitarbeiter verliert das Vertrauen. Er kehrt zu Excel zurück.
Gründer unterzeichnet den Implementierungsvertrag. Der Konfigurator geht in die Produktion. Annahme im Kopf: „Wir werden es bauen und fertig, jetzt wird es funktionieren”. Einen Monat später fügst du eine neue Produktvariante hinzu – der Konfigurator kennt sie nicht. Ein Quartal später aktualisierst du die Preisliste – der Konfigurator zeigt die alten Preise. Ein halbes Jahr später funktioniert die API-Integration mit dem Anbieter nicht mehr, weil dieser Anbieter 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.”. Aber das stimmt nur, wenn Sie KEINEN Wartungsplan haben. Wenn Sie einen haben, sind die Wartungskosten eine vorhersehbare Ausgabe, ähnlich wie bei einem Abo für ein CRM.
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, nicht funktionierende Optionen. Der Händler hört auf, ihm zu vertrauen. Er kehrt zu Excel zurück (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
Wartungsplan VOR Unterzeichnung des Implementierungsvertrags. Nie po premierze. Nie „kiedy będzie potrzeba”. Przed. Typowy roczny koszt: ~20% Projektwerte.
Hierfür brauchst du Besitzer auf Kundenseite – einer Person, die Rückmeldungen bündelt. Ohne sie erhält der Anbieter 15 E-Mail-Postfächer mit „hier funktioniert etwas nicht” von 15 verschiedenen Händlern. Details zu den Wartungskosten in dem Artikel über nach Konfigurator.
Zusammenfassung: 5 Checkpoints vor der Einführung
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 | Wartungsplan in Hauptvertrag | Vertrag nach dem Start„ |
Wenn ein Softwarehaus auf einem dieser Punkte aufbaut – ist das ein Warnsignal. Ein guter Partner scheut keine Transparenz in diesen fünf Bereichen, denn er weiß, dass diese den Erfolg bestimmen, nicht der Technologie-Stack.
Wie machen wir das bei der JSON Crew
Unser Implementierungsprozess für den Konfigurator basiert vom ersten Tag an auf diesen fünf Checkpoints.
- Woche 0–1 (Entdeckung): 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 betrachtet der Handelsvertreter-Botschafter den Prototyp und gibt Feedback. Der Umfang ist ein Festpreis – jede Änderung, die über den Umfang hinausgeht, 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 Jahresplan. 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 Modell + 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 Integrationsprobleme mit dem 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 im Code stecken, welche im Kopf des Verkäufers, was Verkäufer tatsächlich nutzen, wo Integrationen bestehen, was kaputt ist, was gerettet werden kann. Ergebnis: Bericht mit Empfehlung – entweder „wir retten es für X” oder „besser abreißen, hier ist der Grund”. Wir treiben den Verkauf nicht voran, wenn es nicht wirklich gerettet werden kann.
„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 Technologie. 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, aber wir arbeiten mit Partnern in diesem Bereich zusammen. Wenn Ihr ERP die Implementierung des Konfigurators blockiert, empfehlen wir einen Partner und implementieren den Konfigurator parallel zur ERP-Migration. Das 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 Technologie. Eine gute Nachricht: Prozesse lassen sich schneller und kostengünstiger beheben, als das System von Grund auf neu zu schreiben.
