Ihre CPQ-ERP-Checkliste ist eine Falle

Die Checkliste, die perfekt aussah

Sie haben sich an die Liste gehalten. Nicht an irgendeinen Blogartikel. An *die* Liste. Fünf saubere Punkte für die CPQ-ERP-Integration, an der Wand im Projektraum. Ein dediziertes CPQ-System. Standard-Konnektoren. Daten standardisieren. Skalierbarkeit bedenken. Teams frühzeitig einbinden.

Drei Monate nach dem Go-live war der Angebotszyklus langsamer als zuvor. Die Fertigung ertrank in Änderungsanforderungen. Im Vertrieb kursierte eine Excel-Tabelle namens „Quote Hacks“, die angeblich niemand nutzte.

Einen solchen Film habe ich öfter gesehen, als mir lieb ist. Ein Kickoff in Stuttgart ist mir besonders im Gedächtnis geblieben. Der Projektleiter tippte auf die Folie mit der Checkliste wie auf eine Sicherheitskarte im Flugzeug. Auf dem Papier war der Plan perfekt. In der Praxis war er unerprobt.

Checklisten sind sauber. Echte Integration ist es nicht.

„Die Checkliste ist nicht der Plan. Sie ist die Agenda für die harten Gespräche.“

Der Konflikt, den die Checkliste verbirgt

Man glaubt gerne: Wenn wir die richtigen Systeme auswählen und die richtigen Häkchen setzen, ergibt sich der Rest von selbst. Tut er aber selten. Nicht, weil die Liste falsch ist, sondern weil sie es den Teams erlaubt, die Arbeit zwischen den Stichpunkten zu umgehen – die Arbeit mit Menschen, Verantwortlichkeiten und Kompromissen, die auf keine Folie passt.

Hier liegt die Kernspannung: CPQ lebt im Reich des Möglichen – was ein Kunde kaufen *könnte*, wenn Technik und Pricing ja sagen. Das ERP-System lebt in der Realität dessen, was existiert – was bereits gebaut, kalkuliert und geliefert wurde. Sie brauchen beide Sichtweisen. Und Sie müssen die Spielregeln für deren Zusammenspiel definieren.

Eine Checkliste überdeckt diesen Konflikt. Sie vermittelt ein Gefühl von Fortschritt, während die wirklich entscheidenden Fragen aufgeschoben werden: Wer hat die Datenhoheit? Was passiert im Sonderfall? Wo endet die Produktlogik und wo beginnen die Produktionsrestriktionen?

„Bei CPQ geht es nicht um Automation – es geht um Korrektheit.“

Checklisten helfen durchaus, einen Raum auf ein gemeinsames Ziel auszurichten. Sie halten Ihnen den Einkauf vom Hals und bewahren Projekte vor dem Zerfasern. Aber sie sind ein Startsignal, kein Flugplan. Der Raum zwischen den Stichpunkten ist der Ort, an dem Projekte scheitern.

„Am Ende zählt nur die Akzeptanz der Nutzer.“

Gestalten Sie den Raum zwischen den Systemen

Die eigentliche Arbeit beginnt, wenn Sie jeden sauberen Punkt der Liste nehmen und die Fragen stellen, die er vermeidet.

• Mehr als „Daten standardisieren“: Wer hat die Datenhoheit? Welches System ist der Master für Produktstruktur, kundenspezifisches Pricing und Auftragsstatus? Wie sieht der Prozess aus, wenn die Systeme sich widersprechen? Wer entscheidet innerhalb welcher SLA? Wie prüfen Sie diese Entscheidung später nach, wenn aus einem Angebot eine Reklamation wird? Wenn Sie keinen Verantwortlichen und keine Eskalationsfrist benennen können, haben Sie keine Datenhoheit.

