CPQ für Solaranlagen im B2B: Warum Standardsoftware bei komplexen Projekten oft an ihre Grenzen stößt

CPQ – Configure, Price, Quote – klingt zunächst nach einer trockenen Abkürzung aus der Vertriebs-IT. Gemeint ist der durchgängige Prozess, mit dem ein Vertrieb aus einer Kundenanfrage ein valides, korrekt kalkuliertes und verbindliches Angebot macht: Konfiguration des Produkts, automatisierte Preisfindung und Angebotserstellung in einem System, statt Excel-Kalkulation und Word-Vorlage per Hand. Für viele B2B-Branchen mit variantenreichen Produkten – Maschinenbau, Möbel, Fahrzeugausrüster – ist das mittlerweile Standard.

Bei Solaranlagen, insbesondere im B2B-Geschäft mit größeren Dach- oder Freiflächenanlagen, wird es interessant: Hier reicht die klassische CPQ-Logik allein oft nicht aus. Der Grund liegt weniger an der Software als an den Rahmenbedingungen der Branche.

Warum Solar-B2B anders tickt als der klassische CPQ-Anwendungsfall

Klassisches CPQ ist für ein Szenario gebaut, in dem ein Kunde aus einem definierten Baukasten wählt, das System die Kombination auf Gültigkeit prüft und daraus regelbasiert einen Preis errechnet – aus Listenpreisen, Kundenkonditionen, Rabattstufen und Sonderregeln. 

CPQ steht für Konfiguration, Preisermittlung und Angebotserstellung, wobei die Preisfindung Listenpreise, kundenindividuelle Konditionen, Mengenrabatte, Aktionen, Währungen und Steuern berücksichtigen muss.

Das funktioniert gut, wenn die Variablen im Wesentlichen im System selbst liegen.

Bei einer größeren Solaranlage im B2B-Kontext kommen mehrere Ebenen dazu, die ein reines Produktkonfigurations-Problem nicht abbilden:

• Physische Individualität statt Varianten aus dem Katalog. Dachgeometrie, Statik, Verschattung, Netzanschlusspunkt und verfügbare Fläche sind bei jedem Projekt anders. Das lässt sich nicht vollständig in vordefinierten Konfigurationsregeln abbilden, sondern braucht Planungsdaten (Luftbilder, Aufmaße, teils Photogrammetrie), die erst zur Preisgrundlage werden.
• Mehrstufige, unsichere Projektverläufe. Ein Angebot ist selten sofort verbindlich. Dazwischen liegen Netzanschlussanfrage, statische Prüfung, Genehmigung, und – gerade bei größeren Anlagen – die Förderzusage. Der „Preis“ zum Zeitpunkt X ist oft vorläufig, an Bedingungen geknüpft und muss im Projektverlauf neu bewertet werden können, ohne dass der ganze Angebotsprozess neu beginnt.
• Volatile Komponentenpreise. Modul-, Wechselrichter- und Speicherpreise schwanken stärker als in vielen anderen B2B-Branchen üblich. Eine reine Listenpreis-Logik, wie sie klassisches CPQ mitbringt, bildet das nur bedingt ab, wenn Einkaufspreise sich zwischen Angebot und Zuschlag deutlich bewegen können.
• Verteilte Ausführung über Partnerbetriebe. Viele Solarvertriebe verkaufen, lassen aber durch wechselnde Handwerksbetriebe installieren. Preisfindung und Kalkulation müssen also nicht nur Produktkomponenten, sondern auch variable Montage-, Gerüst- und Elektrikerkosten unterschiedlicher Subunternehmer berücksichtigen – oft mit regional unterschiedlichen Sätzen.
• Förderlandschaft als eigene Preisdimension. Zuschüsse, KfW-Kredite, kommunale oder länderspezifische Programme, in Österreich etwa Bundes- und Landesförderungen, in der Schweiz kantonal sehr unterschiedliche Programme, wirken sich direkt auf den Endpreis für den Kunden aus – sind aber zum Angebotszeitpunkt oft noch nicht final zugesagt.

Genau diese Kombination – individuelle physische Planung, mehrstufige Genehmigungs- und Förderprozesse, wechselnde Ausführungspartner, volatile Einkaufspreise – ist der Punkt, an dem generisches CPQ an Grenzen stößt.

Wo Standard-CPQ-Lösungen tatsächlich an Grenzen stoßen

