CAD-Luftfahrzeugbau

Konfigurationsidentifizierung - KI

2. Konfigurationsüberwachung - KÜ

3. Konfigurationsbuchführung - KB 

die Auswahl von Konfigurationseinheiten,

Gliederung von Konfigurationseinheiten zu einer Produktstruktur,

die Dokumentation von Konstruktionseinheiten sowie Nummernbildung zum Zweck der eindeutigen Identifizierung. 

Konstruktionseinheiten sind dabei jedwede Form von Produkten (Geräte, Flugzeuge, Software, usw.)

Die Beschreibung der Änderung eines Konfigurationszustands erfolgt über dessen Effectivity oder Gültigkeit .

Die Effectivity beschreibt damit den Gültigkeitszeitraum einer Konfiguration bzw. den über die Zeitachse (i.d.R. Seriennummer, Fertigungslose) sich ändernden Produktzustand.

Die Effectivity ist je nach Produktions- und Auslieferungsart definiert:

durch den Änderungsindex bei Konsumgütern und auftragsspezifischen Großserienprodukten (Gültigkeit eines Produktes direkt auf Zeitachse bezogen) oder

die Serien- oder Serialnummer (Serial Number) bei Investitionsgütern in kleiner bis mittlerer Stückzahl (typisch für Luft- und Raumfahrt sowie im Transportsektor). 

KÜ adressiert Probleme, die sich aus der Veränderung einer Konfiguration ergeben.

Das Änderungsmanagement stellt die zentrale Aktivität in der KÜ dar.

Die Konfigurationsüberwachung setzt einen festgeschriebenen, formalen Prozess für die Behandlung von Änderungen voraus. 

Der Prozess der Konfigurationsbuchführung hat die rückverfolgbare Dokumentation der Konfigurationen und Konfigurationseinheiten zum Ziel. 

Die Konfigurationsbuchführung beginnt deshalb bereits mit der ersten Erstellung von Konfigurationsdaten einsetzen.

Gegenstand der KB sind alle Daten zur Konfigurationsidentifizierung und -überwachung.

Ein Konfigurationsaudit ist die formale Überprüfung von Konfigurationen hinsichtlich

der Erfüllung von vertraglich zugesicherten funktionellen und physischen Merkmalen

der Übereinstimmung von realisiertem Produkt und zugehöriger Konfigurationsdokumentation. Es werden in diesem Sinne funktionale und physische Konfigurationsaudits unterschieden.

Konfigurationsaudits können sowohl für ganze Konfigurationen als auch einzelne Konfigurationseinheiten durchgeführt werden.

Insbesondere vor der Festlegung einer Bezugs-, Referenz- oder Basiskonfiguration sollte ein Konfigurationsaudit angestrengt werden.

Produktdaten-Management (PDM) und das darauf aufbauende Product Lifecycle Management (PLM) sind die zentralen ITLösungen für den Produktentwicklungsprozess.

PDM Einsatz häufig begrenzt auf abteilungsspezifische Entwicklungs- und Konstruktionstätigkeiten.

PLM-Lösungen hatten im Kern identische Funktionen wie PDMSysteme.

Über die verschiedenen Ausprägungen der Produktstruktur erschlossen PLM-Lösungen größere Teile des Produktlebenszyklus

Prozessplanung,

Wartungs-, Service und Ersatzteilmanagement

Erweiterungen des Konfigurationsmanagements.

internetbasierende Einbindung von Kunden und Zulieferern (Engineering Collaboration Plattform) 

das Produktmodell ( PDM)

das Prozessmodell ( Prozess Management)

das Konfigurationsmodell als Kombination vorgenannter Modelle 

Produktdaten Management (PDM)

Unterstützung der Engineering Collaboration

Unterstützung des Supply Chain Prozesses

Management der Produktionsentwicklung („Digitale Fabrik“)

Customer Needs Management (CNM) als Erweiterung des Anforderungsmanagements

Managementunterstützung für

Governance und Compliance

Programm-/Portfoliomanagement

Analyse und Berichtswesen

Lifecycle Assessment 

Heute verfügbare PLM Anwendungen deckt häufig den Bereich des Team Managements (TDM) und von PDM-Systemen ab – sie bleiben auf der „Engineering-Seite“.

Eine Erweiterung entlang des Produktlebenszyklus führt zur Überlappung und Konkurrenz mit PPS-Systemen.

