Legacy‑Produktmodelle

Von nanologika | 18. Mai 2026 |

Definition

Legacy‑Produktmodelle sind ältere, historisch gewachsene digitale Produktmodelle (z. B. aus CPQ‑, ERP‑ oder Konfigurator‑Systemen), die Produktvarianten, Regeln und Abhängigkeiten abbilden. Diese sind aber technisch oder fachlich nicht mehr zeitgemäß, schwer wartbar, weil unvollständig dokumentiert oder stark über Sonderlogik/Workarounds geprägt.

Erläuterung

In vielen Unternehmen existieren Produktmodelle aus „früheren Generationen“ der Angebotserstellung: Regeln liegen verteilt in Altsystemen, Excel‑Logiken oder individuellen Anpassungen. Das führt oft zu technischer Schuld und begünstigt Spreadsheet‑Workarounds, wenn das Altsystem die reale Angebotslogik nicht mehr sauber abbildet.
Gerade bei CPQ‑Modernisierung zeigt sich, dass Legacy‑Modelle häufig aus unterschiedlichen Quellen stammen können – z. B. aus Legacy‑Applikationen, Papierkatalogen oder personengebundenem Wissen – und erst für ein neues Zielsystem gemappt, bereinigt, harmonisiert und übertragen werden müssen.

Typische Merkmale (fachlich/technisch)

Legacy‑Produktmodelle erkennt man häufig an wiederkehrenden Mustern wie:

„Flacher“ Produktkatalog (viele SKUs/Varianten als einzelne Datensätze statt attribut-/regelbasierter Modellierung).
Unübersichtliche Sonderlogik (z. B. viele individuelle Preisregeln/„Hacks“), die ein System „spröde“ macht und Änderungen riskant werden lässt.
Erosion von Geschwindigkeit und Governance: Angebotsprozesse laufen zwar noch, fühlen sich aber „schwerer“ an, weil Anpassungen überproportionalen Aufwand erzeugen und die Regel‑/Datenlage unklar ist.

(Die Punkte beschreiben typische Muster im CPQ‑Kontext; je nach Unternehmen können weitere Merkmale hinzukommen.)

Rolle im Vertriebs‑ und Angebotsprozess

Legacy‑Produktmodelle wirken im Vertriebs‑ und Angebotsprozess als „Regel‑ und Datenfundament“ für Konfiguration, Preisberechnung und Angebotsdokumente. Wenn dieses Fundament veraltet oder fragmentiert ist, verschiebt sich Arbeit aus dem System heraus in manuelle Umgehungen — und genau dort entstehen operative Reibung und Qualitätsrisiken.

1) Angebotserstellung: Workarounds statt Systemlogik

Wenn Vertriebs-Teams für eine korrekte Konfiguration oder Preisfindung „aus dem CPQ heraus“ auf Tabellenkalkulationen ausweichen müssen, ist das ein typisches Symptom: Das Legacy‑Modell bildet die reale Angebotslogik nicht mehr sauber ab. Diese Umgehungen erhöhen laut Quelle die operativen Risiken und fördern technische Schuld, weil sich Logik und Daten über Systemgrenzen hinweg weiter zersplittern.

2) Geschwindigkeit und Verlässlichkeit im Sales Cycle

Legacy‑Modelle werden selten „plötzlich“ unbrauchbar; sie erzeugen vielmehr schleichend Friktion: Angebotszyklen werden schwerfälliger, Abstimmungen dauern länger und selbst kleine Änderungen verursachen unverhältnismäßigen Aufwand. In der Praxis zeigt sich das als „Speed Erosion“ im Angebotsprozess und als wachsende Abhängigkeit von wenigen Expert:innen, die Sonderfälle manuell „geradeziehen“.

3) Preis- und Margentransparenz / Governance

Ein zentraler Effekt veralteter Modelllogik ist die abnehmende Steuerbarkeit von Preisen und Margen: Wenn Regeln unübersichtlich werden oder außerhalb des Systems gepflegt werden, sinkt die Transparenz und die Kontrolle über Pricing‑ und Margin‑Entscheidungen. Die Quelle beschreibt genau diesen Mechanismus als schleichenden Schaden („reduced visibility into pricing and margins“) bei Legacy‑CPQ‑Setups.
Parallel dazu steigen Governance‑Probleme, wenn Preisregeln, Genehmigungen und Ausnahmen über die Zeit „multiplizieren“ und Verantwortlichkeiten unklar werden.

