Integration von Produktdatenmanagement-Systemen und Softwarekonfigurationsmanagement-Werkzeugen

Inhaltsverzeichnis

0 Einleitung

1 Konfigurationsmanagement
1.1 Produktbegriff
1.2 Begriffsbestimmung
1.2.1 Konfigurationsmanagementorganisation und -planung
1.2.2 Konfigurationsidentifizierung
1.2.3 Konfigurationüberwachung
1.2.4 Konfigurationsaudit
1.2.5 Konfigurationsbuchführung

2 Produktdatenmanagement
2.1 Der Produktlebenszyklus als Bezugsebene des Produktdatenmanagements
2.1.1 Produktentwicklung
2.1.1.1 Produktplanung
2.1.1.2 Produktkonstruktion
2.1.1.3 Produktionsvorbereitung
2.1.2 Produktherstellung - Produktvertrieb - Produktnutzung - Produktentsor- gung
2.2 Anwendungssysteme im herstellungsorientierten Produktlebenszyklus
2.3 Produktdaten und Prozesse
2.4 Produktdatenmanagement und Produktdatenmanagement-Systeme
2.4.1 Begriffsbestimmung
2.4.2 Funktionen von Produktdatenmanagement-Systemen
2.4.2.1 Digitales Archiv und Dokumentenmanagement
2.4.2.2 Produktstrukturmanagement
2.4.2.3 Workflow- und Prozessmanagement
2.4.2.4 Projektmanagement
2.4.2.5 Klassifikationsmanagement
2.4.2.6 Kommunikation und Benachrichtigung
2.4.2.7 Datentransport und -konvertierung
2.4.2.8 Administration
2.4.2.9 Visualisierung
2.4.2.10 Anwendungsintegration
2.4.3 Systemarchitektur

3 Softwarekonfigurationsmanagement
3.1 Der Softwareprozess
3.2 Begriffsbestimmung
3.3 Funktionen eines Softwarekonfigurationsmanagement-Werkzeugs
3.3.1 Objektmanagement und Versionierung
3.3.1.1 Produktraum
3.3.1.2 Versionsraum
3.3.1.3 Zusammenführung von Produkt- und Versionsraum
3.3.2 Prozessmanagement und Teamwork

4 Integration von PDM-Systemen und SKM-Werkzeugen
4.1 Anwendungsbereich eines integrierten Systems
4.2 Generelle Integrationsmöglichkeiten
4.3 Übertragung auf den Diskursbereich
4.3.1 (Fast) keine Integration
4.3.2 Lose Integration
4.3.3 Vollintegration
4.4 Verträglichkeit von PDM und SKM Konzepten
4.4.1 Generelle Einreden
4.4.2 Repository
4.4.3 Versionierung
4.4.4 Prozessmanagement
4.4.5 Produktinformationsmodell
4.5 Praktische Erwägungen und Handlungsempfehlungen .

5 Zusammenfassung und Ausblick

Literaturverzeichnis

Tabellenverzeichnis

Abbildungsverzeichnis

Abk ürzungsverzeichnis

Anh ¨ange

A SKM Konzeptnachweis für ClearCase 2003.06
A.1 Repository
A.2 Aufbau einer Projektstruktur
A.3 Softwareobjekte
A.4 Beziehungen zwischen Softwareobjekten
A.5 Versionierung
A.6 Konfigurationen und Prozessmanagement
A.6.1 Pfade, Aktivitäten und Views

Abstract

Software spielt in der heutigen Produktwelt eine immer wichtigere Rolle. Vermehrt werden Funktionen eines Produktes, die ehemals in Hardware umgesetzt wurden, über Software rea- lisiert. Diese ist gegenüber der individuellen Entwicklung einer äquivalenten Hardwarelösung vergleichsweise preiswerter zu entwickeln und sie zeigt sich flexibler, da sie leichter anpassbar und erweiterbar ist (vgl. [Ara+03], S. 1). Durch die eingebrachte Heterogenität wird die Kom- plexität der Produkte erheblich gesteigert, da enge funktionale Zusammenhänge zwischen Hard- ware und Software bestehen, die bereits bei ihrer Entwicklung Ber ücksichtigung finden müssen (vgl. [Tara98], S. 20). Dazu ist die Integration von Informationen zu Software- und Hardware- bestandteilen erforderlich. Traditionell erfolgt die Verwaltung von Informationen zu Hardwa- re in Produktdatenmanagement-Systemen, während softwarebezogene Informationen in Soft- warekonfigurationsmanagement-Werkzeugen verwaltet werden. Beide sind derzeit nicht f ür ein Zusammenspiel ausgelegt (vgl. [Crn+03], S. XIX). Unternehmen sehen sich daher vor enor- men Schwierigkeiten zu einer ganzheitlichen Sicht auf ihre Produkte zu gelangen. Aus dieser Situation erwächst die Forderung nach einer Integration der Systeme (vgl. [Crn+03], S. 125; [Est+98b], S. 75).

Die Untersuchung von Möglichkeiten zur Realisierung dieser Forderung ist Gegenstand der vorliegenden Arbeit. Mit dem Ziel zu einer fundierten Betrachtungsgrundlage zu gelangen, wird ein Großteil der Arbeit darauf verwendet, die Disziplinen Produktdatenmanagement und Soft- warekonfigurationsmanagement sowie deren Werkzeuge und Systeme zu analysieren. Im Zuge dessen werden auf Basis der Literatur die wesentlichen Konzepte und Vorgehensweisen heraus- gearbeitet, welche darin zur Anwendung kommen. Um einen Kontext zu schaffen, werden die Ausführungen von einer Darstellung der wesentlichen Prozesse beider Disziplinen begleitet.

Im zweiten Teil der Arbeit wird, auf den Erkenntnissen der vorangegangenen Analyse auf- bauend, die Integration von Produktdatenmanagement-Systemen und Softwarekonfigurations- management-Werkzeugen thematisiert. Um dabei auf einer einheitlichen Betrachtungsgrundla- ge aufsetzen zu können, wird ein Rahmenwerk entwickelt, welches die uniforme Analyse und Bewertung von Integrationsmöglichkeiten gewährleisten soll. Im Fortgang der Untersuchung wird das Rahmenwerk auf, in der Literatur vorzufindende, Integrationsansätze angewendet. Die Realisierbarkeit der, über die beschriebenen Ansätze hinausgehenden, Idee der Schaffung eines integrierten Systems durch vollständige Neuentwicklung wird im Rahmen der Betrachtung zur Verträglichkeit der identifizierten Konzepte und Vorgehensweisen gepr üft.

Als Ergebnis der Arbeit werden aus den Erkenntnissen der durchgef ührten Untersuchungen Handlungsempfehlungen abgeleitet, die sich auf einer abschließenden Betrachtung unter praktischen Gesichtspunkten begründen.

0 Einleitung

BOSCH durfte in diesem Jahr 25 Jahre Motronic, ein System zur Steuerung der Benzin- einspritzung in Automobilen, feiern. Was dieses System zum Zeitpunkt seiner serienmäßigen Einführung zu etwas Revolutionärem machte, war ein frei programmierbarer Mikroprozessor, der Software in den Bereich der Fahrzeugtechnik Einzug halten ließ (vgl. [Bosc04]). Heute resultieren etwa 90 Prozent der Innovationen im Automobilsektor direkt oder indirekt aus Soft- ware. Dieser enormen wirtschaftlichen Bedeutung stehen jedoch hohe Fehlerquoten gegen über. So sind im Automobilsektor aggregiert über alle Baugruppen eines Fahrzeuges 55 % der auf- tretenden Fehler durch Elektronik verursacht, wovon der größte Teil der Steuergerätesoftware zugeschrieben wird (vgl. [Gese03], S. 2). Die gegenseitige Durchdringung von Hard- und Soft- ware ist jedoch nicht nur auf die Fahrzeugtechnik beschränkt, sondern erfasst heute fast alle Bereiche des täglichen Lebens, wie etwa Gebäudetechnik, Telefonie, Flugwesen oder Medizin.

Es wird deutlich, dass sich Produkte heute vermehrt durch Heterogenität auszeichnen, indem sie Hardware und Software in einem Ganzen vereinen. Bauteile, die im Zusammenspiel von Hardware und Software Steuerungsaufgaben in einem umgebenden Produkt wahrnehmen, wer- den als eingebettete Systeme bezeichnet. Mit der immer breiteren Verwendung dieser Art von Bauteilen auch in sicherheitsrelevanten Kontexten wird deren Zuverlässigkeit zum erfolgskriti- schen Faktor für Hersteller. Um dem angemessen zu begegnen, ist eine ganzheitliche Sicht auf das Produkt bereits während seiner Entwicklung notwendig (vgl. [Tara98], S. 20). Dies erfordert die Integration von Informationen zu Hardware- und Softwarebestandteilen. Unternehmen se- hen sich bei der Erfüllung dieser Anforderung jedoch erheblichen Schwierigkeiten gegenüber, da für Hardware und Software separate Systeme zur Verwaltung dieser Informationen einge- setzt werden, die nicht für eine wechselseitige Kommunikation ausgelegt sind (vgl. [Crn+03], S. XIX). Traditionell werden für den Bereich der Hardware Produktdatenmanagement-Systeme als informationstechnische Umsetzung der Disziplin Produktdatenmanagement eingesetzt. F ür den Bereich der Software werden Softwarekonfigurationsmanagement-Werkzeuge als informationstechnische Umsetzung der Disziplin Softwarekonfigurationsmanagement verwendet. Seit ihrer nahezu zeitgleichen Etablierung in den 1970er Jahren haben sich Produktdatenmanagement und Softwarekonfigurationsmanagement unabhängig voneinander entwickelt und eigenständig Konzepte und Methoden ausgeprägt, die sich in ihrer informationstechnischen Umsetzung niederschlagen. Gemein ist ihnen, dass sie das Konfigurationsmanagment als Problemdomäne adressieren (vgl. [Crn+03], S. 126; [Dart92a], S. 1).

Ein Ansatz, der im aufgerissenen Problembereich zu einer L ösung führen soll, wird in der Integration von Produktdatenmanagement-Systemen und Softwarekonfigurationsmanagement- Werkzeugen gesehen [Crn+03], S. 125; [Est+98b], S. 75). Die Untersuchung der Realisierbar- keit eines solchen Vorhabens ist Gegenstand der Arbeit. Daraus erwachsende Fragestellungen können im Rahmen dieser Arbeit jedoch nicht vollumfänglich beantwortet werden. Ihre Zielsetzung ist auf die Schaffung von Grundlagen für eine fundierte Diskussion durch Analyse der betroffenen Domänen und das Aufzeigen von Lösungsansätzen begrenzt. Dazu soll wie folgt vorgegangen werden:

