CPQ-Integrationsleitfaden: CRM, ERP und PLM ohne Silos verbinden

„Das Angebot ist freigegeben, aber die Buchhaltung kann es nicht sehen. Kann jemand ein PDF exportieren und ans Werk schicken?“

Wenn Ihnen das bekannt vorkommt, ist Ihr CPQ-System nicht integriert. Es ist eine Insellösung. Einige wenige Mitarbeiter werden dadurch schneller, während der Rest des Unternehmens Workarounds basteln muss. Genau so verliert ein Vertriebsprozess an Geschwindigkeit.

In unzähligen Projekten sehe ich immer wieder dieselbe Wahrheit: Ein CPQ-System ist nur so stark wie seine Integration. Ein reines Angebotstool schafft neue Datensilos und manuelle Arbeit. Der wirkliche Mehrwert entsteht erst, wenn CPQ nahtlos in die Prozesskette aus CRM, ERP und – im Maschinen- und Anlagenbau – PLM eingebettet ist.

Wenn CPQ und CRM sich widersprechen, verliert der Vertrieb das Vertrauen in beide Systeme.

Die versteckten Kosten von Insellösungen

Teams schieben langsame Angebotsprozesse oft auf die Benutzeroberfläche oder mangelndes Training. In Wahrheit ist es fast immer ein Integrationsproblem, das sich als Prozessschwäche tarnt. Angebote sind zwar korrekt, bleiben aber im System stecken. Forecasts sehen sauber aus, sind aber falsch. Stücklisten sind perfekt konfiguriert, aber nicht in dem System, das sie für die Produktion benötigt.

Diese Systembrüche sind teuer. Sie führen zu verpassten Lieferterminen, eiligen Notfall-Tickets in der Technik und Umsätzen, die am Quartalsende wegrutschen, weil die Produktion den Auftrag nie rechtzeitig gesehen hat. Wer die Integration nicht von Anfang an als zentrales Projektergebnis begreift, geht ein hohes Risiko ein.

Ein Angebot, das nicht im ERP ankommt, ist nur eine wertlose Skizze.

Was zwischen den Systemen fließen muss

Gute Integration bedeutet nicht, alles mit allem zu verbinden. Es geht um einige wenige, aber absolut zuverlässige Übergabepunkte, die ohne manuellen Aufwand funktionieren. Auf diese Datenflüsse konzentriere ich mich zuerst.

CRM ↔ CPQ: Eine Opportunity, eine Datenbasis

Im CRM entsteht die Verkaufschance. Im CPQ erhält sie Struktur und einen Preis. Beide Systeme müssen sich über Kunde, Produkt und Deal-Status einig sein.

• Ins CPQ: Kunde, Ansprechpartner, Opportunity, Preisliste oder Rahmenvertrag sowie kommerzielle Konditionen, die das Pricing beeinflussen.
• Zurück ins CRM: Angebotsversion, Wert, Margenklasse, ein Signal zur Abschlusswahrscheinlichkeit und wichtige Termine (Gültigkeit, angenommene Liefertermine).

Beispiel: Ändert ein Vertriebler Menge oder Umfang im CPQ-System, muss sich der Forecast-Wert im CRM automatisch anpassen. Ein Forecast sollte auf Daten basieren, nicht auf Hoffnung.

CPQ ↔ ERP: Von der Konfiguration zur produzierbaren Stückliste

Hier wird aus einem korrekten Angebot ein lieferbares Produkt. Das ERP-System darf nicht raten müssen, was das Angebot bedeutet.

• Ins ERP: Die strukturierte, konfigurierte Stückliste (BOM), bei Bedarf Arbeitspläne, erwartete Durchlaufzeiten und kommerzielle Daten (Preis, Konditionen, Steuern, Währung).
• Zurück ins CPQ: Kalkulationsergebnisse bzw. Herstellkosten, Verfügbarkeiten, zugesagte Lieferzeiten und gegebenenfalls Kredit- oder Margenprüfungen.

Beispiel: Ändern sich die Lieferzeiten nach einem ERP-Update, sollte das CPQ-System den Angebotseigner informieren und das Angebot zur erneuten Kundenbestätigung markieren. Ganz ohne manuelle Detektivarbeit.

