CPQ, ERP, and PLM? – CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.

CPQ, ERP und PLM? – Wie bringt man die eigentlich zusammen?

CPQ, PLM, ERP ein Thema, das immer wieder in Beratungssituationen aufkommt, ist, wie man CPQ mit ERP und PLM zusammenbringt. Ein beliebtes Thema, über das man intensiv diskutieren kann. Auf Lined in habe ich mich in einer Reihe von Posts dem Thema genähert die ich für euch hier zusammenstellen will.

Post 1: CPQ, ERP und PLM? – Wie bringt man die eigentlich zusammen?

Post1

CPQ, ERP und PLM? – Wie bringt man die eigentlich zusammen?

Nun zuallererst: CPQ = Configure Price Quote!

Wir sprechen also von Konfigurationssystemen, die primär darauf ausgelegt sind, Angebote zu konfigurieren.

Angebote bestehen aus Preispositionen!

Hier beginnt oft schon das erste Verständnisproblem.

Sind Preispositionen gleichzeitig Materialpositionen (im Sinne verkaufbarer Materialien)?

Manchmal ja, oft jedoch nicht! Hieraus ergeben sich zwei Fälle.

  • Fall 1: Gleichheit von Preispositionen und Materialpositionen wird hergestellt, dann kann CPQ mit ERP und PLM über diese Positionen verknüpft werden. Dabei ist Vorsicht geboten. Materialpositionen haben im Gegensatz zu Preispositionen einen anderen Lebenszyklus. Dies liegt daran, dass Preispositionen nicht oder nicht immer dem Grundsatz Form Fit Function unterliegen! Sie haben demnach andere Ansprüche an Austauschbarkeit. Da Preispositionen zumeist keine Hierarchie haben und um auch noch Raum für „MBOM“ Baugruppen in tieferen Stücklistenebenen zur Verfügung zu haben, werden die Positionen in der Produktstruktur oft sehr weit oben angesiedelt. Das vermindert die Flexibilität der Konfiguration und damit der Gesamtlösung.
  • Fall 2: Wenn Preispositionen und Materialpositionen sich nicht vereinheitlichen lassen, kann CPQ mit ERP nur über den Variantenraum bzw. den zu übergebenden Konfigurationsstring angebunden werden. Wenn Berater von High Level (CPQ) und Low Level (BOM) Konfiguration sprechen ist dies oft der Fall. Bei geschlossenem CTO und wenig Änderungsfrequenz auf dem Baukasten funktioniert das oft problemlos. Beim CTO+ ist das eine besondere Herausforderung weil
    • die in den Baugruppen wirkenden Variantenräume Teilmengen des Variantenraums im CPQ sind und daher mit diesem abgeglichen werden müssen. Das erfordert ein ausgeprägtes Configuration Lifecycle Management.
    • sich die Frage stellt, ob der EBOM/MBOM Übergang vor oder nach der Konfiguration geschehen muss.
    • eine Konfiguration, die auf der logistischen Stückliste (Stichwort – KMAT) verankert ist, die Lagerfähigkeit von Baugruppen erschwert (geht nur mit Ausprägung einer Lagervariante).

 

Soweit in aller Kürze.

Das Ganze ist natürlich sehr stark vom jeweiligen Prozessmuster und der zugrundeliegenden Produktlinie abhängig.

Was meint ihr zum Thema?

Was sind eure Erfahrungen?

Wenn ihr Fragen habt, schreibt diese gerne in die Kommentare. Ich werde versuchen, diese auch in eigenen Posts zu beantworten.

Gerne helfen wir vom RIM euch, die Konfigurationsstrategie und das sich daraus ergebende Zusammenwirken von CPQ, PLM und ERP zu erarbeiten.

 

Post 2: CPQ, ERP und PLM? – Was denn nun? Einstufige oder mehrstufige Konfiguration?

Post2