Da sowohl das Produktdatenmanagement als auch das Softwarekonfigurationsmanagement in der einen oder anderen Form Probleme des Konfigurationsmanagements adressieren, soll diese Disziplin in Kapitel 1 dargestellt werden. Teil der Ausführungen wird die Einführung des der Arbeit zugrunde gelegten Produktbegriffes sowie die Darstellung der Basisprozesse des Konfigurationsmanagements sein. Damit wird die Einordenbarkeit der anschließenden Darstellungen unter dem Aspekt des Konfigurationsmanagements verfolgt.

In Kapitel 2 sollen die Disziplin des Produktdatenmanagements sowie die unterst ützenden Produktdatenmanagement-Systeme thematisiert werden. Da es sich um ein fremdes Fachgebiet handelt, soll ein grundlegender Verständnisrahmen durch Darstellung des Produktlebenzyklus aus Sicht der Fertigungsindustrie sowie besonderer Prozessmerkmale geschaffen werden. Dies wird von der Klärung des informationstechnischen Umfeldes begleitet. Im Anschluss soll zu einem Begriffsverständnis des Produktdatenmanagements gefunden werden. Im Weiteren wer- den die Funktionsbereiche eines Produktdatenmanagement-Systems ausgef ührt. Dabei wird es erforderlich sein, aus divergierenden Begriffen und Ansichten ein konsistentes Gesamtbild zu formen. Unterstützend soll dabei die Modellierung der zentralen Punkte auf fachkonzeptioneller Ebene wirken.

Die Disziplin des Softwarekonfigurationsmanagements wird Gegenstand von Kapitel 3 sein. Hier wird eine Darstellung des Softwareprozesses den Ausführungen zum eigentlichen Ge- genstandsbereich vorangehen. Im Anschluss soll das Softwarekonfigurationsmanagement als Managementdisziplin umrissen werden, um im Weiteren auf Funktionen von Softwarekonfi- gurationsmanagement-Werkzeugen einzugehen. Die Ausführungen dazu werden mehrere Teil- funktionen aggregieren und eine breit angelegte Analyse von Umsetzungsm öglichkeiten vor- nehmen. Zielsetzung ist dabei, nach wesentlichen Unterscheidungsmerkmalen eine Gruppie- rung von Ansätzen aus der Literatur vorzunehmen und die sich daraus ergebenden Konzepte zu erläutern.

Die in der Analyse der einzelnen Fachbereiche erlangten Erkenntnisse sollen in Kapitel 4 ge- nutzt werden, um mögliche Integrationsansätze zu diskutieren. Dabei soll in einem ersten Schritt der Anwendungsbereich integrierter Systeme durch Ausführungen zum Entwicklungsprozess eingebetteter Systeme konkretisiert werden. Im Anschluss wird ein Rahmenwerk entwickelt, welches die Analyse und Bewertung von Integrationsansätzen ermöglichen soll. Dieses wird im Weiteren auf in der Literatur beschriebene Integrationsansätze angewendet. Eine Diskussion um die Verträglichkeit von ausgewählten Konzepten des Softwarekonfigurationsmanagements und Produktdatenmanagements soll die Realisierbarkeit eines dar über hinausgehenden Ansat- zes prüfen. Die Ergebnisse sollen in einem letzten Schritt unter Gesichtspunkten der Praxis beleuchtet werden, um daraus Handlungsempfehlungen abzuleiten.

In Kapitel 5 wird die Arbeit reflektiert und es werden Anknüpfungspunkte für weitere Forschungen aufgezeigt.

Folgende Formatkonventionen sind der Arbeit zugrunde gelegt:

Fettdruck kennzeichnet die erstmalige Definition eines Begriffes im selben oder im Folgesatz.

Kursivdruck kennzeichnet die besondere Bedeutung eines Wortes oder einer Wortgruppe

KAPITÄLCHEN kennzeichnet eine Autor zitierter Literatur

[Maschine in eckigen Klammern] kennzeichnet einen Geschäftsobjekttyp Maschine kennzeichnet die Instanz eines Geschäftsobjekttyps

1 Konfigurationsmanagement

Produktdatenmanagement und Softwarekonfigurationsmanagement überlappen sich, indem sie Probleme adressieren, deren Behandlung Gegenstand der domänenübergreifenden Disziplin des Konfigurationsmanagements ist (vgl. [Crn+03], S. 126; [Dart92a], S.1). Im Folgenden soll daher nach der Einführung des Produktbegriffes, eine Darstellung des Konfigurationsmanage- ments durch Begriffsbestimmung und Ausführungen zu Grundprinzipien sowie Basisprozessen erfolgen.

1.1 Produktbegriff

Der Terminus des Produkts stammt vom lateinischen Wort producere f ür hervorbringen ab (vgl. [Trip02], S. 6). Dieser sprachliche Herkunftsnachweis macht den generativen Charak- ter des Begriffs klar. PAHL und BEITZ bezeichnen technische Gebilde oder Systeme als Pro- dukt. In Abhängigkeit von Branche, Komplexität und Zusammenhang können darunter Anla- gen, Apparate, Maschinen, Geräte, Baugruppen, Maschinenelemente sowie Einzelteile gefasst werden ([PaBe86], S. 21f). Produkte oder dessen Teile müssen jedoch nicht notwendiger Weise materieller Natur sein. Der Begriffsumfang muss von technischen Produkten auch auf Dienst- leistungen, Software usw. als immaterielle Produkte ausgedehnt werden (vgl. [Trip02], S. 6). CRNKOVIC ET AL. und SCHICHTEL führen sehr anschaulich aus, dass die Wahrnehmung eines Produkts, abhängig vom Blick darauf, als Aggregat oder auch als beliebig tiefe, hierarchische Komposition von Teilen erfolgen kann. Sie weisen weiter darauf hin, dass diese Blickweise vom konkreten Kontext der Betrachtung abhängig ist (vgl. [Crn+03], S. 3f; [Schi02], S. 40ff). Ein Fahrradfahrer wird sein Fahrrad somit als ein Produkt wahrnehmen, welches er in seiner Gesamtheit vom Händler bezogen hat. Dessen Konstrukteur wird darin eine Ansammlung von Teilen sehen, währenddessen der Einkäufer im produzierenden Unternehmen in den Einzeltei- len eine Ansammlung von Produkten sieht, die er für die Herstellung beschaffen muss.

1.2 Begriffsbestimmung

Konfigurationsmanagement (KM) ist nach DIN EN ISO 10007 ”...eineManagement-Dis- ziplin, die technische und verhaltensmäßige Regeln auf den Produktlebenslauf einer Konfigu- rationseinheit von seiner Entwicklung über Herstellung und Betreuung anwendet..“([DIN [96]], S.7 ). Eine Konfigurationseinheit stellt dabei eine ”...KombinationausHardware,Softwa- re, Dienstleistung oder eine beliebige Unterteilung davon auf die Konfigurationsmanagement angewendet werden soll und die im Konfigurationsmanagement-Prozess als eine Einheit be- handelt wird..“([DIN [96]], S.6 ) dar. KM ist somit nicht an bestimmte Branchen oder Produkte gebunden, sondern kommt übergreifend zum Einsatz. Entsprechend der hier zugrunde liegenden Norm, ist es das Hauptziel des Konfigurationsmanagements ”...diegegenwärtigeKonfiguration eines Produkts sowie den Stand der Erfüllung seiner physischen und funktionellen Forderun- gen zu dokumentieren und volle Transparenz herzustellen..“([DIN [96]], S.7 ). Eine Konfigura- tion wird hierbei als die Menge funktioneller und physischer Merkmale eines Produkts, wie sie in dessen technischen Dokumenten beschrieben und im Produkt verwirklicht sind, verstan- den (vgl. [DIN 96], S. 5). Weiterhin soll sichergestellt werden, dass jeder Projektbeteiligte zu jedem Zeitpunkt im Produktlebenslauf die richtige und zutreffende Dokumentation verwen- det (vgl. [DIN 96], S. 7). KM gliedert sich also in einen über den gesamten Lebenszyklus ei- nes Produktes andauernden Prozess (Konfigurationsmanagementprozess (KMP)) und dessen Organisation (Konfigurationsmanagementorganisation und -planung (KMO)) in Form von Re- geln und Festlegungen. Unter einem Prozess soll im Rahmen dieser Arbeit übergreifend ei- ne zeitlich, sachlogische Abfolge von Aktivitäten verstanden werden, deren Durchführung zur Bearbeitung eines prozessrelevanten Objektes erforderlich ist (in Anlehnung an [Beck97], S. 176). Sie ist durch Anfangs- und Schlussereignis begrenzt und in diesem Sinne abgeschlos- sen (vgl. [Sche95], S. 404ff). Die Transformation von Eingangsgrößen (Input) in werthaltige Ausgangsgrößen (Output) ist ein weiteres Merkmal von Prozessen (vgl. [HaCh95], S. 52). In- nerhalb des KMP werden vier Hauptprozesse bzw. konzeptionelle Teilgebiete des Konfigura- tionsmanagements unterschieden. Das sind im Einzelnen Konfigurationsidentifizierung (KI), -überwachung (K Ü), -audit (KA) und -buchführung (KB). Eine sinnvolle Anwendung des Konfigurationsmanagements kann nur durch die integrierte Umsetzung dieser Teilprozesse erreicht werden (vgl. [Sayn98], S. 12f; [DIN 96], S. 7).

1.2.1 Konfigurationsmanagementorganisation und -planung

Innerhalb der KMO werden projekt- oder produktspezifisch die technischen und organisato- rischen Festlegungen zu den vier Teilgebieten des KM getroffen. Festgelegt werden sollten Informationsrechte und -pflichten sowie Befugnisse der Projektbeteiligten. Hinzu kommt die Zuweisung von KM-Aufgaben an Aufgabenträger der institutionellen Projektorganisation bzw. die Zuweisung einer Rolle im KM-Prozess. Des Weiteren sollten Verfahren des KM ausgewählt und festgesetzt sowie KM-Pläne als diesbezügliche Festschreibung formuliert werden. Weitere Aufgaben der KMO sind die Auswahl von Werkzeugen für KM, deren Pflege und Wartung so- wie die Auditierung des KM-Systems, zum Zweck der Kontrolle bez üglich der Einhaltung der festgelegten Regeln und Verfahren sowie der Überprüfung ihrer Wirksamkeit (vgl. [Sayn98], S. 14f; [DIN 96], S. 8 u. 11).

