CPQ + Business Central im Anlagenbau: Go-Live Muster und Integrationserfahrungen

Projektkontext

Anlagenbau-Unternehmen stehen vor einer strukturellen Spannung: Jede Anlage ist technisch ein Unikat, aber der Angebotsprozess folgt immer denselben Phasen — Komponentenauswahl, Dimensionierung, optionale Module, länderspezifische Anforderungen. Ohne CPQ entstehen Angebote durch Einzelrecherche, Engineering-Rückfragen und manuelle Kalkulationen. Die Angebotszyklen liegen häufig bei zwei bis vier Wochen.

Dynamics 365 Business Central ist im mittelständischen Anlagenbau (typisch 50–500 Mitarbeiter) weit verbreitet. Es deckt Einkauf, Produktion, Lager und Finanzbuchhaltung ab und bietet mit den Business Central APIs eine gut dokumentierte Grundlage für CPQ-Integrationen. Anders als SAP S/4HANA hat Business Central keine eigene Variantenkonfiguration — was die Konfigurationslogik vollständig ins CPQ verlagert und dort zu einem klareren Systemschnitt führt.

Integrationsarchitektur

Die Business Central REST API (OData v4) ist der primäre Integrationspunkt. Für CPQ-Projekte werden typischerweise diese Datenbereiche angebunden: Artikel- und Komponentenstamm (Preise, Einheiten, Verfügbarkeit), Debitorenstamm (Kundenpreisfindung, Währungen), und Stücklisten (Production BOMs für den Rückschrieb).

In Projekten mit Siemens NX als CAD-System wurde die CAD-Anbindung als zweite Phase implementiert: CPQ generiert zunächst das kaufmännische Angebot inklusive Stückliste, NX-Zeichnungen werden im zweiten Schritt als Anlagen automatisch hinzugefügt. Diese Phasierung hat sich bewährt, weil der kaufmännische Go-live nicht von der CAD-Integration blockiert wird.

Power Platform (Power Automate) wurde in mehreren Projekten für Freigabe-Workflows genutzt: Angebote über einem definierten Schwellenwert werden automatisch zur Genehmigung eskaliert, bevor das finale Dokument generiert wird. Diese Funktionalität ließ sich ohne zusätzliche Middleware-Entwicklung realisieren.

Implementierungsverlauf

Business Central-Projekte sind kompakter als SAP-Projekte — die Datenbasis ist in der Regel sauberer, Entscheidungswege sind kürzer, und die Anzahl der Systemadministratoren, die in die Integration eingebunden werden müssen, ist überschaubar.

Die typische Phasenstruktur: Datenaudit und API-Verbindung in Woche 1–3, Konfigurationsmodellierung in Woche 4–8, Key-User-Testing in Woche 9–11, Go-live in Woche 12–14. In gut vorbereiteten Projekten ist ein funktionsfähiges System in 10 Wochen realistisch.

Go-live-Muster folgen häufig demselben Ablauf: zuerst geht der Angebotsprozess (Konfiguration → PDF) live, danach der Stücklisten-Rückschrieb in die BC-Produktion. Diese Sequenz reduziert das Risiko beim ersten Rollout erheblich und ermöglicht schnelles Feedback aus dem Vertrieb.

Fachliche Einschätzung

Business Central + CPQ ist für mittelständische Anlagenbauer im Microsoft-Ökosystem die naheliegendste Kombination. Die kürzeren Implementierungszeiten gegenüber SAP-Projekten sind real — sie entstehen nicht durch geringere Qualität, sondern durch weniger Systemkomplexität auf BC-Seite.

Die Grenze der Kombination zeigt sich bei sehr tiefer Variantenstruktur: wenn Konfigurationsregeln Tausende von Abhängigkeiten abbilden müssen, ist CPQ auch ohne BC-seitige Variantenkonfiguration leistungsfähig — der Konfigurationsaufwand liegt dann vollständig im CPQ-Modell. Für Anlagenbauer mit überschaubarer Produktstruktur ist das kein Nachteil, sondern ein klarer Systemschnitt.

Hinweis: Als Gründer von Mercura bin ich an der Implementierung der Mercura CPQ Plattform beteiligt. Die Inhalte stellen persönliche fachliche Beobachtungen aus Implementierungsprojekten dar.