PLM ↔ CPQ: Leitplanken und Änderungsmanagement

In der komplexen Fertigung definiert das PLM, was technisch machbar ist. Das CPQ-System sollte diese Vorgaben respektieren, nicht sie kopieren.

• Ins CPQ vom PLM: Gültige Optionssätze, Kompatibilitätsregeln, Gültigkeitsdaten (Effectivity Dates) und Revisionsstände.
• Zurück ins PLM: Strukturierte Änderungsanträge, wenn das CPQ-System wiederkehrende, aber nicht erfüllbare Kundenwünsche erkennt; optional Auslöser für CAD-Automatisierungen.

Beispiel: Läuft eine Konfigurationsoption zu einem bestimmten Datum aus, blockiert CPQ sie für neue Angebote und markiert betroffene offene Angebote mit einem simplen Status – statt in einer E-Mail zu versanden.

Forecasts werden präziser, wenn sich Angebote selbst aktualisieren.

Warum es heute einfacher ist als früher

Vor zehn Jahren bedeutete Integration fragile Punkt-zu-Punkt-Verbindungen und starre Feld-Mappings. Heute haben wir stabile APIs, ereignisbasierte Architekturmuster und standardisierte Integrationsplattformen. Die Herausforderung ist heute weniger technischer Natur als eine Frage der Disziplin im Systemdesign.

Drei Faktoren machen die Umsetzung heute praxistauglich:

• Stabile IDs und ein klares Product-Master-System: Legen Sie fest, welches System die Hoheit über Produkt- und Kundendaten hat. Ohne eine klare ID-Strategie gibt es keine Integration.
• Ereignisbasierte Updates statt nächtlicher Batch-Läufe: Angebote ändern sich, wenn Kunden ihre Meinung ändern – nicht um 2 Uhr nachts. Ereignisbasierte Prozesse halten die Systeme synchron.
• Testbare Mappings: Behandeln Sie Schnittstellen wie ein Produkt. Sie benötigen Tests, Versionierung und eine Änderungsdokumentation, genau wie Konfigurationsregeln.

Integrations-Anti-Pattern, die Sie vermeiden sollten

Die CPQ-Insellösung. Das CPQ-System existiert nebenher mit eigenen Produkttabellen und Preislisten. Der Vertrieb nutzt es, alle anderen ignorieren es. Das Ergebnis: kurzfristige Geschwindigkeit, langfristige Zersplitterung.

Der Mythos der zentralen Datendrehscheibe. Eine gigantische Schnittstelle, die alles kann. Sieht auf einer Powerpoint-Folie sauber aus, scheitert aber in der Praxis. Sie brauchen domänenspezifische Datenflüsse mit klaren Verantwortlichkeiten.

Änderungsmanagement per E-Mail. Die Technik nimmt eine Option per E-Mail aus dem Programm. Der Vertrieb erfährt davon, wenn ein Angebot in der Produktion auf einen Fehler läuft. Änderungen müssen systemgestützt, nachvollziehbar und mit Gültigkeit versehen sein.

Das Playbook: Praxisregeln, die sich bewähren

Regel 1: Eine einzige, versionierte Quelle für Produktdaten. Entscheiden Sie, wo die Produktdefinition lebt – oft PLM für technische Details und ERP für verkaufsfähige Artikel. Das CPQ konsumiert diese Daten, es definiert sie nicht neu. Nutzen Sie Gültigkeitsdaten, damit bereits erstellte Angebote nicht ungültig werden.

Beispiel: Eine neue Motorvariante wird nächsten Monat aktiv. CPQ zeigt sie mit Startdatum als „Vorabversion“, damit der Vertrieb sie anbieten, aber keine falschen Lieferversprechen machen kann.

Regel 2: Angebote erzeugen Struktur, nicht nur Dokumente. Das ERP braucht eine konfigurierte Stückliste, kein PDF. Die Schnittstelle muss strukturierte Positionen, Attribute und Referenzen übergeben, die das ERP für Kalkulation, Terminierung und Fertigung nutzen kann.