1.2.2 Konfigurationsidentifizierung

Die Durchführung der Konfigurationsidentifizierung ist die Voraussetzung für die Durchführung von Konfigurationsüberwachung, -auditierung und -buchführung. Der Prozess umfasst die Aus- wahl von Konfigurationseinheiten, deren Formierung zu einer Produktstruktur, ihre Dokumen- tation und Benummerung sowie das Einrichten von Bezugskonfigurationen. Die Auswahl von Konfigurationeinheiten bestimmt, was als Einheit betrachtet und verwaltet werden soll. F ür die Auswahl sollte das Produkt hierarchisch gegliedert werden und anhand der Gliederung un- ter Anwendung von Orientierungskriterien eine Entscheidung getroffen werden. Die, aus den ausgewählten Einheiten zu formierende, Produktstruktur sollte die Gliederung des Produkts beschreiben sowie die Anordnung und Beziehungen der Konfigurationseinheiten offen legen. Konfigurationseinheiten müssen über eine Nummer (Sachnummer), die einem Nummernsy- stem folgt, eindeutig identifizierbar sein. Zu möglichst im KM-Plan festgelegten Zeitpunkten sollten Bezugskonfigurationen, auch als Baseline oder Referenzkonfiguration bezeichnet, fest- gelegt werden. Geeignete Zeitpunkte stellen Abschl üsse wesentlicher Phasen der Produktent- wicklung dar. Bezugskonfigurationen bilden den formal spezifizierten Ausgangspunkt f ür wei- tere Arbeiten am Produkt sowie die Bestimmung von Kosten, Terminen und Bewertung der Konfiguration (vgl. [Sayn98], S. 15f; [EiSt01], S.71ff; [DIN 96], S. 8 u. 11).

1.2.3 Konfiguration überwachung

Zentrale Aktivität der Konfigurationsüberwachung ist das Änderungsmanagement. Ziel ist es alle Änderungen an Konfigurationseinheiten sowie deren zugeordneten Dokumenten zu identi- fizieren, beschreiben, klassifizieren, bewerten, genehmigen und einzuf ühren. Die mit entspre- chenden Kompetenzen und Befugnissen ausgestattete Instanz wird als Konfigurationsausschuss oder Change Control Board (CCB) bezeichnet. Sinnvolle Konfigurationsüberwachung setzt einen festgeschriebenen, formalen Prozess für die Behandlung von Änderungen voraus. Übli- che Prozessschritte sind die Beantragung, Bewertung, Entscheidung, Beauftragung, Review der umgesetzten Änderungen und Freigabe. Alle Schritte werden möglichst standardisiert doku- mentiert. In diesem Zusammenhang relevante Dokumente sind Änderungsantrag, Sitzungspro- tokoll des CCB und Änderungsauftrag. Referenzobjekt für das Änderungsmanagement ist eine Bezugskonfiguration. Zu einem bestimmten Zeitpunkt stellt diese zusammen mit allen bis dahin freigegebenen Änderungen die gültige Konfiguration dar (vgl. [DIN 96], S. 9f).

1.2.4 Konfigurationsaudit

Ein Konfigurationsaudit ist die formale Überprüfung von Konfigurationen hinsichtlich der Erfüllung von vertraglich zugesicherten funktionellen und physischen Merkmale sowie 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 von Bezugskonfigurationen sollte ein Audit angestrengt werden (vgl. [DIN 96], S. 10).

1.2.5 Konfigurationsbuchf ührung

Der Prozess der Konfigurationsbuchführung hat die rückverfolgbare Dokumentation der Kon- figurationen und Konfigurationseinheiten zum Ziel. Sie sollte von daher bereits mit der er- sten Erstellung von Konfigurationsdaten einsetzen. Gegenstand der KB sind alle Daten zur Konfigurationsidentifizierung und -überwachung. DIN EN ISO 10007 empfiehlt daher KB- Aufzeichnungen als Nebenprodukt dieser Prozesse zu realisieren (vgl. [DIN 96], S. 10).

2 Produktdatenmanagement

Es wäre vermessen, zu glauben, man könne den Bereich des Produktdatenmanagements in we- nigen Sätzen charakterisieren und einer zusammenfassenden Betrachtung zuf ühren. Zu ver- schieden sind Sichtweisen, Begriffsinhalte zu diesem Thema in der Literatur. Die Hinf ührung zur Disziplin des Produktdatenmanagements, die Abgrenzung des Begriffes sowie die Darstel- lung von Produktdatenmanagement-Systemen sollen daher Gegenstand dieses Kapitels sein.

2.1 Der Produktlebenszyklus als Bezugsebene des Produktdatenmanagements

Der Begriff Lebenszyklus entstammt der Biologie und geht auf die Beobachtung von Organis- men zurück. Es wird dabei zwischen sich periodisch wiederholenden Zyklen und einmaligen Zyklen zu unterschieden. Bezogen auf Produkte, hat sich in vielen Wissenschaftsdisziplinen der Begriff Produktlebenszyklus etabliert. (vgl. [SiSe95], S. 3f). Zur Beschreibung des Pro- duktlebenszyklus wird dieser in Phasen aufgeteilt (vgl. [AnJo00], S. 10; [Crn+03], S. 5ff). Die Vielfalt von Bezeichnungen der Phasen und deren Darstellungen kann kaum übertroffen wer- den. Sie generiert sich aus den verschiedenen interessierenden Zusammenhängen. Trotz dieser Vielfalt ist vor dem Hintergrund des Produktdatenmanagements die marktorientierte Sicht (vgl. [Gälw86], S. 251ff; [Duns83], S. 66f) von der herstellungsorientierten Sicht (vgl. [AnJo00], S. 10; [Trip02], S. 6) zu trennen. Erstere orientiert sich an monetären Gesichtspunkten, als Anhaltspunkt für die Lebensphasen eines Produkts am Absatzmarkt (vgl. [Inst95], S. 70). Die herstellungsorientierte Sicht hingegen verfolgt das Produkt aus einem technisch-organisatorisch geprägten Betrachtungswinkel. ULRICH und EPPINGER haben zu einer branchen- und produktunabhängigen Sicht gefunden, welche in einem generischen Produktlebenszyklus zum Ausdruck kommt (zit. in [Crn+03], S. 5ff). Im Folgenden soll eine kurze Analyse der Lebenszyklusphasen erfolgen. Der Verfasser wird sich dabei am herstellungsorientierten Modell ausrichten und teilweise Bezüge zum generischen Modell herstellen. Abbildung 1 stellt die genannten Lebenszyklusmodelle gegenüber, setzt sie zueinander in Beziehung und soll es ermöglichen, die nächsten Ausführungen in andere Modelle zu übertragen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Gegenüberstellung von Modellen des Produktlebenzyklus und gegenseitige Pha- senzuordnung

2.1.1 Produktentwicklung

Die Produktentwicklung stellt eine Phase in der Produktentstehung dar. Das Wesen dieser Pha- se ist die Suche einer konstruktiven Lösung für ein neues oder wesentlich verbessertes Pro- dukt (vgl. [VDI-79], S. 23). Der Prozess¹ ist durch die systematische, zweckgerichtete Aus- wertung und Anwendung von wissenschaftlichen Erkenntnissen und technischer Erfahrung gekennzeichnet und schließt die Entwicklung von Herstellungsverfahren ein (vgl. [Möll01], S. 13). Das im Unternehmen vorhandene Know-How zu diesem Prozess differenziert es ent- scheidend von seinen Wettbewerbern und ermöglicht so die Schaffung von Wettbewerbsvortei- len (vgl. [Möll01], S. 10). Die Komplexität der Produktentwicklung sieht TRIPPNER durch die Komplexität des zu entwickelnden Produkts selbst, die Komplexität der Anforderungen an das Produkt, die Komplexität der Organisation sowie der Kommunikation bestimmt (vgl. [Trip02], S. 14f). Jeder dieser Faktoren beschreibt ein System. Darunter soll ein dynamisches Ganzes verstanden werden, das als solches bestimmte Eigenschaften und Verhaltensweisen besitzt und aus Teilen besteht, die so miteinander verknüpft sind, dass kein Teil unabhängig ist von ande- ren Teilen und das Verhalten des Ganzen beeinflusst wird vom Zusammenwirken aller Teile (vgl. [UlPr95], S. 30). Nach STEINMEIER ist Komplexität eines Systems durch das Merkmal der Variätät, gemessen an der Anzahl und Verschiedenartigkeit der Systemteile, sowie der Konnektivität, gemessen an der Anzahl und Verschiedenartigkeit der Beziehungen zwischen den Systemteilen bestimmt (zit. in [Trip02], S. 8f).²

2.1.1.1 Produktplanung

Die Produktplanung leitet den Produktentstehungsprozess ein. Nach dem generischen Modell des Produktlebenszyklus stellt die Erkenntnis einer Geschäftsidee das diesbezüglich auslösen- de Ereignis dar. Diese begründet die Vorstellung von einem neuen oder wesentlich verbesserten Produkt. Begreift man ein Unternehmen als (Organisations)System, welches in seine Umwelt eingebettet ist, kann der Anlass zur Bildung dieser Vorstellung durch externe Impulse sowie interne Anreize induziert sein (vgl. [Stae97], S. 902ff). Als Impulse, die auf die Umgebung einer Organisation oder deren Wahrnehmung zurückzuführen sind, können u.a. die Erkenntnis vom markttechnischen Ableben des eigenen Produktes, wirtschaftspolitische Ereignisse oder das Aufkommen von Substituten angesehen werden. Ebenso können systeminterne Faktoren zu einer neuen Produktvorstellung führen, etwa Ergebnisse eigener Forschungs- und Entwick- lungsarbeit oder die Einführung neuer Fertigungsverfahren (vgl. [PaBe86], S. 58f; [Stae97], S. 905). Grundlegende Aktivitäten dieser Phase sind die Untersuchung des Marktes, das Auffin- den von Unzulänglichkeiten der eigenen Produkte, die Identifikation von Erfolgchancen, sowie die Machbarkeitsstudie (vgl. [Crn+03], S.5; [VDI-80], S. 3ff). Tragende Organisationseinhei- ten sind in dieser Phase die Marketingabteilung und bereits auch Teile der Entwicklungsab- teilung. Die Vorstellung eines Produktes und dessen Erfolgschancen begründen sich auf ei- ner Vorstellung von Anforderungen des Marktes. In der Phase des Anforderungsmanagements ist es die Aufgabe der Beteiligten, diese Anforderungen zu analysieren und zu spezifizieren (vgl. [Crn+03], S. 5). Als Ergebnis dieser Aktivitäten entsteht eine vorläufige Anforderungs- liste, die je nach Vorgehensweise bereits strukturiert ist. Sie stellt eine den Produktentwick- lungsprozess begleitende Informationsunterlage dar, die stets auf aktuellem Stand zu halten ist (vgl. [VDI-93], S. 10).