Die großen CPQ-Suiten – SAP CPQ, Salesforce/Conga, Oracle CPQ – sind mächtig, wenn es um Preisregeln, Rabattstaffeln, Genehmigungsworkflows für ausgehandelte Preise und ERP-Anbindung geht.

Conga CPQ wurde für große, komplexe Geschäftsumgebungen entwickelt und zeichnet sich durch die Verwaltung ausgehandelter Preise, komplexe Genehmigungsworkflows und Angebotsautomatisierung aus, während Oracle CPQ vor allem bei globalen Preisregeln und umfassender ERP-Integration stark ist.

Das Problem: Sie gehen von einem Produktkatalog mit definierbaren Varianten aus, nicht von einem physischen Bauprojekt mit offenen Genehmigungsschritten. Statik, Dachaufmaß oder Netzanschluss lassen sich in diesen Systemen nur mit erheblichem Zusatzaufwand oder externen Schnittstellen abbilden – sie sind für Variantenkonfiguration gebaut, nicht für Planungsdaten.

Auf der anderen Seite gibt es einen wachsenden Markt an solar-spezifischer Software für Handwerks- und Installationsbetriebe – etwa HERO, ToolTime, Reonic, Leadaro, pds oder Photovate. Diese Tools decken die praktische Seite gut ab: PV-Planung mit Dach- und Stringplanung, Wirtschaftlichkeitsberechnung, Angebots-PDFs, teils digitale Signatur, CRM- und Projektpipeline-Funktionen.

Für die Planung und Angebotserstellung nutzen manche Anbieter Integrationen mit spezialisierten Solarplanungs-Tools, die Dach- und Stringplanung inklusive Wechselrichterdimensionierung, automatisch generierter Schaltpläne sowie 3D-Planung auf Basis von Satellitenbildern oder Drohnenaufnahmen umfassen.

Auch Finanzierungsbausteine werden zunehmend direkt integriert.

Ein Anbieter hat kürzlich eine Finanzierungslösung in seine Angebotssoftware integriert, sodass Fachbetriebe Ratenkäufe für Photovoltaik, Speicher und Wärmepumpen direkt im Angebotsprozess anbieten können.

Was diesen Solar-Vertikal-Tools in der Praxis oft fehlt, ist die Tiefe einer echten CPQ-Pricing-Engine für komplexere B2B-Konstellationen: mehrstufige Freigabeprozesse für abweichende Rabatte, dynamische Regeln für wechselnde Subunternehmer-Kalkulationen, sauber modellierte Förder- und Finanzierungslogik mit Wahrscheinlichkeiten statt fixer Beträge, oder eine Angebotsversion, die sich automatisch aktualisiert, wenn sich Modulpreise oder der Genehmigungsstatus ändern. Diese Tools sind primär für Endkunden- und kleinere B2B-Projekte optimiert, weniger für die Steuerung großer, mehrstufiger Projekt-Pipelines mit vielen beteiligten Gewerken.

Die Situation in Süddeutschland, Österreich und der Schweiz

Gerade im deutschsprachigen Alpenraum verschärft sich die Komplexität zusätzlich durch die Kleinteiligkeit der Förder- und Genehmigungslandschaft:

• In Deutschland unterscheiden sich Netzanschlussprozesse zwischen Netzbetreibern spürbar, dazu kommen kommunale Förderprogramme neben Bundesförderung.
• In Österreich existieren Bundes- und Landesförderungen parallel, mit unterschiedlichen Fristen, Budgettöpfen und Antragsverfahren – ein Angebot muss oft mit mehreren möglichen Förderszenarien kalkuliert werden.
• In der Schweiz variieren Förderungen und Einspeisevergütungen kantonal und teils sogar auf Gemeindeebene, was eine Standardisierung der Preislogik zusätzlich erschwert.

Für Solarvertriebe, die über mehrere dieser Regionen hinweg tätig sind oder mit wechselnden regionalen Handwerkspartnern arbeiten, heißt das: Eine reine Copy-Paste-Preislogik aus einer Standardsoftware funktioniert selten. Es braucht eine Struktur, die Regionen, Förderprogramme und Partnerkonditionen als eigene, pflegbare Dimensionen behandelt – nicht als Sonderfälle, die hart codiert werden.

Standard kaufen, spezialisiertes Tool nutzen oder selbst bauen?