Die Ausdehnung eines PLM-Systems auf die Entwicklung von Software und Elektronik führt zum Systems Lifecycle Management (SysLM).

Primäres Ziel aktueller Entwicklungen ist das ganzheitliche Management der Prozesse und der Organisation sowohl in der frü- hen Phase des PEP als auch in der Betriebsphase des Produkts.

PPS Systeme besitzen häufig nicht die notwendig flexible Gestaltungsmöglichkeiten zur firmenspezifischen Adaption sowohl des Produkt- als auch des Prozessmodells

Eine Verbindung PLM und PPS auf dem kleinsten gemeinsamen Nenner führt daher nicht zum Optimum

Voraussetzung ist eine intelligente Kopplung von PLM und PPS

Häufig scheitern PLM-Initiativen oder gelingen nur mit erheblichen Kostenerhöhungen und Verzögerungen.

Ein wesentlicher Grund ist die zu „technische Sicht“ auf die PLM Einführung.

Eine PLM Initiative gehört als Prozess-, Methoden- und Tool- Änderung zu den Change Prozessen.

Diese Change Prozesse sind beeinflusst von den Faktoren

Mensch,

Technik und

Organisation.

Sie wirken auf die drei Dimensionen der Nachhaltigkeit: Ökologie, Ökonomie und Soziales

Grundsätzlicher Umfang (= Komplexität) der PLM-Lösung in Übereinstimmung mit Unternehmensstrategie und – möglichkeiten

Erfüllung der funktionalen Anforderungen durch die PLMLösung

„Kompatibilität“ mit bzw. Anpassungsfähigkeit an vorhandene IT-Lösungen (CAD-System, PPS, …)

Aufwand des Customizings (Umfang und Kosten)

Bedienoberfläche („Usability“ Anwenderakzeptanz)

Grundsätzlicher Umfang (= Komplexität) der PLM-Lösung in Übereinstimmung mit Unternehmensstrategie und – möglichkeiten

Bei der Einführung von PLM-Lösungen sind alle daran Beteiligten einzubeziehen und zu beteiligen!

Die Einführung einer PLM-Lösung ist mittels ChangeManagement-Ansatzes durchzuführen.

Dieser Ansatz bietet Menschen in Veränderungsprozessen Hilfestellungen an, um organisatorische, technische und psychologische Komponenten von Veränderungsprozessen in Einklang miteinander zu bringen.

Es ist die Einbeziehung aller am Projekterfolg beteiligter Menschen, d.h. Mitarbeiter, Anwender, Stakeholder und Führungskräfte erforderlich.

Nur wenn Akzeptanz für die Einführung einer PLM-Lösung besteht, wird sie erfolgreich sein!

Leistung( Technik) , Termine, Kosten

Innerhalb des Dreiecks gilt der „Satz von der Erhaltung des Ärgers“: Wird ein Projekt in eine Richtung „gepusht“, geht es immer zu Lasten der anderen Eckziele! 

1. Ein geändertes Denk- und Arbeitsverhalten, das auf ganzheitliches Denken ausgerichtet ist und partnerschaftliches interdisziplinäres Arbeiten innerhalb des Unternehmens sowie mit Kunden und Zulieferern voraussetzt.

2. Eine methodische Vorgehensweise, die eine Betrachtung des gesamten Produktlebenszyklus beinhaltet, bei der nicht nur das Produkt, sondern auch die Prozesse im Vordergrund stehen.

3. Eine Organisationsform, die eine teilweise Parallelisierung unterschiedlicher Arbeitsprozesse ermöglicht und interdisziplinäre Teamarbeit fördert.

4. Den Einsatz geeigneter informationstechnischer Hilfsmittel, die diesen ganzheitlich integrierten Ansatz unterstützen. 

Die integrierte, multidisziplinäre Produktentwicklung umfasst alle Tätigkeiten und Disziplinen, die das Produkt und sein zur Produktion, Betrieb und Entsorgung benötigtes Umfeld (Werkzeuge, Vorrichtungen, Maschinen, Anlagen,...) über den Produktlebenszyklus, alle beteiligten Disziplinen und die Zuliefererkette beschreiben.

Das Ergebnis ist eine vollständige Produktdefinition („Intellectual Product“), die aus sichten- und phasenorientierten Produktstrukturen und allen zugehörigen Dokumenten und Konfigurationen besteht.

