Unternehmen setzen Produktkonfiguration in verschiedenen Bereichen ein – im Vertrieb, in der Entwicklung sowie in der Fertigung. Das Ziel im Kontext des digitalisierten Unternehmens und Industrie 4.0 ist es, end-to-end Konfiguration zu ermöglichen.
End-to-end Konfiguration, auch manchmal als „one-touch“ Konfiguration bezeichnet, bedeutet, dass eine Bestellung durch eine einzelne Interaktion mit dem Kunden im Vertrieb erzeugt wird und für alle nachgelagerten Prozesse unverändert genutzt werden kann. Diese Interaktion findet direkt in einem Konfigurator statt, der die vollständige und konsistente Konfiguration der Bestellung sicherstellt.
Die Abbildung zeigt die Verknüpfung der Konfigurationstätigkeiten in den einzelnen Abteilungen über eine gemeinsame end-to-end Produktkonfiguration. Diese end-to-end Verknüpfung von Konfigurationstools vom Vertrieb über die Entwicklung und Konstruktion bis hin zur Fertigung ermöglicht dann die automatisierte Erstellung aller Informationen, die zur Anpassung, Produktion und Auslieferung der Bestellung nötig sind.
Diese verknüpfte Art der Produktkonfiguration ermöglicht es Unternehmen, schneller zu reagieren und Vorlaufzeiten zu reduzieren, schneller neue Produkte einzuführen, die interne Effizienz zu verbessern und Fehler zu reduzieren.
Während ein Großteil der Unternehmen bereits Konfiguratoren in vielen Bereichen einsetzen, bleibt die durchgängige end-to-end Konfiguration eine Vision, die bisher nur wenige Unternehmen vollständig realisiert haben.
Die Herausforderung liegt in der Vielfalt der Anforderungen der verschiedener Abteilungen an Konfiguration und der daraus folgenden Diversität an der eingesetzten Lösungen: Das Produktmanagement beschreibt Produkte in PowerPoint-Präsentationen und Excel-Tabellen, die Entwicklung verwaltet Lösungsvarianten in PDM- und CAD-Systemen, die Fertigung nutzt im ERP-System gepflegte 150%-Stücklisten, die an den Produktionsstandort angepasst sind und der Vertrieb nutzt Configure Prize Quote (CPQ)-Systeme zur Konfiguration von Produkten für Kunden und zur Erstellung von Angeboten.
Diese verschiedenen Lösungen zur Produktkonfiguration folgen den unterschiedlichen Anforderungen der einzelnen Abteilungen. Die Entwicklung und Konstruktion arbeitet mit technischen Lösungen und Funktionalitäten, die Fertigung organisiert den Materialfluss gemäß den Prozessschritten zur Herstellung des Produktes, das Produktmanagement denkt in Features und Roadmaps und der Fokus des Vertriebs liegt auf Optionen-, Preis- und Performance-Klassen.
Während es den eingesetzten Tools also gelingt, die Effizienz jeder Abteilung für sich zu steigern, scheitert durch den Fokus auf einzelne Stakeholder die durchgängige Verknüpfung zu einer end-to-end Produktkonfiguration.
Um das Ziel einer durchgängigen und konsistenten Produktkonfiguration zu erreichen, bedarf es einer Lösung, die den Ansprüchen aller Disziplinen gerecht werden kann. Dies gelingt mit einem ganzheitlichen Produktarchitektur-Informationsmodell auf der Basis von 4 Säulen:
In diesem Artikel wollen wir die Herausforderungen bei der Umsetzung von end-to-end Produktkonfiguration genauer beleuchten und zeigen, wie diese überwunden werden können. Wir werden Ihnen in diesem Rahmen an verschiedenen Beispielen Modular Management’s Product Architecture Lifecycle Management Software, PALMA, vorstellen, um zu zeigen, wie eine Lösung zur end-to-end Konfiguration für Modulsysteme aussehen kann.
Leseempfehlung: In diesem Artikel besprechen wir die Herausforderungen und Lösungsansätze bei der end-to-end Konfiguration von komplexen Produkten. Eine wichtige Voraussetzung zur Lösung ist natürlich die Konfigurierbarkeit der Produkte. Konfigurierbarkeit wird ermöglicht, indem das Produktportfolio in Form eines Modulsystems strukturiert wird. Wenn Sie mehr darüber erfahren wollen, wie es gelingt mit einem Modulsystem interne Komplexität zu reduzieren, Kundenvielfalt zu erhöhen und Kundennutzen sowie Unternehmensziele in der Produktarchitektur zu verankern, empfehlen wir Ihnen unseren Artikel „Modularisierung in 5 Schritten“.
Bei der Verknüpfung verschiedener Ansätze zur Produktkonfiguration gibt es zwei Herausforderungen, die besonders häufig zu Problemen führen und die wir hier daher explizit beschreiben wollen:
Um Produkte konfigurieren zu können, bedarf es immer einer Produktstruktur als Basis. Die unterschiedlichen Anforderungen führen dazu, dass die Konfigurationslösungen verschiedener Abteilungen mit unterschiedlichen Strukturen arbeiten. Der Unterschied liegt einerseits im Fokus auf unterschiedliche Aspekte des Produkts und andererseits in großen Unterschieden im benötigten Detailgrad.
Dieser Unterschied lässt sich durch den Vergleich von Entwicklung und Vertrieb leicht illustrieren. In der Vertriebskonfiguration wird das Produkt mittels Funktionen, Optionen, Features und Leistungsstufen beschrieben. Häufig wird auch eine Vertriebs-Stückliste erstellt, die all die Baugruppen enthält, die im Vertriebsprozess konfiguriert werden und die Preise für gewählte Optionen ausweist.
Diese Stückliste und die durch die Konfiguration erstellte Spezifikation umfasst aber nur einen Bruchteil der Bauteile und Anforderungen, die von der Entwicklung berücksichtigt werden müssen. Die Entwicklung arbeitet daher mit einer deutlich umfangreichen Struktur in mehreren Hierarchiestufen. Es ist hierbei auch nicht ungewöhnlich, dass sich die Baugruppen aus der Vertriebs-Stückliste auf mehrere Bereiche der technischen Produktstruktur verteilen.
Betrachten wir zur Anschaulichkeit das Beispiel eines PKW-Sitzes und zweier Zusatzoptionen, die der Kunde auswählen kann: Zusätzliche Schonbezüge und eine verstellbare Lendenwirbelstütze.
Für den Fall der Schonbezüge verhalten sich Sales-Konfiguration und die Entwicklungs-Konfiguration ähnlich und es wird lediglich eine zusätzliche Baugruppe hinzugefügt. Im Falle der verstellbaren Lendenwirbelstütze hat die Auswahl der Option hingegen Einfluss auf eine Vielzahl von varianten Modulen innerhalb der detaillierten Entwicklungsstückliste. So sind neben der Lendenwirbelstütze mit Stellmotor auch die Bedieneinheit für die Sitzeinstellung und die seitlichen Airbagsysteme betroffen.
Diese starken Unterschiede im Aufbau der Struktur der Produktkonfiguration verschiedener Abteilung stellen eine große Herausforderung bei der Verknüpfung verschiedener Konfiguratoren dar.
Ursprünglich umfasste eine Stückliste alle Bauteile, die benötigt wurden, um ein bestimmtes Produkt herzustellen. Mit zunehmender Variantenvielfalt in den angebotenen Produktportfolios hat sich auch der Aufbau von Stücklisten verändert. Die Einführung von Variantengruppen innerhalb einer Stückliste ermöglichte es, mehrere Produktvarianten mit einer Stückliste abzudecken. Diese Stücklistenvorlagen, aus denen sich mehrere individuelle Stücklisten ableiten lassen, werden im Englischen als super-imposed BoMs oder kurz Super-BoMs bezeichnet.
Während diese Super-BoMs es ermöglichen die Anzahl an Stücklisten zu reduzieren und Produktvarianten in einer gemeinsamen Stückliste zusammenzufassen, bringen sie auch einige Schwierigkeiten mit sich: Um aus einer Super-BoM eine Stückliste für eine Produktvariante abzuleiten, bedarf es eines Regelwerks, das sicherstellt, dass für jede Variantengruppe in der Super BoM die passende Baugruppen- oder Bauteilvariante ausgesucht wird.
Diese technischen Regeln werden auf der Ebene der Variantengruppen definiert. Diese sind an vielen verschiedenen Stellen der Super BoM meist auf einer tieferen Hierarchieebene angeordnet. Dies führt in Summe zu einem sehr komplexen Regelwerk, das nur von Experten mit detailliertem technischen Verständnis für die einzelnen Variantengruppen betreut werden kann. Gleichzeitig ist die Anforderung an die technische Konsistenz der Regeln hoch – für einen Satz Auswahlkriterien muss genau eine passende Variante ausgewählt werden.
Die Komplexität einer Super BoM und des Regelwerks nimmt noch einmal stark zu, wenn unterschiedliche Produkte Veränderungen in der Produktstruktur erfordern, was zu einer Vervielfachung von Teilen der BoM und des verknüpften Regelwerks führt.
Im Bestreben diese Komplexität handhaben zu können, nutzen Unternehmen mehrere Super BoMs gleichzeitig, die jeweils einen Teil der gesamten Produktvariantenvielfalt abdecken. Diese Super BoMs stellen dann eigenständige Konfiguratoren mit individuellen Regelwerken dar. Während dies die Komplexität einer einzelnen Struktur reduziert, nimmt der Gesamtaufwand zum Erstellen und Instandhalten dieser Strukturen stark zu.
Dieses Aufteilen des Produktportfolios in mehrere Konfigurationsstrukturen für Entwicklung und Produktion führt außerdem zu einem Konflikt mit der Vertriebskonfiguration. Diese findet innerhalb eines Konfigurators für das gesamte Produktportfolio statt, um so einen effizienten Vertriebsprozess und eine positive Kauferfahrung für den Kunden zu ermöglichen.
Dieser Vertriebskonfigurator muss nun mit einer Vielzahl von Konfiguratoren in Form von Super BoMs der Entwicklung und Produktion kommunizieren. Diese BoMs haben jeweils ein eigenes Regelwerk und meist einen Detailgrad und Hierarchiestufen, die sich stark vom Vertriebskonfigurator unterscheiden. Das Ergebnis ist ein kompliziertes, teures und instabiles Gesamtsystem. Durchgehende Datenkonsistenz ist nur schwer und aufwendig erreichbar.
Wie im vorherigen Abschnitt beschrieben, führen unterschiedliche Strukturierungen in Kombination mit variantenreichen Produktportfolios und dem Super BoM Ansatz zu einem System, das eine end-to-end Konfiguration schwierig macht. Dieser Konflikt lässt sich mit einem alternativen Ansatz zur Produkt- und Stücklistenstrukturierung überwinden.
Die Strukturierung in Form einer modularen BoM ermöglicht es, eine gemeinsame Struktur für komplexe Produktportfolios zu nutzen. Das Grundprinzip ist die Trennung der Struktur und des Inhalts dieser Struktur in eine generische Produktstruktur und eine Modulbibliothek. Die folgende Abbildung zeigt das generelle Prinzip der Trennung von Struktur und Inhalt sowie die Umsetzung einer generischen Produktstruktur und einer Modulbibliothek in PALMA. Das Schöne ist, dass sich hiermit konsistent Produktportfolios bestehend aus Hardware, Software und/oder Servicedienstleistungen darstellen lassen.
In der Modulbibliothek sind die verschiedenen Modultypen und deren Varianten definiert. Für jede Modulvariante ist ein Satz von Regeln definiert, der die Einsatzbedingungen der Modulvarianten beschreibt. Die Trennung der Modulbibliothek von der Struktur erlaubt es, dass Modultypen an mehreren unterschiedlichen Orten der Struktur eingesetzt werden können.
Die generische Struktur bietet das Gerüst für die Platzierung der Module. Wenn verschiedene Produktvarianten unterschiedliche Anforderungen an die Struktur stellen, kann diese auf Basis eines entsprechenden Regelwerks ebenfalls angepasst werden.
Die generische Struktur in Kombination mit einer Modulbibliothek ergibt eine modulare BoM, die dafür geeignet ist, ein diverses Produktportfolio abzudecken. Diese lässtisich mit einem ganzheitlichen Vertriebskonfigurator für das Portfolio verknüpfen. So muss nicht mehr ein Vertriebskonfigurator mit einer Vielzahl von BoMs verknüpft werden.
Die im vorherigen Absatz beschriebene modulare BoM steht im Kern eines umfassenden Produktarchitektur-Informationsmodells, das einen synchronisierten end-to-end Informationsaustausch und damit end-to-end Konfiguration ermöglicht. Dieses Modell besteht aus den folgenden vier Elementen:
Diese beiden Elemente ergeben zusammen die im vorherigen Abschnitt beschriebene modulare BoM, die es durch separate Konfiguration von Struktur und Modulvarianten ermöglicht eine große Produktvielfalt abzudecken, ohne dass die Komplexität überhandnimmt. Dies ist auch deshalb möglich, da die Regeln für alle Modultypen und die Struktur mithilfe der gleichen Produkteigenschaften definiert werden.
Die Produkteigenschaften sind die Stellschrauben des Produktarchitektur-Informationsmodells. Produkteigenschaften mit auswählbaren Zielwerten bieten eine Beschreibung auf Produktebene in Form von Funktionen, Features, Leistungsstufen und zusätzlichen technischen Eigenschaften. Diese Eigenschaften können sowohl vom Kunden zur Festlegung einer Konfiguration, wie auch von der Entwicklung zur Definition von Konfigurationsregeln genutzt werden.
Das Modell wird durch kommerzielle Verkaufsoptionen ergänzt. Diese ermöglichen es dem Vertrieb Teilkonfigurationen für Märkte zusammenzufassen und zu bepreisen. Diese Verkaufsoptionen werden über Produkteigenschaften mit zugehörigen Produktkonfigurationen und Modulvarianten verknüpft.
Wie anfangs beschrieben kann end-to-end Konfiguration nur dann gelingen, wenn es hierfür eine Lösung gibt, die den Anforderungen aller Disziplinen gerecht wird und die gleichzeitig durchgängige Konfiguration auf Basis einer konsistenten Datengrundlage als „single source of truth“ ermöglicht.
Das hier beschriebene Produktarchitektur-Informationsmodell ist eine solche Lösung, die die einzelnen Disziplinen entsprechend ihren Anforderungen unterstützt und dabei mit einer gemeinsamen Datenbasis Konsistenz und Durchgängigkeit garantiert.
Im Produktmanagement werden Produkteigenschaften, die Stellschrauben der Produktarchitektur, festgelegt und Zielwerte geplant. In einer Roadmap wird festgelegt, welche Features, Funktionen und Leistungsklassen zu welchem Zeitpunkt benötigt werden, um die Marktstrategie umzusetzen. In diesem Rahmen wird auch schon identifiziert, welche Modulvarianten zur Erfüllung der Zielwerte von Produkteigenschaften benötigt werden; hier findet die Verknüpfung von Produkteigenschaften und technischen Varianten statt.
Die folgende Abbildung zeigt die Modulvariantenplanung in PALMA. Mit dieser lassen sich für Module- und Modulvarianten Pläne für die Markteinführung erstellen. So kann aktiv gesteuert werden, dass Innovationen zum richtigen Zeitpunkt in den Markt eingebracht werden. Gleichzeitig stellen Sie sicher, dass Ihre Entwicklungsabteilung und Produktion sich auf die Markteinführung einstellen können.
Die im Produktmanagement geplanten Modulvarianten müssen von der Entwicklung technisch realisiert werden. Um sicherzustellen, dass alle gewünschten Produktvarianten umgesetzt werden können, bedarf es hierbei sowohl der Modulvarianten, der Bauteile und Baugruppen, aus denen diese bestehen, als auch der Kombinationsregeln und der Absicherung der sich ergebenden Konfigurationen. Mit der generischen Struktur, der Modulbibliothek, den Bauteilen und Baugruppen für jede Modulvariante und dem Regelwerk auf Basis von Produkteigenschaften lässt sich so für jede Produktvariante eine Entwicklungs-Stückliste, eine F&E-BoM, ableiten. Wie hier zu sehen ist bedient sich diese BoM der gleichen Knoten und Modultypen, die Strukturierung ist aber den Bedürfnissen der Entwicklung angepasst.
In der Modulvariantenspezifikation (MVS) in PALMA werden Modulvarianten mit den für die Kunden relevanten Produkteigenschaften mittels einer Matrix verknüpft. Um die Module in einem Konfigurator nutzen zu können, müssen jeder Modulvariante die entsprechenden Werte der Produkteigenschaften zugewiesen werden. Die Abbildung zeigt die Verknüpfung von Modulvarianten und Produkteigenschaften für ein einfaches Produkt.
Im Vertrieb werden die Produkte passend zu den Anforderungen der Kunden konfiguriert. Hierzu werden Produkteigenschaften bzw. Produktmerkmale genutzt, die Funktionen, Features und Leistungsgrade auf Produktebene beschreiben. Der Vertrieb kann außerdem spezifische kommerzielle Verkaufsoptionen einsetzen, die bestimmte Teilkonfigurationen zusammenfassen und Produktkonfigurationen direkt mit Preisen verknüpfen. Das Ergebnis dieses Prozesses ist ein Angebot für den Kunden; und für das Unternehmen eine abgesicherte Konfiguration, auf deren Basis automatisiert alle Unterlagen erstellt werden, die für die Entwicklung, die Produktion und die Lieferung benötigt werden.
Die folgende Abbildung zeigt den in PALMA integrierten Konfigurator, mit dem Sie einfach und schnell die Konfigurationslogik ihres Baukastens überprüfen und Produktvarianten definieren können. Das Schöne ist, dass Sie in Palma Konfigurationslogik erzeugen können, ohne zu programmieren.
Auf Basis des Informationsmodell kann jede definierte Modulvariante mit allen relevanten Details aus dem ERP-System angereichert werden. So wird eine Fertigungsstückliste, eine M-BoM, erstellt, die spezifisch auf die Bedürfnisse der Lieferkette oder sogar einzelner Produktionsstandorte zugeschnitten ist. Auch hier ist der Link zu den Strukturen der anderen Disziplinen über die gemeinsamen Knoten und Modultypen gegeben, die Strukturierung ist aber für die Lieferkette angepasst.
Die Verknüpfung zum durchgängigen Informationsmodell findet hier auf Ebene der Modulvarianten statt. Diese Individualisierung für die Lieferkette ermöglicht die Ergänzung nötiger Zusatzinformationen wie Fertigungsanweisung, Materialspezifikationen oder Montageanleitungen.
Im Rahmen dieses Artikels haben wir die Herausforderungen beschrieben, mit denen sich Unternehmen bei der Umsetzung von end-to-end Produktkonfiguration konfrontiert sehen.
Es müssen die Anforderungen verschiedener Abteilungen, in denen Produkte konfiguriert werden, erfüllt werden. Gleichzeitig müssen die verschiedenen Strukturen miteinander verknüpfbar sein. Weiterhin sollte das sich ergebende Gesamtsystem in seiner Komplexität überschaubar und stabil sein, sowie Datenkonsistenz gewährleisten (single source of truth).
Wir haben in diesem Artikel gezeigt, wie eine end-to-end Konfiguration auf Basis eines Produktarchitektur-Informationsmodells umgesetzt werden kann, in dessen Zentrum eine modulare BoM steht. Die modulare BoM trennt Struktur und Lösungsvarianten und ermöglicht es so, diverse Produktportfolios in einer gemeinsamen Struktur abzudecken.
Die Variantenkonfiguration im Produktarchitektur-Informationsmodell findet mit einem System von Produkteigenschaften statt. Diese gemeinsame Sprache, die von allen Abteilungen für ihre unterschiedlichen Konfigurationsaufgaben genutzt wird, stellt sicher, dass sich eine im Vertrieb definierte Konfiguration end-to-end in eine detaillierte Konfiguration in der Entwicklung/Konstruktion über die Lieferkette hin in ein ausgeliefertes Produkt übersetzen lässt.
Wie die folgende Abbildung zeigt, ist das Informationsmodell so die gemeinsame Basis für die Beschreibung von Kundenanforderungen, technischen Lösungen, Roadmaps und Release-Plänen und jeder ausdefinierten Produktkonfiguration, die einem Kunden angeboten wird.
Das Produkt-Architektur-Informationsmodell in PALMA ermöglicht neben der end-to-end Produktkonfiguration auch eine umfassende Lösung, um die benötigten Informationsbereiche und alle relevanten Daten eines Modulsystems und des resultierenden Produktportfolios zusammenzuführen. Darüber hinaus umfangreiche Werkzeuge zur Definition, Governance (Steuerung), Optimierung und Analyse einer modularen Produktarchitektur.
Leseempfehlung: Erfahren Sie hier mehr über die Nutzung von PALMA zur Entwicklung eines Modulsystems: „Mit dem richtigen Software-Tool schneller und besser zum modularen Baukasten“
Die Nutzung eines Produktarchitektur-Informationsmodells für die end-to-end Konfiguration sowie für die Produktarchitekturentwicklung hat ganz konkreten wirtschaftlichen Nutzen:
Erleben Sie PALMA in Aktion und schauen Sie sich unsere Video-Demo für eine Auswahl von PALMA-Tools hier an:
Senior Consultant
ingo.bogemann@modularmanagement.com
LinkedIn