CPQ, ERP, and PLM? 🤔 - Which one is it? Single-stage or multi-stage configuration?**
CPQ, ERP, and PLM? 🤔 – Which one is it? Single-stage or multi-stage configuration?**

 

Heute für euch der zweite Post zum Thema CPQ, ERP und PLM.

Es geht um einstufige vs. mehrstufige Konfiguration.

Vielleicht habt ihr schon die unterschiedlichen Argumentationen gehört. Manche argumentieren, dass mehrstufige Konfiguration zu komplex wäre und schwören auf einstufige Konfiguration. Andere haben 5-7 stufige KMAT in ihren SAP-Systemen. Meist können das nur Spezialisten handhaben (ich habe ein Unternehmen erlebt, die hatten dafür nur 2 Personen und haben diese gebeten, nie gleichzeitig im selben Flugzeug zu fliegen 😊) – aber es funktioniert!

Heute möchte ich den Hintergrund beleuchten:

  • Einstufige Konfiguration:
    • Einstufige Konfiguration folgt der Idee der generischen Produktstruktur (GPS). Die GPS ist in der Oberstruktur gliedernd, bis sie auf eine Ebene mit Positionen und deren Varianten kommt. Dies ist dann die Ebene der Konfiguration. Darunter befinden sich Baugruppen. Was ist der Hintergrund eines solchen Vorgehens? Zumeist wird damit eine EBOM konfigurierbar gemacht, d.h. die Gliederung ist funktional systemisch. Da dennoch eine MRP-fähige BOM im ERP notwendig ist (Einstrukturenkonzept) wird die Ebene der Konfiguration in der Struktur meist weit nach oben gelegt. So ist ab der Baugruppenebene noch viel Raum für die „MRP-fähige“ Struktur. Die Baugruppen sind dann oft ein EBOM/MBOM Kompromiss. Gelingt dies, ist keine explizite EBOM und MBOM Trennung notwendig. Angewendet wird dieser Fall, wenn Unternehmen sich vom ETO zum CTO+ entwickeln. Wir sprechen dabei gerne vom Late Industrial Engineering. Der Fall findet ebenfalls Anwendung bei der Linienmontage. Hier reicht es, Gruppen von Material zu bilden, die an einen bestimmten Takt geliefert werden. Das ermöglicht eine einstufige Konfiguration, sodass die GPS bis auf Ebene der an die Line gelieferten Zusammenbauten heruntergebrochen wird.
    • Mehrstufige Konfiguration:
  • … und wie ist es jetzt mit mehrstufiger Konfiguration?
    • Hier wird eine M(RP)-BOM mit all ihren Dispositionsstufen konfigurierbar gemacht. Damit der MRP Lauf funktioniert, müssen die notwendigen Dispositionsstufen in der Stückliste vorhanden sein. Bei hochvarianten Produkten ist daher eine mehrstufige Konfiguration notwendig. Das ist insbesondere dann notwendig, wenn die Varianz in den Tiefen der Struktur sitzt, da sie sich dann nach oben in der Struktur ausmultipliziert und alle diese Varianten dann ausgeprägt werden müssten.
    • Warum geht das ohne Ausprägung der Dispositionsstufen als Materialnummer? Der MRP-Lauf erzeugt Fertigungsaufträge. Ein Fertigungsauftrag ist implizit mit einem Ort im Layout der Montage verbunden. Wenn an diesem Ort alle Varianten, die eine Struktur bzw. Dispositionsstufe enthält, montiert werden können, dann reicht es aus, für jeden dieser Orte ein KMAT (konfigurierbares Material im SAP) anzulegen. Dieses konfiguriert auf der jeweiligen Dispositionsstufe die notwendige Variante, die dann dort montiert wird.
    • Nun hier könnte man noch Fachbücher schreiben, warum in welcher Situation welches Vorgehen das richtige ist. Insbesondere mit dem Aufkommen der Multistrukturkonzepte ist dieses Thema noch mehr in den Fokus gerückt. Die Frage ist, welchen Fall man braucht:
    • – 150% EBOM → 100% EBOM → 100% MBOM
    • – 150% EBOM → 150% MBOM → 100% MBOM
    • – 200% EBOM → 150% MBOM → 100% MBOM Etc.