• Mehr als „Standard-Konnektoren nutzen“: Was kann der Konnektor *nicht*? Überträgt er Ihre benutzerdefinierten Felder, die Variantenlogik oder eine mehrstufige konfigurierte Stückliste mit Phantom-Baugruppen? Kommt er mit Staffel- und Matrixpreisen, Einheitenumrechnungen und Preisgültigkeiten zurecht? Was passiert bei Versionierung, Wiederholungsversuchen oder Teil-Fehlern? Wie verfolgen Sie eine Angebotsposition bis zum Fertigungsauftrag, ohne dass ein Mensch manuell IDs in Excel verknüpft? Wenn Sie die Fehlermodi nicht durchgespielt haben, haben Sie für eine Demo geplant, nicht für den Ernstfall.

• Mehr als „Teams einbinden“: Wie sieht der Entscheidungsprozess aus? Spielen Sie einen echten Ausnahmefall durch: Der Vertrieb bietet eine Nicht-Katalog-Variante an. Wer gibt das frei? Wo landet die Anfrage? Wie reagiert die Technik? Wie fließt die Fertigungskapazität zurück in den Angebotsprozess? Und in welcher Zeit? Hier liegt die wahre Komplexität Ihres Geschäfts. Die Integration muss diesen Pfad sicher und wiederholbar machen.

Ein paar Regeln, die ich bei dieser Arbeit mit Kunden anwende:

Regel 1: Verantwortung schlägt Mapping. Ein Daten-Mapping ohne klare Verantwortung ist Theater. Bestimmen Sie pro Daten-Domäne einen einzigen Master – für Produktstruktur, Pricing, Kundenkonditionen, Auftragsstatus – und definieren Sie eine klare Regel für Konfliktfälle. Beispiel: Produktvarianten werden im CPQ-System gemastert, bis aus dem Angebot ein Auftrag wird. Ab dann ist das ERP für die konfigurierte Stückliste verantwortlich. Gibt es einen Konflikt, löst der Verantwortliche ihn innerhalb von 24 Stunden, und die Entscheidung wird für den Vertrieb nachvollziehbar protokolliert.

Regel 2: Der Sonderfall ist das eigentliche Produkt. Designen Sie nicht nur für den Happy Path. Die 10 % der Angebote, die manuelle Eingriffe der Technik erfordern, bestimmen Ihren Zeitplan und Ihre Reputation. Schaffen Sie einen transparenten, nachverfolgbaren und zeitlich begrenzten Prozess für Ausnahmen. In einem Tacton-CPQ-Projekt halbierten wir die Durchlaufzeit für Sonderlösungen allein durch einen einfachen Status-Abgleich mit dem ERP und eine klare Veto-Regel für die Technik. Kein neues Tool. Nur ein sauber definierter Prozess.

Regel 3: Konnektoren sind Verträge, kein Wundermittel. Behandeln Sie die CPQ-ERP-Schnittstelle wie einen API-Vertrag mit Konsequenzen für Menschen. Definieren Sie Felder, Events, Fehlercodes und Latenztoleranzen. Legen Sie fest, was passiert, wenn Aufträge nur teilweise gültig sind. Beispiel: Ein Auftrag darf erst dann angelegt werden, wenn die konfigurierte Stückliste eine Freigabe von der Technik hat. Kein Tag, kein Auftrag. Machen Sie es explizit, damit die Leute aufhören zu raten.

Regel 4: Ohne Nachvollziehbarkeit geht es nicht. Wenn der Vertrieb nicht nachvollziehen kann, warum eine Produktkonfiguration oder ein Preis gültig ist, wird er das System umgehen. Machen Sie die Logik sichtbar und damit hinterfragbar. In der Praxis bedeutet das: Zeigen Sie Regelgründe, Preiskomponenten und Restriktionen in Klartext an. Ich habe erlebt, wie die Nutzerakzeptanz allein dadurch sprunghaft anstieg, dass Preisaufschlüsselungen und Konfigurationsbegründungen angezeigt wurden. Vertrauen folgt auf Klarheit.

Regel 5: Veränderung ist ein Kern-Feature, kein Störfall. Governance ist kein Overhead. Sie ist die Methode, um Veränderungen umzusetzen, ohne den Vertrieb lahmzulegen. Etablieren Sie einen wöchentlichen Rhythmus für Regel-Updates, mit einem kleinen Release-Zug und einem sichtbaren Backlog. Verlangen Sie Tests für Produktregeln, genau wie Sie Qualitätssicherung für Code verlangen. Wenn eine Änderung immer noch einen Projektplan braucht, ist Ihr Prozess zu langsam.

