Alten Konfigurator ablösen, ohne den Vertrieb zu stoppen
Veröffentlicht · Yotec Configurators
Viele Hersteller wissen, dass ihr Konfigurator sie bremst, doch der Vertrieb ist jeden Tag auf ihn angewiesen. Der Ausweg ist eine Migration, bei der der Vertrieb nie stillstehen muss.
Anzeichen, dass es Zeit ist
- Nur eine Person oder nur der Anbieter kann die Regeln ändern.
- Kleine Änderungen dauern Wochen, und niemand weiß sicher, was sie sonst beeinflussen.
- Zwei Personen können nicht gleichzeitig am Produktmodell arbeiten.
- Fehlersuche ist Raten, weil es keine Tests und kaum Protokolle gibt.
- Die Plattform hängt vom Hosting oder der Roadmap eines einzigen Anbieters ab.
Warum eine Umstellung auf einen Schlag riskant ist
Ein alter Konfigurator enthält oft jahrelange Entscheidungen, die niemand aufgeschrieben hat. Wer alles neu baut und an einem festen Tag umschaltet, entdeckt fehlende Regeln in echten Angeboten. So verlieren Ablöseprojekte das Vertrauen des Vertriebs.
Eine schrittweise Migration
1. Bestandsaufnahme. Produkte, Regeln, Eingaben und Ergebnisse auflisten: Preise, Stücklisten, Zeichnungen, Exporte. Festlegen, welche Ergebnisse exakt übereinstimmen müssen und welche besser werden dürfen.
2. Referenzfälle aus echten Aufträgen. Eine Reihe vergangener Konfigurationen auswählen und festhalten, was das alte System jeweils erzeugt hat. Daraus werden automatisierte Tests für den neuen Code.
3. Zuerst eine Produktfamilie. Die Familie mit den meisten Angeboten in Code überführen, die Referenzfälle ausführen und Abweichungen beheben, bis sie übereinstimmen oder erklärt sind.
4. Parallelbetrieb. Für kurze Zeit kalkuliert der Vertrieb in beiden Systemen, oder das neue läuft im Hintergrund mit und die Ergebnisse werden verglichen. Abweichungen werden behoben, bevor sich jemand auf das neue System verlässt.
5. Umschalten und wiederholen. Ist die Familie stabil, wechselt der Vertrieb für sie auf den neuen Konfigurator. Die nächste Familie folgt demselben Weg.
Wo KI hilft und wo nicht
KI-Werkzeuge lesen alte Regeldateien und Skripte gut, fassen sie zusammen und entwerfen gleichwertigen C#-Code. Eine Prüfung ersetzen sie nicht. Ob die neue Logik stimmt, entscheiden die Referenzfälle, nicht das Modell, das den Code geschrieben hat.
Was Sie am Ende haben
Produktregeln in einem Standard-.NET-Projekt mit Versionskontrolle und Tests, das jedes C#-Team pflegen kann und das Ihnen gehört. Änderungen werden zu normalen Softwareänderungen, die geprüft, getestet und freigegeben werden.
Wir beginnen meist mit einem Pilot für eine Produktfamilie in 8–12 Wochen. Erzählen Sie uns von Ihrem aktuellen Konfigurator.