Ihr Konfigurator ist nicht das Problem. Ihre Architektur könnte es sein.

In der Fertigungsindustrie gibt es einen Moment, den jeder kennt.

Der Vertrieb will schneller Angebote versenden. Die Technik will weniger Unterbrechungen. Die IT wünscht sich eine wartbare Lösung. Das Controlling will einen Business Case, der ohne den Satz „das klären wir später“ auskommt.

Dann stellt jemand eine absolut berechtigte Frage:

„Sollten wir einfach unseren eigenen Konfigurator entwickeln?“

Jemand anderes schlägt den Kauf eines CPQ-Systems vor. Eine dritte Person erwähnt eine bestehende Plattform. Innerhalb kürzester Zeit wird das Meeting zu einer Debatte über Software, Lizenzen, APIs und die Frage, ob das aktuelle ERP-System nicht irgendwie alles erledigen kann.

Währenddessen bleibt das eigentliche Problem unangetastet.

Kunden warten auf Angebote. Ingenieure prüfen Konfigurationen, die verdächtig denen ähneln, die sie letzten Dienstag geprüft haben. Und der Vertrieb fragt immer noch Bob aus der Technik, ob diese eine bestimmte Komponenten-Kombination funktioniert.

Bob kennt die Antwort. Bob kennt immer die Antwort.

Genau das ist das Problem.

Eigenentwicklung vs. Kauf: die falsche Einstiegsfrage

Die eigene Software zu entwickeln, klingt aus guten Gründen attraktiv.

Sie kontrollieren die Funktionalität. Sie können das Nutzererlebnis auf Ihre Produkte zuschneiden. Sie sind nicht gezwungen, Ihr Geschäft nach den Vorstellungen eines anderen zu organisieren.

Und wenn Ihre Produkte wirklich komplex sind, sind diese Punkte entscheidend.

Aber Softwareentwicklung ist kein einmaliges Ereignis. Sie schafft eine dauerhafte Verantwortung für Entwicklung, Wartung, Sicherheit, Infrastruktur und alles, was passiert, wenn sich das Geschäft ändert.

Ihre Produktpalette entwickelt sich weiter. Preise ändern sich. Neue Märkte entstehen. ERP-Systeme werden aktualisiert. Der Entwickler, der vor fünf Jahren den cleveren Code geschrieben hat, macht heute vielleicht etwas völlig anderes.

Herzlichen Glückwunsch. Sie besitzen jetzt nicht nur ein Produktionsunternehmen, sondern auch ein Softwareprodukt.

Der Kauf von Software hat ebenfalls Vorteile. Etablierte Funktionalität, vorhandene Infrastruktur und ein gewartetes Produkt können erheblichen Aufwand sparen. Aber eine Plattform, die für Standard-Katalogprodukte hervorragend funktioniert, kann an ihre Grenzen stoßen, wenn Ihr Produkt auf komplexen technischen Regeln basiert.

Und die teuerste Einschränkung ist nicht unbedingt ein fehlendes Feature.

Es ist die Erkenntnis, dass Ihr gesamter Prozess an die Software angepasst werden muss.

Keiner der Ansätze ist per se richtig oder falsch. Die Entscheidung hängt von Ihren Produkten, Ihrem Wettbewerbsvorteil, Ihren internen Fähigkeiten und der Komplexität ab, die Sie tatsächlich unterstützen müssen.

Das bringt uns zu einer nützlicheren Frage:

Was sollten Sie selbst besitzen und was sollten Sie nicht ständig neu erfinden?

Die dritte Option: das Fundament kaufen, den Vorteil selbst entwickeln

Die Wahl steht nicht immer nur zwischen dem Kauf eines Standardsystems und der vollständigen Eigenentwicklung.

Es gibt einen Mittelweg.

Nutzen Sie eine etablierte Plattform für die Funktionen, die sie gut beherrscht. Entwickeln Sie die produktspezifische Logik, das visuelle Erlebnis, die Integrationen und die Workflows, die Ihr Unternehmen einzigartig machen, selbst.

Stellen Sie es sich wie den Bau eines Hauses vor.

Sie wollen wahrscheinlich nicht Ihre eigenen Ziegel herstellen, einen neuen Elektrostandard entwickeln und ein Sanitärsystem erfinden, bevor Sie einziehen können. Aber vielleicht wünschen Sie sich einen ungewöhnlichen Grundriss.

Bei Software funktioniert das ganz ähnlich.

Eine passende Plattform kann das Fundament bilden. Ihre eigene Anwendungslogik kann die Teile übernehmen, die tiefes Wissen über Ihre Produkte und Prozesse erfordern.

Für einen Hersteller könnte das ein visueller Konfigurator sein, mit dem Händler ein Lagerlayout entwerfen. Für einen anderen könnte es eine Anwendung sein, die Maschinen konfiguriert, Komponenten-Kombinationen validiert und präzise technische Dokumentationen erstellt.

Die zugrundeliegende Technologie muss nicht einzigartig sein.