2.1.1.2 Produktkonstruktion

Die Produktkonstruktion widmet sich der Überführung von Anforderungen in eine konstruktive Lösung. Grundsätzlich sind diesbezüglich die Formen Variantenkonstruktion, Neukonstruktion und Anpassungskonstruktion zu unterscheiden (vgl. [PaBe86], S. 5). Dem dabei verfolgten Vor- gehen liegt eine Konstruktionsmethodik zugrunde, für die verschiedene Vorschläge existieren 2(vgl. [Trip02], S. 7). Einen in breiter Anwendung befindlichen Ansatz stellt die in VDI RICHT- LINIE 2221 vorgesehene Methode dar (vgl. [PaBe86], S. 50). Dieser Norm folgend, gliedert sich Produktkonstruktion in folgende vier Hauptphasen (vgl. [PaBe86], S. 51; ähnlich auch [Trip02], S. 7; die originäre Phasenaufteilung ist wesentlich differenzierter ([VDI-93], S. 7ff)):

- Klären der Aufgabenstellung,
- Konzipieren,
- Entwerfen sowie
- Ausarbeiten.

Die Eingangsgröße des Gesamtablaufes stellt die vorläufige Anforderungsliste aus der Produktplanung dar. Sie wird während der Klärung der Aufgabenstellung präzisiert und unter dem Blickwinkel der Konstruktion erweitert. Dieser Vorgang dient somit der Abgrenzung der Aufgabenstellung, welche in der Konstruktion gelöst werden soll. Damit wird ein wesentlicher Beitrag zur Fehlervermeidung geleistet (vgl. [PaBe86], S. 65ff).

Die anschließende Phase des Konzipierens führt zu einer prinzipiellen Lösung. Sie beinhaltet das Identifizieren der wesentlichen Probleme, das Ermitteln von Funktionen, das Aufstellen von Wirkprinzipien und -strukturen sowie die Bewertung des ermittelten L ösungsspektrums unter technischen und betriebswirtschaftlichen Gesichtspunkten (vgl. [PaBe86], S. 51f).

Die gestaltgebende Phase des Entwerfens erarbeitet die Baustruktur eines Produkts. Aus- gangspunkt dafür sind Wirkprinzipien und -strukturen der festgelegten Prinzipl ösung. Über Stufen vorläufiger Entwürfe entsteht ein endgültiger Gesamtentwurf, der den festgelegten An- forderungen genügen muss und auch aus betriebswirtschaftlicher Sicht verifiziert wurde (vgl. [PaBe86], S. 52f).

Den Abschluss des Konstruktionsprozesses bildet das Ausarbeiten. In dieser Phase erfolgt die Erarbeitung der Produktdokumentation. Dies beinhaltet insbesondere die Erstellung von Fer- tigungsunterlagen, welche das Herstellungsverfahren beschreiben, Nutzungsunterlagen sowie deren Prüfung. Ergebnis ist die herstellungsorientierte Festlegung der L ösung (vgl. [PaBe86], S. 53f).

2.1.1.3 Produktionsvorbereitung

Für die Phase der Produktionsvorbereitung wird auch die Bezeichnung Arbeitsvorbereitung verwendet. Eingangsgrößen dieses Planungs- und Steuerungsprozesses bilden die dargestellten Arbeitsergebnisse der Konstruktion. Sie werden während der Arbeitsvorbereitung in Ausgangs- größen transformiert, welche die fertigungsgerechte Herstellung eines Produkts sichern. Zu den wesentlichen Ausgangsdokumenten zählen unter anderem Arbeitspläne, NC-Programme, Fer- tigungsstücklisten und Dokumente der Fertigungslogistik (vgl. [Hell94], S. 51ff).

2.1.2 Produktherstellung - Produktvertrieb - Produktnutzung - Produktentsorgung

In der Phase der Produktherstellung erfolgt die physische Fertigung einzelner Instanzen des ge- planten Produktes gemäß den Vorgaben der Produktionsvorbereitung. Mit dem Abschluss der Produktherstellung wird gleichsam der Produktentstehungsprozess abgeschlossen. Das herge- stellte Produkt kann somit als Instanz seiner Produktklasse in den Absatzmarkt eintreten. Der endgültige Eintritt erfolgt durch den Produktvertrieb. Somit kann ab diesem Zeitpunkt auch vom Eintritt in den marktorientierten Produktlebenszyklus ausgegangen werden. Solange das Produkt für seinen Besitzer einen Nutzen hat und seine Funktionsfähigkeit gewährleistet ist, verbleibt das Produkt in der Produktnutzung. Dabei können sich bereits neue Impulse ergeben, die den Produktentwicklungsprozess von neuem anstoßen. Nach Ablauf seiner Lebenszeit wird das Produkt der Entsorgung zugeführt. Dies kann sich in der physischen Zerstörung oder dem Recycling ausdrücken. Ein wirklicher Lebenszyklus entsteht, wenn es gelingt, Teile wieder zu verwenden oder Erkenntnisse aus dem alten Produkt in die Planung einer neuen oder wesentlich verbesserten Produktklasse einfliessen zu lassen (vgl. [Ande04], S. 4).

2.2 Anwendungssysteme im herstellungsorientierten Produktlebenszyklus

Mit der Einführung von Informationstechnik wird die Unterstützung von humaner Aufgaben- träger bei der Erfüllung ihrer Aufgaben durch Computer und Programme angestrebt. Dies f ührt zum Begriff des Anwendungssystems. Im engeren Sinne ist darunter die Gesamtheit aller Pro- gramme zu verstehen, die für ein konkretes betriebliches Anwendungsgebiet entwickelt, ein- geführt und eingesetzt werden (vgl. [StHa97], S. 242). Im weiteren Sinn umfasst der Begriff eine Menge inhaltlich zusammengehöriger Aufgaben, die dafür verantwortlichen Aufgaben- träger und die zur Erfüllung der Aufgaben eingesetzte technische Ausstattung (vgl. [Hes+94], S. 43).

Im Prozess der Produktplanung werden neben gängigen Büroanwendungen zur Textverarbei- tung und Tabellenkalkulation zunehmend Anwendungssysteme zum Anforderungsmanagement angewandt. Sie werden in der Klasse der Requirements Management Systeme (RMS) bzw. in einem weitergehenden Ansatz Systeme des Requirements Tracebility Managements (RTM) zu- sammengefasst (vgl. [Trip02], S. 16). Prominente Vertreter dieser Klasse sind beispielsweise DOORSTM(Dynamic Object Oriented Requirements System) und Requisite ProTM.

Als historische Triebfeder der informationstechnischen Aufrüstung stehen heute aber vor al- lem in der Produktkonstruktion eine Vielzahl von Anwendungssystemklassen zur Verf ügung, die eine schnellere und Kosten sparende Entwicklung erm öglichen. Hier begann der Siegeszug des großen Feldes der CAx-Systeme in den 1970er Jahren (vgl. [Est+98b], S. 76). CAx steht dabei für Computer Aided. Systeme dieser Klasse besetzen jeweils eine Anwendungsdomäne, welche durch x bestimmt ist. Beispielhaft sind hierfür CAD (Computer Aided Design), CAS (Computer Aided Styling), CAE (Computer Aided Engineering) und verbundene Methoden wie FEM (Finite Elemente Methode) zu nennen (vgl. [Zwic98], S. 40; [Trip02], S. 16f). In den nachgelagerten Phasen nahmen und nehmen CAP (Computer Aided Planning), CAM (Computer Aided Manufacturing) und CAQ (Computer Aided Quality Assurance) ihren Platz ein. Vor allem CAD-Systeme sind für die Verwendung und Entwicklung der anderen Systeme von besonderer Bedeutung. Auf mit ihnen erstellten Zeichnungen und Modellen k önnen die anderen Methoden und Systeme überhaupt erst aufsetzen.

Eine weitere, vornehmlich in Entwicklung und Konstruktion eingesetzte, Technologie ist die Simulation. Systemklassen, welche in diesem Bereich eingesetzt werden, sind Systeme des Digital-Mock-Up (DMU) und der Virtual Reality (VR). Systeme dieser Art haben in den letz- ten Jahren erheblich an Bedeutung gewonnen und werden diese Entwicklung wohl auch in den nächsten Jahren fortsetzen. Der große Vorteil der genannten Technologien liegt in der Auf- wandssenkung bei der Herstellung von Prototypen. Deren Verwendung nimmt in der Produkt- entwicklung nach wie vor eine wichtige Stellung ein. Der Weg f ührt vom physischen Prototypen hin zum virtuellen Substitut (vgl. [Bul+99], S. 9f). Grundlage dieser Arbeitsweise sind wieder- um Ergebnisse von CAD-Systemen im Allgemeinen und 3D-CAD-Systemen im Besonderen. Mit dem Voranschreiten der Simulationstechnik ist mithin auch der Trend von 2D zu 3D-CAD- Anwendungen zu erklären, welche heute in dieser Systemklasse dominieren (vgl. [Bul+99], S. 19ff). Zu den herstellungsorientierten Anwendungssystemen treten aus Sicht der Betriebs- wirtschaft Produktionsplanungs- und -steuerungssysteme (PPS), Enterprise Resource Planning Systeme (ERP) und wertschöpfungsstufenübergreifend Supply-Chain-Management(SCM) Sy- steme.

2.3 Produktdaten und Prozesse

