ERP-Integration und Stücklistenverwaltung
Wenn ein Entwicklerteam ein ERP-Integrationsprojekt startet, dreht sich die Diskussion in der Regel darum, was entwickelt werden muss: wie Stücklisten übertragen werden, wie Artikel angelegt werden und wie Lebenszyklusstatus den ERP-Statuscodes zugeordnet werden. Weniger Beachtung findet dabei die in jedem Standard-Integrationspfad enthaltene Annahme, dass die Vault-Umgebung bereits so strukturiert ist, wie es die Integration erwartet.
Für die Rohstoffverwaltung hat diese Annahme konkrete Konsequenzen. Wenn ein Entwicklungsteam bereits über einen etablierten Prozess zur Identifizierung von Rohstoffen in Vault verfügt und dieser Prozess nicht mit dem übereinstimmt, was die Integrationsschicht auslesen soll, stellt sich die Frage, ob der bestehende Workflow neu aufgebaut oder die Integration an ihn angepasst werden soll. Die Antwort darauf ist wichtiger, als es zunächst erscheinen mag.
Wie Rohstoffdaten typischerweise von Vault ins ERP übertragen werden
Bei einer Standardintegration von Vault zu ERP folgt die Rohstoffverwaltung einem definierten Pfad. Dateien, die Rohstoffe darstellen, werden über in Inventor zugeordnete Eigenschaften gekennzeichnet. Während der Stücklisten- und Artikelübertragung liest die Integration diese zugeordneten Vault-Eigenschaften aus und verwendet sie, um die Rohstoffdetails im entsprechenden ERP-Artikel zu füllen.
Wenn die Vault-Umgebung dieser Struktur folgt, ist der Prozess zuverlässig und konsistent. Die richtigen Eigenschaften sind in den richtigen Dateien vorhanden, die Integration liest sie während der Übertragung aus, und der ERP-Artikel erhält korrekte Rohstoffdaten, ohne dass das Konstruktionsteam bei jedem Schritt manuell eingreifen muss.
Wenn ein bestehender Workflow einen anderen Weg einschlägt
Ein Kunde kam mit einem bereits etablierten Prozess zur Rohstoffidentifizierung zu diesem Integrationsprojekt. Eine Vault-Eigenschaft kennzeichnete Dateien als Rohstoffe, und das Konstruktionsteam pflegte eine genehmigte Liste mit Rohstoffbeschreibungen und Artikelnummern als CSV-Datei, die in Vault gespeichert war. Diese CSV-Datei war die operative „Quelle der Wahrheit“: Sie erfasste, welche Rohstoffe das Team als für die aktuelle Konstruktionsarbeit gültig festgelegt hatte, und die Kennzeichnung der Eigenschaften in Vault richtete sich danach.
Das Team hatte diese Liste aus Gründen erstellt, die spezifisch für seine Umgebung waren. Das ERP-System enthielt weitaus mehr Lagerartikel, als das Konstruktionsteam den Konstrukteuren anzeigen wollte: veraltete Materialien, historische Einkaufseinträge und Optionen, die eher zur Produktionsbeschaffung gehörten als zu aktiven technischen Entscheidungen. Eine direkte Abfrage des ERP-Systems bei jeder Materialrecherche hätte all diese Optionen zurückgegeben und während der Konstruktionsarbeit eine direkte Abhängigkeit von der ERP-Verbindung geschaffen. Indem das Team stattdessen eine kürzere, kuratierte Liste in Vault pflegte, konzentrierte es die Materialauswahl auf das, was tatsächlich genehmigt und relevant war, und die Verantwortung für diese Liste lag beim Konstruktionsteam und nicht beim Einkauf oder in der Produktion. Die CSV-Datei war bereits in Vault eingecheckt und wurde dort im Rahmen der Arbeitsabläufe des Teams aktualisiert.
Der Workflow war bereits so lange etabliert, dass eine Neugestaltung auf Basis der Standard-Integrationsstruktur kein praktikabler Ansatzpunkt war. Die Frage war, ob „powerGate“, die Vault-zu-ERP-Integrationslösung von coolOrange, mit dem bereits vom Team verwendeten CSV-basierten Ansatz funktionieren könnte, anstatt dass das Team die von der Standardvorgehensweise erwartete, auf Inventor abgestimmte Eigenschaftsstruktur übernehmen musste.
Anpassung der Integration an den bereits bestehenden Prozess
Anstatt den Kunden zu bitten, die Art und Weise zu ändern, wie Rohstoffe in Vault identifiziert werden, wurde powerGate so konfiguriert, dass es während der Stücklisten- und Artikelübertragung aus der CSV-Datei liest. Anstatt Rohstoffdetails aus zugeordneten Inventor-Eigenschaften abzurufen, liest die Integration die in Vault gespeicherte CSV-Datei, findet anhand der Rohstoffbeschreibung die entsprechende Zeile und übergibt die relevanten Informationen an den ERP-Artikel.
Das Ergebnis auf ERP-Ebene ist dasselbe wie bei einer Standardimplementierung: Der Artikel erhält während der Übertragung korrekte Rohstoffdaten. Was sich geändert hat, ist die Quelle, aus der die Integration diese Daten bezieht. Die CSV-Datei übernimmt die Rolle, die die zugeordneten Inventor-Eigenschaften im Standardpfad spielen, und der restliche Prozess der Stücklisten- und Artikelübertragung läuft unverändert weiter.
Das Dateiformat ist ein Detail, das das Team auf der Grundlage der Lesweise durch die Automatisierung festgelegt hat: CSV erwies sich für die Art der Abfrage, die powerGate während der Übertragung durchführt, als zuverlässiger als Excel. Operativ entscheidend ist, dass die Integration nun konsistent aus derselben Quelle liest, die das Entwicklungsteam bereits pflegt, ohne dass eine parallele Datenstruktur daneben existieren muss.
Was dies für Teams bedeutet, die sich in einer ähnlichen Situation befinden
ERP-Integrationsprojekte, die von einer „sauberen“ Vault-Umgebung ausgehen, können mehr Störungen verursachen, als die Integration eigentlich beheben soll. Wenn Entwicklungsteams erfahren, dass ihr bestehender Rohstoffprozess umstrukturiert werden muss, bevor die Integration fortgesetzt werden kann, erweitert sich der Projektumfang, noch bevor eine einzige Stückliste übertragen wurde, und das Vertrauen in die Integration sinkt, noch bevor sie die Chance hatte, ihren Wert unter Beweis zu stellen.
Die Alternative ist eine Integrationsschicht, die flexibel genug ist, um sich an die bestehende Entwicklungsumgebung anzupassen. Dies ist kein Argument gegen den Standardansatz: Der standardmäßige Rohmaterial-Workflow von powerGate über zugeordnete Inventor-Eigenschaften ist für die meisten Implementierungen der richtige Ausgangspunkt und lässt sich im Laufe der Zeit leichter pflegen. Es bedeutet jedoch, dass eine Abweichung von diesem Weg die Integration nicht blockieren muss und die Teams nicht zu einer Neugestaltung zwingt, mit der sie zu Beginn des Projekts nicht gerechnet hatten.
Für Konstruktionsteams, deren Prozess zur Rohstoffidentifizierung in Vault bereits etabliert ist und funktioniert, kann die Integration so angepasst werden, dass sie darauf zurückgreift. Der vom Team aufgebaute Prozess bleibt bestehen. Die ERP-Integration arbeitet parallel dazu, anstatt dessen Ersatz zu erfordern.
