LinkedIn-Post 1
ERP-nahes PLM – Was ist das eigentlich?
Heute möchte ich Paradigma 1, die Object Type Cascade, erläutern.
Die Kaskade der Objekttypen beschreibt die Kette der Objekte, die man zukünftig braucht, um das Lifecycle Management bis ins ERP und darüber hinaus zu stabilisieren.
Die Notwendigkeit der ERP-nahen PLM-Schicht zeigt sich durch die Stabilisierungsanforderung auf dem Shop Floor. Es gilt das Prinzip, dass jeder Mitarbeiter im gesamten Werksverbund auf dem Shopfloor frei sein muss zu überlegen, welches Teil er aus einem Lagerplatz nimmt. Sie müssen alle unter jeder Bedingung passen!
Diese Anforderung ist bei CTO und insbesondere CTO+ Prozessmustern ein absolutes Muss. Bei ETO und STO konnte sie noch lazy behandelt werden.
Wenn man sich also daran macht, dieses Prinzip zu realisieren, stellt man fest, dass es nicht mehr möglich ist, ganz unterschiedliche Aspekte unter einer Materialnummer zu verstecken, sondern man akzeptieren muss, dass unter bestimmten Bedingungen aus einem Part im PLM eben eine Vielzahl an Materialien im ERP entstehen. Man könnte auch sagen, dass aus dem Part im PLM mehrere Materialien im ERP geboren werden.
Das passiert heute regelmäßig! Bei unseren Strukturanalysen finden wir es häufig. Das Problem ist jedoch, dass dies Downstream in der Supply Chain passiert und damit unsichtbar für die Entwicklung ist. Daher wird dieser Effekt auch oft von PLM-Beratern oder Entwicklungsabteilungen negiert oder abgestritten. Die Menschen in der Supply Chain bestätigen diese Effekte jedoch regelmäßig.
Um diesen Aspekt sicher modellieren zu können, braucht man ERP-nah ein Objekt als Klammer, über hinreichend ähnliche Materialien, so dass das Part-Objekt im PLM mit den aus ihm entstandenen Materialien im ERP nachverfolgbar verbunden werden kann.
Konsequent weitergedacht, entsteht daraus eine Kette von Objekttypen (siehe Post Bild), die in einer Kaskade auseinander entstehen.
Daraus ergibt sich das Paradigma 1, die der Objekttypen-Kaskade.
Es postuliert die Notwendigkeit einer Kette aus vernetzten Objekttypen, die eine stabile, jederzeit revisionssichere Nachvollziehbarkeit der im Verlauf der PLM-Prozesse entstandenen Objekte vom PLM bis ins ERP sicherstellen kann.
Heute hat diese Kette noch eine Lücke, da allgemein angenommen wird, dass ein Part im PLM einem Material im ERP entspricht.
Im Bild seht ihr, wie die Kette aus der RIM-Perspektive aussehen sollte. Wie immer ist es unser Best so Far Wissen. Gerne liefere ich auch eine genauere Beschreibung in einem Folgepost.
Falls ihr bei euch im Unternehmen erkennt, dass eure Parts in Wirklichkeit nicht dem Material entsprechen, geht es besser sofort an. Das Risiko, das entsteht, wenn ihr die Object Type Cascade nicht realisiert habt, sollte nicht unterschätzt werden.
Gerne unterstützen wir vom STZ-RIM euch, ein entsprechendes tragfähiges Konzept zu entwickeln und umzusetzen.
LinkedIn-Post 2
ERP nahe PLM – Dimensionen einer Material Bubble 🌐
Lasst uns in die unglaubliche 🌍 und spannende Welt des ERP-nahen PLM tiefer eintauchen 💡.
Im letzten Post habe ich das erste Paradigma des ERP-nahen PLM beschrieben. Dabei habe ich konstatiert, dass sich ein Part im PLM zukünftig in vielen Fällen über eine Materialrealisation ins ERP versorgen lässt und dort eine Material Bubble entsteht.
Heute möchte ich mich den Dimensionen der Material Bubble widmen und erläutern, warum und wie Material im Material Bubble entsteht.
Eines vorab: Ja, es ist prinzipiell möglich, PLM und ERP ohne Berücksichtigung der Material Bubble zu implementieren und dabei so zu tun, als ob diese nicht existiert. Das führt Downstream dann zu einer Reihe sehr unschöner Effekte. Diese bleiben nach der Implementierung ggf. sogar lange Zeit unsichtbar. Die Symptome zeigen sich erst später und an ganz anderen Stellen!
Nun zu den Dimensionen:
Dimension 1: Location (Plant): Das Material muss im Werksbezug angelegt werden, da Material in unterschiedlichen Werken unterschiedlich disponiert wird und auch häufig anderes Rohmaterial hat.
Dimension 2: F3 (Form Fit Function Stabilisation): Wird in der Entwicklung eine Komponente über Revisionen im F3-Korridor geführt, kann es sein, dass diese den Korridor zu weit auslegt. Ebenso ist Interchangeability aus Sicht der Entwicklung oft anders als aus Sicht der Produktion und vollständiger Traceability. In der Folge muss zur Absicherung von F3 dann ggf. eine neue Materialnummer für eine Revision oder zusammenfassend für mehrere Revisionen angelegt werden.
Dimension 3: M(RP)-BOM Snippets: Aus einer Reihe von Gründen müssen Materialnummern in den tiefen Strukturen der M(RP)-BOM ausgetauscht werden. Dies gilt z.B. für Veredelungsteile. Es gibt noch eine Reihe weiterer Fälle, die hier spannend sind, z.B. die Early and Late Component Decision und operational Make or Buy… In vielen Kundendiskussionen kommen inzwischen diese Fälle auf und wir vom RIM haben sie systematisiert und beschrieben.
Aufgabe der Material Realisation ist es dann, im ERP-nahen PLM eine Klammer um den Material Bubble zu bilden.
Nun damit ist das Paradigma 1 und der Material Bubble für LinkedIn hinreichend beschrieben. Weitere Details und Unterstützung bei der Umsetzung bekommt ihr bei uns im STZ-RIM.
Ich freue mich auf eure Kommentare und falls euch noch Fälle für M(RP)-BOM Snippets einfallen, wäre ich auch sehr gespannt.
#ERP #PLM #MaterialBubble #SupplyChain #Innovation #Technology
LinkedIn-Post 3
Paradigms for ERP near PLM – Paradigm 2 – Generic Structure Instance Embedding 🌐💼
Heute möchte ich das Paradigma 2, das Generic Structure Instance Embedding, vorstellen. 🔄📈
Die digitale Supply Chain verändert sich grundlegend. Zum einen ist es notwendig, die Fähigkeit zu erlangen, variantenreiche Produkte zu Preisen und zu Lieferzeiten von Standardprodukten zu liefern. Zum anderen stehen sie durch Einflüsse von Markt und Politik unter Druck, und es ist dringend notwendig, diese hochflexibel und viel besser steuerbar zu machen.
Heute werden im Wesentlichen zwei Ansätze für die Umsetzung des Modular Kits für den CTO+ in der Industrie diskutiert:
Vom ETO kommend den Aufbau eines nicht industrialisierten Engineering-Baukastens, der im Auftragsfall mühsam industrialisiert werden muss.
Vom geschlossenen CTO kommend der Ansatz der generischen Produktstruktur, die zwar bereits industrialisiert ist, aber den + Anteil am CTO (+) nicht hinreichend abdeckt.
Hieraus ergibt sich das Paradigma 2 – Generic Structure Instance Embedding. Es entwickelt den klassischen Ansatz der generischen Produktstruktur konsequent weiter.
Der Ansatz einer generischen Produktstruktur geht davon aus, dass die Oberstruktur eines Produkts generisch, d. h., gliedernd ist. Ab einer dedizierten Strukturebene wird dann über Positionen/Positionsvarianten die Produktstruktur durch Komponenten/Baugruppeninstanzen vervollständigt.
Der zukünftige Ansatz, den wir Generic Structure Instance Embedding nennen, entwickelt den klassischen Ansatz konsequent weiter. Mit ihm wird ermöglicht, einen anwachsenden CTO+ Modular Kit umzusetzen. Dieser Baukasten ist dann ein hybrider Modular Kit. Das bedeutet, dass der Baukasten zum maximal möglichen Umfang bereits vollständig industrialisiert ist.
Was ist nun der methodische Ansatz des Generic Structure Instance Embedding? Die generische Struktur wird dabei in die tiefen Ebenen der Produktstruktur weitergeführt. Die Grenze zwischen Gliederung und Instanziierung verschwindet. Die Instanziierung erfolgt nicht mehr horizontal, sondern vertikal zur Struktur, und es entsteht eine „Doppelstruktur“, die sowohl die Instanzen als auch die generische Struktur enthält. Damit wird eine automatisierte Instanziierung, die auch den CTO+ Anteil inkludieren kann, bis in die unteren Strukturstufen möglich!
Da mir der Platz für den Post ausgeht, muss ich es leider bei diesem kurzen Text belassen. Ich freue mich auf eure Fragen und Kommentare. Daraus würde ich dann Folgeposts generieren.
Bitte versteht die Formulierung der Themen hier auch als Einladung an die PLM und ERP-Vendoren. Gerne diskutieren wir mit euch, warum dieser Ansatz notwendig ist und ob und wie er in euren PLM oder ERP-Systemen vielleicht heute schon implementierbar ist.