Daten sind ganz allgemein als Zeichen oder kontinuierliche Funktionen zu verstehen, die un- terstellten oder vorhandenen Regeln folgen. Die Zusammenfassung erfolgt mit dem Ziel Infor- mationen darzustellen (vgl. [VDI-79], S.7 unter Verweis auf [DIN 79]).³ Daten sind damit nicht unmittelbar zweckgerichtet. Die zweck- und zielgerichtete Aufbereitung von Daten macht diese erst zur Information. Daten sind mithin Träger von Informationen. Eine festgelegte und struk- turierte Informationsmenge, welche als Einheit verwaltet und zwischen Anwendern und Syste- men ausgetauscht werden kann, stellt ein Dokument dar. Darunter sind neben konventionellen papierbasierten Dokumenten insbesondere auch rechnerbasierte Informationen, welche als ein geschlossener Informationsbehälter verwaltet werden können, zu verstehen (vgl. [DIN 01], S. 8 u. 10). Sofern Daten in einem gewissen Bezug zum Produkt selbst, seinen Teilen oder deren Entstehungsprozess stehen, sollen sie Produktdaten bezeichnet werden. Sie repräsentieren auf eine formale Weise Informationen über ein Produkt und sind für die Kommunikation, Interpre- tation und Verarbeitung durch den Menschen oder Computer geeignet (vgl. [ISO 96], S. 4). Wer- den Produktdaten oder eine Verknüpfung daraus in einen Verwendungskontext gesetzt, sollen sie im Folgenden als Produktinformationen betrachtet werden. Produktinformationen stellen Fakten, Konzepte und Instruktionen über ein Produkt dar (vgl. [ISO 96], S. 4). Sie lassen sich in technische und kommerzielle Informationen gliedern (vgl. [DIN 90], S. 2). EIGNER und STEL- ZER ergänzen eine dritte Form, die sie als Qualitätsinformationen bezeichnen (vgl. [EiSt01], S. 54).

Die Erzeugung von Produktdaten erfolgt immer im Kontext von Prozessen (vgl. [Schi02], S. 17). Der maßgebliche Teil der produktrelevanten Daten entsteht während Produktentwicklung. Hinterließ die erfolgte Beschreibung den Eindruck einer iterativ, sequentiellen Abfolge der Arbeitsschritte, soll an dieser Stelle kurz auf Besonderheiten moderner Entwicklungsprozesse eingegangen werden.

Die Einführung von DV-Unterstützung führte zu einer Umgestaltung der Arbeitsabläufe bzw. ermöglichte diese überhaupt erst. Zwei im diesem Sinne neue Arbeitsmethoden sind dabei be- sonders hervorzuheben. Die erste Neuerung ist im Concurrent Design oder allgemeiner Concur- rent Engineering zu sehen. In dieser Entwicklungsmanagement-Methode wird die Entwicklungs- und Konstruktionsaufgabe als ein Projekt betrachtet, dem die Zerlegung der Gesamtaufgabe in Teilaufgaben sowie die Berücksichtigung verschiedener, oft gegenläufiger Anforderungen an die konstruktive Lösung zugrunde liegen. Für die Zerlegung in Teilaufgaben werden dabei Zer- legungsprinzipien, welche sich beispielsweise an systemisch-funktionalen oder strukturellen Gesichtspunkten ausrichten können, benötigt. Des Weiteren gewinnen Projektplanungs- und - managementmethoden, welche die konstruktiven L ösungen aufeinander abstimmen und Metho- den der kooperativen Arbeit an Bedeutung. Die zweite wesentliche Veränderung im Entwick- lungsprozess stellt das Simultaneous Engineering dar. Hier wird ein simultanes Vorgehen in den Phasen der Produktentstehung angestrebt, was sich in einer zeitlichen Überlappung nieder- schlägt. Die Anforderungen an die methodische Unterstützung dieses Vorgehens ähneln denen des Concurrent Engineerings. Allerdings ist ein effektives und transparentes Koordinationssy- stem von vergleichsweise größerer Bedeutung (vgl. [AnJo00], S. 13f). Abbildung 2 veranschau- licht die dargestellten Entwicklungsmanagementmethoden.

Und noch eine wesentliche Veränderung ist zu beobachten. Die Prozessleistung, nicht nur des Entwicklungsprozesses, wird nicht mehr isoliert in einer Abteilung, an einem Standort erbracht, sondern ist in Folge der Globalisierung das Ergebnis geographisch verteilter Aktivitäten. Die Auswirkungen der ausgeführten Prozessveränderungen beschränken sich nicht nur auf den Pro- zess selbst, sondern verändern auch Rollenverständnis und Arbeitsinhalte der beteiligten Auf- gabenträger, insbesondere in der Produktentwicklung. Die Interdependenz der parallel und/oder simultan durchgeführten Aktivitäten führt zu einer wesentlich früheren und stärkeren Einbin- dung des Ingenieurs in den Planungs-, Beschaffungs- und Produktionsprozess. Damit einherge- hend verschiebt sich dessen Tätigkeitsschwerpunkt weg von kreativer Tätigkeit hin zu Admini- stration, Kommunikation, Information und teamorientiertem Entscheiden (vgl. [EiSt01], S. 2; (vgl. [EiZa99], S. ,) S. 107). Abbildung 3 zeigt die Ergebnisse einer Studie in diesem Kontext.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Schematische Gegenüberstellung von Concurrent Engineering und Simultaneous Engineering ([AnJo00], S. 14)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Arbeitsinhalte des Konstrukteurs ([Harm94], S. 14)

Die Erzeugung und Bearbeitung von Produktdaten ist von der jeweiligen Fachdisziplin und dem Fortschritt in der Entwicklung geprägt. Gemeinsam ist den Teilprozessen und Aktivitäten, dass die durch sie erzeugten Arbeitsergebnisse ganz spezifische, von den genannten Faktoren beeinflusste Modelle dessen sind, was entstehen soll. Diese Modelle sollen im Folgenden als Produktmodelle bezeichnet werden. Diese Form der Modellbildung geschieht unabhängig vom Einsatz unterstützender Anwendungssysteme. TRIPPNER führt den Gedanken jedoch auf die- sem Gebiet fort. Er stellt fest, dass die Erstellung und Bearbeitung von Produktdaten in Anwen- dungssystemen auf einer endlichen Anzahl anderer Produktdaten basiert, die untereinander in Beziehung stehen. Diese bilden gesamthaft ein Produktmodell f ür das jeweilige Anwendungs- system (vgl. [Trip02], S. 28) mithin dessen Anwendungsdomäne. Das Ergebnis einer vom Ein- zelfall abstrahierenden Modellierung der in einem Produktmodell enthaltenen Fakten, Konzepte und Instruktionen wird als Produktinformationsmodell bezeichnet (vgl. [ISO 96], S. 4). Werden Produktinformationsmodelle aller Anwendungsdomänen zusammengeführt, spricht man von einem integrierten Produktinformationsmodell. Die konstituierenden Teile stehen dann in der Rolle eines Partialmodells. Konkrete Ausprägungen eines integrierten Produktinformationsmodells werden entsprechend als integriertes Produktmodell bezeichnet. ANDERL und JOHN schlagen eine Klassifikation von Produktdaten vor. Sie unterscheiden nach der Funktion von Produktdaten folgende Klassen (vgl. [AnJo00], S. 15):

1. Produktdaten der Produktdefinition,
2. Produktdaten der Produktrepräsentation sowie
3. Produktdaten der Produktpräsentation.

Unter produktdefinierenden Daten werden administrative und organisatorische Daten zusam- mengefasst. Sie dienen der eindeutigen Identifikation und Klassifikation eines Produkts, erm ög- lichen dessen Einordnung in die Phasen des Produktlebenszyklus und definieren durch Relati- onen die Produktstruktur. Beispiele für diese Klasse sind Produktbenennung, Klassifikations- schemata, Verwendungsbeziehungen, Alternativen, Varianten, Freigabestatus oder Änderungs- zustände. Produktrepräsentierende Daten fassen computerverarbeitbare Abbildungen von Pro- duktmerkmalen zusammen. Dies umfasst neben eigenschaftsbeschreibenden auch funktions- beschreibende Daten. Beispiele für diese Klasse sind Geometrie-, Material- oder Festigkeits- daten. Produktdefinierende und -repräsentierende Daten bilden in ihrer Gesamtheit das inte- grierte Produktmodell. Produktdaten der Präsentation dienen lediglich der textuellen und/oder graphischen Darstellung von Repräsentations- und Definitionsdaten oder einer Kombination daraus. Hier können als Beispiele Produktstrukturbäume, perspektivische Hüllendarstellungen eines Produkts oder eines einzelnen Bauteils sowie jegliche Art textueller Produktbeschreibung angeführt werden (vgl. [Trip02], S. 25f; [AnJo00], S.15f).

2.4 Produktdatenmanagement und Produktdatenmanagement-Systeme

Unternehmen sehen sich heute veränderten Markt- und Wettbewerbsbedingungen gegenüber. Als besonders kritisch ist eine stetig sinkende, vom Markt zugelassene Forschungs- und Ent- wicklungszeit, anzusehen. Hinzu kommen Kostendruck und steigende Anforderungen an die Produktqualität. Gleichzeitig weisen Produkte eine sinkende, vom Marktumfeld akzeptierte, Produktlebenszeit auf (vgl. [Töpf94], S. 225). Unternehmen drängen daher auf eine verkürz- te Time-to-Market Spanne, da sich doch durch einen, gegenüber den Wettbewerbern, früheren Markteintritt die Produktlebenszeit verlängern sowie Marktanteile vergrößern lassen (vgl. [SiSe95], S. 66f). Die Herausforderung für Unternehmen besteht somit darin, in immer kürzerer Zeit neue Produkte in steigender Qualität zu sinkenden Kosten zu entwickeln und fer- tigen (vgl. [EiSt01], S. 1; [The 03], S. 2; [Bul+99], S. 4). Für das Erreichen der erforderlichen Zeit-, Kosten-, Qualitäts- und Ergebnisziele genügt es aber nicht, lediglich klassische Rationa- lisierungspotentiale, etwa durch Automatisierung der Fertigung, auszusch öpfen (vgl. [Möll01],

S. 2f). Unternehmen müssen die Optimierung ihrer Entwicklungsprozesse fokussieren. In die- sem Prozess werden maßgeblich Kosten, Qualität und somit auch Erlöse eines Produkts festge- legt (vgl. [SiSe95], S. 79). Zudem birgt die Produktentwicklung ein enormes Einsparpotential bezüglich der Gesamtdurchlaufzeit. Parallelisierung und simultane Durchf ührung der entspre- chenden Aktivitäten sind geeignet, dieses Potential auszuschöpfen. Mit der Einführung solcher Durchführungsmethoden steigen jedoch die Komplexität von Prozessen und deren Dynamik. Es wird somit eine neue Instanz im betrieblichen Koordinationssystem ben ötigt. Produktdaten- management-Systeme (PDMS) sollen genau diese Lücke ausfüllen und stellen den Analysege- genstand der folgenden Ausführungen dar.