Beispiel: Statt „Pumpenaggregat – 48.700 €“ senden Sie die konkreten Komponenten mit ihren Parametern, damit der Einkauf sieht, was bestellt werden muss und was auf Lager ist.

Regel 3: Der Forecast ist datengestützt. Der CRM-Forecast muss sich aus CPQ-Ereignissen speisen: Angebot erstellt, überarbeitet, genehmigt, abgelaufen, beauftragt. Entfernen Sie manuelle Schritte, die zu Wunschdenken einladen.

Beispiel: Übersteigt ein Rabatt einen Schwellenwert, fällt die Abschlusswahrscheinlichkeit automatisch, bis die Freigabe erteilt ist. Die Pipeline spiegelt die Realität wider, nicht den Optimismus.

Regel 4: Lieferzeiten und Kosten sind Live-Signale. Ein Pricing im CPQ ohne aktuelle Kosten und Verfügbarkeiten ist reines Theater. Ziehen Sie Kalkulationsergebnisse und Lieferzeiten aus dem ERP – entweder live oder über einen Cache mit kurzer Lebensdauer.

Beispiel: Wird eine Schlüsselkomponente als „kritisch“ eingestuft, passt CPQ die Lieferzeit an und schlägt eine alternative Konfiguration vor, die den Wunschtermin des Kunden einhält.

Regel 5: Änderungen brauchen einen sicheren Prozess. Nehmen Sie Änderungen an der Integration nur in Testumgebungen mit realitätsnahen Daten vor. Jede Änderung braucht einen Test, der die korrekte Funktion in beide Richtungen nachweist.

Beispiel: Bevor eine neue Rabattart freigeschaltet wird, vergleicht ein Regressionstest die CRM-Forecast- und ERP-Auftragswerte von 50 historischen Angeboten, um Abweichungen zu finden.

Womit Sie dieses Quartal beginnen sollten

Dokumentieren Sie die drei wichtigsten Übergabepunkte. Wählen Sie eine Produktfamilie und beschreiben Sie exakt, welche Felder zwischen CRM ↔ CPQ, CPQ ↔ ERP und PLM ↔ CPQ fließen. Benennen Sie für jedes Feld einen klaren Eigner.

Implementieren Sie ereignisbasierte Angebotsstati. Publizieren Sie Angebotsereignisse aus dem CPQ (erstellt, überarbeitet, genehmigt usw.) und lassen Sie CRM und ERP diese abonnieren. Machen Sie den Status in der Opportunity und der Auftragsverwaltung sichtbar.

Binden Sie Kosten und Lieferzeiten direkt ins Pricing ein. Ziehen Sie – und sei es nur für ein Pilotprojekt – ERP-Kosten und Verfügbarkeiten ins CPQ, damit der Vertrieb mit realistischen Margen und Lieferfenstern arbeitet.

Schaffen Sie Transparenz über die Schnittstellen. Ein simples Dashboard, das die letzten Integrationsmeldungen, Fehler und Wiederholungsversuche anzeigt, ist wertvoller als eine perfekte Architektur, die niemand debuggen kann.

Der Zinseszinseffekt der Integration

Wenn CPQ richtig in die Prozesskette integriert ist, passieren drei Dinge. Angebote werden schneller, weil der Vertrieb keine Informationen mehr zusammensuchen muss. Die Genauigkeit steigt, weil Kosten und technische Restriktionen dort sichtbar sind, wo die Entscheidungen fallen. Und Änderungen werden sicherer, weil Sie Updates einspielen können, ohne das Tagesgeschäft zu gefährden.

Die Unternehmen, die hier erfolgreich sind, behandeln Integration als Teil des Produkts, nicht als IT-Infrastruktur. Sie wählen einige wenige, aber kritische Datenübergaben aus, machen diese absolut robust und erweitern sie von dort aus schrittweise. Der Rest exportiert weiterhin PDFs und wundert sich, warum Deals am Quartalsende platzen.

Zuverlässige Schnittstellen schlagen heldenhafte Notlösungen – jedes einzelne Mal.