Variantenmanagement: Der Schlüssel zur Bewältigung der explodierenden Produktkomplexität

Der Inhalt dieser Seite wurde automatisch von einem Drittanbieter übersetzt.

Früher wurde das Management von Produktvarianten mit CPQ-Tools (Configure, Price, Quote) durchgeführt, die es den Nutzern ermöglichten, eine Produktkonfiguration anhand eines Satzes von Regeln zu lösen, die auf die bestehenden Funktionen, Optionen und Einsatzbedingungen der Produktplattform angewendet wurden. Die Idee war, jegliche kundenspezifische Ingenieursarbeit zu vermeiden und gleichzeitig der Fertigung das richtige BOM (Bill of Materials) für ein maßgeschneidertes Produkt bereitzustellen. Ein gutes Beispiel dafür ist die Nutzung der Website eines Autoherstellers, um Kunden die Konfiguration ihres Fahrzeugs zu ermöglichen. Die Reihe von Auswahlmöglichkeiten wird dabei dynamisch auf Grundlage der bereits getroffenen Kundenauswahl angepasst. Wenn Sie sich zum Beispiel für ein Basismodell eines Autos entscheiden, haben Sie möglicherweise nicht mehr die Möglichkeit, Ausstattungsmerkmale wie Sitzheizung zu wählen. In einem anderen Szenario kann ein CPQ-Tool erkennen, welche Teile der gewünschten Konfiguration eine kundenspezifische Konstruktion erfordern. Zum Beispiel bei einer zentralen Klimaanlage, bei der Luftbehandler, Kondensator, Lüftungsöffnungen und Thermostat als Standardteile verfügbar sind, die Luftkanäle jedoch speziell auf das Layout und die Architektur des Hauses zugeschnitten werden müssen. Ziel von CPQ-Tools ist es, die Zeit zwischen der Bestellung eines kundenspezifischen Produkts und dem Versand aus der Fertigung zu minimieren.

Heutzutage zwingen Produktkomplexitäten, die durch allgegenwärtige Konnektivität, steigenden Softwareanteil und ein hohes Maß an Individualisierung entstehen, OEMs dazu, die grundlegenden Prinzipien des Variabilitätsmanagements viel früher im Produktlebenszyklus zu berücksichtigen. Dabei handelt es sich um Fälle, in denen die Verwaltung der in eine Produktplattform eingebauten Variabilität ein höheres technologisches Verständnis seitens des Nutzers erfordert, als typische CPQ-Tools verlangen. Das Konzept der Variabilität wird beispielsweise oft in zahlreichen Konstruktionsphasen und innerhalb verschiedener Konstruktionsdarstellungen verwendet, um aus technologischer Sicht zu erkunden, was möglich ist. Da CPQ-Tools für diesen Zweck nicht entwickelt wurden, greifen Ingenieurteams standardmäßig auf komplexe Tabellenkalkulationen zurück. Das ist eine erhebliche Belastung aufgrund des fehlenden durchgängigen Datenmodells, mangelnder Rückverfolgbarkeit, fehlender Versionskontrolle, unzureichender Änderungsprozesse und der Unsicherheit, welche Tabelle in einem bestimmten Fall die maßgebliche ist. Selbst wenn der Tabellenprozess funktioniert, ist er anfällig für menschliche Fehler und bietet keine Möglichkeit, die Ergebnisse mit den Nutzern der CPQ-Tools zu verbinden.

Aras hat über einen längeren Zeitraum erhebliche Zeit und Ressourcen investiert, um diese Probleme gemeinsam mit Kunden zu untersuchen. Dies führte zu mehreren Schlussfolgerungen, die in unsere neueste Anwendung, Aras Variant Management, eingeflossen sind – und die allesamt erwähnenswert sind.

Die Logik zur Variabilitätsauflösung sollte niemals als Teil der aufzulösenden Produktstruktur implementiert werden. Die Produktstruktur ist jede Produktdarstellung, die die Definition aller Variantenpunkte und zugehörigen Komponenten enthält. Eine Produktstruktur kann eine Darstellung eines Produkts auf Ebene der Anforderungen, des funktionalen Zerlegungsplans, der architektonischen Struktur oder einer physischen Umsetzung einschließlich Mechanik, Elektronik und Software sein. Variabilitätsauflösungslogik und Produktstruktur sind zwei unterschiedliche Datenmodelle, und durch ihre separate Verwaltung kann eine Methodik für Konfigurationslogik – Regeln, Merkmale und Optionen – entwickelt werden, die auf mehrere Sätze von Konstruktionsdarstellungen mit Variantenkomponenten angewendet werden kann. Das bedeutet, dass die Regeln selbst zu einem wiederverwendbaren Asset für den OEM werden. Es bedeutet auch, dass die Prozesse zur Entwicklung von Regeln und Produktstrukturen ihre eigenen Lebenszyklen, Versionskontrollen, Änderungsmanagement- und Genehmigungs-Workflows haben können.