2.4.1 Begriffsbestimmung

Grundsätzlich muss zwischen dem Konzept Produktdatenmanagement (PDM) und einem Pro- duktdatenmanagement-System unterschieden werden. Während das Konzept Regeln, Methoden und Prinzipien festlegt, ist ein PDMS die informationstechnische Umsetzung der Konzeption (vgl. [Crn+03], S. 20; methodische Ansatzeigenschaft auch bei [Schö99b], S. 211). Im Wege einer Definition des Produktdatenmanagements sind in der Literatur vier wesentliche Stoßrich- tungen zu identifizieren, deren Konzeptionen aufeinander aufbauen und von der historischen Entwicklung dieser Disziplin geprägt sind (vgl. [Golt02], S. 59f). Der Autor sieht vor allem in dem weiten Spektrum an Begriffsinhalten, welche zwischen der Darstellung von Vision und Wirklichkeit beliebig wechseln, das Problem bei der Kommunikation des PDM-Begriffes. F ür die Begriffsbildung zum Produktdatenmanagement-Systems ist diese Lage in sofern von Bedeu- tung, als dass Inhalt und Umfang eines PDMS in einem sehr engen Zusammenhang mit Inhalt und Umfang des darunter liegenden Begriffsverständnis zum PDM stehen. Im Folgenden soll daher unter einem Produktdatenmanagement-System eine dedizierte Software-Lösung ver- standen werden, welche nach einer zu spezifizierenden Konzeption des Produktdatenmanage- ments aufgebaut ist (in Anlehnung an [Schö99b], S. 93). TRIPPNER verwendet in seiner Arbeit neben dem Begriff Produktdatenmanagement-System den Terminus Produktdatenmanage- ment-Lösung. Er fasst darunter alle anwendbaren Elemente des Produktdatenmanagements, womit sowohl einzelne Konzepte, Methoden, Prozessfestlegungen, Datenmodelle und Systeme als auch vollständige Produktdatenmanagement-Architekturen und -Systemnetzwerke in dieses Begriffsverständnis fallen. Damit wird der Gedanke, an eine PDM-Realisierung im Unterneh- men durch Einsatz eines PDM-Systems abgelehnt. Vielmehr ist ein solches System Kern einer PDM-Realisierung, der durch flankierende Systeme, insbesondere Erzeugersysteme, ergänzt wird (vgl. [Trip02], S. 81f). Diese Argumentation wird zusätzlich durch die Ausführungen von SCHOLZ-REITER und KRAUSE gestützt, die auf die Variabilität von PDM-Umsetzungen hin- weisen. Ihnen zu Folge muss der erforderliche Funktionsumfang nicht zwingend vollständig durch ein dediziertes PDM-System erbracht werden, vielmehr k önnen einzelne Funktionen auch durch andere Anwendungssysteme bereitgestellt werden (vgl. [ScKr01], S. 908).

Historisch gesehen etablierte sich der Begriff Produktdatenmanagement Anfang der 1980er als Lösungsansatz für Probleme der CAD-Zeichnungsverwaltung. Zu diesem Zeitpunkt ver- drängte die CAD-Systemklasse mehr und mehr das Zeichenbrett, was zu einem sprunghaften Anstieg von Entwicklungsdaten führte. An diesem Hintergrund richtet sich ein erstes sehr en- ges Verständnis von PDM mit der Zielsetzung der konsistenten Verwaltung von Produktdaten in Form von CAD-Dokumenten aus. Es ist damit auf den Prozess der Konstruktion beschränkt. Informationstechnische Umsetzungen, welche dieser Konzeption folgen, konzentierten sich auf die Verwaltung von Dateien (vgl. [Golt02], S. 59; [EiSt01], S. 23; [Schö00], S. 1; [Aman04]). Spätere Umsetzungen stützten sich auf Datenbanken (vgl. [Schö99b], S. 92).

In der nächsten Stufe der PDM-Konzeption wurde die durchgängige Verwaltung von Da- ten des Produktentwicklungsprozesses angestrebt. Neben dem weiteren Anwachsen der Daten- menge stieg durch höhere Produktkomplexität auch der Grad der Vernetzung von Produktda- ten (vgl. [Wehl00], S. 1; [Golt02], S. 60). Zudem erweiterte sich die Menge der eingesetzten CAx-Anwendungssystemklassen, so dass eine zunehmende Datenheterogenität den Produkt- entwicklungsprozess prägte. Ziel der veränderten Konzeption war die Integration der CAx- Informationsinseln sowie die vollkommen rechnergestützte Abwicklung des Produktentwick- lungsprozesses (vgl. [Schö99b], S. 91). Grundlage dieses Wirkens ist ein integriertes Produkt- modell, welches produktdefinierende und -repräsentierende Daten (vgl. Kapitel 2.3) zu einer umfassenden Beschreibung aller produkt- und produktionsbeschreibenden Merkmale zusam- menfügt und daraus die Ableitung produktpräsentierender Daten ermöglicht (vgl. [Gra+93], S. 1). In der Abkehr vom Gedanken, dass Produktdaten lediglich digitale Dokumente sind, hin zu besagter Klassifikation, ist die Grundlage der Nutzung von Produktdaten f ür digitale In- formationsflüsse in Prozessketten zu sehen (vgl. [AnJo00], S. 16). Produktdatenmanagement wird von daher auch als Enabler Technologie für die modernen Durchführungskonzepte der Produktentwicklung Concurrent Engineering und Simultaneous Engineering betrachtet (vgl. dazu umfassend die Arbeit von HELMS [Helm02]). Als Reaktion auf die Anforderungen der ISO 9001 Normenreihe sowie zunehmenden Produkthaftungsanforderungen erfolgte neben der Erweiterung der reinen Datenverwaltungsfunktion die Anreicherung um Funktionen der Pro- zessverwaltung, wie etwa Änderungsmanagement oder Freigabewesen. Diese erweiterte PDM- Konzeption ermöglicht es einem Unternehmen durch Verwaltung der entsprechenden Produkt- und Prozessmodelle eindeutige, reproduzierbare Konfigurationen eines Produkts zu erstellen (vgl. [EiSt01], S. 20). In diese Konzeption ist die Definition von ESTUBLIER einzuordnen, der unter PDM ”...thediscipleofdesigningandcontrollingtheevolutionofaproductde- sign..“([Est+98b], S. 75) versteht (vgl. auch [Crn+99], S. 2; [Dah+01], S. 1).

Als weiterer Evolutionsschritt in der PDM-Konzeption kann die Ausweitung der Nutzung- phase von im Produktentwicklungsprozess erfassten und verwalteten Produktdaten gesehen werden. Vertreter dieses PDM-Verständnisses sind z.B. HELMS und CRNKOVIC. Sie sehen ne- ben dem Management der Produktentwicklung auch die Versorgung aller anderen Prozesse des gesamten Produktlebenszyklus mit Produktdaten als Aufgabe des PDM. Die Versorgung richtet sich dabei an den Zielen der Informationslogistik aus. Im Einzelnen wird damit die Verf ügbar- keit der richtigen Informationen, zur richtigen Zeit, am richtigen Ort in der richtigen Qualität verfolgt (vgl. [Crn+03], S. 20; [Helm02], S. 13). In dieses Verständnis ist auch die Vorstel- lung eines Produktdatenkontraktes einzuordnen, der eben durch diese Faktoren spezifiziert ist (vgl. [Schi02], S. 35ff) Im Kontext von Entwicklungspartnerschaften im Rahmen des erweiter- ten Unternehmens, expandiert damit der Anwendungsbereich des Produktdatenmanagements über Standortgrenzen und Grenzen einzelner Unternehmen hinaus. Mit diesem Anspruch stei- gen vor allem die Anforderungen an die Integrationsfähigkeit von PDM-Systemen. Gleichzeitig nähert sich diese Konzeption der Vision des Produktdatenmanagements ”...allerelevanten Produkt- und Prozessinformationen über den gesamten Lebenszyklus eines Produkts hinweg konsistent zu speichern, zu verwalten und transparent bereitzustellen ...“([ScKr[01]], S.907 ).

Die vorerst letzte Veränderung der PDM-Konzeption setzte etwa im Jahr2000 ein. Produkt- datenmanagement wurde zu Product Lifecycle Management (PLM). Der scheinbare Austausch der Akronyme stiftet nicht wenig Unfrieden und Unsicherheit in der Fachwelt (vgl. [CIMd[02]], S. 2 f; [Day[04]]; [Huij[04]]). Es besteht bis jetzt Uneinigkeit über den Inhalt der Idee des Product PRODUKTDATENMANAGEMENT Seite: 20 Lifecycle Managements und wodurch sie sich von der zuletzt ausgef ührten Konzeption des Pro- duktdatenmanagements abhebt. SCHOLZ-REITER und KRAUSE sehen den Unterschied in der nochmaligen Ausweitung des PDM-Anwendungsbereiches auf die gesamte Wertsch öpfungs- kette (vgl. [ScKr01], S. 907). Dem folgend ist der maßgebliche Unterschied in einem sehr viel weiteren Verständnis des Produktlebenszyklus zu sehen. Grundlage dieser Sichtweise ist somit die Betrachtung eines Produktes als Zusammensetzung anderer Produkte. Ein Durchbruch f ür eine erfolgreiche und konsistente Begriffsbildung ist in der Ver öffentlichung der Liebensteiner Thesen des SENDLER \ CIRLCE zu sehen. Sie lauten im Einzelnen [send04]:

1”ProductLifecycleManagement(PLM)isteinKonzept,keinSystemundkeine(insich abgeschlossene) Lösung.“
2”ZurUmsetzung/RealisierungeinesPLM-KonzepteswerdenLösungskomponentenbenö- tigt. Dazu zählen CAD, CAE, CAM, VR, PDM und andere Applikationen für den Pro- duktentstehungsprozess.“
3”AuchSchnittstellenzuanderenAnwendungsbereichenwieERP,SCModerCRMsind Komponenten eines PLM-Konzeptes.“
4”PLM-AnbieterofferierenKomponentenund/oderDienstleistungenzurUmsetzungvon PLM Konzepten.“