„Governance ist kein Overhead – so skalieren Sie Veränderungen, ohne den Vertrieb auszubremsen.“

Achten Sie auf diese Warnsignale in Ihrem Projekt:

• Checklisten-Theater: Das Team kann die Checkliste herunterbeten, aber niemand kann den Verantwortlichen für Preisstreitigkeiten benennen. Die Meetings sind sauber, die Angebote nicht.

• Konnektor-Anbetung: Der Glaube, ein Standard-Konnektor erspare das Design des Datenvertrags. Tut er nicht. Er beschleunigt nur, was Sie bereits (gut oder schlecht) designt haben.

• Formular-CPQ: Sie bauen ERP-Formulare im CPQ nach. So machen Sie aus einem geführten Produktkonfigurator einen reinen Aktenschrank und wundern sich, warum der Vertrieb wieder Excel nutzt.

• Abnick-Gremium: Ein Komitee, das sich trifft, nickt und alles durchwinkt. Wenn nie etwas abgelehnt wird, haben Sie keine Governance. Sie haben einen Kalendereintrag.

Stellen Sie sich CPQ und ERP als tragende Balken eines Gebäudes vor. Die Balken haben unterschiedliche Aufgaben, aber die Lastenverteilung zwischen ihnen entscheidet, ob der Boden hält. Sie können die Balken beliebig verstärken – wenn die Verbindungsverbindungen falsch konstruiert sind, biegt sich die Decke durch.

Was können Sie also diese Woche tun, ohne auf den nächsten Budgetzyklus zu warten?

• Führen Sie einen „Wahrheits-Workshop“ durch. Klären Sie in einer Stunde die Hoheit für Produktstruktur, Pricing, Kundenkonditionen und Auftragsstatus. Schreiben Sie Konfliktregeln und SLAs auf eine einzige Seite. Machen Sie sie für Vertrieb und Betrieb zugänglich.

• Analysieren Sie einen Sonderfall von Anfang bis Ende. Nehmen Sie das letzte Angebot, das eine Sonderlösung erforderte. Malen Sie die Schritte von der Anfrage bis zur Auslieferung auf ein Whiteboard. Markieren Sie Wartezeiten, Übergaben und Entscheidungsgründe. Machen Sie daraus einen definierten Prozess in CPQ und ERP mit klaren Status und Verantwortlichen.

• Spielen Sie einen Konnektor-Ausfall durch. Ziehen Sie in einer Testumgebung den Stecker. Beobachten Sie, wie sich Angebote und Aufträge verhalten. Legen Sie fest, was das System automatisch tut, was ein Mensch entscheidet und wie der Vorfall protokolliert wird. Schreiben Sie das Playbook.

• Machen Sie die Logik sichtbar. Zeigen Sie Konfigurationsgründe und Preiskomponenten direkt im Angebot an. Wenn Ihr Tool das nicht kann, schaffen Sie eine einfache Darstellungsebene. Menschen vertrauen dem, was sie sehen.

Ich mache diese Arbeit seit 2000, hauptsächlich mit Tacton CPQ. Die Projekte, die langfristig erfolgreich sind, behandeln Integration wie Gartenarbeit, nicht wie Montage am Fließband. Man bereitet den Boden vor, pflanzt klare Regeln und schneidet regelmäßig zurück. Der Fortschritt wirkt von Woche zu Woche unspektakulär, aber über Jahre hinweg beeindruckend.

Kümmern Sie sich gezielt um die unsauberen Details. Entscheiden Sie, wer welche Datenhoheit hat. Definieren Sie die Schnittstellenprozesse. Üben Sie den Fehlerfall. Machen Sie Ihre Arbeit nachvollziehbar.

Das ist die eigentliche Integration.

Integration ist nichts, was man installiert. Es ist ein gemeinsames Verständnis, das man gezielt gestaltet.