Eine unabhängige Variabilitätslogik wendet denselben Satz von Regeln auf jede der RFLP-Design-Darstellungen (Requirements, Functional, Logical und Physical) einzeln oder gemeinsam an. Beispielsweise kann durch den Aufbau einer Produktstruktur, die einer funktionalen Systemzerlegung entspricht, die Struktur und die zugehörigen Variantenkomponenten so definiert werden, dass diese Funktionen auf eine Vielzahl von Implementierungsdomänen ausgerichtet werden können. Das bedeutet, dass derselbe Satz an Variabilitätskonfigurationsregeln auf eine funktionale Systemzerlegung angewendet werden kann, um deren Zuweisung zwischen mechanischer, elektronischer und Software-Implementierung zu verteilen. Dies ist ein leistungsstarkes Konzept für MBSE (Model-based Systems Engineering)-Initiativen, da es die Produktvariabilitätsmethodik bis in die Phase der Designexploration im Produktlebenszyklus ausdehnt.

Die Informationen, die aus der aufgelösten Produktstruktur – einer Variante – resultieren, sind ebenfalls entscheidend, um die Methodik des Variantenmanagements für jede Phase des Produktentwicklungszyklus relevant zu machen. In einem typischen CPQ-Szenario ist die Ausgabe des Konfigurators dafür gedacht, CRM- oder MRP-Systeme zu speisen. Wenn jedoch das Variabilitätsmanagement früher im Entwicklungszyklus eingesetzt wird, besteht die gewünschte Ausgabe oft darin, Technologiefragen zu informieren, zu bewerten und zu klären, die die Definition einzelner Variantenkomponenten, Gruppen dieser Komponenten, die Teilsysteme bilden, und die Variabilitätskonfigurationsregeln bestimmen. Dabei können auch überhaupt keine Daten erzeugt werden – außer einer temporären Ansicht der Zielkonfiguration, einer Menge von Systemmodellelementen, einer Reihe von zugehörigen Anforderungen, einem gefilterten Dokumenteninhalt und Ähnlichem. Die Flexibilität, die Art der resultierenden Daten zu bestimmen, ist der Schlüssel zur Ausweitung der Variabilitätsmethodik im gesamten Unternehmen.

Schließlich ist auch die Flexibilität wichtig, den Kontext der Variabilitätsauflösung festzulegen, ohne die Regeln oder die Produktstruktur zu ändern. Im Laufe der Zeit entwickeln sich die Details der Regeln oder der Struktur weiter, und daher kann eine Variabilitätsauflösung, die vor einem Monat durchgeführt wurde, zu anderen Ergebnissen führen als eine, die heute ausgeführt wird. Während der Standardkontext dieses Typs in der Regel auf die neueste Version von Regeln und Strukturen eingestellt ist, kann es entscheidend sein, ein früheres Datum auszuwählen, um vergleichen zu können, wie Änderungen der Regeln und Strukturen die Variantenauflösung beeinflussen. Diese Art der Kontextfestlegung ist entscheidend und nur möglich, wenn die zugrunde liegenden Daten den Lifecycle- und Traceability-Services unterliegen.

Dies sind einige Aspekte des Variantenmanagements, die die Methodik über den traditionellen Fokus der CPQ-Tools hinaus anwendbar machen. Wichtig ist, dass alle diese Aspekte die Dienste der zugrunde liegenden PLM-Plattform erfordern, einschließlich Rückverfolgbarkeit, Versionskontrolle, Änderungsmanagement, Zugriffskontrolle auf die Daten und weitere. Daher ist die neueste Aras Variant Management-Funktionalität, die auf der Low-Code-PLM-Plattform von Aras aufbaut, ein wichtiger Schritt, um OEMs bei der Bewältigung der immer komplexer werdenden Produkte zu unterstützen.

Besuchen Sie www.aras.com um zu erfahren, wie die Aras Variant Management-Anwendung Ihnen hilft, Produktvarianten effizient zu verwalten.