Wenn ihr Sparring oder Unterstützung dafür braucht, wir vom STZ-RIM können euch ein exakt für euren Fall und für eure Softwarebebauung zugeschnittenes Lösungskonzept ausarbeiten.

Was meint ihr dazu?

Welche Ansätze verfolgt ihr und welche Herausforderungen treten dabei auf?

Habe ich etwas wichtiges Vergessen was ergänzt werden müsste?

 

Post 3: CPQ, ERP und PLM? – SAP KMAT oder was bedeutet Konfiguration in der M(RP)-BOM?

Post3

Heute für euch der weiterer Post zum Thema CPQ, ERP und PLM.

CPQ, ERP und PLM? – SAP KMAT oder was bedeutet Konfiguration in der M(RP)-BOM?
CPQ, ERP und PLM? – SAP KMAT oder was bedeutet Konfiguration in der M(RP)-BOM?

In zukünftigen Posts werde weiter auf die zukünftigen Anforderungen an die Konfiguration eingehen.

Heute jedoch erstmal den Klassiker schlechthin erklärt.

Konfiguration in einer 150% M(RP)-BOM die während des MRP-Laufs stattfindet und welche Logik dort dahinter ist (besonders interessant für PLM Experten die ERP Logiken oft nicht oder nicht sehr gut kennen :). Konfiguration in einer 150% M(RP)-BOM ist insbesondere bei CTO+ Prozessmustern mit stabilem modularen Baukasten verbreitet. Der Lösungsansatz ist z.B. auch besonders beliebt bei Komponentenherstellern.

Im Bild ist die Grundlogik dargestellt. Ihr seht die M(RP)-BOM 150% (4711-KMAT) für die Fruchgummies. Ihr seht links im Bild eine leere Glasschüssel. Diese ist ein Production Location in der Produktion. An diesem werden die Fruchtgummietüten montiert. Es gibt 2x Varianten. Die Goldbärentüte und die Colaflaschentüte.

Im SAP ERP würde man das als KMAT abbilden und eine 150% #M(RP)-BOM daraus generieren. Sie würde aussehen wie im Bild (4711 KMAT).

Über wird der MRP Lauf durchgeführt. Der Instanziierungskontext des KMAT ist der Production Location. Da beide Varianten am selben Ort montiert werden, können sie in der M(RP)-BOM 150% (4711-KMAT) zusammengefasst werden. Dem aus dem #MRP -Lauf erzeugte Production Order reich ein Bezug zum Production Location. Die #Variante, die gebildet wird, ist dann Bestandteil der Production Order (zu sehen am kleinen schwarzen Kasten auf dem Production Order). Ist es nun der Wunsch, die fertigen Produkte auf Lager zu legen, ist eine Materialvarianten (4712 und 4713 rechts im Bild) notwendig.

Materialvarianten müssen sortenrein sein! Das liegt u.A. daran, dass alles, was auf einem Lagerplatz zusammengefasst, ist, dem Prinzip 100% Austauschbarkeit unterliegen sollte (form-fit-funktion Prinzip).

Das KMAT hat also einen Produktionsorstbezug, wohingegen eine Materialvariante einen Lagerortsbezug hat. Nutz man nun KMAT‘s ohne Materialvariante dann sind alle zwischenbaugruppen nicht lagerfähig.

Oft wurde dieser Ansatz noch unter dem Gedanken des Einstrukturenkonzepts implementiert. Damit unterliegen die KMAT Stücklisten in der Praxis oft eine EBOM/MBOM Mischung. Sie enthalten dann oft Strukturstufen die funktionale Modulbaugruppen ausdrücken und eben nicht Produktionsorte. Bei unternehmen zeigt sich das dann oft dadurch dass bestimmte Logistikprozesse wie. z.B. eine Vorausplanung fürs Assmble to Order oder Intercompanyprozesse nicht so leicht umzusetzen sind.

 

