Was die CPQ-Integration in beide Richtungen leisten muss
Ein Konfigurator ist nur so gut wie die Daten, mit denen er gespeist wird, und der Auftrag, den er generiert. Beide Richtungen überschreiten eine Systemgrenze.
- Produkt- und Optionsdaten (eingehend): welche Komponenten, Funktionen und Varianten aktuell verfügbar sind, verwaltet durch das ERP oder das Produktinformationssystem
- Kosten und Preise (eingehend): aktuelle Kosten, Vertragspreise und Rabattbefugnisse aus dem ERP, damit ein Angebot die Marge widerspiegelt und nicht nur den Listenpreis
- Verfügbarkeit und Lieferzeit (eingehend): ob die Kombination zum versprochenen Termin geliefert werden kann – eine Information, die nur das ERP oder das Planungssystem kennt
- Die Konfiguration (ausgehend): das angenommene Angebot wird in einen ERP-Kundenauftrag umgewandelt, inklusive der daraus resultierenden Stückliste und Arbeitspläne
- Auftragsstatus zurück an den Vertrieb: Fortschritt bei Produktion und Versand wird an das CRM zurückgemeldet, damit der Vertrieb dem Kunden Auskunft geben kann
Die meisten CPQ-Implementierungen lösen den ersten eingehenden Datenfluss durch einen periodischen Produktexport und belassen es dabei. Der ausgehende Fluss – die Umwandlung eines angenommenen Angebots in einen Auftrag – wird fast immer manuell erledigt.
Warum wird ein konfiguriertes Angebot manuell in das ERP übertragen?
Ein Konfigurator und ein ERP beschreiben dasselbe Produkt in unterschiedlichen Sprachen. Ein CPQ betrachtet eine Konfiguration als Auswahl von Optionen für ein Modell – so denkt der Vertrieb. Das ERP benötigt eine Stückliste und einen Arbeitsplan – so denkt die Fertigung. Die Übersetzung zwischen diesen Systemen erfordert die Definition, wie jede Option auf Teile und Arbeitsschritte abgebildet wird. Es ist bequemer, dies jedes Mal einer Person zu überlassen, als es einmalig grundlegend zu lösen.
Konfigurierbare Produkte treiben die Übersetzung über das hinaus, was man im Voraus erstellen kann. Ein Produkt mit fünfzehn Optionsgruppen hat mehr gültige Kombinationen, als ein Unternehmen jemals als feste Teilenummern definieren könnte. Der ERP-Eintrag wird daher für jeden Auftrag neu zusammengestellt – genau die Arbeit, die das CPQ eigentlich hätte erledigen sollen. Das ist ein Grund, warum ERP-Integration in der Fertigung selten bei einer einzigen Zuordnung stehen bleibt.
Nichts davon taucht im Business Case für CPQ auf, da dieser auf der Geschwindigkeit der Angebotserstellung basiert. Die Kosten dafür fallen erst später an und landen in einer anderen Abteilung.
Was eine schwache CPQ-Integration nach dem Verkauf kostet
Die Verluste entstehen in der Produktion, im Finanzwesen und im Vertrieb – weshalb sie niemand zusammenrechnet und auf die Angebotserstellung zurückführt.
- Konfigurationsfehler, die die Produktion erreichen: eine falsch eingegebene Option führt dazu, dass eine Einheit mit der falschen Spezifikation gebaut wird, was erst bei der Prüfung oder durch den Kunden bemerkt wird
- Angebote auf Basis veralteter Kosten: eine Konfiguration, die auf einer Kostenliste vom letzten Quartal basiert, für ein Produkt, dessen Materialpreise sich geändert haben
- Liefertermine ohne Kapazitätsprüfung versprochen: eine Lieferzeit, die auf einem Standardwert basiert und nicht auf dem aktuellen Auftragsbestand
- Vertrieb kann Statusanfragen nicht beantworten: der Kunde fragt nach dem Status seiner Bestellung und der Vertriebsmitarbeiter muss erst nachfragen
Der erste Punkt erreicht den Kunden, da eine Einheit, die nach einer Spezifikation gebaut wurde, die niemand verkauft hat, zu Nacharbeit oder einer Gutschrift führt. Alle vier Punkte konzentrieren sich auf eine bestimmte Art von Unternehmen.
Konfigurierbare Produkte sind der Bereich, in dem sich die CPQ-Integration bezahlt macht
Unternehmen, die Standardkatalogartikel verkaufen, benötigen selten ein CPQ, da ein Angebot lediglich ein Nachschlagen in der Preisliste ist. Ein Händler, der verpackte Befestigungselemente anbietet, liest einfach eine Nummer von einer Liste ab. Ein Hersteller, der eine Industriepumpe anbietet, spezifiziert Laufradgröße, Dichtungsmaterial, Motorleistung und Beschichtung – und jede Kombination erfordert einen anderen Teilesatz und einen anderen Fertigungsablauf.
Deshalb ist das Tool in der auftragsbezogenen Fertigung unverzichtbar und deshalb ist die Übergabe an das ERP dort am schwierigsten. Die Komplexität, die die manuelle Angebotserstellung verlangsamt, ist dieselbe Komplexität, die es schwierig macht, eine Konfiguration in einen fertigungsreifen Auftrag zu verwandeln. Den vorderen Teil des Prozesses zu lösen, ohne den hinteren Teil zu berücksichtigen, verschiebt den Engpass nur, anstatt ihn zu beseitigen.
Hersteller, die den vollen Nutzen aus CPQ ziehen, betrachten das Konfigurationsmodell als gemeinsame Infrastruktur und nicht als reines Vertriebstool. Die Regeln, die festlegen, was gebaut werden kann, sind zentral hinterlegt; sowohl das Angebot als auch der Auftrag basieren darauf. Die Aktualisierung dieser Regeln erfordert dieselbe Disziplin wie bei technischen Änderungsmitteilungen, da sich eine geänderte Option auf beiden Seiten widerspiegeln muss. Es stellt sich also die praktische Frage, wo die Verbindung zwischen Angebot und Auftrag tatsächlich implementiert wird.
Wie verbindet eine Integrationsplattform CPQ mit dem ERP?
Die Verbindung zwischen Angebot und Auftrag wird an einer von drei Stellen realisiert, wobei jede ihre eigenen Grenzen hat. Erstens: CPQ direkt im ERP ausführen. Dies macht die Übergabe überflüssig, führt jedoch meist zu einem schwächeren Verkaufserlebnis. Zweitens: Ein spezialisiertes CPQ-System, das über einen Standard-Konnektor an das ERP angebunden ist. Dies deckt gängige Systemkombinationen ab, stößt aber bei komplexen Produktmodellen – was bei konfigurierbaren Produkten meist der Fall ist – an seine Grenzen. Drittens: Ein Mitarbeiter liest das Angebot und überträgt es manuell in das ERP. Dies ist die gängige Praxis in den meisten Unternehmen und begrenzt den Nutzen erheblich.
Um eine validierte Konfiguration in das ERP zu übertragen, sie auf Basis aktueller Kosten zu kalkulieren und gegen den Auftragsbestand zu prüfen, benötigen Hersteller eine Zwischenschicht zwischen dem Konfigurator und den nachgelagerten Systemen. Diese Schicht ist eine Integration Platform-as-a-Service (iPaaS). Die Implementierung der Verbindungen auf dieser Plattform bedeutet, dass jede Verbindung nur einmal konfiguriert und nicht für jede Produktfamilie neu erstellt werden muss. Auf der Alumio iPaaS geschieht dies in vier Formen.
- Konfiguration umgewandelt in eine Auftragsstruktur: ein Daten-Transformer ordnet die ausgewählten Optionen der Stückliste, den Arbeitsplänen und den vom ERP benötigten Teilenummern zu, sodass ein Angebot ohne manuelle Neueingabe zum Auftrag wird
- Kalkulation auf Basis aktueller Kosten: ein Echtzeit-Proxy prüft während der Angebotserstellung die aktuellen Kosten, Vertragspreise und Rabattbefugnisse direkt im ERP, anstatt auf veraltete Tabellen vom letzten Quartal zurückzugreifen
- Verfügbarkeitsprüfung vor der Zusage: dieselbe synchrone Prüfung liest den Auftragsbestand und die Komponentenverfügbarkeit aus, sodass der angebotene Liefertermin auch tatsächlich vom Werk eingehalten werden kann
- Statusrückmeldung an den Vertrieb: eine ereignisgesteuerte Daten-Route übermittelt den Produktions- und Versandfortschritt zurück an das CRM, sodass der Vertrieb Auskünfte direkt aus dem System geben kann, das er bereits nutzt
Diese Abläufe werden konfiguriert, anstatt sie für jede Produktfamilie manuell zu programmieren; für Fälle, in denen die Konfiguration eine Regel nicht abbilden kann, steht der Code-Transformer zur Verfügung. Eine neue Optionsgruppe erfordert lediglich eine Anpassung der Zuordnung, kein neues Projekt. Was sich ändert, ist nicht die Geschwindigkeit der Angebotserstellung, sondern die Gewissheit, dass Angebot und Auftrag exakt dasselbe beschreiben.
Was eine CPQ-Integration für Hersteller bedeutet
CPQ wird oft mit der Geschwindigkeit der Angebotserstellung und der Abschlussquote begründet – beides Kennzahlen für die erste Hälfte des Prozesses. Die Arbeit nach dem Angebot verteilt sich jedoch auf drei Rollen: Der Vertriebsingenieur verantwortet die Konfiguration und ist nach der Kundenunterschrift raus. Der Auftragsadministrator baut sie im ERP nach und trägt das Risiko von Tippfehlern bei den Optionen. Der Produktionsplaner plant auf Basis dessen, was bei ihm ankommt. Da niemand die gesamte Kette überblickt, ist dies eine Entscheidung für die Integration und nicht für eine Schulung.
Die Verbindung des Konfigurators mit dem ERP verändert den Wert des Tools. Ein Angebot, das ohne manuelle Übertragung zum Auftrag wird, behält die validierte Konfiguration bei. Das Unternehmen profitiert von weniger Spezifikationsfehlern in der Produktion, Angeboten auf Basis aktueller Kosten und Lieferterminen, die das Werk auch halten kann.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