Die Art und Weise, wie Sie Ihr Produktwissen in einen Wettbewerbsvorteil verwandeln, ist es aber vielleicht schon.

Natürlich ist der Mittelweg nicht automatisch die günstigste oder einfachste Option. Es hängt von den Erweiterungsmöglichkeiten der Plattform, dem Lizenzmodell, den Integrationsfähigkeiten und dem Umfang der erforderlichen Eigenentwicklung ab.

Das Ziel ist nicht, die Entwicklung von Software zu vermeiden. Das Ziel ist, bewusst zu entscheiden, was Sie entwickeln.

CPQ vs. Engineering Automation: Zwei Lösungen für unterschiedliche Probleme

Angenommen, Sie stellen konfigurierbare Industrieprodukte her.

Ein Kunde wünscht sich eine Lösung. Ihr Vertriebsteam muss die Anforderungen verstehen, die richtigen Komponenten auswählen, einen Preis kalkulieren und ein Angebot versenden.

Hier kommt CPQ ins Spiel.

CPQ steht für Configure, Price, Quote. Es hilft Unternehmen, Produktauswahl, Konfigurationsregeln, Preisgestaltung und Angebots-Workflows zu verwalten.

Ein guter CPQ-Prozess kann inkompatible Auswahlen verhindern, kaufmännische Regeln konsistent anwenden und den manuellen Aufwand zwischen Kundenanfrage und Angebot reduzieren.

Aber es gibt eine wichtige Unterscheidung.

Zu wissen, was man verkaufen darf, ist nicht immer dasselbe wie zu wissen, wie man es konstruiert.

Nehmen wir einen Hersteller von Palettenregalen.

Ein Vertriebsmitarbeiter muss ein Lagerlayout konfigurieren. Das System muss dabei Abmessungen, verfügbare Komponenten, Produktkompatibilität und Preise berücksichtigen.

Das ist bereits komplizierter als die Auswahl eines Produkts aus einem Dropdown-Menü.

Fügen wir nun die technischen Anforderungen hinzu.

Welches Trägerprofil ist für die Last geeignet? Erfüllt die Konfiguration die relevanten statischen Anforderungen? Sind die ausgewählten Komponenten für den vorgesehenen Einsatzzweck geeignet? Welche Berechnungen oder Prüfungen sind erforderlich, bevor die Konstruktion freigegeben werden kann?

Diese Fragen erfordern Ingenieurwissen, nicht nur kaufmännische Regeln.

Einige CPQ-Systeme können komplexe technische Randbedingungen und Berechnungen verarbeiten. Andere konzentrieren sich hauptsächlich auf Produktauswahl, Preisgestaltung und Angebote. Ebenso kann Engineering Automation als separate Anwendung existieren oder direkt in den Konfigurations-Workflow integriert sein.

Die Bezeichnungen allein sagen noch nichts darüber aus, was ein System leisten kann.

Entscheidend ist, ob die Software die tatsächlichen Regeln, die für Ihre Produkte gelten, abbilden und anwenden kann.

Eine praktische Unterscheidung

Diese Funktionalitäten überschneiden sich. Sie müssen nicht in getrennten Produkten untergebracht sein, und es gibt keine universelle Architektur, der jeder Hersteller folgen sollte.

Der Punkt ist, dass sie unterschiedliche Teile des Problems lösen.

Wenn Sie eine Software nur nach ihrer Fähigkeit bewerten, ein Angebot zu erstellen, übersehen Sie möglicherweise die technische Arbeit, die stattfinden muss, bevor dieses Angebot sicher versendet werden kann.

Und wenn Sie sich ausschließlich auf technische Berechnungen konzentrieren, übersehen Sie möglicherweise das Vertriebserlebnis, das darüber entscheidet, wie einfach Kunden und Händler das Ergebnis nutzen können.

Die Chance liegt darin, beides zu verbinden.

Der wahre Engpass ist oft die Übergabe

Stellen Sie sich Ihren aktuellen Vertriebsprozess vor.

Ein Kunde sendet eine Anfrage. Der Vertrieb interpretiert die Anforderungen. Jemand erstellt eine Vorkonfiguration. Die Technik prüft sie. Der Vertrieb passt den Vorschlag an. Die Technik prüft erneut. Eine Komponente ändert sich, der Preis ändert sich, und jemand aktualisiert das Angebot.

Keine dieser einzelnen Aufgaben ist für sich genommen unangemessen.

Das Problem sind die wiederholten Übergaben von Informationen und Entscheidungen zwischen Menschen und Systemen.

Ingenieure verbringen Zeit damit, Routinekonfigurationen zu prüfen. Der Vertrieb wartet auf Antworten auf Fragen, die schon viele Male beantwortet wurden. Produktwissen existiert in Tabellenkalkulationen, Dokumenten und den Köpfen der Mitarbeiter.

Sie können ein neues CPQ-System kaufen und dieses Problem immer noch haben.

Sie können einen wunderschönen 3D-Konfigurator entwickeln und dieses Problem immer noch haben.