Die Verfasser der Thesen treten damit vor allem der Argumentation diverser Systemhersteller entgegen. Diese kommunizierten oftmals die Vorstellung, dass Unternehmen durch Einsatz der von ihnen angebotenen Anwendungssysteme PLM umsetzen können (vgl. [Gras[04]], S.10 ).

Besonders die zweite These erscheint dem Autor geeignet, das PLM-Verständnis im Sinne von SCHOLZ-REITER und KRAUSE zu bestätigen. Betrachtet man noch einmal die Ausführun- gen TRIPPNERS zur PDM-Lösung, können die, in der zweiten These erwähnten, Lösungskom- ponenten durch seinen Terminus PDM-Lösung ersetzt werden. PLM ist demnach korrespon- dierend zu der Auffassung von SCHOLZ-REITER und KRAUSE lediglich die Anwendung von Produktdatenmanagement mit einem weiteren Fokus. Eine informationstechnische Umsetzung in diesem Sinne ist also durch eine nochmalige Anhebung der Integrationsanforderungen ge- kennzeichnet, da zusätzlich die in der dritten These aufgeführten Anwendungssystemklassen zu berücksichtigen sind. Begründet durch die uneinheitliche Verwendung des PLM-Begriffes und das hergeleitete Begriffsverständnis soll im Folgenden stattdessen von Produktdatenmana- gement im weiteren Sinn gesprochen werden, wie es auch EIGNER und STELZER vorschlagen (vgl. [EiSt01], S. 24).

Bevor im folgenden Abschnitt auf die Funktionen von Produktdatenmanagement-Systemen eingegangen wird, soll noch eine kurze diesbezügliche Eingrenzung erfolgen. Entsprechend der Entwicklungsgeschichte des Produktdatenmanagements k önnen verschiedene Stilrichtungen für dessen Umsetzung in PDM-Systemen identifiziert werden (vgl. [Ober03], S. 11ff; [Schö99b], S. 290ff; [o.A.97]):

1. CAD/CAM zentrierte PDM-Systeme,
2. ERP/PPS zentrierte PDM-Systeme sowie
3. Stand-alone PDM-Systeme.

In CAD/CAM zentrierten Produktdatenmanagement-Systemen werden entsprechende Funktio- nen in das CA-System durch den Hersteller integriert. Die Arbeitsweise der PDM-Funktionen ist daher meist auf dieses spezielle System angepasst und damit nur bedingt geeignet, Produkt- datenmanagement unternehmensweit zu realisieren. ERP/PPS zentrierte L ösungen nähern sich dem Produktdatenmanagement von der Seite betriebswirtschaftlicher Standardsoftware. Da die- se Systeme bereits eine enorme Stärke bei der Integration betriebswirtschaftlicher Teilbereiche gezeigt haben, wird versucht, auch den Bereich der Produktentwicklung in diese Systeme zu integrieren. Solche Lösungen werden jedoch als ungeeignet betrachtet, da das darunter liegende Informationsmodell nicht die Flexibilität bietet, mit der in Produktentwicklungsvorhaben agiert werden muss. Es verbleiben Stand-alone PDM-Systeme, welche als eigenständige Lösungen PDM-Funktionen in ihrer Gesamtheit oder in Teilen realisieren. Die folgenden Betrachtungen sollen für Systeme dieser Klasse gelten.

2.4.2 Funktionen von Produktdatenmanagement-Systemen

Bei der Betrachtung der Funktionen von Produktdatenmanagement-Systemen erfolgt in der Literatur mehrheitlich eine Differenzierung in die Kategorien Anwendungs- und Unterst ützungsfunktionen. Unter Anwendungsfunktionen werden dabei Funktionen verstanden, die eine Schnittstelle zwischen PDMS und Benutzer darstellen. Hierbei lassen sich folgende f ünf Subkategorien unterscheiden ([Crn+03], S. 21; [CIMd01], S.12):

1. digitales Archiv und Dokumentenmanagement,
2. Workflow- und Prozessmanagement,
3. Produktstrukturmanagement,
4. Klassifikationsmanagement sowie
5. Projektmanagement.

Unterstützungsfunktionen stellen Schnittstellen zu anderen operativen Umgebungen oder Basisdienste für Anwendungsfunktionen zur Verfügung. Auch hier lassen sich fünf Subkategorien bilden ([Crn+03], S. 21):

1. Kommunikation und Benachrichtigung,
2. Datentransport und -transformation,
3. Visualisierung,
4. Administration und
5. Anwendungsintegration.

2.4.2.1 Digitales Archiv und Dokumentenmanagement

Der Großteil an produktrepräsentierenden und produktpräsentierenden Daten im Sinne der Klassifikation von ANDERL und JOHN (vgl. Kapitel 2.3) ist in Dokumenten gebunden. Aktualität, Sicherheit und Konsistenz des Dokumentenbestandes sind daher f ür ein Unternehmen von besonderer Wichtigkeit. Im Rahmen von Produktdatenmanagement-Realisierungen ist die Umsetzung einer Dokumentenmanagementfunktion mithin essentiell.

Für einen effektiven Umgang mit Dokumenten und deren Verwaltung werden sie mit Me- tadatensätzen versehen. Dem Dokument wird dadurch zusätzlicher Nutzen beigebracht, indem Verwaltung, Suche, Wiederauffinden usw. unterstützt werden (vgl. [DIN 01], S. 10). Metadaten für Dokumente sind nach DIN EN 82045-2 beispielsweise für Identifikation, Beschreibung, Klassifikation, Status, Freigabe, Gültigkeit und Verteilung vorzusehen (eine vollständige Auf- listung ist [DIN 03], S. 6 zu entnehmen). In Abhängigkeit der Verknüpfung von Metadaten und Dokumenten werden nach DIN EN 82045 -1:2001 die Dokumentenerscheinungsformen Einzeldokument, zusammengesetztes Dokument, Sammeldokument und Dokumentensatz un- terschieden. Das Einzeldokument (bspw. ein Geschäftsbrief) stellt dabei den Basisfall dar. Er verpflichtet dazu, jedem zu verwaltenden Dokument einen Metadatensatz zuzuordnen, der um- gekehrte Fall ist nicht bindend. Jede physisch getrennte Einheit stellt ein Einzeldokument dar. Werden ursprünglich getrennte Dokumente in einem neuen Dokument zusammengef ührt, ent- steht ein zusammengesetztes Dokument. Jeder Teil des entstehenden Kompositums kann dabei von einer separaten Anwendung erstellt worden sein. Aus Sicht des zusammengesetzten Do- kumentes ist der Prozess seiner Entstehung nicht bekannt. In diesem Fall wird nur dem neuen Dokument ein Metadatensatz zugeordnet. Es ist darauf hinzuweisen, dass diese Form der Do- kumentenabbildung nur anwendbar ist, wenn nicht eine weitere, über den Zeitpunkt der Kom- position hinausgehende Betrachtung und/oder Bearbeitung der Einzelteile verfolgt wird. Eine andere Form der Zusammenfassung von Dokumenten ist das Sammeldokument. Dabei handelt es sich um eine Zusammenstellung von in sich geschlossenen Dokumenten, welche in einer logischen Abhängigkeit stehen. Ein Sammeldokument besitzt in jedem Fall einen eigenen Me- tadatensatz, ein separates Dokument ist dagegen entbehrlich. Die zur Sammlung geh örenden Dokumente erben jeweils wertmäßig die Metadaten des übergeordneten Sammeldokumentes und können diese um eigene Spezifika ergänzen. Eine weitere Aggregationsform von Doku- menten stellt der Dokumentensatz dar. Dieser bildet eine Dokumenteneinheit, die f ür einen bestimmten Zweck in ihrer Gesamtheit von Wert ist. Das Bild der Dokumentenmappe veran- schaulicht aus Sicht des Verfassers diese Erscheinungsform am Besten und grenzt sie gegen über Sammeldokumenten ab. Jeder Dokumentensatz verfügt über eigene Metadaten, welche neben dem Zweck des Dokumentensatzes auch alle enthaltenen Dokumente ausweisen. Im Unter- schied zum Sammeldokument besteht in dieser Erscheinungsform keine Vererbungsbeziehung zwischen den Metadaten, sondern lediglich eine Referenzbeziehung (vgl. [DIN 01], S. 10ff). Abbildung 4 veranschaulicht die dargestellten Erscheinungsformen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Erscheinungsformen von Dokumente ([DIN 01], S. 10ff)

Eine Sonderstellung nehmen verknüpfte Dokumente ein. Diese sind vor allem seit Einführung interoperabler Office-Anwendungen mit der Möglichkeit von verknüpften Objekten eher der Regelfall, denn eine Ausnahme. Per Objekt-Verweis werden hier mehrere unabhängige Doku- mente in einer Entität abgebildet (bspw. ein Word-Dokument mit verknüpften, fortschreibungs- pflichtigen Excel-Tabellen). Ändert sich der Inhalt des verknüpften Objekts, hat dies Auswir- kungen auf den Inhalt des umgebenden Dokuments. Containerdokument und verkn üpfte Do- kumente bilden jedoch abgeschlossene Informationseinheiten, so dass sich eine Metadatensatz- zuordnung für jedes beteiligte Dokument erforderlich macht. In DIN EN 82045-1:2001 wird ausdrücklich darauf hingewiesen, dass solche aktiven Verknüpfungen zu Problemen bei der Pro- dukthaftung führen können. Ab dem Zeitpunkt, an dem der Inhalt des umgebenden Dokuments fixiert wird, sind aktive Verknüpfungen verboten. Mit deren Auflösung entsteht ein zusammen- gesetztes Dokument im Sinne der ausgeführten Klassifikation (vgl. [DIN 01], S. 13).