Arbeitsprozesse und die Organisationsform müssen einerseits die Kreativität und andererseits die Parallelisierung und Optimierung der nachfolgenden Lebenszyklusphasen unterstützen. 

Die Modellbasierte Virtuelle ProduktEntwicklung (MVPE) ist die durchgehende, rechnerunterstützte, formale Modellbildung und Dokumentation entlang aller entwicklungsrelevanten Phasen des Produktlebenszyklus.

1. Anforderungs-/Aufgabenklärung, Planen

2. Konzipieren

3. Entwerfen

und 4. Ausarbeiten, Detaillieren 

 (dt. Anforderungsentwicklung)

bezieht sich auf die Entwicklung von Anforderungen aus abstrakten Vorgaben des Kunden.

steht für die Aktivitäten am Beginn einer Entwicklung zur Präzisierung der Problem- und Aufgabenstellung.

bezeichnet einen kooperativen, iterativen, inkrementellen Prozess zum Ermitteln, Analysieren, Verstehen und Festlegen von Anforderungen.

alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,

die Projektbeteiligten eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen und

alle Anforderungen konform zu den Vorschriften dokumentiert und spezifiziert sind.

1. Anforderungen erheben, durch z. B. Befragung von Stakeholdern,

2. Anforderungen dokumentieren, durch z. B. Lastenhefte in natürlicher Sprache,

3. Anforderungen verifizieren*, z. B. im Hinblick auf eine zugrunde liegende Spezifikation,

4. Anforderungen validieren*, z. B. im Hinblick auf den zu erfüllenden Zweck oder zugrunde gelegte Kundenanforderungen

5. Anforderungen verwalten, z. B. über spezifische administrative Werkzeuge (Requirements Management)

Ein Requirement (dt. Anforderung) definiert eine Aussage über die geforderte oder gewünschte Eigenschaft.

Mögliche Eigenschaften:

Funktionalität, die das Produkt oder das System zu leisten hat (funktionale Anforderung)

Qualitätsmerkmal (nicht-funktionale Anforderung),

Bedingung oder Fähigkeit, die von einer Person zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird

Stakeholder sind Personen oder Organisationen mit Interesse an dem geplanten System. 

Operationale Anforderungen: Beschreibung des Verhaltens, Beispiel: „Der Anschluss soll im Flug durch eine selbsttätig schließende Klappe verdeckt sein“

Quantitative Anforderungen: definieren einer messbaren Größe, Beispiel: „Das Bauteil soll eine Masse von maximal 2kg haben“

Qualitative Anforderungen: festhalten eines Qualitätsaspekts, Beispiel: „Das Bauteil soll eine Längentoleranz von +/-0,1 haben.“

Deklarative Anforderungen: festlegen einer ersten Lösung. Beispiel: „Das Bauteil soll aus CFRP hergestellt werden.“

Außerdem: Härtegrad von Anforderungen:

Unverzichtbar, wesentlich, wünschenswert

Das Lastenheft enthält die Gesamtheit aller Forderungen an die Lieferung und Leistungen eines Auftragnehmers. 

Das Pflichtenheft

beschreibt in konkreter Form die angestrebten Lösungen der Anforderungen,

wird vom Auftragnehmer erstellt,

beinhaltet die erste (System-)Spezifikation,

sollte Fragen nach dem „Wie“ und Womit“ beantworten,

sollte Bestandteil des Vertrags zwischen Auftragnehmer und Auftraggeber sein. Definition „Pflichtenheft“:

Das Pflichtenheft beschreibt die vom Auftragnehmer erarbeiteten Realisierungsvor- gaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts.

Verifikation und Validierung sind wichtig, um Fehler in den Anforderungen zu identifizieren.

Validierung: „die richtigen Dinge machen“:

Vergleich der Anforderungen an das Produkt mit verfügbaren Ergebnissen

Luftfahrt: Ist die Anforderung zutreffend und erfüllbar?

Verifikation: „die Dinge richtig machen“

Vergleich von Prozessanforderungen mit Prozessergebnissen

Es handelt sich hierbei um eine interne Sicht innerhalb des Unternehmens.

Luftfahrt: Wie/mit welchen Mitteln (Means of Compliance – MoC) wird die Anforderung erfüllt?