Was meint ihr dazu. Wie ist eure Erfahrung mit der klassischen Nutzung der Konfiguration mit M(RP)-BOM 150% im MRP lauf?

Und wie immer, wenn ihr ein modernes Mehrstrukturenkonzept mit MBOM, CPQ und Konfiguration vollständig lagerfähig und hochautomatisiert implementieren wollt dann helfen wir vom RIM euch gerne dabei.

 

Post 4: CPQ, ERP und PLM? – Was ist eigentlich der Unterschied zwischen additiver und substraktiver Konfiguration?

(Post4)

Heute für euch ein weiterer Post zum Thema CPQ, ERP und PLM.

Ich möchte mich dem Thema additive und substraktive Konfiguration widmen.

CPQ, ERP und PLM? – Was ist eigentlich der Unterschied zwischen additiver und substraktiver Konfiguration?
CPQ, ERP und PLM? – Was ist eigentlich der Unterschied zwischen additiver und substraktiver Konfiguration?

 

  • Substraktive Konfiguration
      • Wenn man über Konfiguration nachdenkt, hat man zumeist substraktive Konfiguration im Sinn. Von einer Maximalstückliste oder einem Maximalumfang werden durch Konfigurationsregeln diejenigen Elemente substrahiert, die für die jeweilige Konfiguration nicht von Belang sind.
      • Dabei hat einmal die zu konfigurierende Struktur (oft eine BOM oder ein Angebot) für jedes der möglichen Elemente eine Regel. Also eine Variantenkondition (Beziehungswissen). Will man nun die Konfiguration starten, dann werden Merkmale für diese gesamte Struktur (typischerweise die Produktlinie) ausgewählt. Der Regelmechanismus gleicht nun die ausgewählten Merkmale mit den Variantenkonditionen ab und subtrahiert alles, was nicht gebraucht wird.
      • Vorab gibt es noch die Zusteuerung (also das Zusteuern von abhängigen Merkmalen, die der Eingabe folgen müssen) und die Baubarkeitsprüfung (das Prüfen, ob die Merkmale in der Kombination Gültigkeit haben). Spannend ist das Wording, das benutzt wird. Man hört bei Unternehmen an den Worten, die sie benutzen, welchen Software eingesetzt ist. (SAP: KMAT, Merkmale, Merkmalswerte, Beziehungswissen; Teamcenter: (Named)VariantConditions, Stored Option Sets, Option Families)…

     

      • Additive Konfiguration
          • Bei der additiven Konfiguration werden im Unterschied zur substraktiven Konfiguration die Elemente nicht subtrahiert, sondern aufgesammelt. Manche denken jetzt bestimmt an den etablierten Ausdruck Solution Configuration. Das ist aber nur ein kleiner Teil, da es mehrere Konfigurationen gibt, die additiv sind. Ich zähle mal auf, was mir einfällt. Ergänzt gerne:
          • ETO – aus dem Baukasten – aus Baukastenelementen werden die jeweiligen aufgesammelt, kopiert und ggf. angepasst. Die Struktur zum Sammeln nennen wir gerne Technical Order Structure oder TOS.
          • Geometrische Konfiguration über Konnektorenpunkte.
          • Aus einer Reihe von Elementen werden die jeweiligen ausgesucht und passend positioniert (2D oder 3D). Die Positionierung erfolgt über Konnektorenpunkte, die auch Wissen, welche Elemente an sie angedockt werden können bzw. welche Paarungen zulässig sind. Die entsprechenden Konfiguratoren haben dann oft sehr schicke 3D-Oberflächen.
          • Aufsammeln für einen zusammenpassenden Warenkorb.
          • Oft wird additive Konfiguration auch zum Aufsammeln von Komponenten, die zusammenpassen, verwendet. Hier wird die Produktfindung mit der Konfiguration in Verbindung gebracht. Wichtig ist es, dass der Anwender über die additive Konfiguration zusammenpassende Komponenten in den Warenkorb bekommt.

        Vorsicht! – Meistens findet man nicht die Reinformen additiv oder substraktiv, sondern Mischungen und man kann substraktiven Mechanismen durchaus auch additive Funktionalität abtrotzen. Das klingt zwar komisch, habe ich in der Industrie jedoch auch schon gesehen.

        So an der Stelle könnte man bestimmt noch viel mehr Beispiele zur additiven Konfiguration finden. Ich freue mich auf Ergänzungen und Kommentare.

        Wenn’s geht, keine Kommentare von Sales, deren Quintessenz ist, dass der von ihnen angebotene Konfigurator alles kann 😊. Ich weiß, dass ihr das sagen müsst, und zum Schluss stimmt es dann leider oft nicht.

     