In der Literatur existieren widersprüchliche Ansichten wie eine Dokumentenmanagement-Funk- tion in PDMS realisiert werden sollte und welche Konzepte dabei zum Einsatz kommen. (vgl. [FZI 04]; [Schö99b], S. 94f u. S. 166ff; [Crn+03], S. 22f u. 31; [EiSt01], S. 58f, S. 86ff, S. 222; [ScKr01], S.910). Daher sollen im Folgenden die Erkenntnisse auf fachkonzeptioneller Ebene zu einem einheitlichen Bild geformt werden. Als Basis soll die literatur übergreifend bestätigte Tatsache dienen, dass Metadatensätze und reale Dokumente getrennt von einander abgelegt werden. Übereinstimmung besteht auch darüber, dass durch ein PDMS direkt nur Repräsentationen realer Dokumente verwaltet werden. Diese Repräsentationseinheiten sollen als Instanzen von Geschäftsobjekttypen (GOTs) betrachtet werden. Metadaten zu Dokumen- ten sollen in Attributen der Geschäftsobjekte gebunden sein. Die mögliche Attributmenge wird dabei durch die Attributtypmenge des Geschäftsobjekttyps (GOT) festgelegt. Als generische Dokumentenrepräsentation soll der GOT [Dokumentationseinheit] eingeführt werden. Er definiert Attributtypen, welche in allen Dokumenten auftreten, also insbesondere identifi- zierende und klassifizierende Metadaten sowie Teile der beschreibenden Metadatenmenge, wie Benennung, Status, Reifegrad, Ersteller usw.. Nach dem Kriterium der Atomarität erben vom GOT [Dokumentationseinheit] jeweils die GOTs [Dokument] als Repräsentation einer physisch getrennten Einheit und [mehrgliedriges Dokument] als generische Repräsen- tation einer wie auch immer gearteten Zusammensetzung von Dokumenten. Als feinstgranu- lare Stufe des Dokumentenmanagements definiert [Dokument] den Ablageort der physischen Einheit, welche seine Instanzen repräsentieren. Nach der Dokumentenart sollen des Weiteren Spezialisierungen des GOT [Dokument] gebildet werden. Hier soll nur grob in [Zeichnung], [Modell] und [Allgemeines Dokument] unterschieden werden. Es wird diesbezüglich kein Anspruch auf Vollständigkeit erhoben. Es ist durchaus eine weitergehende Differenzie- rung von Dokumentenarten denkbar und im konkreten Fall der Anwendung wohl auch not- wendig. Innerhalb der genannten GOTs werden zusätzliche für die jeweilige Klasse von Doku- menten typische Beschreibungsattribute definiert, z.B. Ansicht, Darstellunggrad f ür [Modell], Maßstab, Format für [Zeichnung] und Wortanzahl für [Allgemeines Dokument]. Be- zug nehmend auf das Thema der Arbeit sei darauf hingewiesen, dass auch Softwarepakete und Quellcode, wenn sie innerhalb eines PDMS verwaltet werden, als Dokument gelten. Abbildung 5 veranschaulicht den bisherigen Stand der Konzeption.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Geschäftsobjekttypen für unterschiedliche Dokumententypen

Durch Verwendung der bisher definierten GOTs lassen sich bereits Einzeldokumente artspe zifisch abbilden. Für Zusammenfassungen von Einzeldokumenten gilt dies nicht. Hier m üssen weitere Unterscheidungen getroffen werden. Als Diskriminator soll in der Konzeption des Ver- fassers die logische Abhängigkeit der, an einer Zusammensetzung beteiligten, Einzeldoku- mente zur Anwendung kommen. Vom GOT [mehrgliedriges Dokument] werden dies- bezüglich die GOTs [Dokumentensatz] und [Sammeldokument] abgeleitet. Aus DIN EN 6789-1:2001 ergibt sich keine eindeutige Trennung der Konzepte Dokumentensatz und Sammeldokument nach dem logischen Zusammenhang ihrer Teile. Es lässt sich diesbezüglich nur schließen. Daher soll hier gelten, dass Instanzen des GOT [Dokumentensatz] für sach- logische Einheiten stehen, während Geschäftsobjekte vom Typ [Sammeldokument] aufbau- logische Zusammenfassungen repräsentieren. Nicht jedes Dokument ist daher Teil eines Sam- meldokumentes. Wenn eine solche Beziehung besteht, ist sie jedoch exklusiv bez üglich des Sammeldokumentes. Die Repräsentation aufbaulogischer Zusammenhänge rechtfertigt sich aus dem Fakt, dass einige Anwendungssysteme der Konstruktion jedes Blatt einer Zeichnung in einer separaten Datei speichern (wie durch das 2-D CAD System ME-10 der Firma Co- Create realisiert (vgl. [EiSt01], S. 98)). Für diesen Fall besagt DIN 6789-2: ”IstesausDar- stellungsgründen erforderlich, ein Dokument in mehrere Blätter aufzuteilen, so erhalten diese Blätter dieselbe Dokumentennummer, dieselbe Benennung und denselben Änderungsindex. Die Blätter sind mit der Blattnummer und einem Hinweis auf Folgeblätter zu versehen..“([DIN [90]], PRODUKTDATENMANAGEMENT Seite: 26 S. 4).⁴ Für aufbaulogisch zusammenhängende Einzeldokumente bedeutet dies, dass sie in ei- ner strengen Teile-Ganzes Beziehung zu ihrem Aggregat stehen und damit von ihrem Aggre- gat existenzabhängig sind. Die wohlweislich mögliche Zusammenfassung von Dokumenten zu sachlogischen Dokumentensätzen gestaltet sich loser. Dokumente sind diesbezüglich nicht exklusiv einer Instanz zugeordnet und auch nicht davon existenzabhängig. Die Beziehung stellt von daher statt einer Komposition die schwächere Form der Teile-Ganzes-Beziehung der Aggregation dar. Die Gleichzeitigkeit der Teilnahme an der Beziehung [Dokumentensatz]- [Dokument] und [Sammeldokument]-[Dokument] ist dabei nicht ausgeschlossen, in die- sem Fall wohl aber an die Existenz des Sammeldokumentes gebunden. Eine weiterhin zu bedenkende Dimension des Dokumentenmanagements ist die Hierarchie von Dokumentenzu- sammensetzungen. Hier soll gelten, dass Dokumentensätze zu Dokumentensätzen höherer Ord- nung zusammengesetzt werden können. Dieser Zusammenhang wird durch eine reflexive Ag- gregation in die Konzeption eingebracht. Ferner können aufbaulogische Kompositionen vom Typ [Sammeldokument] nichtexklusiver Teil eines Geschäftsobjektes Dokumentensatz sein. Sie stehen daher in einer möglichen Aggregationsbeziehung zu Dokumentensätzen. Neben aufbau- und sachlogischen Betrachtungen müssen weitere Relationen zwischen Do- kumenteneinheiten modelliert werden können. Anzahl und Inhalt solcher Beziehungen sind von konkreten Anforderungen einer Organisation abhängig und sollen daher nur generisch durch eine [related document-relating document] Beziehung in die Konzeption eingehen. Eine beispielhafte und in jedem Fall notwendige Anwendung dieser Relationen stellt die Beziehung zwischen zeitpunktbezogenen Zuständen von Dokumentationseinheiten dar. Sie soll als [Vorgänger-Nachfolger] Beziehung hervorgehoben werden. Von Wert sind die meisten Dokumentationseinheiten jedoch nur, wenn Sie in einen Verwendungskontext gesetzt werden können. Zu diesem Zweck wird die Mehrheit⁵ der Geschäftsobjekte des Dokumen- tenmanagements mit Geschäftsobjekten anderer Teilgebiete des Produktdatenmanagements in eine assoziative Beziehung gesetzt. Diese Geschäftsobjekte sind ausschließlich Teil einer De- finitionsstruktur. Darunter können Geschäftsobjekte der Produktstrukturdefinition, wie Bauteil, Baugruppe ebenso fallen wie Geschäftsobjekte einer Projektstrukturdefinition etwa eine Tei- laufgabe. Als Repräsentation dieser Art von Geschäftsobjekten soll daher nur ein generischer Geschäftsobjekttyp [Definitionsobjekt] in die konzeptuelle Darstellung eingehen (vgl. Abbildung 6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Geschäftsobjekttypen des Dokumentenmangements

Der Zugriff auf reale Dokumente erfolgt in einem PDM-System ausschließlich über Instan- zen der definierten Geschäftsobjekttypen, welche in Datenbanken gespeichert werden. Die realen Entsprechungen dieser Repräsentationen sind in geschützten Bereichen abgelegt. Für elek- tronische Dokumente werden diese zumeist auf File-Servern realisiert⁶, während sich für Pa- pierdokumente jede Art der konventionellen Ablage eignet. Im Folgenden sollen jedoch nur Zugriffsprinzipien für elektronische Dokumente dargestellt werden, da auf dieser Ebene die Wirkung des Einsatzes eines PDM-Systems am stärksten zum Tragen kommt. Der geschütz- te Ablagebereich für Dateien auf File-Servern wird Datentresor (engl.

[...]

---

¹ Ausnahmsweise sollen im Folgenden die Begriffe Phase und Prozess synonym Verwendung finden. Dies kann in sofern gerchtfertigt werden, als dass hinter jeder Phase des Produktlebenzyklus gleichsam ein Prozess zu erblicken ist und umgekehrt jeder betriebliche Prozess im Kontext einer Phase des Produktlebenszyklus durch- geführt wird.

² Die alleinige Betrachtung von Komplexität wird nicht von allen Autoren unterstützt. So unterscheidet SCH ÜTTE zwischen Komplexität und Kompliziertheit eines Systems und weist dabei einer zunehmenden Anzahl von Teilen und Beziehungen, eine komplexitätssteigernde Wirkung zu und auf der anderen Seite vermehrter Inho- mogenität von Elementen und Beziehungen eine gesteigerte Kompliziertheit zu (vgl. [Schü98], S. 39).

³ Die Norm DIN 44300 ist laut Perinorm-Datenbank inzwischen zurückgezogen worden.

⁴ Darstellungsgrund bezieht sich bei der Betrachtung von elektronischen Dokumenten auf getrennte Speicherung.

⁵ Die auf Ausnahmen hindeutende Formulierung Mehrheit ist gerechtfertigt, da es Dokumentationseinheiten gibt, welche nicht an solchen Beziehungen teilnehmen. Darunter fal- len z.B. Repräsentationen von Normen, Formularen oder allgemeinen Verfahrensanweisungen (vgl. [EiSt01], S. 56).

⁶ Im Grunde ist jedes heute verfügbare, ernstzunehmende Datenbanksystem in der Lage auch große Datenmengen in Form von Binary Large Objects aufzunehmen. Allerdings entstehen dabei aufgrund der enormen Größe die bereits einzelne Dokumente aufweisen können beträchtliche Performanz-Probleme, so dass eine solche Form der Persistenzrealisierung eher als Ausnahme anzusehen ist.