Die Beherrschung und Optimierung des Produktlebenszyklus wird von Unternehmen zunehmend als Kernkompetenz, der einen strategischen Wettbewerbsfaktor darstellt, begriffen. Dies setzt die Harmonisierung und Integration verschiedener Anwendungsbereiche bzw. Domänen entlang des Produktentwicklungsprozesses in einem informationstechnisch ganzheitlichen Konzept voraus. Viele Domänen übergreifende IT-Projekte zur Einführung von PLM Lösungen werden aktuell jedoch so angegangen, als würden klassische IT-Produkte wie z.B. PDM, CAx-Komponenten oder aber ERP-Systeme eingeführt. Typischerweise ziehen Kunden für die Konzeption von IT-Systembebauungskonzepte Business Strategie und Prozessberatungsunternehmen zu Rate, deren wesentlicher Vorteil die Herstellerunabhängigkeit ist. Zur konkreten Umsetzung wird technische IT-Applikationsberatung bei den IT-Herstellern des spezifischen Anwendungsbereichs eingekauft. Der integrative Projektanteil wird dabei häufig über IT-Konzept-Schlagworte wie „Lose Kopplung“ oder Serviceorientierte Architektur (SOA) wegdiskutiert.
Im beschriebenen Beratungsansatz klafft eine Lücke, die in aktuellen IT-Projekten oft schwer zum Tragen kommt, die erfolgreiche Umsetzung der Projektziele erschwert und im ungünstigsten Falle scheitern lässt. Integration, unabhängig von vieldiskutierten Konzepten wie Lose Kopplung oder SOA, bedeutet immer, dass sich Systemelemente und deren Beziehungen aus IT-Systemen einer Domäne zumindest teilweise auch in IT-System anderer Domänen wiederfinden müssen. Dies erhöht die Anforderungen an die Konzeption der Produktmodelle für die Implementierung derartiger Systeme und erfordert in der Folge methodische Vorgehensweisen, eingebettet in neue Ansätze des PLM Solution Consulting. Der Artikel erklärt einige der aktuellen Schwierigkeiten und zeigt wie diese sich durch Einsatz der Do(PLM)Con Methode lösen lassen.
Dieser Artikel erschien 2011 in folgender Quelle
FISCHER, Jörg W.; Lammel, Bernhard; Hosenfeld, Dirk; Glauche, Marc; Brinkmeier, Bernd:
Implementierung domänenintegrierender PLM-Lösungen.
Do(PLM)Con – ein Ansatz zur Konzeption und Realisierung domänenintegrierender PLM-Lösungen.
In: Industrie Management,
Berlin, 27(2011)5, S. 17-21.
(ISSN 1434-1980)
Derzeitige IT-Lösungsbebauung in der Produktentwicklung
Rechnereinsatz und IT-Systeme ermöglichen digitale Daten zu erzeugen und zu verwalten. Die derzeitig in der Produktentwicklung zum Einsatz kommenden Systeme lassen sich nach ihrem Zweck im Wesentlichen in die folgenden zwei IT-Systemtypen unterscheiden.
- Authoring Systeme,
sind Systeme denen die Verantwortung zu Erzeugung der jeweils relevanten Daten obliegt. Mit ihnen können Datensätze dargestellt werden, sie bieten Funktionalität, diese Daten mit Informationen anzureichern und Beziehungsgeflechte zwischen ihnen zu modellieren. Typisches Beispiel für solche Systeme sind CAx- und DMU-Systeme. Ebenso zählen typische Client Anwendungen wie der PLM Rich- oder Thin-Client hinzu. - Datenmanagementsysteme,
sind Systeme, die die Funktionalität bereitstellen, die von den Authoring System erzeugten Daten zu verwalten und zu sichern.
Die Basis eines informationstechnisch Konzepts für die Produktentwicklung bilden die eingesetzten Datenmanagementsysteme. In Bild 1 sind wesentliche am Produktentwicklungsprozess beteiligten Domänen aufgezeigt. Darüber hinaus sind die typischerweise genutzte IT-Systemklassen der Datenmanagementsysteme sowie deren Einsatzhorizont im Verlauf des Produktentwicklungsprozess aufgeführt. Bei der Realisierung eines domänintegrierenden PLM-Konzepts sind dies die IT-Systemklassen, die bei Diskussionen über eine Zusammenführung von Prozessen und Daten betrachtet werden. Insbesondere stehen bei solchen Diskussionen die Integration zwischen PDM-, ERP- und Konfigurationssystemen im Fokus.
Aufgabe von PDM-Systemen ist die Verwaltung, Bereitstellung und das Prozessmanagement bei der Erstellung der geometrischen Produktdaten. ERP-Systeme bieten die notwendigen Funktionen zum Management aller für die Herstellung, den Vertrieb und die Kundenbetreuung notwendigen Ressourcen, Daten und Informationen. Die IT-Systemklasse „Konfigurationssysteme“ wurde durch die zunehmende kundenindividuelle Massenfertigung notwendig. Ihre wesentliche Aufgabe ist die automatische Konfiguration definierter Produktinstanzen. Sie dient in der Produktion dazu, für eine definierte Produktinstanz (die vom Kunden bestellte Variante) benötigte Teile zu bestimmen und deren Bauarbeit in der angegebenen Konfiguration zu prüfen [1].
Digitale Fabrik Systeme unterstützen die ganzheitliche Planung, Realisierung, Steuerung und laufende Verbesserung aller wesentlichen Fabrikprozesse und -ressourcen in Verbindung mit dem Produkt. Dies beinhaltet als einen Aspekt entsprechende Authoring Systeme für die Methoden der Digitalen Fabrik. Zum anderen haben verschiedene Anwender unter der Bezeichnung Manufacturing Process Management inzwischen IT-Datenmanagementsysteme für die Digitale Fabrik entwickelt, die die im Rahmen ihrer Anwendung anfallenden Daten über den Lebenszyklus bereitstellen und verwalten (siehe hierzu VDI 4499 Blatt 1:2008-02).
Datenmanagementsysteme für die Domänen elektrische Entwicklung und Softwareentwicklung dienen dazu mechantronische Elemente, deren Komponenten sowie die entsprechenden Softwarestände zu verwalten. Aktuell werden solche Systeme häufig als Individualsoftware ausgeführt oder auf Basis von PDM-Systemen entwickelt.
Die methodische technische Problematik eines domainintegrierenden PLM
PLM-Lösungen bilden das funktionale, administrative und informationstechnische Rückrad des Produktentwicklungsprozesses. Die Idee von PLM ist im Wesentlichen Ende der 90er Jahre aus einer Erweiterung von PDM-Systemen entstanden. Das Ziel ist es, die relevanten Daten und Informationen zu einem Produkt über dessen gesamten Lebenszyklus zu managen.
Vor der Umsetzung eines solchen integrierten Produktmodells, steht die Frage, welche Integrationsbereiche dieses abdecken soll. In Bild 2 sind die wesentlichen Integrationsdimensionen des PLM dargestellt. Die Darstellung folgt dabei im Wesentlichen Eigner, Bitzer und Burr [3]. Die Integration über die Achse „Lifecycle“ spannt sich entlang des Produktlebenszyklus eines Produkts vom Produktkonzept bis hin zum Produktsupport so dass ein paralleles Arbeiten der Produktentwicklung und der Produktionsplanung im Rahmen eines Concurrent Engineering möglich wird. Mit dem Verschwimmen der klassischen gewerkartigen Trennung der verschiedenen Domänen (Elektrik, Mechanik, Informatik) entsteht darüber hinaus die Notwendigkeit, Produktmodelle entlang der Achse Domain d.h. der verschiedenen Anwendungsbereiche/Gewerke zu integrieren. Um die vom globalen Markt geforderten, kundenindividuellen Produkte zu vertretbaren Kosten liefern zu können wird die Entwicklung modularer Baukästen, die in verschiedenen Produktlinien genutzt werden können, zu einem wichtigen Wettbewerbsfaktor. Demzufolge muss auch eine Integration über die Achse „Product Lines“ vorgenommen werden. Ist es das Ziel ein integriertes Produktmodell umzusetzen dann ist es notwendig dessen Implementierungsraum im Rahmen dieser Dimensionen zu definieren (Bild 2, A).
Ein Beispiel für eine aktuelle IT-Landschaft, die in viele Industrieunternehmens (z.B. der Automobilindustrie) vorzufinden ist, ist in Bild 3 (Detail A) skizziert. Um einen gewachsenen, i.d.R. wenig harmonisierten Produktentwicklungsprozess, sind individuelle IT-Systemlösungen entstanden. Mit der Tendenz hin zu Standardisierung von Software wurden dann Standardlösungen wie z.B. PDM- und ERP-Systeme implementiert. Derzeit ist es das Ziel die Zahl der Individualsysteme zu reduzieren und deren Daten- und Funktionsinhalte in vorhandene Standardlösung zu integrieren. Mit der Notwendigkeit hin zu einem domainübergreifenden PLM ist es zukünftig die Aufgabe eine geeignete IT-Systembebauung, die diesen Ansatz realisieren kann zu definieren und diese unter Berücksichtigung der vorhandenen Systembebauung in einem evolutionären Prozess technisch umzusetzen.
Ein in diesem Zusammenhang oft propagiertes Idealbild (siehe Bild 3, Detail B) ist es, vorhandene Systeme (z.B. PDM, ERP, Konfigurationssysteme) lose über einen sog. Servicebus zu koppeln. Die von diesem Ansatzes verfolgte Idee ist es, von jedem der beteiligten Systeme standardisierte „Services“ anbieten zu lassen, die von den anderen beteiligten Systemen verstanden und genutzt werden können.
Bei der Umsetzung eines solchen Ansatzes besteht oft die Hoffnung, dass es lediglich der Implementierung geeigneter Services bedarf, um wie von selbst die Integrationsproblematik zu lösen und damit eine komplizierte Klärung fachlicher und politischer Probleme zwischen den beteiligten Domänen nicht mehr erforderlich ist. Ein solches Idealbild ist jedoch nicht realistisch. Services und SOA bezeichnen ein IT-Architekturparadigma welches auf eine IT-technisches Kopllung von Systemen abzielt. Eine Lösung für fachliche Probleme stellen derartige Ansätze nicht zur Verfügung.
Geht man in der Analyse der Situation noch einen Schritt tiefer lässt sich erkennen, dass diese nicht so einfach wie in Bild 3 (Detail B) dargestellt ist. IT-Systeme im Produktentwicklungsprozess stellen Methoden bereit, die Anwendungsfälle der Produktentwicklung realisieren. Beispiele solcher Anwendungsfälle sind u.a. das Erstellen von CAD-Dokumenten, von Stücklisteneinträgen sowie das revisionssichere Verwalten derartiger Dokumente über den zeitlichen Verlauf der Produktentwicklung. Die im Rahmen der Anwendungsfälle erstellten und modifizierten Produktdaten werden in den Datenmanagementsystemen der jeweiligen Domänen in Form von vernetzten Produktmodellen abgebildet. Um dies zu leisten, stellen IT-Systeme Metamodelle zur Verfügung mit denen sich diese Produktmodelle abbilden lassen.
Die Integration verschiedener Domänen verfolgt als wesentliches Ziel, Anwendungsfälle zu realisieren, die zuvor nicht realisierbar waren. Ein Beispiel eines solchen Anwendungsfalls ist die Bereitstellung eins lagerichtigen, digitalen Produktprototypen der sich auf Basis vom Kunden wählbaren Optionen konfigurieren lässt.
Zur Realisierung solcher Anwendungsfälle müssen Daten über die Domängrenzen hinweg zusammengeführt werden. Dabei muss berücksichtigt werden, dass um die integrativen Anwendungsfälle überhaupt zu ermöglichen neue, bisher nicht dokumentierte Informationsinhalte, bei der Zusammenführung ergänzt werden müssen. Das bedeutet dass die zugrundeliegenden Produktmodelle nicht nur zusammengeführt sondern deren Zusammenführung um Informationsinhalte ergänzt werden müssen. Diese Informationsinhalte besitzen einen eigenen Lebenszyklus und müssen folglich persistent in einem System vorgehalten werden.
In Bild 4 ist das aus dieser Tatsache resultierende „Reale Bild“ dargestellt. In den verschiedenen Datenmanagementsysteme (PDM, ERP, Konfigurationssysteme) sind die Produktmodelle des jeweiligen Anwendungsbereiches abgebildet. Durch den Ansatz zur Integration der Anwendungsbereiche werden im gezeigten Beispiel Teil-(Modelle) der Systemklassen ERP- und Konfigurationssystem in das Produktmodell des PDM-Systems integriert (Bild 4, Detail A). Um einen solchen ersten Schritt der Integration zu verwirklichen, muss das Trägersystem der Integration (in Bild 3 B das PDM-System) Modellelemente der anderen beteiligten Systeme abbilden. In einem nächsten Schritt werden dann die neuen Informationsinhalte erzeugt und dadurch persistente Beziehungsgeflechte zwischen den Elementen der verschiedenen Domänen aufgebaut. Erst durch dieses Vorgehen wird die notwendige Basis geschaffen, den jeweiligen anwendungsbereichsübergreifenden Anwendungsfall abzubilden.
Die Anwendungsfälle werden vom Anwender mit Hilfe von Funktionen in IT-Applikationen durchgeführt. Die Applikationen (z.B. CAD, siehe Bild 4, Detail C) greifen auf die im Datenmanagementsystem abgebildeten Produktmodelle zu, stellen deren Daten für den Nutzer bereit und bieten Funktionalitäten, um mit dem Modell arbeiten zu können.
In Bild 5 ist der Zusammenhang dargestellt. Ein Anwendungsfall kann mit Hilfe einer oder mehrerer technischer Funktionen erfüllt werden. Diese Funktionen sind technisch in einer Applikation realisiert. Ob es sich dabei um ein CAx-System, einen typischen PLM-Rich Client oder aber einen browserbasierten Thin Client handelt, ist unerheblich. Applikationen lesen die für sie notwendigen Daten aus den Produktmodellen, die im jeweiligen Datenmanagementsystem abgebildet sind. Dabei nutzen die Applikationen Funktionsumfänge die das Datenmanagementsystem anbietet (z.B. eine vom Datenmanagementsystem vorkonfigurierten Struktur). Um die Daten auszulesen und die gewünschten Funktionen für den Anwender fehlerfrei ausführen zu können, setzt jede Applikation eine spezifische, semantische Konsistenz der Daten voraus. Ist diese nicht vorhanden, kann die Funktion nicht oder nur teilweise genutzt werden. Das bedeutet, dass jede Applikation aufgrund ihrer Forderung nach semantischer Konsistenz die Modellierungsflexibilität im Produktmodell einschränkt.
Integration von Teilmodellen anderer Domänen bedeutet letztendlich, dass neue Inhalte in das Datenmodell des Datenmanagementsystems gelangen, dass das integrierte Datenmodell tragen soll. Desweiteren bedeutet Integration, dass neue Funktionen auf demselben Datenmodell durchgeführt werden. Das verstärkt die Gefahr von Kollisionen der verschiedenen Anforderungen der domainspezifischen Applikationen an die semantische Konsistenz des Produktdatenmodells. Letztendlich bedeute das, dass je nachdem wie die Integration aufgesetzt wird ein aufrechterhalten angebotener Funktionen nicht mehr zu gewährleisten ist. Bei der Ausgestaltung eines domänintegrierten PLM ist es daher notwendig die betreffenden Anwendungsfälle, die sie realisieren den technischen Funktionen sowie deren Anforderungen an die semantische Konsistenz der dabei aufgebauten Modelle entsprechend zu berücksichtigen.
Demgegenüber steht der bisher gängige Ansatz, der bei dem Aufbau von integrierten Produktmodellen lediglich auf rein methodisch/fachliche Anforderungen fokussiert. Oft wird in diesem Zusammenhang gefordert, die Applikationsintegration und die eingesetzten Datenmanagementsysteme an die jeweils aufgeworfene methodische Problematik bedingungslos anzupassen. Liegt ein solcher Denkansatz einem Integrationsprojekt zugrunde zeigt sich inzwischen häufig, dass die Projekte in der Durchführung problematisch sind und im schlimmsten Falle scheitern. Der Grund hierfür liegt im wesentlichen daran, dass sich die eingesetzten IT-Systeme nicht in jedem Falle und wenn, dann nur in einem von der Systemphilosophie vorgegebenen Maße, an die methodisch/fachlichen Anforderungen anzupassen lassen.
Damit ist der Gedanke, dass sich die IT-Systeme den methodischen Konzepten der Anwendungsbereiche zu fügen haben, nicht mehr haltbar. Letztendlich haben die IT-Systemklasse, deren Philosophie und zugrunde liegende Technologie wesentlichen Einfluss auf das sich herauskristallisierende integrierte Produktmodell. Immer häufiger tritt in der Folge die Situation ein, dass sich die Anwendungsbereiche mit den Vorgaben der IT-Systeme arrangieren müssen um die Vorteile einer integrierten Systemlandschaft im Unternehmen nutzbar zu machen.
Die Problematik von domainintegrierenden PLM Projekten
Dennoch werden viele IT-Projekte zur Umsetzungen von domainintegrierende PLM Lösungen noch immer so angegangen, als würden domänspezifische Lösungen eingeführt.
Häufig wird dabei ein IT-Projektansatz verfolgt, der zwischen einer rein strategisch/methodischen Sicht in der Anforderungen diskutiert und beschrieben werden und einer IT-technischen Sicht, in der die Anforderungen technisch umgesetzt werden, unterscheidet (Bild 6, links).
Für die methodischen Projektumfänge setzen Kunden vornehmlich ihr eigenes Personal unter Hinzuziehung von IT-Beratungsunternehmen ein, die oft keinen spezifischen Bezug zu einem bestimmten Datenmanagementsystem haben. Der wesentliche Vorteil dieses Vorgehens ist die dadurch realisierte Neutralität. Die konkrete technische Umsetzung der Lösung wird dann als Beratungsleistung z.B. beim IT-Systemunternehmen, die das genutzte Datenmanagementsystem vertreiben, eingekauft. Dem Ansatz liegt i.d.R. die Erwartung zugrunde, dass das jeweilige Softwareunternehmen den technischen Anteil dann -notfalls mit Hilfe von ausgeprägter Anpassungsprogrammierung- umsetzen wird.
Dieses Vorgehen ist noch von der Zeit geprägt, in der die Unternehmen Individualsoftware entwickeln lassen mussten, da Standardsoftware nicht verfügbar war.
Bei der Implementierung von domänübergreifenden Produktmodellen klafft im geschilderten Ansatz jedoch eine Lücke da beim Aufbau der Modelle die Problematik der semantischen Konsistenz im Modell nicht hinreichend berücksichtigt wird (Bild 6, Mitte). Diese Lücke erschwert die erfolgreiche Umsetzung in IT-Projekten und lässt diese im ungünstigsten Falle scheitern. Die Einführung eines domänübergreifende PLM-Ansatz verlangt, ein technisch/methodisch ganzheitliches Konzept für eine intergierte Modellwelt. Ein solches Konzept muss methodisch und technisch so aufgebaut sein, dass sich die notwendigen Anwendungsfälle realisieren lassen ohne durch deren Realisierung andere notwendige Anwendungsfälle auszuschließen.
Do(PLM)Con, ein methodischer Ansatz zum PLM-Solution Consulting
Ein derartiger Ansatz ist von der Artung her vergleichbar mit existierenden systematischen Ansätzen wie z.B. der methodischen Konstruktion oder dem systematischen Vorgehen zur Arbeitsstrukturierung.
Im Rahmen eines industriellen Forschungsprojektes von Siemens PLM und der Beuth Hochschule für Technik Berlin wurde ein solcher Ansatz entwickelt. Er basiert auf der Analyse bester Industriepraxis hin zu einer generischen Methode, die in ihren Grundzügen im Folgenden vorgestellt wird.
Die „Domain integrating PLM Consulting Method [Do(PLM)Con]“ systematisiert die Konzeption und Umsetzung integrierte Produktmodelle. Mit Do(PLM)Con lässt sich ein Gestaltungsrahmen für domainübergreifenden Produktmodelle definieren. Ein solcher Gestaltungsrahmen macht Vorgaben, wie das Produktmodell unter gegebenen Rahmenbedingungen (u.A. Use Cases, Einflussfaktoren) in einem IT-System prinzipiell aufgebaut sein muss, um die gestellten Anforderungen zu erfüllen, lässt jedoch Freiheitsgrade zur individuellen, unternehmensspezifischen Ausgestaltung[4].
Um einen solchen Gestaltungsrahmen zu definieren stellt Do(PLM)Con ein Werkzeugkasten bestehend aus verschieden Methoden, Best Practice Bibliotheken und systematischen Vorgehensweisen bereit, die in den verschiedenen Umsetzungsphasen helfen einen technisch realisierbares integrierten Produktmodell zu definieren und zu dokumentieren. Darüber hinaus definiert Do(PLM)Con ein prinzipielles Vorgehensmodell das folgende systematische Umsetzungsphasen beinhaltet.
- Integrated Structure Pre-Framing,
- Structure Influence Factor Analyzing,
- Structure Prototyping,
- Definition of Structure Framework und
- Continues Build and Test of Integrated Structure.
Im ersten Schritt dem „Integrated Structure Pre-Framing“ ist es das Ziel prinzipielle Lösungsansätze für die umzusetzende Teilmodelle des integrierten Produktmodells zu definieren. Diese werden in der Do(PLM)Con Methodik in sog. Realization Packages analysiert und dokumentiert. Ein Realization Package definiert eine mögliche technische Umsetzungsalternative. Es beinhaltet dabei die umzusetzenden Anwendungsfälle, die Funktionen mit denen diese umgesetzt werden sollen/können sowie die Applikationen die diese Funktionen zur Verfügung stellen (Bild 7, Detail A). Durch Auswahl eines Integrationsansatzes im Raums möglicher Integrationsansätze [4] für das jeweiligen Realization Package wird hinaus die Anwendungsart, die Strukturierung sowie die IT-Systemklasse und das genutzte Datenmanagementsystem festgelegt (Bild 7, Detail B).
Auf Basis dieser Rahmendefinition kann dann der Inhalt des jeweils umzusetzenden Produktmodells, die aus Drittsystemen zu integrierenden Daten, die notwendigen Schnittstellen sowie die Verantwortung für die Dateninhalte die sich daraus ergeben abgeleitet werden (Bild 7, Detail C). Die Definition eines Realization Package legt damit einen Rahmen von Prämissen für eine mögliche Umsetzungsalternative fest. Für jede Umsetzungsalternative wird dann durch eine Analyse aufgezeigt, welche Potenziale aber auch welches Umsetzungsrisiko das jeweilige Realization Package in sich trägt. Ein Realization Package ist ein auf hoher Abstraktionsebene festgelegter Rahmen, der sich verständlich und transparent in den jeweiligen Entscheidungsgremien diskutieren und beschließen lässt. Die Phase endet mit der Festlegung des Entscheidungsgremiums, welche Realization Packages für ein domainintegrierendes PLM als geeignet, für die weitere Umsetzung angesehen und in den nachfolgenden Phasen weiterverfolgt werden.
Den im Realization Packages festgelegten Prämissen folgen Faktoren, die in der technischen Umsetzung das jeweilige integrierte Modell beeinflussen und dessen Modellierungsflexibilität eingrenzen. Einflussfaktoren können sich u.A. aus methodischen Ordnungsvorgaben und Wünsche der Anwendungsbereiche, aus den Anwendungsfällen, aus dem gewählten Integrationsansatz, aus der IT-Systemklasse sowie der Architektur und Funktionsmächtigkeit des gewählten IT-Systems ergeben. Diese Einflussfaktoren werden in der anschließenden Phase, dem „Structure Influence Factor Analyzing“ expliziert, analysiert und systematisch bewertet. Dabei wird einerseits deren Wichtigkeit für den Kunden/Anwender des integrierten Produktmodells als auch der Aufwand zur Einhaltung/Realisierung dieser bewertet. Auf Basis der identifizierten Einflussfaktoren liefert Do(PLM)Con Strukturierungsvorschläge die am Ende der Phase „Structure Influence Factor Analyzing“ bereitstehen.
Aufbauend auf den erzielten Ergebnissen werden in der Phase „Structure Prototyping“ Prototypstrukturen aufgebaut und realitätsvergleichbar erprobt. Das Prototyping erfolgt dabei analog zu einem Prototyping wie es z.B. in der Automobilindustrie praktiziert wird. Realitätsvergleichbare Prototypen werden unter „realitätsnahen“ Produktivbedingungen außergewöhnlichen Belastungen ausgesetzt. Dabei kann das Verhalten, die Anwendbarkeit, der Performanz sowie die tatsächlichen Auswirkungen der Einflussfaktoren analysiert werden. Anhand dieses Prototyps ist es möglich prospektiv Einflüsse, Aufwände und Risiken bei der Umsetzung zu diskutiert und damit die gewählte Lösung hinreichend abzusichern. Auf Basis der gemachten Erfahrungen kann in der Folge die „Definition of Structure Framework“ durchgeführt werden. In dieser wird ein Gestaltungsrahmen aufgestellt, der für die Implementierung als ein Leitmodell fungiert [4]. Der Gestaltungsrahmen wird den Projektbeteiligten vorgestellt und ermöglicht eine transparente, abschließende Diskussion in der mögliche Anpassungen und Kompromisse über die Domänen abgestimmt und kommuniziert werden können. Am Ende dieser Phase wird vom Management sowohl auf Kunden- als auch auf Anbieterseite der Gestaltungsrahmen genehmigt und die eigentliche Umsetzung, die dann in der letzten Phase des „Continues Build and Test of Integrated Structure“ erfolgt, kann begonnen wenden.
Fazit und Ausblick
Do(PLM)Con stellt eine Basis bereit, die bei domänübergreifenden PLM-Projekten hilft die fundamental richtigen Entscheidungen zu treffen, damit das intergierter Produktmodelle den Anforderungen genügt, ohne die Notwendigkeit aufwändiger nachträglichen Systemanpassungen. Mithilfe von Do(PLM)Con können einfache und flexible Entwürfe von Prototypen integrierter Produktmodelle abgeleitet werden. Durch das Prototyping als zugrunde liegende Entwurfsmethodik kann damit bereits in einer frühen Phase der Integration ein konkreter Gestaltungsvorschlag für die Struktur in Form eines Prototyps als Experimentierumgebung, Diskussionsbasis und Erkenntnisobjekt zur Verfügung gestellt werden um so aufwändige Nachbesserungen zu vermeiden und sich üblicherweise lang hinziehende Integrationsprojekte nachhaltig zu beschleunigen. Do(PLM)Con wirkt sich damit nachhaltig aufwandsreduzierend bei der Umsetzung intergierte Produktmodell aus. Ebenso kann der Aufwand zur Aufrechterhaltung und Pflege der Struktur während der Anwendung wesentlich verringert werden.
Literatur
- Sinz, Carsten (2003): Verifikation regelbasierter Konfigurationssysteme.
Tübingen: Uni-Diss,.http://w210.ub.uni-tuebingen.de/dbt/volltexte/2004/1055/, 10.07.2009. - Kern, E.-M. Verteilte Produktentwicklung. Rahmenkonzept und Vorgehensweise zur organisatorischen Gestaltung. Herausgegeben von Technische Universität Hamburg-Harburg, 2005
- Eigner, Martin; Bitzer, Michael, Burr Holger: Produktlebenszyklus mit Unterbrechungen. Abstimmungsbedarf zwischen Konstruktion und Produktion. In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb, Jahrg. 102 (2007) 9, S. 582-586.
- Jörg W. Fischer; Marc Glauche: Skizzierung eines Gestaltungsrahmens für Produktstrukturen. Integration der Anwendungsbereiche CAx und BOM unter Berücksichtigung der Aspekte Methodik, Organisation und IT-Technologie. In: ZWF Zeitschrift für wirtschaftlichen Fabrikbetrieb, Jahrg. 106 (2011) 3, S. 127–132.