Post 5: CPQ, ERP und PLM? – Design Automation within Configuration

Post5

CPQ, ERP und PLM? – Design Automation within Configuration
CPQ, ERP und PLM? – Design Automation within Configuration

Heute für euch ein weiterer Post im Kontext des Themas CPQ, ERP und PLM.

Ich möchte mich dem Thema Design Automation widmen.

Bei Design Automation geht es darum Design Dokumente z.B. 3D Modelle und ECAD Modelle automatisiert zu generieren. Ich konzentriere mich bei der Erläuterung auf MCAD Modelle und auf ein einzelnes Part. Stellt euch vor ihr erstellt ein Template eines CAD 3D Modells. Das Template beschreibt dann die Topologie des späteren Parts. Wird nun das Template mit entsprechenden Parameterwerten (z.B. Maße, Länge Breite Höhe etc.) versorgt kann das Template zu einen vollständigen 3D Modell incl. Zeichnung instanziiert werden. Zur Berechnung der Parameterwerte bedarf es Regeln bzw. Berechnung (oft auch vollständige Auslegungsrechnungen). Diese Regeln werden in einer Regelmaschine (Konfigurationsengine) ausgeführt. Das ist der Kern der Desing Automation.

Nun muss man jedoch weiter aushohlen. Oft wurden die Regeln im CAD System hinterlegt. Konstrukteure haben sich dann an solchen Regel verkünstelt. Löst man es so dann entsteht jedoch eine proprietären Insel und die Regeln sind außerhalb des spezifischen CAD-Systems nicht verwendbar und können auch nur schwer gewartet werden. Deswegen ist es wichtig dass die Regelmaschine serverseitig läuft und unabhängig von einer proprietären Applikation ist.

Wenn in der Regelmaschine nun auch noch die Struktur der Baugruppe oder des Produkts auf Basis von Regeln zusammengesetzt werden kann erhält man im Idealfall alle notwendigen Dokumente und Modelle für diese Baugruppe.

Soweit so gut. Es liegt an der Stelle also die CAD-BOM vor. Diese muss nun in eine EBOM und ggf. eine MBOM übertragen werden. Hat man die Produktionsfähigkeit intern oder arbeitet immer mit denselben Lieferanten zusammen kann das Dokument zum Part/(global) Material in der EBOM als 1:1 realisiert werden. Für die MBOM braucht das Material nun die für die Logistische und kaufmännische Bewertung notwendigen Attribute sowie den Arbeitsplan. Diese lassen sich im beschriebenen Fall ebenfalls vorab als Templates definieren und von der Regelmaschine erzeugen.

In der Wandlung von CAD-BOM zur EBOM und MBOM liegt der Schlüssel zur Vollautomatisierung des Desing Automation Prozesses.

Oft sehen wir vom RIM tolle Automatisierungen die dann nach Erzeugung des CAD Dokuments in mühsame Händische Arbeit abgleiten. Manchmal auch parallele nicht synchronisierte Prozesse so dass Desing Automation parallel zu eine nicht synchronisierten logistischen Konfiguration laufen.