Sie können KI einführen und dieses Problem immer noch haben.

Wenn die zugrundeliegenden Produktregeln fehlen, die Daten unzuverlässig sind oder der Workflow schlecht konzipiert ist, löst eine weitere Benutzeroberfläche das Problem nicht auf magische Weise.

Das Ziel sollte sein, wiederholbare Entscheidungen in einen kontrollierten, wartbaren Prozess zu überführen.

Wo eine Konfiguration automatisch validiert werden kann, sollte die Software dies tun. Wo eine Berechnung standardisiert und verifiziert werden kann, machen Sie sie wiederverwendbar. Wo eine Entscheidung wirklich technisches Urteilsvermögen erfordert, behalten Sie den Ingenieur im Prozess.

Das Ziel ist nicht, Ingenieure aus dem Prozess zu entfernen.

Es geht darum, teures Ingenieur-Know-how nicht mehr für Arbeit zu verwenden, von der das Unternehmen bereits weiß, wie sie zu erledigen ist.

Was sollten Sie also tatsächlich entwickeln?

Bevor Sie eine Plattform auswählen, ein Entwicklungsprojekt starten oder eine Ausschreibung versenden, stellen Sie sich fünf Fragen.

1. Wo genau verlangsamt sich der Prozess?

Bilden Sie den Weg von der Kundenanfrage bis zum Angebot und zur Lieferung ab. Finden Sie die Warteschlangen, wiederholten Prüfungen, doppelte Dateneingaben und manuellen Entscheidungen. Beginnen Sie beim Engpass, nicht bei der Technologie.

2. Welche Entscheidungen sind wiederholbar?

Trennen Sie einfache kaufmännische Regeln von technischen Berechnungen und Entscheidungen, die Expertenurteil erfordern. Identifizieren Sie, was zuverlässig automatisiert werden kann und wer für die Validierung verantwortlich ist.

3. Was ist wirklich einzigartig an Ihrem Unternehmen?

Ihr Produktwissen, Ihre Engineering-Methoden und Ihr Kundenerlebnis können Differenzierungsmerkmale sein. Authentifizierung, Infrastruktur und standardisierter Datenaustausch sind es möglicherweise nicht. Gehen Sie nicht davon aus, dass jede Komponente intern entwickelt werden muss.

4. Was passiert, wenn sich das Geschäft ändert?

Fragen Sie, wie einfach die Lösung neue Produkte, neue Regeln, zusätzliche Integrationen und neue Märkte aufnehmen kann. Berücksichtigen Sie die laufenden Eigentumsverhältnisse, Lizenzierung, Wartbarkeit und die Abhängigkeit von einzelnen Entwicklern oder Anbietern.

5. Können Sie klein anfangen, ohne sich in eine Sackgasse zu manövrieren?

Sie müssen nicht unbedingt jede Produktfamilie und jeden Prozess vom ersten Tag an automatisieren. Eine fokussierte erste Phase kann den Ansatz mit einer echten Produktkategorie und echten Nutzern beweisen und gleichzeitig ein Fundament schaffen, das später erweitert werden kann.

Die Architektur sollte den nächsten Schritt unterstützen, ohne dass Sie jedes zukünftige Problem im Voraus lösen müssen.

Die beste Architektur ist die, die das Geschäftsproblem löst

Es gibt keinen universellen Gewinner in der Debatte „Eigenentwicklung vs. Kauf“.

Manchmal ist eine Standard-CPQ-Lösung genau das, was Sie brauchen. Manchmal ist eine maßgeschneiderte Anwendung gerechtfertigt. Manchmal ist die richtige Antwort ein visueller Konfigurator, der mit technischen Berechnungen, einem ERP-System und einem Händlerportal verbunden ist.

Und manchmal ist das Erste, was Sie reparieren müssen, der Prozess selbst.

Die Technologie sollte dem Problem folgen.

Bei NorrLab arbeiten wir mit Herstellern zusammen, deren Produkte mehr als nur eine einfache Auswahl von Optionen erfordern. Wir entwickeln visuelle Produktkonfiguratoren und vernetzte Software, die Produktwissen, Konfigurationsregeln, Engineering Automation und Geschäftssysteme zusammenführen.

Unser Ziel ist es nicht, Ihnen das größtmögliche Softwareprojekt zu verkaufen. Es geht darum, zu erkennen, wo bessere digitale Werkzeuge Reibungsverluste beim Verkauf, der Konfiguration und der Lieferung Ihrer Produkte beseitigen können.

Denn der beeindruckendste Konfigurator ist nicht unbedingt der mit den meisten Funktionen.

Es ist der, der Ihrem Unternehmen hilft, die richtigen Entscheidungen schneller zu treffen – ohne dass Bob alles prüfen muss.

Produktkonfiguration. Und mehr.

Wollen Sie herausfinden, wo Konfiguration und Automatisierung in Ihrem Unternehmen einen Unterschied machen könnten? Beginnen wir mit dem Prozess, nicht mit der Software.