Für die Frage „Standardsoftware oder Eigenentwicklung“ gibt es keine pauschale Antwort, aber ein paar belastbare Abwägungspunkte aus der CPQ-Praxis generell:

Für Standardsoftware bzw. bestehende Plattformen spricht: Ein einmal sauber modelliertes Preis- und Regelwerk lässt sich auf weitere Märkte oder Regionen übertragen, ohne für jede Variante neue Logik zu programmieren.

Ein sauber aufgebautes Modell kann auf mehrere Länder ausgerollt werden, wobei neue Märkte primär durch zusätzliche Daten statt durch neue Logik ergänzt werden.

Dazu kommt, dass Rollen- und Rechtesysteme, Genehmigungs-Workflows und Partnervertrieb bei etablierten Anbietern bereits mitgeliefert werden, was Entwicklungszeit spart. Über eine Fünf-Jahres-Perspektive betrachtet, ist eine scheinbar günstigere Eigenentwicklung häufig langfristig die teurere Option, unter anderem weil Wartung, Weiterentwicklung und Skalierung dauerhaft eigene Ressourcen binden.

Für eine Eigenentwicklung oder ein individuell zugeschnittenes System spricht: Wenn im Unternehmen ohnehin Entwicklungs-Know-how vorhanden ist und die Preislogik – etwa die Kombination aus Förderszenarien, Subunternehmer-Kalkulation und volatilen Komponentenpreisen – so spezifisch ist, dass sie sich in keiner Standardsoftware sauber abbilden lässt, kann eine eigene Lösung sinnvoll sein, besonders wenn schnelle, eigenständige Anpassungen ohne Abhängigkeit von einem Softwareanbieter gewünscht sind. Der Preis dafür: dauerhafte Personalressourcen für Pflege und Weiterentwicklung, und das Risiko, bei jeder externen Änderung – etwa einer neuen Förderregel – selbst nachbauen zu müssen, statt ein Update vom Hersteller zu bekommen.

Der Mittelweg, der in der Praxis oft übersehen wird: Low-Code. Für Teams mit grundlegenden Entwicklungskenntnissen, aber ohne Kapazität für eine vollständige Eigenentwicklung, können Low-Code-Plattformen einen brauchbaren Kompromiss bieten. Die Entwicklungszeit lässt sich damit gegenüber klassischer Individualentwicklung deutlich verkürzen, und viele Anwendungen erreichen innerhalb weniger Monate Produktionsreife.

Schätzungen zufolge verkürzt Low-Code die Entwicklungszeit im Vergleich zu traditionellen Ansätzen um 50 bis 90 Prozent, wobei die meisten Anwendungen in weniger als drei Monaten produktiv gehen.

Für ein Preisregelwerk, das Förderszenarien, Partnerkalkulationen und Projektstatus abbildet, kann das ausreichen, ohne dass man ein vollständiges CPQ-System neu erfindet. Auch spezialisierte, no-code-fähige CPQ-Bausteine für individuelle Preislogik jenseits starrer Standardregeln existieren mittlerweile am Markt und lassen sich teils punktuell in bestehende Vertriebsprozesse einbinden.

Fazit

Die eigentliche Herausforderung bei CPQ für Solar-B2B liegt selten in der reinen Softwarefrage, sondern darin, dass ein Angebot hier kein statischer Preis ist, sondern ein sich entwickelnder Zustand: abhängig von Planungsdaten, Genehmigungsfortschritt, Förderzusage, Partnerverfügbarkeit und Einkaufspreisen zum jeweiligen Zeitpunkt. Standard-CPQ-Suiten bilden die Preisregel-Seite gut ab, aber nicht die physische Planung. Solar-Vertikal-Tools bilden die Planung und den Betriebsalltag gut ab, aber selten komplexe, mehrstufige B2B-Preislogik.

Wer im süddeutschen, österreichischen oder Schweizer Raum mit größeren Projekten, wechselnden Handwerkspartnern und mehreren parallelen Förderprogrammen arbeitet, kommt deshalb häufig um eine Kombination nicht herum: eine belastbare Basis (Standardsoftware oder spezialisiertes Solar-Tool) plus eine gezielt ergänzte, eventuell auch selbst oder per Low-Code gebaute Preis- und Regelschicht für genau die Punkte, die generisch nicht abgebildet werden.