Wir vom RIM haben -so unsere Überzeugung- bahnbrechende Methoden entwickelt wie sich das Thema methodisch aufarbeiten, planen und Umsetzen lässt dass eine ganzheitliche Konfiguration mit Desing Automation möglich wird. Wenn ihr mehr wissen wollt meldet euch hier.

Und wie ist eure Erfahrung mit dem Thema?

Habt ihr es schon gelöst und wenn ja wie war euer Ansatz?

Ich freue mich auf Kommentare und Rückmeldungen.

 

CPQ, ERP und PLM? – CPQ vs. ERP-Konfiguration 🤖 Wenn Sie dies lesen, können Sie für Ihr Unternehmen einen erheblichen Betrag einsparen! 💰

Post 6

CPQ, ERP, and PLM? – CPQ vs. ERP Configuration 🤖 If you read this, you can save a significant amount for your company! 💰

Zurück mit einem weiteren Beitrag in der CPQ-, ERP- und PLM-Serie.

Ich möchte mich mit den Unterschieden zwischen Konfigurationen in CPQ- (Configure Price Quote) und ERP-Systemen befassen.

Warum können Sie damit Geld sparen? Die Vertriebsteams der CPQ-Anbieter behaupten, sie könnten alles konfigurieren. Das behaupten sie natürlich, aber ist das wirklich der Fall? 🧐

👉 Es gibt grundlegende Unterschiede zwischen Konfigurationen in CPQ- und ERP-Systemen. Im Kern geht es um den Unterschied zwischen High- und Low-Level-Konfigurationssystemen. Aus methodischer Sicht geht es aber noch um mehr.

👉 Ein CPQ-System konfiguriert ein Angebot. Ein Angebot besteht im Wesentlichen aus Angebotspositionen, die mit einem Preis versehen sind und textlich beschreiben, was gekauft werden soll. Diese Positionen werden oft mit Materialien oder einkaufbaren Artikeln gleichgesetzt. Dies ist manchmal richtig, da häufig physische Produkte verkauft werden.

❗️It ist es wichtig zu verstehen, dass Angebotspositionen keine Materialien sind und sich nicht wie ERP-Materialien verhalten.💡

👉 Warum? Angebotspositionen kapseln etwas, das gekauft werden kann. Dies kann ein Produkt, eine abstrakte kaufbare Funktion oder etwas Ähnliches sein. Außerdem haben Angebotspositionen zwar einen Lebenszyklus, aber der unterscheidet sich grundlegend von dem von Materialien. Materialien halten sich streng an die Form-Fit-Function (F3). Eine Angebotsposition kann jedoch leicht ersetzt werden, auch wenn sie nicht F3 entspricht.
Auch der Variantenraum der ERP-Konfiguration unterscheidet sich von dem in CPQ. Typischerweise sind die Optionen und Optionswerte in CPQ viel umfangreicher als in ERP.

CPQ-Systeme eignen sich sehr gut für High-Level Configuration (da sie dafür ausgelegt sind) und bieten oft ein attraktives WEB-Frontend.

❗️With Low-Level Configuration, insbesondere bei mehrstufigen Konfigurationsansätzen, wird es schwierig, da viele CPQ-Systeme mit Produktstrukturen und Stücklisten nicht vertraut sind. Solche Szenarien werden schnell hochkomplex und damit schwer handhabbar, und Änderungen können zu einem echten Problem werden. Einer der Hauptgründe dafür ist, dass die Diktion der Produktstruktur in CPQ oft über Konfigurationsregeln und auch Hierarchien von Konfigurationsregeln modifiziert werden muss.

👉 Ich empfehle daher (je nach Fall) High-Level-Konfiguration in CPQ und Low-Level-Konfiguration, insbesondere wenn sie mehrstufig ist, in ERP.
Und im PLM? Konfigurieren Sie dort, wenn Sie ein nicht-industrialisiertes Baukastensystem (bzw. Baukästen) in einer ETO-nahen Situation haben oder wenn Sie Designs sichern wollen. Ich werde das Thema in einem nächsten Beitrag aufgreifen.