4) Integrationen & Übergaben (Quote → Order) werden fragil

Legacy‑Produktmodelle hängen häufig an historisch gewachsenen Integrationen (z. B. zu CRM/ERP/Billing). Wird diese Kopplung spröde, kann Modernisierung zu operativen Störungen führen — bis hin dazu, dass Sales während eines Cutovers keine Angebote erzeugen kann. Das wird in der Quelle als typisches Scheitern von „rip‑and‑replace“‑Ansätzen beschrieben (Integrationsprobleme, Kaskadeneffekte, Angebotsfähigkeit während der Transition).
Entsprechend wird als Gegenansatz betont, Modernisierung als phasenweise Integration zu planen, um den laufenden Vertriebsbetrieb aufrechtzuerhalten.

5) Verlängerung/Änderung (Renewals/Amendments): Altlasten schlagen später durch

Legacy‑Daten und Produktmodell‑Artefakte wirken nicht nur beim Neugeschäft, sondern auch bei Vertragsverlängerungen und Änderungen. Die Salesforce‑Dokumentation weist explizit darauf hin, dass falsch oder unvollständig migrierte CPQ‑Daten erst bei Renewals/Amendments als Fehler sichtbar werden können („You don’t realize there’s a problem until you begin to amend or renew a contract“) und daher korrekt transformiert/importiert werden müssen.

6) Praktische Konsequenz für den Vertriebsprozess

Operativ heißt das: Legacy‑Produktmodelle beeinflussen direkt, ob Angebote schnell erstellt werden können, wie konsistent Preise/Margen angewendet werden und wie stabil Übergaben in nachgelagerte Systeme funktionieren. Deshalb betonen Migrations‑/Modernisierungsquellen häufig strukturierte Vorgehensweisen wie Bereinigung veralteter Produktdaten, Konsolidierung und klare Dokumentation der Preislogik, um Implementierungsrisiken zu senken und den Vertrieb nicht zu unterbrechen.

Abgrenzung zu verwandten Begriffen

Konfigurationswissen: beschreibt das fachliche Regel‑ und Abhängigkeitswissen. Legacy‑Produktmodelle sind dessen alte Implementierung/Formalisierung (oft mit Lücken oder historischer Sonderlogik).
Produktdaten: sind Stammdaten (Merkmale, Texte, Preise). Legacy‑Produktmodelle beinhalten darüber hinaus Regeln/Logik, wie Varianten überhaupt entstehen bzw. erlaubt sind.
Technische Schuld: ist eine Folgeerscheinung; Legacy‑Produktmodelle können technische Schuld verursachen oder verstärken, sind aber nicht mit ihr gleichzusetzen.

Bedeutung im CPQ‑Umfeld

Bei der Migration von einem Legacy‑CPQ zu einem modernen CPQ sind Legacy‑Produktmodelle ein zentraler Risikofaktor – nicht, weil „CPQ nicht funktioniert“, sondern weil Regeln, Daten und Sonderfälle konsolidiert und korrekt in das Zielmodell überführt werden müssen. Eine strukturierte Migration betont u. a. Datenbereinigung (z. B. veraltete Produkte entfernen, Produktdatensätze konsolidieren) und klare Dokumentation der Preislogik, um Implementierungsrisiken zu senken.
Ein häufiger Modernisierungsschritt ist der Wechsel von einem SKU‑getriebenen, „flachen“ Katalog zu einem attributbasierten Modell (ein Produkt, Varianten über Attribute/Constraints), um Komplexität beherrschbarer zu machen.

Praxisbezug

In der Praxis werden Legacy‑Produktmodelle selten „1:1“ übernommen. Stattdessen werden sie typischerweise bereinigt, harmonisiert, getestet und erst dann in das Zielsystem übertragen. Einige Ansätze betonen dabei Prototypen/Piloten sowie Mapping‑ und Übersetzungsprozesse der vorhandenen Konfigurationsregeln in eine neue Knowledgebase.