Lösungsfindung: Intercompany mit Variantenkonfigurator

Moin,

wir stehen gerade vor einer Herausforderung im Bezug auf die Intercompany-Schnittstelle, für die ich gerne mal Erfahrungswerte aus der Community in die Überlegungen mit einbeziehen möchte.

Ausgangslage
Wir sind eine international vertretene Unternehmensgruppe mit einer heterogenen Applikationslandschaft, die jetzt Stück für Stück vereinheitlicht werden soll. Im Headquarter nutzen wir aktuell noch NAV 2018, welches mittelfristig auf ein BC OnPrem umgestellt werden soll. Aktuell nutzen zwei weitere Tochtergesellschaften ein NAV 2018. Eine in derselben Datenbank, eine weitere wegen lokalen Anforderungen eine gesonderte DB.

Das HQ produziert in Auftragsfertigung hochkomplexe Anlagen mit einer hohen Variantenvielfalt. Zu diesem Zweck ist ein Produktkonfigurator in unser NAV integriert, der die Zusammenstellung der Geräte deutlich vereinfacht und hinten raus die Stücklisten für die Fertigungsaufträge erzeugt. Da dieser Konfigurator sehr Stammdatenintensiv und damit auch fehleranfällig ist, wird er aktuell und soll auch weiterhin nur im Headquarter-System zur Detailkonfiguration der Anlagen genutzt werden.

Ausblick
Um einen einheitlichen Vertriebsprozess zu etablieren, soll ein Gruppenweites CRM eingeführt werden, welches dem Vertrieb die Möglichkeit bietet, Kundenangebote zu generieren. Hier soll die Logik des Konfigurators adaptiert werden um im ersten Schritt eine High-Level Konfiguration zu ermöglichen.

Weiterhin sollen dann mittelfristig die einzelnen Gesellschaften auf BC umgestellt werden (je nach Größe: SaaS oder OnPrem, SaaS soll aber im Fokus liegen).

Für ein Rollout sind mMn zwei Aspekte vorher zu klären:
1. Wie kann eine Stammdatensynchronsation etabliert werden (maßgeblich Artikel und verbundene Stammdaten wie Einheiten, Übersetzungen etc.)
i) Annahme: NAV 2018 OnPrem <-> BC SaaS
2. Wie können per Intercompany-Schnittstelle Bestellungen/Aufträge/Lieferungen ausgetauscht werden
i) Standard IC unterstützt weder Übergabe von Varianten noch von Lieferungen (müssen manuell gebucht werden)

Für die Stammdatensynchronisation werden wir sicher eine Lösung finden. Hier gibt es diverse Module bspw. von integro.PL, XtensionIT etc. die unsere Anforderungen offenbar abdecken. Auch eine synchronisation zwischen unterschiedlichen Systemversionen scheint grundsätzlich kein Problem zu sein.

Aus meiner Sicht ist die Frage wie mit dem Intercompany umgegangen wird, die viel wichtigere. Für die ich bisher auch keinen schönen Lösungsansatz habe. Der grobe Ablauf wird folgender sein:
1) Grobkonfiguration im CRM
2) Bei Bestellung -> Angebot in HQ anlegen
3) Detailkonfiguration durch PM im HQ System
4) Auftragserstellung und mit Auftragsbestätigung den entsprechenden Auftrag + Bestellung im System der TG anlegen

Nur wie geht man Charmant mit den Varianten um?
a) Alles über eine Artikelnummer ohne Varianten laufen lassen und dann die Auftragsbezogenen Preise in die Bestellung + Auftrag der TG übergeben? -> ggf. Problem mit der Lagerbewertung da große Schwankungen in den EPs
b) Varianten + Lagerhaltungsdaten über Stammdatensynchronisation vorher im System der TG anlegen und dann die Varianten in den Aufträgen/Bestellungen mit übergeben? -> Problem bei Grundlegenden Änderungen am Produkt, wenn Preise sich ändern.

Hat hier jemand Erfahrungen mit einer ähnlichen Konstellation und Vorschläge wie man das optimalerweise abbildet? Oder zumindest eine Option, die ich bisher nicht bedacht habe?

Ich würde mich über Erfahrungswerte bzgl. Intercompany und Stammdatensynchronisation und einen offenen Austausch freuen.

Vielen Dank und beste Grüße

[Timo Lässer]

Moin kinsion,

ich befasse mich seit 25 Jahren beruflich mit der Frage, wie man variantenreiche Produkte effizient in verschiedenen Geschäftsprozessen behandelt. Wenngleich ich nicht in einem produzierenden Unternehmen arbeite, habe ich bereits zahlreiche Unternehmen dabei begleitet und beraten vergleichbare Herausforderungen, wie jene die Du beschreibst, zu lösen.
Ich habe mich mal mit einem Kollegen von mir hingesetzt und wir haben uns dein Problem vorgenommen. Folgendes sind unsere Gedanken dazu:
Zunächst einmal möchten wir dich in deinen bisherigen Entscheidungen bestärken: Es ist gut und richtig die Bereiche „Low-Level“ (oder auch „Detail-“ bzw. „Auftrags-Konfiguration“) und „High-Level“ (oder auch „Vertriebs-“, „Angebots“, „Grob-Konfiguration“) zu trennen. Diesen Ansatz empfehlen wir generell, im speziellen aber Maschinen- und Anlagenbauern.
Auch in dem Aspekt, dass das Angebotswesen noch vollständig ohne Varianten (im Sinne der Fertigung bzw. Lagerhaltung) auskommen sollte sind wir voll und ganz bei Dir. Dafür benutzt man am besten Standard-Software (CPQ-Systeme „Configure-Price-Quote“). Unserer Erfahrung nach reichen die Konfiguratoren aus den CRM-Standard hier nicht aus, um die Anforderungen des Vertriebs abzudecken.
Die spannende Frage ist natürlich, wie ein verbindlicher Preis zu Stande kommen kann, wenn die Preise eben nur auf Varianten-Ebene gepflegt sind und diese Stammdaten in den lokalen CRM Systemen (also in den Tochtergesellschaften) nicht zur Verfügung stehen. Hier sind wir bereits häufig mit dem Ansatz ins Rennen gegangen die Preisbildung eben auch in einem CPQ System umzusetzen, welches „zentral“ (meint hier: durch das HQ gepflegt und in allen TG verwendet) bereitgestellt wird. Damit spart man im Prinzip die Stammdatensynchronisation von Produkten/Varianten/Artikeln zwischen zentralem ERP und den diversen CRM der TG ein und verlagert diesen Prozess auf das zentrale ERP und das zentrale CPQ System. Das CPQ System wiederum befüllt die diversen CRM dann lediglich noch mit Informationen um Reporting-Prozesse (z.B. Sales-Funnel usw.) zu unterstützen. Das unterstellt natürlich, dass ausschließlich das HQ produziert und die Töchter selbst nur Vertriebs-Organisationen sind. Ob das der Realität in deinem Unternehmen entspricht, wissen wir natürlich nicht genau. Da können wir gerne in die Details abtauchen.

(Werbenden Text entfernt)

Dr. Thorsten Krebs

Zuletzt geändert von Timo Lässer am 9. Mai 2023 07:55, insgesamt 1-mal geändert.
Grund: Werbenden Text entfernt