Ich wollte und könnte noch viel mehr schreiben, aber das würde diesen Beitrag zu langatmig machen.
Ihr könnt also gerne eure Fragen in den Kommentaren stellen, und ich werde sie gerne beantworten. ⬇️

Ich bin auch gespannt auf eure Meinung dazu! 📢

Wenn Sie ein #CPQ-, #ERP- oder #PLM-Szenario angehen wollen, wenden Sie sich an uns von STZ-RIM Reshape Information Management. Wir sind Spezialisten, auch für komplexe Fälle. 🌐

Nehmen Sie noch heute Kontakt mit uns auf: https://stz-rim.com/kontakt/

CPQ, ERP und PLM? – Industrialized vs. Non-Industrialized Modular Kits 🧩.

Post 8

CPQ, ERP, and PLM? – Industrialized vs. Non-Industrialized Modular Kits 🧩.

 

Das Durchdringen dieses Themas ist der zentrale Schlüssel zum Verständnis des Übergangs von ETO zu CTO+ 🔍.

Ihr kennt vielleicht die Diskussion 🗣️. Manche sagen: Konfigurieren und MBOM im PLM und danach ins ERP; andere sagen, Konfiguration nur im ERP. Was stimmt denn nun?

Mit einigen Posts im Themenfeld CPQ-ERP-PLM möchte ich das herausarbeiten 🧐.

Als Grundlage ist es am wichtigsten, den Unterschied zwischen – Industrialized vs. Non-Industrialized Modular Kits und damit auch den Unterschied zwischen Early und Late Industrial Engineering zu verstehen 🤔.

An der Stelle vielen Dank an Ulrich Schmidt von BDF-Experts fürs Augenöffnen 🙏 und Frederik Breckwolt und Dominik Mayer für den Sparring🤼.

Im Bild seht ihr ein Szenario 📸. Stellt euch vor, der Baukasten wird neu entwickelt. Dabei wird typischerweise das V-Modell durchlaufen 🔄.

An dieser Stelle gibt es zwei prinzipielle Möglichkeiten:

🅰️Fall A: Der Baukasten kann ohne Industrialisierung entwickelt werden, d.h., die Hinentwicklung zur Produktion ist noch nicht abgeschlossen, da dies erst später, d.h., im Auftragsfall geschieht. Daher auch der Name Late Industrial Engineering Erkennbar ist dies zumeist daran das lediglich ein CAD-BOM bzw. EBOM Baukasten (150%) vorliegt.

🅱️Fall B: Der Baukasten wird schon bei der Entwicklung komplett industrialisiert. Das Material ist durchentwickelt, so dass die logistische Handhabung und Lieferantenwahl bereits komplett abgeschlossen ist. Diesen Fall nennen wir auch Early Industrial Engineering. Erkennbar ist dies das bereits zum SOP eine MBOM richtiger eine M(RP)-BOM 150% vorliegt.

Im Falle eines Auftrags mit kundenspezifischem Anteil kann bei industrialisiertem Baukasten (Bild Detail C) sehr schnell reagiert werden, da die Industrialisierung nur für den kundenspezifischen Anteil erfolgt. Bei nicht industrialisiertem Baukasten (Bild Detail D) ist es notwendig, die komplette Industrialisierung vorzunehmen 🔄. Dadurch hat der industrialisierte Baukasten einen Zeitvorteil wohingegen der nicht industrialisierte Baukasten eine Flexibilitätsvorteil hat.

Zur Einordnung. Fall A ist ein typischer Unterfall des ETO (wir sagen ETO aus dem Baukasten) wohingegen Fall B ein erweiterter CTO fall ist. Wir nennen es CTO+

Was dies im Kontext von PLM und dem ERP-nahen PLM bedeutet und wie ein hybrider Ansatz zwischen beiden Fällen implementiert werden kann, erfahrt ihr in den folgenden Posts 📘.

#CPQ #ERP #PLM #Konfiguration #BusinessSolutions

CPQ, ERP und PLM? – CPQ- und E-BOM-basierte nicht-industrielle modulare Baukästen in ETO-nahen Fällen🧩.

Post 9

CPQ, ERP, and PLM? – CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.
CPQ, ERP, and PLM? – CPQ & E-BOM based non-industrialized modular kits in ETO close cases🧩.

Meiner Meinung nach liegt die Zukunft in hybriden modularen Baukästen mit einem erheblichen industriellen Anteil (>60-95%📊). Diese Baukästen müssen so konzipiert sein, dass sie flexibel im Werksverbund🏭 nach dem Assemble-to-Order-Prinzip gefertigt werden können. IT-Systeme🖥, die dies unterstützen, müssen verschiedene Konfigurationsszenarien, d.h. additive➕, subtraktive➖ und Konstruktionsautomatisierung🔄 in beliebiger Form vereinen und darüber hinaus M(RP)-BOM-fähig📋 sein.

Dies ist die ultimative Voraussetzung für die Widerstandsfähigkeit in einer modernen digitalen Lieferkette🌍⛓.

Die meisten aktuellen Ansätze verfolgen in erster Linie EBOM-basierte Strategien für nicht-industrialisierte Kits. Diese stehen im diametralen Widerspruch zu dem oben genannten Ansatz. Deren Einrichtung ist ein guter Anfang für die Modularisierung, aber nur der erste Schritt🚶.

Es ist also an der Zeit zu untersuchen, wie CPQ mit EBOMs in PLM in nicht-industrialisierten Fällen funktioniert🔍.

Das Prinzip ist einfach und in der folgenden Abbildung dargestellt🖼. In CPQ gibt es Angebotspositionen, die Kunden konfigurieren können🛠. Diese werden im PLM als Strukturebenen einer E-BOM abgebildet. Da Angebotspositionen typischerweise funktionale Einheiten darstellen, ergeben sich daraus funktionale Baugruppen. Diese Funktionsbaugruppen sind nicht montierbar und spielen auch keine Rolle für die Disposition🚫.
Es ist wichtig zu verstehen, dass diese Funktionsbaugruppen, als Anker der Angebotsposition in CPQ, nicht dem F3-Prinzip folgen müssen. Sie haben nur unterschiedliche Versionen🔄.

Da die nicht-industrialisierten Bausätze in der Regel sehr mechanisch und CAD-orientiert📐 sind, haben viele Implementierungen noch den klassischen CAD-BOM/EBOM-Mix. Es ist sogar möglich, dass diese Mischstrukturen leichte MBOM-Anteile haben.
Die automatisierte Übernahme dieser Struktur in das ERP scheitert in der Regel. Der Grund ist nicht die Schnittstelle❌!
Warum eigentlich? Die Umwandlung einer solchen vereinheitlichten Struktur in eine ERP-fähige M(RP)-BOM-Struktur erfordert mühsames ERP-nahes Industrial Engineering🔧, das die meisten der heute verfügbaren PLM-Systeme kaum bieten.

Was meinen Sie dazu? Ich bin gespannt auf Ihre Erkenntnisse zu diesem Thema! 📢

Bitte stellen Sie Ihre Fragen in den Kommentaren, und ich werde mehr als glücklich sein, answer⬇️.
Wenn Sie ein hybrides Szenario erforschen, setzen Sie sich mit uns in Verbindung🤝. Wir sind Experten für die Gestaltung solcher Situationen🌐.
Nehmen Sie noch heute Kontakt auf: https://rim-crm.odoo.com/r/Uid

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Weitere Artikel

Im Beitrag werden Bezeichnungen und Kategorisierungen von Stücklisten (BOMs) sowie das RIM-360°-Multi-Structure-Model vorgestellt....