Integriertes Produktdaten- und Prozeßmanagement …...Lehrstuhl für Betriebswissenschaften und...

Lehrstuhl fürBetriebswissenschaften und Montagetechnik

der Technischen Universität München

Integriertes Produktdaten- und Prozeßmanagement

in virtuellen Fabriken

Stefan Brandner

Vollständiger Abdruck der von der Fakultät für Maschinenwesen derTechnischen Universität München zur Erlangung des akademischenGrades eines

Doktor-Ingenieurs (Dr.-Ing.)

genehmigten Dissertation.

Vorsitzender: Univ.-Prof. Dr.-Ing. U. Lindemann

Prüfer der Dissertation:

1. Univ.-Prof. Dr.-Ing. G. Reinhart

2. Univ.-Prof. Dr.-Ing. K. Bender

Die Dissertation wurde am 21.10.1999 bei der Technischen Universität

München eingereicht und durch die Fakultät für Maschinenwesen am

09.02.2000 angenommen.

(QTUEJWPIUDGTKEJVG

$CPF��

5VGHCP�$TCPFPGT

+PVGITKGTVGU�2TQFWMVFCVGP��WPF

2TQ\GOCPCIGOGPV�KP

XKTVWGNNGP�(CDTKMGP

JGTCWUIGIGDGP�XQP

2TQH��&T��+PI��)��4GKPJCTV

*GTDGTV�7V\�8GTNCI��

(QTUEJWPIUDGTKEJVG�KYD

$GTKEJVG�CWU�FGO�+PUVKVWV�HÒT�9GTM\GWIOCUEJKPGP

WPF�$GVTKGDUYKUUGPUEJCHVGP

FGT�6GEJPKUEJGP�7PKXGTUKV·V�/ÒPEJGP

JGTCWUIGIGDGP�XQP

7PKX��2TQH��&T��+PI��)WPVJGT�4GKPJCTV

6GEJPKUEJG�7PKXGTUKV·V�/ÒPEJGP

+PUVKVWV�HÒT�9GTM\GWIOCUEJKPGP�WPF�$GVTKGDUYKUUGPUEJCHVGP�KYD�

&KG &GWVUEJG $KDNKQVJGM _ %+2�'KPJGKVUCWHPCJOG

'KP 6KVGNFCVGPUCV\ HÒT FKGUG 2WDNKMCVKQP KUVDGK &GT &GWVUEJGP $KDNKQVJGM GTJ·NVNKEJ

<WINGKEJ� &KUUGTVCVKQP� /ÒPEJGP� 6GEJP� 7PKX��

&KGUGU 9GTM KUV WTJGDGTTGEJVNKEJ IGUEJÒV\V� &KG FCFWTEJDGITÒPFGVGP 4GEJVG� KPUDGUQPFGTG FKG FGT ªDGTUGV\WPI� FGU0CEJFTWEMU� FGT 'PVPCJOG XQP #DDKNFWPIGP� FGT 9KGFGTICDGCWH RJQVQOGEJCPKUEJGO QFGT ·JPNKEJGO 9GIG WPF FGT5RGKEJGTWPI KP &CVGPXGTCTDGKVWPIUCPNCIGP DNGKDGP� CWEJ DGKPWT CWU\WIUYGKUGT 8GTYGPFWPI� XQTDGJCNVGP�

%QR[TKIJV� *GTDGTV 7V\ 8GTNCI )OD* ��

+5$0��

2TKPVGF KP )GTOCP[

*GTDGTV 7V\ 8GTNCI )OD*� /ÒPEJGP

6GN�� (CZ� ��

Geleitwort des Herausgebers

Die Produktionstechnik ist für die Weiterentwicklung unserer Industriegesell-schaft von zentraler Bedeutung. Denn die Leistungsfähigkeit eines Industriebe-triebes hängt entscheidend von den eingesetzten Produktionsmitteln, den ange-wandten Produktionsverfahren und der eingeführten Produktionsorganisationab. Erst das optimale Zusammenspiel von Mensch, Organisation und Technikerlaubt es, alle Potentiale für den Unternehmenserfolg auszuschöpfen.

Um in dem Spannungsfeld Komplexität, Kosten, Zeit und Qualität bestehen zukönnen, müssen Produktionsstrukturen ständig neu überdacht und weiterentwi-ckelt werden. Dabei ist es notwendig, die Komplexität von Produkten, Produk-tionsabläufen und -systemen einerseits zu verringern und andererseits besser zubeherrschen.

Ziel der Forschungsarbeiten des iwb ist die ständige Verbesserung von Pro-duktentwicklungs- und Planungssystemen, von Herstellverfahren und Produkti-onsanlagen. Betriebsorganisation, Produktions- und Arbeitsstrukturen sowieSysteme zur Auftragsabwicklung werden unter besonderer Berücksichtigungmitarbeiterorientierter Anforderungen entwickelt. Die dabei notwendige Steige-rung des Automatisierungsgrades darf jedoch nicht zu einer Verfestigung ar-beitsteiliger Strukturen führen. Fragen der optimalen Einbindung des Menschenin den Produktentstehungsprozeß spielen deshalb eine sehr wichtige Rolle.

Die im Rahmen dieser Buchreihe erscheinenden Bände stammen thematischaus den Forschungsbereichen des iwb. Diese reichen von der Produktentwick-lung über die Planung von Produktionssystemen hin zu den Bereichen Ferti-gung und Montage. Steuerung und Betrieb von Produktionssystemen, Quali-tätssicherung, Verfügbarkeit und Autonomie sind Querschnittsthemen hierfür.In den iwb-Forschungsberichten werden neue Ergebnisse und Erkenntnisse ausder praxisnahen Forschung des iwb veröffentlicht. Diese Buchreihe soll dazubeitragen, den Wissenstransfer zwischen dem Hochschulbereich und dem An-wender in der Praxis zu verbessern.

Gunther Reinhart

Vorwort

Die vorliegende Dissertation entstand während meiner Tätigkeit als wissen-schaftlicher Mitarbeiter am Institut für Werkzeugmaschinen und Betriebswis-senschaften (iwb) der Technischen Universität München.

Herrn Prof. Dr.-Ing. Gunther Reinhart, dem Leiter dieses Instituts, gilt meinbesonderer Dank für die gute und vertrauensvolle Zusammenarbeit sowie fürdie wohlwollende Förderung und großzügige Unterstützung meiner Arbeit.

Bei Herrn Prof. Dr.-Ing. Klaus Bender, dem Leiter des Lehrstuhls für Informa-tionstechnik im Maschinenwesen der Technischen Universität München,möchte ich mich für die Übernahme des Korreferates und die aufmerksameDurchsicht der Arbeit sehr herzlich bedanken.

Darüber hinaus bedanke ich mich bei allen Mitarbeiterinnen und Mitarbeiterndes Instituts sowie allen Studenten, die mich bei der Erstellung meiner Arbeitunterstützt haben, recht herzlich.

München, im Februar 2000 Stefan Brandner

Inhaltsverzeichnis

1 Einführung und Zielsetzung ...........................................................................1

1.1 Projektabwicklung in virtuellen Fabriken ..................................................1

1.2 Zielsetzung der Arbeit ................................................................................2

1.3 Aufbau der Arbeit .......................................................................................4

2 Die virtuelle Fabrik.........................................................................................7

2.1 Vision und Definition .................................................................................7

2.2 Unterschiede zu bekannten Organisationsformen ......................................8

2.3 Erfolgsfaktoren ...........................................................................................9

2.4 Praxisbeispiele ..........................................................................................10

2.5 Defizite in der Projektabwicklung............................................................12

2.6 Zusammenfassung ....................................................................................15

3 Produktdaten- und Prozeßmanagement – Stand der Technik.......................17

3.1 Übersicht...................................................................................................17

3.2 Projektmanagement ..................................................................................18

3.2.1 Begriffsdefinition und Entwicklung .................................................18

3.2.2 Methoden und Werkzeuge zum Projektmanagement .......................23

3.2.3 Zusammenfassende Bewertung.........................................................30

3.3 Geschäftsprozeßmanagement ...................................................................31


3.3.2 Methoden und Werkzeuge zum Geschäftsprozeßmanagement ........35

ii Inhaltsverzeichnis

3.3.3 Zusammenfassende Bewertung ........................................................43

3.4 Produktdatenmanagement ........................................................................45


3.4.2 Methoden und Werkzeuge zum Produktdatenmanagement .............47

3.4.3 Zusammenfassende Bewertung ........................................................56

3.5 Grenzen der Ansätze und Handlungsbedarf .............................................57

4 Anforderungen an das Produktdaten- und Prozeßmanagement ...................61

4.1 Definition des Einsatzbereichs für das Konzept.......................................61

4.2 Anforderungen an das Prozeßmanagement ..............................................62

4.3 Anforderungen an das Produktdatenmanagement....................................63

4.4 Anforderungen an die DV-technische Umsetzung...................................63

5 Konzept zum integrierten Produktdaten- und Prozeßmanagement..............65

5.1 Lösungsansatz...........................................................................................65

5.2 Informationsanalyse..................................................................................69

5.2.1 Prozeßdaten.......................................................................................70

5.2.2 Produktdaten .....................................................................................71

5.2.3 Relevante Daten für das Konzept .....................................................72

5.3 Konzept für das Prozeßmanagement ........................................................73

5.3.1 Unternehmensübergreifende Phasenplanung....................................73

5.3.2 Phasenabhängige Zugriffsregelung...................................................73

5.3.3 Unternehmensübergreifende Informationsflußmodellierung ...........75

5.4 Konzept für das Produktdatenmanagement..............................................77

Inhaltsverzeichnis iii

5.5 Konzept für die Integration.......................................................................80

5.6 Vorgehen beim integrierten Produktdaten- und Prozeßmanagement.......84

5.6.1 Phasenplanung ..................................................................................84

5.6.2 Aktivitätenplanung............................................................................87

5.6.3 Auftragsabwicklung..........................................................................90

5.7 Zusammenfassung ....................................................................................92

6 Softwaretechnische Umsetzung....................................................................95

6.1 Spezifikation des Datenmodells ...............................................................95

6.1.1 Produktdatennorm STEP...................................................................96

6.1.2 Übersicht über das Gesamtmodell ....................................................98

6.1.3 Partialmodell "Prozeß"....................................................................100

6.1.4 Partialmodell "Produkt" ..................................................................103

6.1.5 Partialmodell "Organisation" ..........................................................106

6.2 Architektur von UDP..............................................................................108

6.3 Grundlagen der Implementierung...........................................................109

6.3.1 Datenbanksystem und Programmiersprache...................................109

6.3.2 Vorteile durch die eingesetzten Technologien................................111

6.4 Funktionsmodell und graphische Benutzeroberfläche ...........................112

6.5 Zusammenfassung ..................................................................................116

7 Anwendungsszenario am Beispiel des RP-Net.de......................................119

7.1 Einführung Rapid Prototyping / Rapid Tooling .....................................119

7.2 Unternehmensnetzwerk RP-Net.de ........................................................120

iv Inhaltsverzeichnis

7.3 Exemplarische Projektabwicklung .........................................................121

7.3.1 Projektbeschreibung und Aufbau einer virtuellen Fabrik...............121

7.3.2 Phasenplanung ................................................................................122

7.3.3 Aktivitätenplanung..........................................................................126

7.3.4 Auftragsabwicklung........................................................................129

8 Bewertung und Diskussion des Konzepts ..................................................133

8.1 Aufwand/Nutzen-Abschätzung ..............................................................133

8.1.1 Aufwand..........................................................................................133

8.1.2 Nutzen .............................................................................................134

8.1.3 Zusammenfassende Bewertung ......................................................136

8.2 Auswirkungen auf Mensch, Organisation und Technik.........................137

9 Zusammenfassung und Ausblick................................................................141

Literaturverzeichnis ............................................................................................145

Abkürzungen und Symbole v

Verwendete Abkürzungen

AP Application Protocol

CAD Computer Aided Design

CNC Computerized Numerical Control

CPM Critical Path Method

DIN Deutsches Institut für Normung

DMU Digital Mock-Up

DV Datenverarbeitung

DXF Drawing Exchange Format

E-Mail Electronic Mail

EDI Electronic Data Interchange

EDIFACT Electronic Data Interchange for Administration, Commerce andTransport

EDM Engineering Data Management

HSC High Speed Cutting

HTML Hypertext Markup Language

IDEF ICAM Definition Language

IEM Integrated Enterprise Modelling

IGES Initial Graphics Standard

ISO International Standardisation Organisation

IUM Integrierte Unternehmensmodellierung

iwb Institut für Werkzeugmaschinen und Betriebswissenschaften

KMU Kleine und mittlere Unternehmen

vi Abkürzungen und Symbole

MPM Metra-Potential-Methode

N. N. unbekannter Autor (lateinisch: nomen nescio)

PDM Produktdatenmanagement (englisch: Product Data Manage-ment)

PERT Programm Evaluation and Review Technique

PL/SQL Procedural Language SQL

PPS Produktionsplanung und -steuerung

PSP Projektstrukturplan

RP Rapid Prototyping

RT Rapid Tooling

SADT Structured Analysis and Design Technique

SQL Structured Query Language

STEP Standard for the Exchange of Product Model Data

UDP Unternehmensübergreifendes Daten- und Prozeßmanagement

URL Uniform Resource Locator

VANS Value Added Network Services

VDA-FS Verband der Automobilindustrie – Flächenschnittstelle

VDI Verein Deutscher Ingenieure

WFM Workflowmanagement

WWW World Wide Web

1 Einführung und Zielsetzung

1.1 Projektabwicklung in virtuellen Fabriken

Der Wettbewerb erfordert in vielen Branchen die schnelle Entwicklung undHerstellung von kundenindividuellen Produkten in oft nur kleinen Stückzahlen.Langfristigen Erfolg werden dann nur die Unternehmen haben, die neue Tech-nologien rechtzeitig beherrschen und effizient einsetzen können (MILBERG

1998). Dieser Anforderung können kleine und mittlere Unternehmen gerechtwerden, wenn sie intelligent kooperieren, also die Vorteile innovativer Tech-nologien nutzen ohne die Vorteile des Mittelstandes zu verlieren (MAYER

1998). Intelligente Kooperationen schaffen den Zugang zu einer breiten undtiefen Know-how-Basis, ohne daß Reaktionsfähigkeit und Flexibilität aufgege-ben werden (REINHART & BRANDNER 1998).

Unternehmen, die bereit sind zu kooperieren, können sich auf ihre Kernkom-petenzen konzentrieren und sind dadurch konkurrenzfähiger (REINHART &GRUNWALD 1999). Sie müssen aber auch in der Lage sein, projektbezogen ge-eignete Partner auswählen zu können, deren Kompetenzen sich mit den eigenenzu dem Leistungsprofil ergänzen, das der Kunde benötigt (GOLDMAN U. A.1994). Als Basis hierfür kann ein Kooperationsnetzwerk dienen, das zwischenselbständigen Unternehmen aufgebaut wird. Aus diesem Netzwerk wird fürjedes Projekt eine geeignete Wertschöpfungskette in Form einer virtuellen Fab-

rik, also einem produzierenden virtuellen Unternehmen gebildet (REINHART U.A. 1996).

Die Bedeutung von virtuellen Fabriken nimmt stetig zu, allerdings ist die Effi-zienz dieser Organisationsform noch nicht ausreichend. Dadurch, daß die Wert-schöpfungskette auf mehrere Unternehmen verteilt wird, kommt es zwangsläu-fig zu Reibungsverlusten in der Projektabwicklung (MALONE & L AUBACHER

1999). Gründe hierfür sind neben der geographischen Verteilung der Projekt-partner vor allem organisatorische, informations- und kommunikationstechni-sche sowie unternehmenskulturelle Unterschiede, die ein effizientes Informati-onsmanagement verhindern (PICOT U. A. 1996).

2 1.2 Zielsetzung der Arbeit

Effizientes Informationsmanagement bedeutet, daß Informationen strukturiertverwaltet und allen Projektbeteiligten rechtzeitig und in geeigneter Qualität zurVerfügung gestellt werden (EVERSHEIM 1996). Wesentlich sind hierbei Infor-mationen über das Projekt und über während des Projektverlaufs entstehendeund auszutauschende Produktdaten, die nicht nur das Produkt, sondern auch dieProduktionsmittel und den Produktionsprozeß beschreiben.

Viele der in den letzten Jahren entwickelten Methoden und Werkzeuge unter-stützen langfristige unternehmensübergreifende Auftragsabwicklungen. Denbesonderen Anforderungen von kurzfristigen Kooperationen in sich regelmäßigändernden Unternehmenskonstellationen, wie sie virtuelle Fabriken darstellen,genügen diese Ansätze allerdings nicht (MALONE & L AUBACHER 1999).

1.2 Zielsetzung der Arbeit

Diese Arbeit soll einen Beitrag für eine effiziente Projektplanung und-abwicklung in virtuellen Fabriken liefern. Hierbei sollen unternehmensüber-greifende Prozesse sowie die Verwaltung von Produktdaten innerhalb von Ko-operationen in den Mittelpunkt der Betrachtung gestellt werden. Konkret wer-den folgende Ziele angestrebt:

1. Es soll ein Konzept für das integrierte Produktdaten- und Prozeßmanage-ment entwickelt werden. Das Konzept soll vor allem für die Dynamik undHeterogenität von virtuellen Fabriken ausgelegt werden.

2. Das Konzept soll prototypisch in ein DV-System umgesetzt werden, dasunternehmensübergreifend ein effizientes Produktdaten- und Prozeßmana-gement ermöglicht. Hierbei soll weitestgehend auf verfügbare Standards zu-rückgegriffen werden.

In herkömmlichen unternehmensübergreifenden Projekten werden Produkt- undProzeßdaten dezentral und eigenständig bei den beteiligten Unternehmen ver-waltet. Der Austausch von Produktdaten und Projektinformationen erfordertAbsprachen zwischen den Unternehmen und Mitarbeitern und findet deshalbselten statt (PICOT U. A. 1996). Dieses Vorgehen ermöglicht zwar eine struktu-rierte und redundanzfreie Verwaltung von Produkt- und Prozeßdaten innerhalbjedes einzelnen Unternehmens, betrachtet man allerdings das komplette Projekt

1 Einführung und Zielsetzung 3

über die Unternehmensgrenzen hinweg, gehen sowohl die Prozeßtransparenzals auch die strukturierte Produktdatenverwaltung verloren.

In dem hier verfolgten Ansatz werden Kooperationen nicht aus der Sicht einesUnternehmens, sondern aus der Sicht des Gesamtprojekts betrachtet. Da in vir-tuellen Fabriken regelmäßig andere Projektmitarbeiter mit jeweils individuellenMethoden und Werkzeugen beteiligt sind, darf der zu entwickelnde Ansatznicht an den Anforderungen eines einzelnen Unternehmens ausgerichtet wer-den, sondern muß den Anforderungen von Unternehmensnetzwerken genügen.Hierfür ist zu erarbeiten, wie und bis zu welchem Umfang Produkt- und Pro-zeßdaten mit gemeinsamen Methoden und Werkzeugen verarbeitet werdenmüssen, um eine integrierte Modellverwaltung zu ermöglichen. Bild 1-1 zeigtschematisch das Ziel einer unternehmensübergreifend integrierten Verwaltungvon Produkt- und Prozeßdaten.

Produktmodell in der virtuellen Fabrik

Prozeßmodell der virtuellen Fabrik

Produktdaten im Unternehmen BProduktdaten im Unternehmen A

Prozeßmodell Unternehmen BProzeßmodell Unternehmen A

Integriertes Produkt- und Prozeßmodell

Bild 1-1: Integriertes Produkt- und Prozeßmodell in virtuellen Fabriken

4 1.3 Aufbau der Arbeit

1.3 Aufbau der Arbeit

Zur systematischen Durchdringung dieser Thematik wird folgender Aufbau derArbeit gewählt (vgl. Bild 1-2).

Produktdaten- und Prozeßmanagement - Stand der Technik(Kapitel 3)

Konzept zum integrierten Produktdaten- und Prozeßmanagement in virtuellen Fabriken

(Kapitel 5)

Softwaretechnische Umsetzung(Kapitel 6)

Die virtuelle Fabrik(Kapitel 2)

Anforderungen an das Produktdaten- und Prozeßmanagementin virtuellen Fabriken

(Kapitel 4)

Anwendungsszenario (Kapitel 7)

Bewertung und Diskussion des Konzepts(Kapitel 8)

Zusammenfassung und Ausblick(Kapitel 9)

Bild 1-2: Aufbau der Arbeit

1 Einführung und Zielsetzung 5

Die Organisationsform der virtuellen Fabrik wird in Kapitel 2 vorgestellt. Eswerden Praxisbeispiele beschrieben und Erfolgsfaktoren aufgeführt. Weiterhinwerden Defizite bei der Projektabwicklung identifiziert.

Kapitel 3 stellt den Stand der Technik des Produktdaten- und des Prozeßmana-gements vor. Es werden die grundlegenden Konzepte aufgezeigt und aktuelleEntwicklungen diskutiert. Die vorgestellten Lösungsansätze werden bezüglichihrer Eignung für den Einsatz in virtuellen Fabriken bewertet.

In Kapitel 4 werden Anforderungen an eine effiziente Projektplanung und-abwicklung in dynamischen Unternehmenskooperationen aufgestellt. Daraufaufbauend wird in Kapitel 5 das Konzept für das integrierte Produktdaten- undProzeßmanagement in virtuellen Fabriken entwickelt. Die Teilbereiche zur Be-schreibung von Produkt- und Prozeßdaten werden auf Basis einer Informati-onsanalyse erarbeitet. Weiterhin wird eine Vorgehensweise beim integriertenProduktdaten- und Prozeßmanagement aufgezeigt.

Kapitel 6 stellt das auf Internet-Technologien und Standards basierende Soft-waresystem UDP (Unternehmensübergreifendes Daten- und Prozeßmanage-ment) vor. In diesem Prototyp wird das entwickelte Konzept umgesetzt und derNutzen diskutiert. Weiterhin wird das Datenmodell vorgestellt, und Grundlagender Implementierung werden erläutert.

Die Evaluierung des Konzepts folgt in Kapitel 7 anhand eines Anwendungssze-narios in dem Unternehmensnetzwerk RP-Net.de. Kapitel 8 bewertet den Ein-satz des Konzepts und diskutiert den Einfluß auf Mensch, Organisation undTechnik. Kapitel 9 bietet eine Zusammenfassung und einen Ausblick auf weite-re Forschungsarbeiten.

6 1.3 Aufbau der Arbeit

2 Die virtuelle Fabrik

In diesem Kapitel wird die Organisationsform der virtuellen Fabrik vorgestellt.Hierzu werden neben der Vision der virtuellen Fabrik mögliche Einsatzbereicheanhand von Praxisbeispielen diskutiert. Unterschiede zu bekannten Organisati-onsformen sowie die Erfolgsfaktoren werden aufgezeigt. Schließlich folgt dieBetrachtung der Projektplanung und -abwicklung sowie die Identifikation vonDefiziten.

2.1 Vision und Definition

"Wäre es nicht wunderbar, wenn Sie ein wirklich gewinnträchtiges Unterneh-

men betreiben könnten, ohne die Arbeit zu tun? Sie würden sich damit begnü-

gen, sich ein großartiges Produkt auszudenken oder eine Idee zu kaufen, und

dann nur noch den ganzen Prozeß orchestrieren."

So formuliert SEMICH (1994) die Vision der virtuellen Fabrik. Was sich hinterdieser Vision verbirgt, beschreiben ARNOLD & HÄRTLING (1995) wie folgt:

"Eine virtuelle Fabrik ist eine Kooperationsform rechtlich unabhängiger Un-

ternehmen, Institutionen und/oder Einzelpersonen, die eine Leistung auf der

Basis eines gemeinsamen Geschäftsverständnisses erbringen. Die kooperieren-

den Einheiten beteiligen sich an der horizontalen und/oder vertikalen Zusam-

menarbeit vorrangig mit ihren Kernkompetenzen und wirken bei der Leistungs-

erstellung gegenüber Dritten wie ein einheitliches Unternehmen. Dabei wird

auf die Institutionalisierung zentraler Managementfunktionen zur Gestaltung,

Lenkung und Entwicklung der virtuellen Fabrik weitgehend verzichtet und der

notwendige Koordinations- und Abstimmungsbedarf durch geeignete Informa-

tions- und Kommunikationssysteme gedeckt. Die virtuelle Fabrik besteht so

lange, bis ihr Geschäftszweck erfüllt oder hinfällig geworden ist. "

REINHART U. A. (1996) sehen in dieser Organisationsform ein strategischesKonzept für Unternehmen, um in den sich ständig ändernden und unvorherseh-baren Umgebungseinflüssen langfristig erfolgreich zu sein. GOLDMAN U. A.

8 2.2 Unterschiede zu bekannten Organisationsformen

(1994) haben folgende Motive identifiziert, die zum Wunsch nach einer Teil-nahme an virtuellen Fabriken führen:

- Externe Entwicklungs- oder Fertigungsressourcen sollen schnell in die eige-ne Projektabwicklung integriert werden.

- Die Einbindung externer Ressourcen soll keine Ausnahme darstellen, son-dern zur Regel werden.

- Innovative Technologien, die zur Herstellung von komplexen Produktennotwendig sind, sollen nicht im eigenen Unternehmen vorgehalten werden,aber trotzdem kurzfristig verfügbar sein.

Virtuelle Fabriken können zu mehreren Vorteilen für die beteiligten Unterneh-men führen. So können die personellen und maschinellen Ressourcen auf dieKernkompetenzen konzentriert werden. Aufgaben, die nicht zur Kernkompe-tenz gehören, werden von externen Unternehmen bezogen (SCHUH U. A. 1998,WIENDAHL U. A. 1996). Für kleine Unternehmen eröffnet sich die Möglichkeit,auch umfangreiche Aufträge abzuwickeln, da die Arbeitspakete auf mehrereUnternehmen verteilt werden können. Ein kleines Unternehmen kann somit denHandlungsspielraum eines Großunternehmens erreichen. Dadurch können derAuftragseingang erhöht und die Kapazitätsauslastung verbessert werden(MERTENS 1995). Virtuelle Fabriken sind außerdem kundenorientierter alsklassische Fabriken, da weder alt eingefahrene Strukturen noch vorhandeneMethoden und Werkzeuge eine optimale Auftragsabwicklung verhindern(REINHART U. A. 1996).

2.2 Unterschiede zu bekannten Organisationsformen

Das Konzept der virtuellen Fabrik ist weniger durch neue Elemente als durchdie Kombination bekannter Elemente charakterisiert (OLBRICH 1994). Einevirtuelle Fabrik ist eine von mehreren Organisationsformen, in der Unterneh-men zusammenarbeiten können.

Bekanntere Formen der Zusammenarbeit sind Konzerne, Joint Ventures, Kon-sortien und strategische Allianzen. Bei Konzernen, Joint Ventures und Konsor-tien handelt es sich um Kapital- oder Personengesellschaften, die auch nach

2 Die virtuelle Fabrik 9

außen als solche auftreten. Bei strategischen Allianzen gibt es im allgemeineneinen gemeinsamen Kooperationsvertrag, in dem die langfristige Zusammenar-beit auf einem bestimmten Geschäftsfeld vereinbart wird. Virtuelle Fabrikenhaben mit strategischen Allianzen nur gemeinsam, daß es keinen gemeinsamenOverhead gibt (MAYER 1998).

2.3 Erfolgsfaktoren

Für eine erfolgreiche Projektbearbeitung in einer virtuellen Fabrik sind be-stimmte Erfolgsfaktoren zu beachten. Folgende Voraussetzungen haben we-sentlichen Einfluß auf den tatsächlichen wirtschaftlichen Nutzen:

- Vertrauen: Bei virtuellen Fabriken werden vertrauliche Informationen derbeteiligten Unternehmen preisgegeben, und wegen des Zeitdrucks wird oftauf umfangreiche Absicherungen verzichtet (KONRADT 1999). Daher sindvertrauensbildende Maßnahmen sowie eine offene Unternehmenskulturzwischen den beteiligten Partnern unerläßlich für den Erfolg (SCHUH U. A.1998).

- "Fit für die Kooperation": Die Partner müssen strategisch, organisatorisch,unternehmenskulturell sowie informationstechnisch zueinander passen undfür Kooperationen ausgerichtet sein (RUDORFER 1998).

- Moderne I&K-Technologien1: Um den Wettbewerb mit Großunternehmenaufnehmen zu können, müssen KMUs2 so eng kooperieren, daß sie in derAbwicklung ihrer Projekte wie ein Unternehmen wirken. Eine wichtigeVoraussetzung dafür ist eine enge informationstechnische Anbindung alleram Projekt beteiligten Unternehmen, um dem erhöhten Informations- undKommunikationsbedarf gerecht zu werden (GOLDMAN U. A. 1994).

- Qualifizierte und eigenverantwortlich handelnde Mitarbeiter: In virtuellenFabriken vollziehen sich die Arbeitsabläufe anders als in den klassischenOrganisationsformen. Das kann zu einer völlig neuen Arbeitsweise führen,

1 I&K-Technologien – Informations- und Kommunikationstechnologien

2 KMU – kleine und mittlere Unternehmen

10 2.4 Praxisbeispiele

bei der der Mensch im Mittelpunkt steht (MALONE & LAUBACHER 1999).Durch die konsequente Prozeßorientierung von virtuellen Fabriken muß beiden Mitarbeitern das Bewußtsein für Prozesse geschaffen werden. Sie müs-sen eigenverantwortlich in Prozessen denken, planen und handeln. Das Wis-sen und die Erfahrung der Mitarbeiter kann bis heute in vielen Bereichendurch keine Systeme auch nur annähernd ersetzt werden. Jegliche Versuchediesbezüglich blieben weit hinter den Erwartungen zurück (FUCHS 1995).Die Mitarbeiter stellen somit eine tragende Säule in der virtuellen Fabrik darund beeinflussen die Effizienz dieser Organisationsform maßgeblich.

2.4 Praxisbeispiele

In den letzten Jahren wurden vermehrt virtuelle Organisationen aufgebaut. EineTypologie bekannter virtueller Organisationsformen sind in MILLARG (1998) zufinden. Einige typische und auch bekannte Netzwerke aus der Produktionstech-nik, für die das im Rahmen der Arbeit entwickelte Konzept geeignet erscheint,werden im folgenden vorgestellt.

REINHART & SCHLIFFENBACHER (1997) beschreiben ein virtuelles Basisnetz-werk, den sogenannten Virtuellen Markt3, in dem sich 14 Unternehmen aus derProduktionstechnik mit komplementären und auch konkurrierenden Kompeten-zen zusammengeschlossen haben, um am Markt gemeinsam aufzutreten. Re-gelmäßige Besuche bei den Partnerfirmen schaffen ein Vertrauensverhältnis imNetzwerk. Weiterhin lernen die Mitglieder auf diese Art und Weise die Mög-lichkeiten und Grenzen der Partnerfirmen kennen. Das ist vor allem deshalbnotwendig, da im Netzwerk mehrere innovative Technologien wie beispiels-weise Rapid Prototyping und die Finite Elemente Methode vorhanden sind.Diese können von den Partnerunternehmen nur dann effizient eingesetzt wer-den, wenn ein bestimmtes Grundverständnis über die Technologien vorhandenist. Erhält der Virtuelle Markt einen Auftrag, wird von mehreren Unternehmenim Netzwerk eine virtuelle Fabrik aufgebaut, die den Auftrag abwickelt. DieAuswahl von Unternehmen für die virtuelle Fabrik erfolgt nach marktwirt-schaftlichen Prinzipien durch den Einsatz moderner I&K-Technologien

3 im Internet zu finden unter www.virtueller-markt.de, Stand Juli 1999


(MEHLER & REINHART 1998). Für die anschließende Projektabwicklung wer-den konventionelle Tools eingesetzt. Die mit dem Netzwerk angestrebten Zielesind schnelle Zugriffsmöglichkeiten auf innovative Technologien und die ge-meinsame Abwicklung von umfangreichen Aufträgen. Weiterhin soll die Kapa-zitätsauslastung bei den Mitgliedsunternehmen durch zusätzliche Aufträge er-höht werden.

SCHUH U. A. (1997) stellen den Unternehmensverbund Virtuelle Fabrik Euregio

Bodensee4 vor, in dem ca. 20 Unternehmen ähnlich dem Virtuellen Markt mitkomplementären und konkurrierenden Kompetenzen zusammengeschlossensind. Der Unterschied zum Virtuellen Markt liegt im wesentlichen darin, daß inder Virtuellen Fabrik Euregio Bodensee ein Broker-Konzept eingesetzt wird,wo ein sogenannter Broker die Vermarktung des Netzwerks übernimmt. DieWeiterentwicklungen im Netzwerk konzentrieren sich auf Fragestellungen derOrganisationsform und des Marketings. MILLARG (1999) sieht die Vorteile die-ses Unternehmensverbundes vor allem in einem steigenden Auftragseingangund in der Möglichkeit, größere Projekte gemeinsam abwickeln zu können.

Ein Kooperationsnetzwerk in der Kfz-Zulieferindustrie wird von MAYER

(1998) vorgestellt. Sechs Unternehmen haben sich zu einem Kooperations-netzwerk zusammengeschlossen, um projektspezifisch die optimale Wertschöp-fungskette für den Kunden zu konfigurieren. Seit dem Bestehen des Netzwerkskonnten die Produktentstehung beschleunigt, die Reaktionszeit auf Kunden-wünsche verkürzt, die Qualität verbessert sowie die Anzahl der Änderungenreduziert werden. Das Potential für die Zukunft sieht MAYER vor allem in einerunternehmensübergreifenden Informationsbasis für gemeinsame Produktent-stehungsprojekte und Produktionsprozesse, die von allen Partnern mit Projekt-und Prozeßinformationen gefüllt wird und aus der alle Projektbeteiligten Datenanfragen können.

BRANDNER (1998A) stellt ein Unternehmensnetzwerk vor, in dem die Kompe-tenzen der einzelnen Partnerfirmen deutlich fokussierter sind, als in den bisherbeschriebenen Netzwerken: Das Rapid Prototyping Netzwerk RP-Net.de5. In

4 im Internet zu finden unter www.virtuelle-fabrik.org, Stand Juli 1999

5 im Internet zu finden unter www.rp-net.de, Stand Juli 1999

12 2.5 Defizite in der Projektabwicklung

diesem Netzwerk sind 27 Dienstleister mit der Kernkompetenz Rapid Prototy-ping / Rapid Tooling (RP/RT) oder mit ergänzenden Kompetenzen zusammen-geschlossen. Das Netzwerk kann dem Kunden gegenüber ein umfassendesLeistungsspektrum im Modell- und Prototypenbau mit innovativen Fertigungs-technologien anbieten. Ein auf Internet-Technologien basierendes Anfrage- undAngebotssystem sorgt dafür, daß der Kunde schnell die für seine jeweiligeAufgabenstellung am besten geeigneten Dienstleister findet. Der Auftrag wirddann entweder von einem Unternehmen alleine bearbeitet, oder mehrere Unter-nehmen bilden zusammen eine virtuelle Fabrik und wickeln den Auftrag ge-meinsam ab. Bei der Auftragsabwicklung werden außer E-Mail keine speziellenSoftwareprodukte eingesetzt. Das Ziel dieses Netzwerks ist es, Kunden durchdie Kompetenzbündelung und das internetbasierte Anfragewesen den Zugangzu den Fertigungstechnologien im Netzwerk deutlich zu vereinfachen. DieDienstleister im Netzwerk streben durch die Organisationsform einen steigen-den Auftragseingang und die Gewinnung von Großkunden an.

In allen vorgestellten Praxisbeispielen werden für die Projektabwicklung nochkeine speziell für Unternehmensnetzwerke oder virtuelle Fabriken entwickeltenSoftwaretools eingesetzt. Die Bildung von projektspezifischen virtuellen Fabri-ken führt deshalb zu Reibungsverlusten in der Projektabwicklung, die im fol-genden erläutert werden.

2.5 Defizite in der Projektabwicklung

Reibungsverluste in der Projektplanung und -abwicklung bedeuten Zusatzauf-wand und führen häufig zu Projektverzögerungen und Mehrkosten. NachWHEELWRIGHT & CLARK (1994) wird die Projektplanung und -abwicklung indrei Ebenen unterschieden (Bild 2-1). Auf der strategischen Ebene wird zu-nächst die Entwicklungsstrategie auf die Unternehmensziele abgestimmt. Aufder taktischen Ebene erfolgt anschließend eine detaillierte Planung. Hier stehtu. a. die Termin- und Ressourcenplanung im Vordergrund. Es wird entschieden,welches Produkt wann und unter Teilnahme welcher funktionalen Bereiche ab-gewickelt werden soll. In der operationalen Ebene findet schließlich die Pro-jektabwicklung statt. Gründe für die Reibungsverluste in virtuellen Fabrikensind hauptsächlich in der taktischen und der operationalen Ebene zu finden.


Strategische Ebene

TaktischeEbene

Operationale Ebene

Festlegen von Zielen

Erstellen desProjektplans

Projekt-durchführung

Bild 2-1: Ebenen in der Projektplanung und -abwicklung (in Anlehnung an

WHEELWRIGHT & CLARK 1994)

In der taktischen Ebene ist die mangelnde Übersicht über den Projektverlauf zunennen. Die Unternehmen wissen i. d. R. über den Stand Ihrer Teilprojekte Be-scheid. Dieser ist auch in den Planungssystemen der Unternehmen abgebildet.Da die Projektpartner aber zum einen unterschiedliche Softwarewerkzeuge ein-setzen und zum anderen nicht gegenseitig auf Projektpläne zugreifen können,können diese Informationen nicht unternehmensübergreifend in einem Gesamt-projektplan ausgewertet werden. Die Folge ist, daß Verzögerungen in Teilpro-jekten oft zu spät erkannt werden.

Neben diesem Defizit in der taktischen Ebene sind vor allem in der operationa-len Ebene, also in der Projektdurchführung, Gründe für Reibungsverluste vor-zufinden. Im Projektverlauf werden große Mengen an Daten erzeugt, geändertund weiterverarbeitet. Die Notwendigkeit der Nutzung von innovativen Tech-nologien führt zum Einsatz komplexer Systeme, was wiederum zu einem An-wachsen der Datenmenge und vor allem auch zu einer steigenden Komplexitätder Datenstrukturen führt. GAITANIDES U. A. (1994, S. 25) beschreiben die ne-gativen Folgen dieser Entwicklung folgendermaßen:

"Den größten Teil ihrer Zeit verbringen Mitarbeiter damit, Fehler zu korrigie-

ren, die nicht einmal von ihnen selbst verursacht worden sind. Der Aufwand

besteht z. B. darin, Unklarheiten in den zu bearbeitenden Vorlagen zu beseiti-

gen, fehlende Informationen zu beschaffen oder spezifisch formulierte Ansprü-

che und Wünsche in das standardisierte DV-System einzubinden."

14 2.5 Defizite in der Projektabwicklung

In Unternehmenskooperationen wird dieses Defizit verstärkt. Die geographi-sche Trennung sowie heterogene I&K-Technologien und Organisationen führendazu, daß Informationen in unterschiedlichen Formaten und an unterschiedli-chen Orten gespeichert werden. Dadurch wird der Zugriff auf Informationen,die nicht im eigenen Unternehmen verwaltet werden, erschwert und es entstehteine unkontrollierte Datenredundanz. Doppelarbeit beim Einbringen von Ände-rungen ist die Folge (GOLDMAN U. A. 1996).

Mangelnde Transparenz überdie im Gesamtprojekt

fließenden Informationen

Mangelnde Übersicht über

den Projektverlauf

Frühes Einbringen von Know-How der Projektbearbeiter nur

schwer möglich

Ineffiziente Verwaltung und

aufwendiger Austausch vonProduktdaten

Defizite in der

Projektabwicklung

Bild 2-2: Defizite in der Projektabwicklung in virtuellen Fabriken

Weiterhin ist der Informationsfluß im Projekt oft intransparent. Die Projektbe-teiligten haben keinen Überblick darüber, mit welchen SoftwarewerkzeugenDaten in anderen Organisationseinheiten der virtuellen Fabrik weiterbearbeitetwerden müssen. Die Bearbeiter berücksichtigen bei ihrer Tätigkeit kaum da-tentechnische Anforderungen von nachgelagerten Bereichen. Daten werdendeshalb regelmäßig in einem unbrauchbaren Format weitergegeben und müssenmit viel Doppelarbeit neu erzeugt werden (BRANDNER 1997).


MAYER (1998) nennt als eine wesentliche Herausforderung in virtuellen Fabri-ken das Einbringen des Know-hows der einzelnen Kooperationspartner. Durchdie Aufteilung der Wertschöpfungsketten auf mehrere Unternehmen, ist auchdas Know-how über die einzelnen Tätigkeiten auf mehrere Unternehmen ver-teilt. Es reicht in komplexen Projekten allerdings nicht aus, wenn das Know-how der Projektbearbeiter nur in ihre jeweils eigenen Aktivitäten und Teilpro-jekte einfließt. Das Detail-Know-how aller Projektmitarbeiter muß frühzeitig indie Gestaltung des Produkts, der Produktionsmittel und des Produktionsprozes-ses eingebracht werden und bestimmt damit maßgeblich den Projektpla-nungsprozeß mit. Bild 2-2 faßt die beschriebenen Defizite zusammen.

2.6 Zusammenfassung

Virtuelle Fabriken stellen eine neue Organisationsform dar, mit der vor allemkleinen und mittleren Unternehmen aus der Produktionstechnik neue Potentialeeröffnet werden. Ausgangsbasis für die Bildung von virtuellen Fabriken ist inden meisten Fällen ein Basisnetzwerk. Sobald ein konkreter Auftrag vorliegt,bildet sich aus dem Basisnetzwerk eine geeignete Wertschöpfungskette in Formeiner virtuellen Fabrik.

Diese Organisationsform ist weniger durch neue Elemente als durch die Kom-bination bekannter Elemente charakterisiert. Erfolgsfaktoren sind Vertrauen,"Fit für die Kooperation", qualifizierte und eigenverantwortlich handelnde Mit-arbeiter sowie moderne I&K-Technologien.

Aus der Praxis sind unterschiedliche Ausprägungen der virtuellen Fabrik be-kannt. Während bei einigen Beispielen bereits spezielle Softwaresysteme fürden Aufbau von Kooperationen eingesetzt werden, werden bei anderen Bei-spielen außer E-Mail keine speziellen I&K-Technologien genutzt. Die Vertei-lung der Wertschöpfungskette auf mehrere Unternehmen führt somit zu Rei-bungsverlusten in der Projektabwicklung.

Diese Reibungsverluste stehen den Chancen und Möglichkeiten von virtuellenFabriken gegenüber. Um die Organisationsform langfristig tragfähig zu ma-chen, ist deshalb ein effizientes Produktdaten- und Prozeßmanagement zu in-stallieren.

16 2.6 Zusammenfassung

3 Produktdaten- und Prozeßmanagement –

Stand der Technik

In diesem Kapitel werden Methoden und Werkzeuge vorgestellt, die typischer-weise in der Projektplanung und -abwicklung eingesetzt werden. Es wird über-prüft, inwieweit die verfügbaren Ansätze die in Abschnitt 2.5 identifiziertenDefizite bei der Projektabwicklung in virtuellen Fabriken beheben können. AmEnde des Kapitels werden die Möglichkeiten und Grenzen aller vorgestelltenAnsätze zusammengefaßt. Darauf aufbauend wird der Handlungsbedarf abge-leitet.

3.1 Übersicht

In Bild 3-1 sind die unterschiedlichen Methoden und Werkzeuge positioniert,die in der Projektplanung und -abwicklung eingesetzt werden.

Einen sehr verbreiteten Ansatz stellt das Projektmanagement dar. Mit Hilfe vonBalkenplänen und Netzplänen werden Inhalte, Termine und Kosten des Pro-jekts grob geplant.

Für die Feinplanung existieren unterschiedliche Methoden und Werkzeuge desGeschäftsprozeßmanagements. Mit diesen Ansätzen können operative Tätig-keiten modelliert, optimiert und verteilt werden. Weiterhin unterstützen sie dietransparente Darstellung von Informationsflüssen. Im Rahmen dieser Arbeitwerden die Ansätze des Projektmanagements und des Geschäftsprozeßmana-gements unter dem Begriff Prozeßmanagement zusammengefaßt. Dadurch sollauch der ähnliche Charakter der beiden Ansätze widergespiegelt werden.

Letztendlich werden für die strukturierte Verwaltung von Produktdaten undDokumenten sogenannte Produktdatenmanagementsysteme eingesetzt. DieseSysteme unterstützen auch standardisierte Geschäftsprozesse, beispielsweise imÄnderungs- und Freigabewesen.

18 3.2 Projektmanagement

ProzeßmanagementProzeßmanagement

Methoden

Inhalte

DV-Konzepte

Geschäftsprozeß-management

Produktdaten-management

BalkenplanNetzplan

InformationsflußTätigkeitsliste

KlassifikationZugriffspfad

Aufgabe wird grob für Gruppe

definiert.

Aufgabe wird detailiert

für Bearbeiter definiert.

StrukturierteVerwaltung

von Produkt-daten und

Dokumenten.

PM-Tool GPM-ToolWFM-System

PDM-System

PM - ProjektmanagementGPM - GeschäftsprozeßmanagementWFM - WorkflowmanagementPDM - Produktdatenmanagement

Projekt-management

Bild 3-1: Positionierung verfügbarer Lösungsansätze

3.2 Projektmanagement

3.2.1 Begriffsdefinition und Entwicklung

Nach DAENZER & HUBER (1994) ist das Projektmanagement "die Gesamtheit

aller planenden, überwachenden, koordinierenden und steuernden Maßnah-

men, die bei einer Neugestaltung von Systemen notwendig sind."

3 Produktdaten- und Prozeßmanagement – Stand der Technik 19

In der Vergangenheit ist oft der Eindruck entstanden, Projektmanagement istaufwendig und kompliziert und für Kleinvorhaben deshalb nicht anwendbar.Dies trifft jedoch nicht zu. Es ist allerdings schwierig, neuzeitliche Methoden,die meist im Zusammenhang mit Großprojekten entwickelt wurden, im richti-gen Maße auf kleine und mittelgroße Projekte zu übertragen. Deshalb wurdendie vorhandenen Methoden teilweise bereits deutlich vereinfacht. Für das mo-

derne Projektmanagement gilt der Grundsatz, daß auch komplizierte Zusam-menhänge nicht unnötig kompliziert, sondern so einfach wie möglich darge-stellt und beschrieben werden (KRAUS & WESTERMANN 1995).

Einmaligkeit

Zeitliche Befristung

Eindeutige Aufgabenstellung

Komplexität

Interdisziplinärer Charakter

Relative Neuartigkeit

Projektspezifische Organisation

Beteiligung vieler Organisationseinheiten

Größe

Unsicherheit und Risiko

Dynamik

Bild 3-2: Merkmale von Projekten (nach MADAUSS 1994)

Betrachtet man die Projektmerkmale, die MADAUSS (1994) im Rahmen einerLiteraturanalyse zusammengestellt hat (Bild 3-2), so sind große Ähnlichkeitenzu den Merkmalen von virtuellen Fabriken festzustellen: Eine virtuelle Fabrikwird gebildet, wenn eine eindeutige Aufgabenstellung vorliegt. Sie ist in ihrerZusammensetzung einmalig, zeitlich befristet und wird wieder aufgelöst, sobald


der Auftrag abgewickelt ist. Die Beteiligung von mehreren Organisationsein-

heiten und der interdisziplinäre Charakter durch den Einsatz innovativer Tech-nologien erhöhen die Komplexität. Die Aufgabenstellung ist zu umfangreich fürein einzelnes Unternehmen. Unsicherheit und Risiko werden in virtuellen Fab-riken gemeinsam von den beteiligten Partnern getragen. Die relative Neuartig-

keit und Dynamik erfordern eine projektspezifische Organisation.

Die effiziente Abwicklung eines Projekts setzt eine klare und eindeutige Zielde-finition, eine gründliche Ablaufplanung sowie die Anwendung wirkungsvollerSteuerungsverfahren voraus. Nur so läßt sich zwischen den Projektanforderun-gen und den zur Verfügung stehenden Investitionsmitteln ein Gleichgewichtherstellen. Die Durchführung eines Projekts ist also von vornherein mit großenRisiken behaftet, da niemand in der Lage ist, das gewünschte Ergebnis imRahmen eines festgesetzten finanziellen und terminlichen Limits zu garantie-ren. Eine gründliche Planung und Überwachung sind für die Risikoeindäm-mung von äußerster Wichtigkeit (WISCHNEWSKI 1992). Um den richtigen Wegeinschlagen zu können, muß der Ablauf eines Projekts, der Lebenszyklus, genaubekannt sein.

Der Lebenszyklus eines Projekts im Bereich der ProduktionstechnikTrotz der Tatsache, daß kein Projekt dem anderen gleicht, ist ein bestimmterähnlicher Lebenszyklus in Projekten zu beobachten, der in Bild 3-3 dargestelltist. Nicht immer ist ein Unternehmen jedoch für alle Projektphasen zuständig."Forschung und Entwicklung" werden oft von anderen Unternehmen durchge-führt als die "Produktion und Beschaffung". Weiterhin sind auch Aufteilungeninnerhalb der Phasen denkbar.


Lebenszyklus eines Projektes

Konzeptformulierung

Projekt-/Systemdefinition

Forschung und Entwicklung

Produktion und Beschaffung

Betrieb und Wartung

Aussonderung

Bild 3-3: Lebenszyklus eines Projekts im Bereich der Produktionstechnik (in

Anlehnung an MADAUSS 1994)

In der Konzeptformulierung werden Systemkonzepte untersucht sowie dieMöglichkeiten zur Machbarkeit und Erfüllung der Kundenwünsche analysiert.Gleichzeitig werden Zeit- und Kostenpläne sowie Managementkonzepte er-stellt. Diese Phase endet in der Regel mit einem Abschlußbericht, bestehendaus der Systemspezifikation sowie vorläufigen Ablauf- und Kostenplänen unddient der Vorbereitung für die Projektdefinition.

In der Phase der Projektdefinition wird das Projekt technisch gegliedert, defi-niert und detailliert geplant. Baugruppen werden genauer beschrieben und Ent-wicklungsmaßnahmen vorgeplant. Weiterhin werden in dieser Phase kompe-tente Entwicklungspartner und Lieferantenfirmen identifiziert und in die Pla-nung mit einbezogen. Am Ende dieser Phase liegen Planungsunterlagen mitverbindlichen Termin- und Kostenplänen vor.


Im Gegensatz zu den vorhergegangen Phasen handelt es sich bei den PhasenForschung und Entwicklung sowie Produktion und Beschaffung um hardware-orientierte Phasen. Das Ziel ist die spezifikationsgerechte Erstellung eines Pro-dukts im Rahmen vorgegebener Termin- und Kostengrenzen. In dieser Phasemüssen Konstruktions- und Entwicklungstätigkeiten durchgeführt werden undaufbauend darauf Prototypen und letztendlich das Endprodukt hergestellt wer-den. Diese Phase endet mit der Übergabe des funktionsfähigen Endproduktszum vereinbarten Termin.

Der Lebenszyklus wird weitergeführt mit der Phase Betrieb und Wartung undletztendlich mit der Aussonderung des Produkts abgeschlossen.

Die einzelnen Phasen sind durch entsprechende Abschluß-Meilensteine exaktbegrenzt. In der Praxis laufen die einzelnen Phasen allerdings regelmäßig in-einander über, was zu Phasenüberlappungen führt (LINDEMANN &KLEEDÖRFER 1997). Diese Phasenüberlappungen werden beispielsweise beimSimultaneous Engineering bewußt herbeigeführt.

Konzept des Simultaneous EngineeringDas Simultaneous Engineering ist ein Konzept zur prozeßorientierten Integrati-on der Aufgaben in eine Organisationseinheit. Durch die Bildung von Teamswird ein ganzheitlicher Arbeitsansatz gewählt, um möglichst frühzeitigen In-formationsaustausch zu gewährleisten. Dadurch wird die vormals sequentielle,funktionsorientierte Vorgehensweise durch eine eng miteinander vernetzte pa-rallele Entwicklung ersetzt. Da die Entwicklungsdauer durch die Parallelisie-rung abnimmt, steigt die Kommunikation pro Zeiteinheit stark an. SowohlKenntnisse und Fähigkeiten der Mitarbeiter als auch Methoden und Werkzeugemüssen auf diese Problematik hin ausgerichtet werden (EHRLENSPIEL 1995).

Nach der Beschreibung der Grundlagen des Projektmanagements werden imfolgenden Abschnitt Methoden und Werkzeuge vorgestellt.


3.2.2 Methoden und Werkzeuge zum Projektmanagement

3.2.2.1 Grundlegende Methoden zur Projektplanung und

-überwachung

Die Planung eines Projekts ist der erste Schritt zur Projektsteuerung. Planungist eine Projektion in die Zukunft und sie ist deshalb mit den Mängeln, die einePrognose üblicherweise aufweist, belastet. Sie bedarf deshalb einer ständigenIteration durch Hinzufügen neuer Erkenntnisse, die über den Überwa-chungsprozeß eingebracht werden. Die Projektüberwachung besteht nachMADAUSS (1994) aus den Schritten

1. Erfassen der aktuellen Daten,

2. Vergleich dieser Daten mit der Planungsbasis und

3. Festlegung von Schlußfolgerungen.

Planung und Überwachung nehmen im Projektmanagement eine Schlüsselrolleein. In den vergangenen Jahren wurde deshalb eine Vielzahl von Planungsin-strumenten entwickelt.

Konzept-Phase Definitions-Phase Entwicklungs-Phase

PSP

AP‘sPSP - ProjektstrukturplanAP - Arbeitspaket

Bild 3-4: Projektstrukturplan (PSP) nach KERZNER & THAMHAIN (1986)


Eines der wenigen Instrumente, das sich durchgesetzt hat, ist der Projektstruk-

turplan (PSP), der in Bild 3-4 dargestellt ist. Beim Projektstrukturplan werdengroße und komplexe Projekte in einzelne Phasen, Segmente, Baugruppen,Funktionen, Arbeitspakete usw. gegliedert. Den einzelnen Projektelementenwerden anschließend Firmen oder Bearbeiter zugeordnet. Dadurch soll die not-wendige Transparenz geschaffen werden, um die Planung und Ablaufkontrollesicherzustellen.

Vorgang 1

Vorgang 6

Vorgang 5

Woche 1 Woche 6Woche 5Woche 4Woche 3Woche 2

Vorgang 4

Vorgang 3

Vorgang 2

geplanter Zeitraum

Meilenstein

tatsächlicher Zeitraum

Bild 3-5: Balkenplan mit Meilensteinen

Als weitere Projektplanungsmethode hat sich die Termin- und Ablaufplanung

durchgesetzt. In ihr sind die zeitlich aufeinander abgestimmten Einzeltätigkei-ten übersichtlich und kontrollfähig zusammengefaßt. Die Erstellung der Ter-min- und Ablaufpläne erfolgt in enger Anbindung an den Projektstrukturplan.


Wie beim Projektstrukturplan ist auch der Detaillierungsgrad der Planungsun-terlagen in den Frühphasen des Projekts langsam zu erhöhen, so daß am Endeder Definitionsphase eine komplette und detaillierte Planung vorliegt(KERZNER & THAMHAIN 1986).

Das am meisten verbreitete Instrument der Termin- und Ablaufplanung ist derBalkenplan (Bild 3-5). Der Balkenplan kann ohne Vorkenntnisse verstandenwerden und erfährt dadurch eine besonders große Akzeptanz. Durch die Er-weiterung mit Meilensteinen können auch Zwischenergebnisse überprüft wer-den (PLATZ 1995).

Im Balkenplan fehlt allerdings die Ablauflogik. Abhängigkeiten zwischen deneinzelnen Vorgängen werden nicht ausreichend berücksichtigt. Hier bietet derNetzplan deutlich bessere Möglichkeiten. Netzpläne können nach den Verfah-ren

- Critical Path Method (CPM, Bild 3-6),

- Programm Evaluation and Review Technique (PERT) und der

- Metra-Potential-Methode (MPM)

erstellt werden.

Vorgang C

Vorgang DVorgang A

1 4 Tage30.11. 03.12.

Vorgang B

2 3 Tage04.12. 08.12.

3 4 Tage04.12. 09.12.

4 3 Tage10.12. 14.12.

Bild 3-6: Netzplandiagramm (CPM – Critical Path Method)

Grundlage ist bei allen Verfahren die Verknüpfung einzelner Prozeßelemente(Aktivitäten oder Meilensteine) mit Hilfe strenger zeitlicher Abhängigkeitsbe-


ziehungen (vgl. DIN 69900). Inhaltliche Beziehungen werden nicht betrachtet.Diese Systematik eignet sich gut zum einmaligen Modellieren eines Idealab-laufs. Durch die Definition der Abhängigkeitsbeziehungen erhält man eine au-tomatische Terminierung der Vorgänge. Die Qualität der Terminierung hängtdabei stark von der Vollständigkeit des Prozeßmodells ab (GROH & GUTSCH

1982).

Die Netzplantechnik hat den Vorteil, daß alle am Projekt Beteiligten den Pro-jektverlauf genau durchdenken und frühzeitig Absprachen und Entscheidungentreffen müssen. Dies ist besonders dann von Bedeutung, wenn verschiedeneFirmen oder Abteilungen einer Firma zusammenarbeiten. Der Netzplan ver-mittelt in der graphischen Darstellung eine ausgezeichnete Übersicht über dasProjekt, was die Kontrolle über die Vollständigkeit der Planung erleichtert.(REICHERT 1994)

3.2.2.2 Funktionsumfang verfügbarer Projektmanagementsysteme

Im folgenden wird der Funktionsumfang moderner Projektmanagementsystemevorgestellt. In MAN (1999) sind 45 Projektmanagementsysteme untersucht undausführlich bewertet. Danach weisen die Systeme typischerweise folgendeFunktionen auf:

- Projektplanung in Balkenplan- und Netzplantechnik: Diese Basisfunktionenwerden von allen Systemen unterstützt.

- Ressourcen-, Bedarfs- und Kapazitätsmanagement: Ein Schwerpunkt vielerSysteme liegt auf dem Ressourcen-, Bedarfs- und Kapazitätsmanagement.Auslastungen und Verfügbarkeiten können nach unterschiedlichen Kriterienausgewertet und übersichtlich grafisch dargestellt werden. Zeiten werdendetailliert erfaßt und verarbeitet.

- Kostenmanagement: Die meisten Systeme verfügen über flexible Mecha-nismen zur Kostenübersicht, Kostenschätzung und Budgetkontrolle.

- Szenarien: What-If-Szenarien können erzeugt, eingesehen und in die tat-sächliche Planung integriert werden.


- Datenaustausch: Über ein Data-Exchange-Modul können Daten mit ande-ren Projektmanagementsystemen ausgetauscht werden.

Einige Systeme setzen vermehrt Internet-Technologien ein und unterstützendadurch den standortübergreifenden Einsatz:

- Projektverfolgung: Web-basierte Time-Reporting-Module ermöglichen einedetaillierte Projektverfolgung. Rückgemeldete Daten können konsolidiertund dann integriert werden. Unterschiedliche Optimierungsverfahren unter-stützen hierbei den Projektmanager.

- Berichtsgenerator und Präsentationsgrafik: Pläne können durch Bilder undCharts präsentationsgerecht aufbereitet werden. Es ist auch möglich, Pläneim WWW6 zu veröffentlichen oder in Text-, Tabellen- und Präsentations-dateien einzubetten.

- Kommunizieren via E-Mail: Zur Verteilung von Informationen im eigenenNetz oder weltweit, werden elektronische Mail-Systeme unterstützt. E-Mail-Adressen können im Projekt verwaltet werden und frei gestaltbare Rück-meldeformulare dadurch automatisch an die betreffenden Mitarbeiter ver-teilt werden.

- Multiuser-Projektmanagement im Internet: Alle Projekte und alle Ressour-cen sind in einer Datenbank lokalisiert. Das ermöglicht eine projektüber-greifende Planung, Auswertung und Übersicht von beliebig verteilten Ar-beitsplätzen aus. Außerdem ist ein verteiltes Bearbeiten bei großen Projek-ten auf verschiedenen Rechnern möglich. Mittels der Unterplantechnikwerden Planstrukturen in separaten Dateien zur lokalen Weiterbearbeitunggespeichert und danach wieder ins Ursprungsprojekt eingelesen.

Die Internet-Technologie hat zwar bei den kommerziellen Projektmanagement-systemen dazu geführt, daß geographisch verteilte Projektteams besser unter-stützt werden, allerdings wird das Projektmanagement nach wie vor losgelöstvon dem Informationsfluß betrachtet, der auf der operationalen Ebene stattfin-det. Das Defizit der mangelnden Transparenz über die im Gesamtprojekt flie-ßenden Informationen kann deshalb mit kommerziellen Systemen nicht besei-

6 WWW – World Wide Web


tigt werden. In der Forschung sind allerdings Ansätze bekannt, die bei der Pro-jektplanung den Informationsfluß berücksichtigen.

3.2.2.3 Projektmanagementsysteme in der Forschung

Der Bedarf der Planung des Informationsflusses wurde bereits vor einigen Jah-ren u. a. von SCHMALZL (1996) und KLEEDÖRFER (1998) erkannt.

Auftrags-bearbeitung












Aus-/Ein-gangsinfo

Aus-/Ein-gangsinfo

Aus-/Ein-gangsinfo

Aus-/Ein-gangsinfo

Aus-/Ein-gangsinfo

Aus-/Ein-gangsinfo

Netzplan erweiterter Netzplan

Bild 3-7: Vom Netzplan zum erweiterten Netzplan (SCHMALZL 1996)

SCHMALZL hat den Netzplan um ein Informationssymbol als Schnittstelle zwi-schen zwei Vorgängen ergänzt. Damit liegt ein erweiterter Netzplan vor, mitdem abgebildet werden kann, welches Arbeitsergebnis von einem vorgelagertenVorgang erwartet wird (Bild 3-7). SCHMALZL konzentriert sich hierbei auf dieKonzeption und Entwicklung eines Projektleitsystems und der darin verarbeit-


baren Informationen im integrierten Produkterstellungsprozeß. Unternehmens-übergreifende Aspekte und die Integration der Prozesse mit den Produktdatenwerden nicht behandelt. Der Informationsfluß kann deshalb nicht in der gefor-derten Form modelliert werden. Für die Projektplanung und -abwicklung invirtuellen Fabriken ist der Ansatz in der vorgestellten Form deshalb nicht aus-reichend.

Zeitpunkt des Informationsbedarfs

Zeitpunkt der Informationserzeugung

Informationsfluß

t

Bild 3-8: Darstellung des Informationsflusses in einem Prozeßplan (nach

KLEEDÖRFER 1998)

KLEEDÖRFER (1998) stellt ein System der Produktentwicklung vor, das auf derModellstruktur der Systemtechnik beruht. Es dient als Gliederungshilfe für dieProduktentwicklung. Weiterhin kann es für die Beurteilung von Maßnahmenim Rahmen des Änderungsmanagements und dessen Auswirkungen herangezo-gen werden. KLEEDÖRFER hat ein dezentrales Prozeßmanagement entwickelt, indem sowohl eine taktische als auch operationale Phasen- und Strukturplanungrealisiert ist. Auf der Basis von Zielvorgaben einer strategischen Planung wer-den die verantwortlichen Entwickler in die Zieldefinition auf der operationalenEbene eingebunden. Unter Zuhilfenahme von Entwicklungshandbüchern undChecklisten zur Leistungsschnittstellenanalyse ist dadurch ein systematischerund effizienter Planungsprozeß für die Phasen- und Projektstruktur vorgegeben.Mit der entwickelten Methode können vernetzte und konsistente Prozeßpläne


aufgebaut werden. Dazu werden, auf der Basis eines Balkendiagramms zur Pla-nung der Aktivitäten, die Informationsflußbeziehungen zwischen den Organi-sationseinheiten und deren Vorgängen abgebildet (Bild 3-8). Durch die logischeVerknüpfung kann verhindert werden, daß im Falle einer Störung alle nachfol-genden Aktivitäten automatisch nach hinten verschoben werden.

Die Methode wurde in dem datenbankgestützten Rechnersystem GRIPS umge-setzt. Während der Durchführung von Produktentwicklungsprojekten dient derProzeßplan der Konflikterkennung, indem auf mögliche Defizite im Informati-onsfluß hingewiesen wird. Durch das Rechnerwerkzeug wird keine Simulationoder Berechnung des Prozesses durchgeführt, sondern allein der Abstimmungs-bedarf aufgezeigt, der erst durch eine direkte Kommunikation des Senders mitdem Empfänger der Information befriedigt werden kann.

Der Ansatz konzentriert sich auf das Prozeß- und Änderungsmanagement undberücksichtigt hier sowohl die taktische als auch die operationale Phasenpla-nung. Allerdings werden die Produktdaten, die in den Prozessen bearbeitet undweitergegeben werden, nicht näher betrachtet. Der Aspekt der Kooperationwird zwar angesprochen, allerdings geht der Autor von langfristigen, komple-xen Kooperationsbeziehungen aus, wie sie beispielsweise in der Automobilin-dustrie vorzufinden sind. Die besonderen Anforderungen von kurzfristigen dy-namischen Kooperationen in Unternehmensnetzwerken werden nicht berück-sichtigt. Die Projekttransparenz kann somit für langfristige Entwicklungs-kooperationen gesteigert werden, für virtuelle Fabriken bleiben allerdings dieProduktdatenverwaltung ineffizient und der unternehmensübergreifende Infor-mationsfluß intransparent.

3.2.3 Zusammenfassende Bewertung

Projekte sind nach der vorgestellten Definition durch ähnliche Merkmale ge-kennzeichnet wie virtuelle Fabriken, weshalb die Methoden des Projektmana-gements geeignet erscheinen, um Aufträge in virtuellen Fabriken abzuwickeln.Die grundlegenden Methoden, wie beispielsweise der Projektstrukturplan, dieBalkenplantechnik und die Netzplantechnik sind zwar prinzipiell geeignet, wei-sen aber aufgrund ihrer Starrheit Einschränkungen beim Einbringen von Ände-rungen auf. Kommerziell verfügbare Systeme nutzen diese grundlegendenMethoden und wurden in den letzten Jahren um Web-Funktionen erweitert.


Allerdings kann mit den Systemen keine Transparenz über die im Gesamtpro-jekt fließenden Informationen erreicht werden.

Die Ansätze in der Forschung lösen das Problem der starren Netzplantechnikdadurch, daß Verknüpfungen zwischen Prozessen nicht durch strenge zeitlicheAbhängigkeiten, sondern durch inhaltliche Verbindungen hergestellt werden.Allerdings werden die Inhalte nur verbal beschrieben und es wird keine logi-sche Verknüpfung zu den Produktdaten hergestellt. Dadurch kann der unter-nehmensübergreifende Fluß der Produktdaten nicht geplant und transparentgestaltet werden. Vor allem aber sind die verfügbaren Ansätze nicht für ständigneue Unternehmenskonstellationen in virtuellen Fabriken geeignet.

3.3 Geschäftsprozeßmanagement

Während beim Projektmanagement nur grob festgelegt wird, wer wann was mitwelchen Mitteln bis zu welchem Termin durchzuführen hat, werden beim Ge-schäftsprozeßmanagement die Planung konkretisiert und vor allem auch derInformationsfluß berücksichtigt.


Das Geschäftsprozeßmanagement entwickelte sich auf Basis der Erkenntnis,daß alle Aktivitäten der wertschöpfenden Kette, die untereinander verknüpftsind und aufeinander einwirken, auch ein Endprodukt liefern. So werden inFertigungsprozessen materielle Ergebnisse erzeugt, während in indirekten oderVerwaltungsbereichen die Ergebnisse in Form einer Dienstleistung bestehen.Neu ist dabei die Betrachtung der innerbetrieblichen Leistungsverflechtung –also der Input-Output-Verknüpfungen der Prozesse als ein Netzwerk zur Er-stellung von Dienstleistungen. Diese Perspektive steht im Mittelpunkt des Ge-schäftsprozeßmanagements (GAITANIDES U. A. 1994). Das Geschäftsprozeßma-nagement basiert somit auf der Idee der Prozeßorientierung, also in der Struktu-rierung der betrieblichen Abläufe nach dem Flußprinzip.

SCHEER (1995) beschreibt einen Geschäftsprozeß als eine Menge von Aktivi-täten, die

32 3.3 Geschäftsprozeßmanagement

- eine konkrete räumliche und zeitliche Struktur besitzen,

- die Bereitstellung eines bestimmten Produkts durch die Transformation vonObjekten über unterschiedliche Zwischenzustände in den geforderten End-zustand beinhalten,

- auf das Ziel der Wertschöpfung ausgerichtet sind und

- durch das organisierte Zusammenwirken von Menschen, Betriebsmitteln,Material, Energie und Information gekennzeichnet sind.

Jede Beziehung zwischen einzelnen Prozeßschritten kann als Kunden-Lieferan-ten-Beziehung charakterisiert werden. Jede Aktivität hat mindestens einenKunden, der eine Leistung nachfragt. Die Kunden-Lieferanten-Beziehungenhaben maßgeblichen Einfluß auf die gesamte Prozeßkette. (SCHÄFER 1998)

Bearbeitung

ArbeitskraftMaschineMaterialMethodeUmwelt

INPUT

OUTPUT

LIEFERANT

KUNDE

Leistungsvereinbarung

Leistungsindikatoren

Bild 3-9: Geschäftsprozeßmodul als Basiskomponente des Geschäftsprozeßma-

nagements (GAITANIDES U. A. 1994)

Die Basiskomponente des Geschäftsprozeßmanagements ist das Geschäftspro-

zeßmodul, das nach GAITANIDES U. A. (1994) die Bestandteile Input/Output,Bearbeitung, Leistungsvereinbarung und Leistungsindikatoren aufweist (Bild3-9). Diese Bestandteile werden im folgenden kurz vorgestellt.


- Input/Output: Jeder Verarbeitungsschritt ist gekennzeichnet durch Input undOutput. Dies können Informationen, Dienstleistungen oder auch Materialiensein. Entscheidend für die Prozeßeffizienz ist die Qualität von Input undOutput. Ein wesentlicher Aspekt des Geschäftsprozeßmanagements ist so-mit die Frage nach ihrer Notwendigkeit und ihre Bewertung. Die Zufrieden-heit des Kunden ist abhängig von der Übereinstimmung des geplanten Out-put mit dem tatsächlichen Prozeßergebnis.

- Bearbeitung: Der Output wird auf Basis vordefinierter Abläufe aus demInput generiert. Daran erkennt man bereits die Ausrichtung des Ge-schäftsprozeßmanagements auf Standardabläufe im Unternehmen. Ein Zielist es hierbei, diese Abläufe zu verbessern.

- Leistungsvereinbarung: Ein weiteres Ziel des Geschäftsprozeßmanagementsist der Abbau von Koordinationsbedarf. Hierzu müssen die Nahtstellen zwi-schen Geschäftsprozessen möglichst exakt abgestimmt sein.

- Leistungsindikatoren: Um die Geschäftsprozesse langfristig verbessern zukönnen, werden die Vorgaben in den Prozessen (Input, Bearbeitung undOutput) regelmäßig mit den tatsächlichen Vorgehensweisen und Ergebnis-sen verglichen. Kennzahlensysteme messen Abweichungen und geben beiBedarf einen Verbesserungsimpuls.

Der Ansatz des Geschäftsprozeßmanagements erlaubt es, umfangreiche undkomplexe Abläufe im Unternehmen auf Basis dieser einfachen Module darzu-stellen. Entscheidend hierfür ist allerdings die Transparenz der Prozeßstruktur.Hierfür müssen die Prozeßschritte und deren Verknüpfungen visuell aufgezeigtwerden. (WARNECKE U. A. 1998)

Geschäftsprozeßmanagement in den planerischen BereichenDas Geschäftsprozeßmanagement hat seinen Ursprung in den Verwaltungsbe-reichen. Die betrachteten Verwaltungsprozesse waren in ihrem Umfang be-kannt und konnten deshalb komplett modelliert, analysiert und optimiert wer-den. Planende Prozesse in produzierenden Unternehmen weisen demgegenübereine deutlich höhere Komplexität, eine geringere Überschaubarkeit und damitauch eine geringere Planbarkeit auf (GAITANIDES U. A. 1994).

In den letzten Jahren wurden jedoch Methoden und Werkzeuge entwickelt, diees erlauben, die planenden Prozesse in den produzierenden Unternehmen zu


modellieren und hinsichtlich Zeit, Kosten und Qualität zu bewerten. Allen An-sätzen ist gemeinsam, daß Abläufe verbessert und Nahtstellen zwischen Abläu-fen optimiert werden. Um dies zu erreichen sollen nach MERTINS & JOCHEM

(1998) durch Einbeziehung von externen Experten stabile Standardprozesse inallen Abteilungen installiert werden.

Unterscheidung von GeschäftsprozessenSCHUH U. A. (1996) unterscheiden im planerischen Bereich direkte und indi-rekte Prozeßelemente in produzierenden Unternehmen (Bild 3-10).

Koppelelement

Entscheidungselement

Kommunikationselement

Transportelement

Grobterminierungselement

Ressourcentestelement

Registrierungselement

Splitelement

Direkte Prozeßelemente Indirekte Prozeßelemente

Beschaffungselement

Arbeitsplanungselement

Konstruktionselement

Fertigungselement

Montageelement

Besprechungselement

Bild 3-10: Direkte und indirekte Prozeßelemente (SCHUH U. A. 1996)

Erstere beschreiben Prozesse, die unmittelbar zur Wertschöpfung eines Auf-trags beitragen, wie beispielsweise die Zeichnungserstellung, die Teilefertigungoder die Montage einer Baugruppe. Die indirekten Prozeßelemente hingegenwerden für die Beschreibung von Geschäftsprozessen wie Kommunikation,Transport oder Auftragsterminierung herangezogen, die zur Auftragsbearbei-tung notwendig sind, aber nur mittelbar zur Wertschöpfung beitragen.

Untersuchungen von EVERSHEIM (1996) in verschiedenen Unternehmen habengezeigt, daß etwa 80 bis 95% aller Tätigkeiten indirekte Tätigkeiten sind. Ver-


fügbare Prozeßbeschreibungssprachen unterstützen deshalb auch eine spezifi-sche Betrachtung dieser Bereiche.

3.3.2 Methoden und Werkzeuge zum Geschäftsprozeßmanagement

Im folgenden werden einige typische Methoden und Werkzeuge zum Ge-schäftsprozeßmanagement vorgestellt. Es wurden sehr unterschiedliche Ansätzegewählt, um die Einsatzbreite des Geschäftsprozeßmanagements aufzuzeigen.Einer der "extremsten" Ansätze ist das von HAMMER & CHAMPY (1994) vorge-stellte Business Process Reengineering, bei dem alle Geschäftsprozesse desUnternehmens in Frage gestellt werden. Das Unternehmen wird somit funda-mental umstrukturiert und idealisiert auf einer "grünen Wiese" neu aufgebaut.Verbreiteter ist allerdings das evolutionäre Vorgehen, bei dem die Geschäfts-prozesse laufend analysiert, bewertet und verbessert werden. Die im folgendenvorgestellten Ansätze sind dem evolutionären Vorgehen zuzuordnen.

3.3.2.1 Prozeßelementmethode

MÜLLER (1993) stellt eine umfassende Methodik zur prozeßorientierten Reor-ganisation der technischen Auftragsabwicklung vor. Hierbei wurden prozeße-

lementbezogene und auftragsorientierte Kenngrößen definiert, mit deren Hilfeeine kombinierte Prozeß- und Erfolgskontrolle des Auftragsabwicklungsprozes-ses möglich ist. Darüber hinaus wurde eine Berechnungsmethode entwickelt,die es erlaubt, die mittlere Auftragsdurchlaufzeit sowie die mittleren indirektenGesamtauftragskosten auf Basis eines dynamischen Prozeßplans und der ent-sprechenden prozeßelementbezogenen Kenngrößen zu ermitteln.

Diese Berechnungsmethode bildet zusammen mit den prozeßelementbezogenenKenngrößen, die in Bild 3-11 dargestellt sind, die Grundlage der Bewertungvon Reorganisationsmaßnahmen. Der Bewertungsablauf vollzieht sich dabei inzwei Stufen. Im Rahmen der Grobplanungsstufe erfolgt die Abgrenzung sepa-rater Reorganisationssegmente, aus denen anhand der jeweiligen Reorganisati-onspotentiale das zu reorganisierende Prozeßsegment zu bestimmen ist. In derzweiten Planungsstufe sind dann die aus einer detaillierten Problemanalyse desausgewählten Reorganisationssegments und der darauf aufbauenden Alternati-


vengenerierung hervorgegangenen Reorganisationsmaßnahmen gegenüberzu-stellen.

Prozeß-eingang

Eingangs-zeitpunkt

Aufträge

Prozeß-ausgang

Verzweigungszeitpunkt

Verzweigungs-häufigkeit

Prozeß-verzweigung

Prozeß-unterbrechung Unterbrechungszeitpunkt

Unterbrechungs-häufigkeit

Ausgangs-zeitpunkt

Ausgangs-häufigkeit

Prozeßelement-kosten

MittlereProzeßzeit

Wiederhol-häufigkeit

Mittlere Unter-brechungszeit

Mittlere Aus-gangszeit

Mittlere Ver-zweigungszeit

Prozeßelement

Bild 3-11: Prozeßelementbezogene Kenngrößen (MÜLLER 1993)

Die Methode ermöglicht es also, Reibungsverluste in der Auftragsabwicklungzu quantifizieren und Konsequenzen von Reorganisationsmaßnahmen zu beur-teilen. Voraussetzung für den Einsatz der Methode sind Standardabläufe in derAuftragsabwicklung. Diese Standardabläufe stellen in virtuellen Fabriken aller-dings die Ausnahme dar.

3.3.2.2 IEM-Methode

MERTINS & JOCHEM (1995) stellen die IEM-Methode7 (IEM - Integrated En-

terprise Modelling) vor, in der objektorientiert Geschäftsprozesse, die dazuge-

7 wird auch als IUM-Methode (Integrierte Unternehmensmodellierung) bezeichnet


hörigen Organisationseinheiten und die erforderlichen Informationssystememodelliert werden können. Das Ergebnis ist ein Modell für die Planung undOptimierung von Prozessen und der Organisationsstruktur in Unternehmen.Modelle, die mit der IEM-Methode erstellt wurden, geben einen transparentenÜberblick über die Projektplanung und sind eine Diskussionsgrundlage für dieProjektbeteiligten. IEM-Modelle können dazu genutzt werden, exakte Pla-nungsziele, wie die Verbesserung in Zeit, Kosten und Qualität, zuzuweisen unddadurch die Prozeßorganisation zu verbessern.

Basis der Methode ist das sogenannte generische Aktivitätenmodell. Hierbeisind der Start- und Endzustand mit einer Aktion verbunden. Die Durchführungder Aktivität wird durch einen Auftrag gesteuert. Weiterhin ist eine Ressourcezugeordnet, welche für die Durchführung der Funktion verantwortlich ist. DieMethode wird durch das Softwarewerkzeug MO2GO unterstützt.

Die Methode konzentriert sich auf Standardprozesse in Projekten. Da sie keineVerknüpfung zu strukturierten Produktdaten aufweist, kann sie den unterneh-mensübergreifenden Informationsfluß in neuartigen Prozessen nicht transparentdarstellen. Außerdem ist die Methode nicht für die dezentrale Modellierungdurch die Projektmitarbeiter sondern für eine zentrale Modellierung durch einExpertenteam ausgelegt, was den effizienten Einsatz der Methode in virtuellenFabriken verhindert.

3.3.2.3 Kooperative Gestaltung unternehmensübergreifender

Geschäftsprozesse

HIRSCHMANN (1998) hat eine Methode zur kooperativen Gestaltung unterneh-

mensübergreifender Geschäftsprozesse entwickelt. Ein Phasenmodell der Pro-zeßgestaltung bildet die Grundlage des Ansatzes. Für die einzelnen Gestal-tungsphasen wurden betriebswirtschaftliche Methoden ausgearbeitet und daraufaufbauend eine DV-technische Unterstützung konzipiert.

Im vorgestellten Ansatz werden Prozessen Kosten und Erlöse als monetäreMeßgrößen zugrunde gelegt. Anhand dieser Meßgrößen lassen sich Prozesseund Gestaltungsalternativen bewerten, untereinander vergleichen und derenwirtschaftlichen Konsequenzen aufzeigen (Bild 3-12). Die Maßgrößen werden


auch für die periodische Überwachung und Kontrolle realisierter Prozesse ein-gesetzt.

Kostenarten-/Kostenstellen-

rechung

UnternehmenA

Kostenarten-/Kostenstellen-

rechung

UnternehmenB

Unternehmen A

Kostenarten-/stellenrechnung

Prozeß-modellierung

Kosten-zuordnung

Prozeß-kosten-

satz

Prozeß-kosten-

satz

PKS IA TPK

10 2 20

12 1 12

5 5 25

Summe 57

Prozeß-kalkulation

Unternehmen B

PKS - Gesamt-Prozeßkostensatz des TeilprozessesIA - Inanspruchnahme des i-ten TeilprozessesTPK - Teilprozeßkosten

Bild 3-12: Prozeßkostenbewertung unternehmensübergreifender Geschäftspro-

zesse (nach HIRSCHMANN 1998)

Zur Umsetzung der DV-technischen Unterstützung wurde das Multi-Agenten-System PRINCESS prototypisch entwickelt, dessen Komponenten die einzelnenPartner einer Kooperation bei der Prozeßgestaltung repräsentieren. Die Agentengestalten kooperativ einen unternehmensübergreifenden Geschäftsprozeß undunterbreiten ihren Vorschlag den verantwortlichen Mitarbeitern bzw. den Pro-cess Ownern in den jeweiligen Unternehmen.

In dem vorgestellten Ansatz werden die Prozeßmitarbeiter nicht direkt in dieGestaltung der unternehmensübergreifenden Geschäftsprozesse einbezogen.HIRSCHMANN weist aber darauf hin, daß ein solcher Ansatz dazu führen kann,daß sich eine Kooperation aus sich heraus selbst gestalten könnte, ohne daß eseiner ausdrücklichen Entscheidung als Auslöser von Gestaltungshandlungen


bedarf. Weiterhin bezieht sich der Ansatz auf Standardabläufe. Verknüpfungenmit Produktdaten werden ebenfalls nicht diskutiert. Der Ansatz eignet sich so-mit sehr gut zur Optimierung unternehmensübergreifender Standardprozesse, erist allerdings nicht für die Dynamik von virtuellen Fabriken ausgelegt.

3.3.2.4 Integration von Prozeß- und Produktmodell

Im Rahmen des vom BMBF geförderten Forschungsprojekts GIPP (Ge-

schäftsprozeßgestaltung mit integrierten Prozeß- und Produktmodellen) standdie Integration von Prozeß- mit Produktmodellen im Mittelpunkt der Betrach-tung. Es wurden Prozeßtypisierungen, Referenzmodelle sowie Personal- undOrganisationsaspekte im Geschäftsprozeßmanagement erarbeitet (HOFER-ALFEIS U. A. 1999). Die theoretischen Grundlagen wurden anschließend inmehreren Praxisbeispielen umgesetzt. Zwei Beispiele aus dem Forschungspro-jekt, die den Anforderungen von virtuellen Fabriken am ehesten entsprechen,werden im folgenden vorgestellt.

Der Produktentwicklungsprozeß in der AutomobilindustrieMURR (1999) beschreibt eine Methode zur Gestaltung von komplexen DigitalMock-Up (DMU) Entwicklungsprozessen im Seriengeschäft. Hierbei wurdenfür eine modellgestützte Planung und Steuerung von Geschäftsprozessen alswesentliche Objekte der Entwicklungsprozeß selbst, das Bauteil, der Produkti-onsprozeß sowie die Produktionsmittel definiert. Um das Informationswachs-tum dieser Objekte abzubilden, werden sogenannte kontinuierliche Indikatoren

eingeführt, die den aktuellen Fortschritt des jeweiligen Objektes repräsentieren.Als kontinuierliche Merkmale für das Produkt wurden beispielsweise ein Rei-fegrad, eine Struktur oder die CAD-Datenqualität definiert. Analog sind konti-nuierliche Indikatoren für den Produktionsprozeß und das Produktionsmittelabgebildet.

Jeder einzelnen Entwicklungsaktivität, sei es im Bereich der Produktentwick-lung oder Prozeßplanung, können im nächsten Schritt die benötigten Produkt-,Produktionsprozeß- und Produktionsmitteldaten als Eingangs- bzw. Ausgangs-informationen zugeordnet werden (vgl. Bild 3-13). Weitere relevante Informa-tionen, wie etwa die benötigten Ressourcen, CA-Methoden, -Werkzeuge oder-Systeme, die für die softwaregestützte Produkt- und Prozeßentwicklung benö-


tigt werden, können ebenfalls zugewiesen werden. Auf Basis der generischen

Entwicklungsprozeßbausteine kann eine vollständige Definition eines vernetz-ten Entwicklungsprozesses durchgeführt werden.

1. ....2. .......

Input Output

Produkt

Eingangszustand

Produktions-prozeß

Ausgangszustand

Produktions-mittel

Aufgaben:

Beschreibung:

Zeitaufwand:Ressourcen: Kosten:

Entwicklungs-prozeßbaustein

Basisobjekte

Rei

feg

rad

ind

ikat

ore

n

Produkt

Produktions-prozeß

Produktions-mittel

Basisobjekte

Rei

feg

rad

ind

ikat

ore

n

Methode:

Bild 3-13: Generischer Entwicklungsbaustein (MURR 1999)

Die Methode wurde speziell für den Einsatz in komplexen DMU-Entwick-lungsprozessen für Serienprodukte konzipiert. Sie ist deshalb für den Einsatz invirtuellen Fabriken, in denen ständig neue kurzfristige Kooperationen auf- undabgebaut werden, zu komplex und muß außerdem mit hohem Aufwand für ei-nen speziellen Anwendungsfall vorkonfiguriert werden. Dadurch geht die invirtuellen Fabriken benötigte Flexibilität verloren. Die Integration von geogra-phisch verteilten Produktmodellen in unterschiedlichen Unternehmen wird indem Ansatz ebenfalls nicht berücksichtigt.

Produktentwicklung im AnlagenbauAls zweites Beispiel des GIPP-Projekts wird die Produktentwicklung im Anla-genbau vorgestellt. Das Anlagengeschäft ist geprägt durch eine sehr kundenin-dividuelle Leistungserstellung mit hoher Komplexität. Viele Personen aus un-


terschiedlichen Fachbereichen erarbeiten mit einer Vielzahl von Werkzeugensehr komplexe Lösungen. Bei einer Analyse von Auftragsabwicklungen wurdeim Rahmen des GIPP-Projekts festgestellt, daß Datenredundanz, mangelndeDatenaktualität und mangelnde Transparenz über die Datenzusammenhänge zuständigem Überschreiten von Kosten und Terminen führen (KAMM 1999, S.263).

Das von KAMM (1999) vorgestellte Konzept basiert auf einer Prozeßbaustein-

bibliothek, in der die einzelnen Teilprozesse hinterlegt sind. Hierbei wurdenReferenzbausteine erarbeitet, die in produktspezifische und produktneutraleProzesse sowie Standardprozesse unterschieden werden. Die Referenzbausteinekönnen gesamte Prozeßketten in der Anlagenabwicklung beschreiben.

Das entwickelte Referenzmodell besteht aus drei Hierarchiestufen (Hauptpro-zeßketten, Teilprozeßketten und Prozeßkettenbausteine). In den Hauptprozeß-ketten wird der Prozeßablauf grob dargestellt. Auf der zweiten Stufe, denTeilprozeßketten, werden Teilprozesse detaillierter dargestellt. Die Prozeßket-tenbausteine auf der dritten Ebene werden in produktabhängige und prozeßab-hängige Bausteine aufgeteilt. Diese Bausteine stellen Varianten dar, die je nachAnwendungsfall ausgewählt werden können.

Die Methodik verknüpft zwar Prozeßdaten mit Produktdaten, berücksichtigtallerdings nicht die dynamische Bildung von virtuellen Fabriken auf der Basisvon Unternehmensnetzwerken. Um die Methodik dort anzuwenden, müßten füralle am Netzwerk beteiligten Unternehmen entsprechende Referenzbausteineentwickelt, abgestimmt und bei Bedarf verknüpft werden. Das würde einen zugroßen Aufwand bedeuten, und bei jeder Erweiterung des Unternehmensnetz-werks zu Anpassungen und Erweiterungen der Bausteine führen. Virtuelle Fab-riken erfordern eine deutlich höhere Flexibilität, als dies der vorgestellte Ansatzermöglicht. Weiterhin berücksichtigt der Ansatz nicht, daß in virtuellen Fabri-ken die Produktdaten auf mehrere Unternehmen mit unterschiedlichen Organi-sationen und I&K-Technologien verteilt sind.

3.3.2.5 Geschäftsprozeßoptimierung unter emotionalen Aspekten

KAESELER (1997) betont bei seinem Ansatz zur Geschäftsprozeßoptimierungdie Bedeutung der emotionalen Bedürfnisse der Mitarbeiter. Er hat ein Vorge-


hensmodell entwickelt, das neben rationalen auch emotionalen Herausforde-rungen gerecht wird. Das Modell basiert auf der Erfahrung, daß die Einsicht fürdie Notwendigkeit von Verbesserungen vielfach nicht gegeben ist, da Problemenicht in der eigenen Leistungserstellung, sondern vielmehr in der Fehlleistungvor- und nachgelagerter Bereiche gesucht werden. Einen Schritt in dem Vorge-hensmodell stellt die Durchführung von moderierten Workshops dar, was auchin einem Pilotprojekt durchgeführt wurde. Darin visualisierte ein Team be-reichsübergreifende Prozeßketten, die als gemeinsame Sprachbasis dienten. Eswurde besonders deutlich, welche erheblichen Kommunikationsdefizite zwi-schen den Abteilungen bestanden und mit welchen Vorurteilen die Leistungender einzelnen Abteilungen bewertet wurden.

Um die Geschäftsprozesse zu optimieren, wurden Teams gebildet, in denen diedirekt Betroffenen in die Lage versetzt wurden, eigene Erfahrungen zu sam-meln und Anknüpfungspunkte zu schaffen. Dieses Prinzip der Partizipation istdarauf ausgerichtet, die Prozeßbearbeiter in den Entscheidungsprozeß zu integ-rieren und das eigenverantwortliche Handeln zu fördern.

Das von KAESELER entwickelte Vorgehen ist eines der wenigen, bei denen dieVerantwortung über die Prozeßgestaltung und Entscheidungsfindung direkt beiden Mitarbeitern angesiedelt ist. Da in virtuellen Fabriken die Mitarbeiter einetragende Säule darstellen, sollen die Erfahrungen von KAESELER bei der Ent-wicklung des Konzepts berücksichtigt werden.

3.3.2.6 Workflowmanagement

In engem Zusammenhang mit der Geschäftsprozeßmodellierung und -optimie-rung steht das Workflowmanagement. Die WfMC (Workflow Management Co-alition) definiert Workflow und Workflowmanagement-System folgenderma-ßen (VERSTEEGEN 1995):

"Ein Workflow ist eine computergestützte Vereinfachung oder Automatisierung

eines gesamten Geschäftsprozesses oder eines Teils davon. Ein Workflowma-

nagement-System ist ein System, das vollständige Workflow-Prozesse definiert,

managt und ausführt."


SimulationAnalyse

Geschäftsprozeß-modellierung

Workflow-Implementierung

SimulationAnalyse

Geschäftsprozeß-modellierung

Workflow-Implementierung

Geschäftsprozeß-modellierungs-

tool

Workflow-management-

tool

Bild 3-14: Zusammenspiel zwischen Workflow und Geschäftsprozeßoptimie-

rung (in Anlehnung an LINDO 1996)

Durch eine optimierte Steuerung von Arbeitsvorgängen sollen Durchlaufzeitenreduziert, Medienbrüche verringert sowie die Ausführungsqualität und die Vor-gangstransparenz verbessert werden (LINDO 1996). Sinnvollerweise werdenWerkzeuge zur Geschäftsprozeßoptimierung gemeinsam mit Workflowmana-gement-Werkzeugen eingesetzt, um das Potential voll auszuschöpfen (Bild3-14).

Workflowmanagement ist die konsequente Fortführung der Idee der Ge-schäftsprozeßmodellierung und -optimierung. Die vorteilhaften Aspekte diesesAnsatzes müssen auch in einem effizienten Produktdaten- und Prozeßmanage-ment in virtuellen Fabriken umgesetzt werden. Heute wird das Workflowmana-gement allerdings fast ausschließlich in Standardprozessen mit hoher Wieder-holhäufigkeit eingesetzt.


Das Geschäftsprozeßmanagement basiert auf der Idee der Prozeßorientierung,also in der Strukturierung der betrieblichen Abläufe nach dem Flußprinzip. DieBasiskomponente des Geschäftsprozeßmanagements ist nach GAITANIDES U. A.(1994) das Geschäftsprozeßmodul mit den Bestandteilen Input/Output, Bear-beitung, Leistungsvereinbarung und Leistungsindikatoren.


Die Methode des Prozeßmanagements wird mittlerweile bei mehreren Ansätzeneingesetzt. Ein Einsatzbereich ist die prozeßorientierte Reorganisation der tech-nischen Auftragsabwicklung. Weiterhin wird das Grundprinzip in der integ-rierten Unternehmensmodellierung verwendet. Ein relativ neuer Ansatz schließtunternehmensübergreifende Prozesse in die Modellierung und Bewertung mitein. Mit Hilfe dieser Ansätze werden, in der Regel durch Einbeziehung vonexternen Experten, stabile Standardprozesse im Unternehmen oder zwischenfesten Unternehmenskooperationen installiert. Der Vorteil der Ansätze liegtdarin, daß Abläufe optimiert und Informationsflüsse gezielt gesteuert werdenkönnen. Für den Einsatz in virtuellen Fabriken weisen diese Ansätze allerdingsfolgende Defizite auf:

- Dynamische Projektabwicklungen können nicht mit Standard-Prozessenabgebildet werden.

- Aufwendige Modellierungen und Optimierungen durch Expertenteams sindaufgrund der Einmaligkeit von Projekten nicht sinnvoll.

Die vorgestellten Forschungsergebnisse aus dem GIPP-Projekt stellen zwareine wesentliche Erweiterung des Stands der Technik dar, können dieIntransparenz im Projekt und unternehmensübergreifenden Informationsflußallerdings nicht beseitigen. Mangelnde Flexibilität in der Prozeßgestaltung unddie ungenügende Berücksichtung der verteilten Produktdatenhaltung in immerwieder neuen Unternehmenskonstellationen verhindern einen effizienten Ein-satz der entwickelten Methoden in virtuellen Fabriken.

Die Bedeutung von emotionalen Aspekten wurde von KAESELER erkannt, derbei seinem Ansatz die Verantwortung über Gestaltung und Optimierung derProzesse den Mitarbeitern übergibt. Die Ergebnisse seiner Arbeiten sind bei derEntwicklung des Konzepts zum integrierten Produktdaten- und Prozeßmana-gement in virtuellen Fabriken zu berücksichtigen, da die Mitarbeiter eine tra-gende Säule in virtuellen Fabriken darstellen.

Als Fazit kann zusammengefaßt werden, daß die verfügbaren Methoden undWerkzeuge für den Einsatz in dynamischen Unternehmenskooperationen nichtausreichend flexibel sind und die Integration der auf mehrere Unternehmenverteilten Produktdaten nicht unterstützen.


3.4 Produktdatenmanagement

Neben dem Projektmanagement und dem Geschäftsprozeßmanagement bietetdas Produktdatenmanagement (PDM) Methoden und Werkzeuge zur Unterstüt-zung von Projektabwicklungen (GROSSMANN 1997, BERK 1996). In diesemAbschnitt werden die Grundlagen des Produktdatenmanagements beschrieben.Anschließend werden kommerzielle Produktdatenmanagementsysteme (PDM-Systeme) sowie Ansätze aus der Forschung vorgestellt. Möglichkeiten der Da-tenübertragung mit Datenaustauschwerkzeugen runden den Stand der Technikab. Inwieweit die Ansätze auf virtuelle Fabriken übertragbar sind und wo dieGrenzen der Ansätze liegen, wird abschließend diskutiert.


Ein Produkt ist ein technisches Erzeugnis, das konstruiert und hergestellt wird.Verfolgt man den Lebenslauf eines Produkts von der ersten Produktidee bis zurEntsorgung oder Verwertung, dann lassen sich die in Bild 3-15 dargestelltenaufeinanderfolgenden Phasen unterscheiden.

Die im Produktlebenszyklus anfallenden Daten werden in einer Reihe von Do-kumenten oder auch in Datenbanken gespeichert. Diese Dokumente werden imallgemeinen mit Rechnerunterstützung erstellt und weiterverarbeitet.

Je größer der Datenbestand wird, desto schwieriger ist es, die Informationen zusteuern und zu verwalten. Dazu kommen Normen und Gesetze, die den pro-duktbezogenen Informationsbestand zum Bestandteil von Produkthaftungsre-geln (EG-Richtlinie 85/374) und Qualitätsmanagement (ISO 9000 und ISO10007) machen (EIGNER 1996).

46 3.4 Produktdatenmanagement

Produkt-planung

Produkt-entsorgung

Produkt-entwicklung

Produkt-nutzung

Produkt-herstellung

Produkt-vertrieb

Informationsfluß

Stofffluß

Bild 3-15: Lebensphasen eines Produkts (KAISER 1997)

Produktdatenmanagement soll genau diese Probleme lösen. Systeme zum Pro-duktdatenmanagement werden seit ca. zehn Jahren angeboten. Bis heute ist die-ser Markt durch eine große Begriffsvielfalt gekennzeichnet. Neben dem Begriff"PDM – Produktdatenmanagement" werden auch "EDM – Engineering DataManagement" und "Technisches Informationssystem" verwendet8. Alle dieseTermini zielen auf denselben Sachverhalt ab: Die Verwaltung von produktdefi-nierenden Daten (Produktdaten- und Dokumentenmanagement) in Verbindungmit der Abbildung technisch-organisatorischer Geschäftsprozesse (Prozeßma-nagement) im produzierenden Industriebereich. EIGNER (1996) definiert dasProduktdaten- und Dokumentenmanagement folgendermaßen:

"Unter Produktdaten- und Dokumentenmanagement wird schwerpunktmäßig

die Zuordnung von beliebigen Dokumenten (z. B. CAD-Zeichnungen, 3D-

Modelle, Text-Dokumente) zu Produktstamm- und -strukturdaten verstanden.

Die Verwaltung der Freigabe- und Änderungszustände sowie das Konfigurati-

onsmanagement gehören ebenso zu den Standardfunktionen."

8 Im Rahmen der Arbeit wird der Begriff PDM verwendet. Damit werden die betrachteten Da-

tenbereiche komplett abgedeckt.


3.4.2 Methoden und Werkzeuge zum Produktdatenmanagement

Der Lösungsansatz des Produktdatenmanagements besteht im wesentlichen inder strukturierten Verwaltung aller Produktdaten. Die zu verwaltenden Infor-mationen werden in einem logisch zentralen und überwachten Datenbereich,einem sogenannten Datenvault9, gespeichert. Informationen werden unterteiltin Dokumente (z. B. CAD-Modell) und in sogenannte Metadaten (z. B. Teile-klassifikation). Letztere enthalten zusätzliche beschreibende Informationen ü-ber Produkte oder Dokumente in Form von Attributen (MILLER U. A. 1994).

Aufbauend auf dem zentralen Lösungsansatz ergeben sich für PDM-Systemefolgende, voneinander abhängige Funktionsbereiche, die im folgenden vorge-stellt werden:

- Produktdaten- und Dokumentenmanagement

- Prozeßmanagement (Workflow- und Projektmanagement)

- Dienstprogramme

- Schnittstellen zu Applikationen

Zusätzlich zu den PDM-Systemen existieren weitere Ansätze, die sich mit demProduktdatenmanagement befassen. In Rahmen des Stands der Technik wirdvon diesen Ansätzen das Integrierte Produktmodell und ein darauf aufbauenderForschungsansatz zur Unterstützung von kooperativen Organisationsstrukturenbeschrieben. Weiterhin wird der unternehmensübergreifende Datenaustauscherläutert.

3.4.2.1 Produktdaten- und Dokumentenverwaltung

Eine effiziente Informationsverwaltung setzt eine angepaßte Teileklassifizie-rung und -identifizierung voraus. Vor der Einführung eines PDM-Systems sinddeshalb diese Punkte softwarekonform für das Unternehmen zu entwerfen(ANDREWS 1996). Hierbei sind sowohl die Produktdaten als auch die zugehöri-

9 Datenvault bedeutet übersetzt Datenspeicher und soll den geschützten Datenbereich ver-

deutlichen.


gen Dokumente zu berücksichtigen. Aufbauend hierauf verwaltet das Produkt-strukturmanagement die Beziehungen zwischen Einzelteilen, Baugruppen, Ar-tikeln und beliebigen Dokumenten. Zusatzfunktionen ermöglichen die Ablei-tung von unterschiedlichen Stücklistenarten (KELCH 1998).

Bild 3-16: Produktstruktur- und Dokumentenverwaltung (BRANDNER 1998B)

Sowohl die Klassifzierung und Identifizierung als auch das Produktstrukturma-nagement stellen die Grundlage für eine strukturierte Datenablage und damitauch für effiziente Suchfunktionen dar (Bild 3-16). Auf die Daten in der zent-ralen Datenbasis kann über den sogenannten Klassifikationsbaum, über denProduktstrukturbaum oder über die beschreibenden Attribute (Metadaten) zu-gegriffen werden (EIGNER U. A. 1991).

Der Zugriff kann hierbei über die Standardbenutzeroberfläche oder über einWeb-Frontend10 erfolgen. Die rasanten Entwicklungen bei den Internet-

10 Web-Frontends ermöglichen den Zugriff auf den Datenvault des PDM-Systems über Inter-

net-Browser.


Technologien lassen darauf schließen, daß in naher Zukunft alle PDM-Funktionen über Web-Frontends ausgeführt werden können (MENDEL 1997,SANTELL 1996, BAUNACH 1996).

3.4.2.2 Prozeßmanagement mit PDM-Systemen

Zu den in PDM-Systemen realisierten Elementen des Prozeßmanagementszählen das Versions- und Konfigurationsmanagement, das Workflowmanage-ment und das Projektmanagement.

Mit dem Versionsmanagement werden alle freigegebenen Versionen von Pro-dukten, Baugruppen, Bauteilen oder Dokumenten in dem zentralen Datenvaultgespeichert. Somit bleiben die alten Versionen verfügbar und der Konstrukti-onsprozeß nachvollziehbar. Um die Konfiguration eines Produkts von einemfrüheren Zeitpunkt bestimmen zu können, muß das System wissen, welcheVersionen der einzelnen Teile oder Baugruppen und welche Strukturen zu dementsprechenden Zeitpunkt Gültigkeit besaßen. Diese Funktionalität wird alsKonfigurationsmanagement11 bezeichnet (EIGNER & HAESNER 1998).

Eine weitere Funktion des Prozeßmanagements ist das Workflowmanagement.Workflowmanagement ist die elektronische Verarbeitung von Geschäftsprozes-sen (siehe auch Abschnitt 3.3.2.6). In PDM-Systemen wird diese Funktion vorallem für das Freigabe- und Änderungswesen eingesetzt (PÖRTNER 1998). Mo-derne PDM-Systeme können die Aufgaben auch per E-Mail an die Bearbeiterversenden.

Das Projektmanagement in PDM-Systemen beinhaltet die Verwaltung vonProjektdokumenten und der am Projekt beteiligten Personen (Projektteams).Die typischen Projektmanagementfunktionen, wie beispielsweise

- Balkenplantechnik und Netzplantechnik,

- Kapazitätsplanung und -überwachung sowie

- Ressourcenmanagement

11 im englischen als Configuration Management bekannt


werden aber auch oft in eigenständigen Projektmanagementprogrammen undnicht im PDM-System durchgeführt (FURRER 1998).

3.4.2.3 Dienstprogramme in PDM-Systemen

Zusätzlich zu den bereits beschriebenen Funktionalitäten besitzen PDM-Systeme eine Reihe von Dienstprogrammen, die in Bild 3-17 aufgeführt sind.

PDMDienstprogramme

Bild 3-17: PDM-Dienstprogramme (BRANDNER 1996)

Über das interne Kommunikationssystem oder das Internet werden Mitarbeiterautomatisch über Vorgänge benachrichtigt, die sie betreffen, beispielsweiseüber Änderungen an Bauteilen oder Aufgaben.

Der Austausch von Dateien zwischen CA-Systemen12 ist ein zentraler Punktbeim Einsatz von PDM-Systemen. Hierfür können in das PDM-System Datei-

12 CA-System – Computer Aided System: Systeme zur computergestützten Arbeit


en-Konverter eingebunden werden, die manuell oder durch automatische Pro-zesse aufgerufen werden und die Input-Datei in das gewünschte Output-Formatübersetzen (BAUHOFER & K NECHTEL 1997).

Durch den Einsatz von PDM-Systemen muß der Benutzer nicht mehr wissen,wo sich die Daten befinden. Falls er Daten bearbeiten möchte, benutzt er diezur Verfügung gestellten Suchmöglichkeiten, und das PDM-System kopiert dieentsprechenden Dateien in sein Arbeitsverzeichnis (MILLER U. A. 1994). DerBenutzer muß sich somit nicht mehr um den Datentransport kümmern.

Die Visualisierungsfunktion bietet Möglichkeiten zur Anzeige von Raster- undVektorgraphiken. Sie ermöglicht die Anzeige von Produktdaten auch an Rech-nern, die keinen Zugriff auf die Applikation haben, mit der die Daten erzeugtwurden (NIKOL 1998).

Die PDM-Systemverwaltung hat zusätzlich zu den allgemeinen Systemmana-gement-Funktionen die Funktionen "Definition und Anpassung von Metada-ten", "Verwaltung von Zugriffsrechten der Benutzer", "Organisation der Daten-verteilung" und "Archivierung" zu erfüllen.

3.4.2.4 Schnittstellen von PDM-Systemen zu Applikationen

PDM-Systeme stellen die zentrale Drehscheibe des Informationsmanagementsim Unternehmen dar. Sie verwalten alle Daten und Dokumente, die zu Projek-ten oder Produkten gehören. Am häufigsten stammen die im Entwicklungspro-zeß entstehenden Daten von CAD-Systemen und Office-Anwendungen13. DaPDM-Systeme auch Stammdaten und Produktstrukturen verwalten, ist eine An-bindung an PPS-Systeme14 ebenfalls sinnvoll (LOZINSKI & SCHMIDT 1998).

Die Schnittstellen zu Applikationen sorgen dafür, daß die Daten einfach undfehlerfrei von den Anwendungssystemen übernommen und wieder zurückge-spielt werden können. Dadurch stehen die Informationen auch rechtzeitig den

13 typische Office-Anwendungen sind Textverarbeitungen, Tabellenkalkulationen, einfache

Datenbanksysteme und auch Projektmanagementsysteme

14 PPS-System – Produktionsplanungs- und Steuerungssystem


anderen Projektbeteiligten zur Verfügung. Die Schnittstelle zum PPS-Systemdient der automatischen Übergabe der Konstruktionsdaten in die Fertigung.Weiterhin kann auf Seiten des PPS-Systems eine Anbindung realisiert werden,die die Anzeige von Zeichnungen im PPS-System ermöglicht (SCHITTKO

1997).

3.4.2.5 Integriertes Produktmodell

Der Produktlebenszyklus umfaßt nicht nur die Produktentstehung, das heißt dieBereiche Entwicklung und Herstellung, sondern schließt auch Funktionen wieVertrieb, Nutzung und Entsorgung eines Produkts ein (vgl. Abschnitt 3.4.1).Produktdaten beschreiben alle Eigenschaften eines Produkts und enthalten auchdie zu dessen Herstellung notwendigen Informationen. Da es sich bei diesenDaten um eine virtuelle Beschreibung des Produkts handelt, wird die Gesamt-heit dieser Daten als Produktmodell bezeichnet (KAISER 1997).

Ein integriertes Produktmodell faßt Produktdaten in einem einheitlichen Da-tenmodell zusammen und entsteht durch die Integration anwendungsspezifi-scher Produktmodelle auf Schemaebene. Ein Schema bezeichnet die Gesamt-heit eines abgeschlossenen Datenmodells. Es stellt gewissermaßen den Bauplandes Datenmodells dar und wird durch die in ihm festgelegten Elemente undBeziehungen charakterisiert. Ein Schema ist eine präzise Notation mit einerSemantik, die erklärt, wie ein bestimmtes Datenmodell mit der korrespondie-renden Situation der realen Welt übereinstimmt. Wird ein Schema als Aus-schnitt aus der Gesamtheit eines Datenmodells im Hinblick auf eine bestimmteAnwendung definiert, so wird dieses auch als Sicht oder externes Schema be-zeichnet (GRABOWSKI U. A. 1993).

3.4.2.6 EDM-System zur Unterstützung von teamorientierten

Organisationsstrukturen

Aus dem Bereich der Forschung wurden von MARCIAL (1997) Partialmodelleeines objektorientierten EDM-Systems entwickelt und prototypisch implemen-tiert. Das Konzept ist auf die Unterstützung teamorientierter Organisationsfor-men in Entwicklung & Konstruktion ausgerichtet. Die wesentlichen Informati-


onsobjekte sind Produkte, Dokumente und Methoden. Hierfür wurden die er-forderlichen Partialmodelle entwickelt. Internationale Standardisierungen wiebeispielsweise die Produktdatennorm STEP15 fanden dabei Berücksichtigung.Es wurde auch ein Partialmodell "Geschäftsprozeß" entwickelt, das auf Basisvon sogenannten Loops Standardprozesse abbildet.

Der Ansatz berücksichtigt ausschließlich Standardabläufe, die mit dem Pro-duktmodell verknüpft werden. Projektabläufe, die durch ihre Einmaligkeit undNeuartigkeit, ihre Dynamik sowie durch definierte Zeit-, Kosten- und Quali-tätsvorgaben gekennzeichnet sind, werden nicht betrachtet. MARCIAL weißtdarauf hin, daß der von ihm entwickelte Ansatz um Elemente des Projektmana-gements erweitert werden sollte.

3.4.2.7 Unternehmensübergreifender Produktdatenaustausch

In virtuellen Fabriken stellt neben einer effizienten Produktdatenverwaltungauch der unternehmensübergreifende Produktdatenaustausch einen wesentli-chen Erfolgsfaktor dar. Basis hierfür sind Standardisierungen in der Datenbe-schreibung, Methoden der Datenübertragung und spezielle Datenaustausch-werkzeuge.

Standardisierung von ProduktdatenDie bestehenden Defizite im Datenaustausch zwischen Systemen wurden vonder internationalen Normungsorganisation ISO erkannt und führten zur Ent-wicklung der Normenreihe ISO 10303, die allgemein unter dem SynonymSTEP bekannt ist. Das Ziel von STEP ist:

"An unambiguous representation of computer interpretable product informa-

tion throughout the life of a product."

STEP ist als Serie von ISO 10303-Standards erschienen, die neben den eigent-lichen Modellen zur Beschreibung von Produktdaten auch Beschreibungsme-thoden (Description Methods), Implementierungsmethoden (Implementation

Methods) und Methoden zum Konformitätstest (Conformance Testing Method-

15 STEP – Standard for the Exchange of Product Model Data


ology and Framework) enthält. STEP kann als ein Baukasten aufgefaßt werden,mit dem anwendungsspezifische Produktdatenmodelle (Application Protocols)unter Verwendung von Grundbausteinen (Integrated Resources) nach definier-ten Regeln und genormten Methoden beschrieben werden (GRABOWSKI U. A.1993).

Für den Bereich des Austauschs von PDM-Daten besitzt das Anwendungsda-tenmodell ISO 10303-214 (Core Data for Automotive Mechanical Design Pro-

cesses) eine große Bedeutung. Hierin wurde unter Beteiligung namhafter Au-tomobilhersteller und ausgewählter Zulieferanten weltweit die Beschreibungvon Produkt- und Betriebsmitteldaten in der Produktentstehung festgelegt. Mitdiesem Umfang werden die rein auf CAD-Daten ausgerichteten Austauschpro-tokolle IGES16, VDA-FS17 oder DXF18 bei weitem übertroffen (TRIPPNER &ENDRES 1998).

Methoden der DatenübertragungDaten können entweder mehrfach kopiert und durch die Benutzer unabhängigvoneinander bearbeitet werden (Data Exchange), oder aber Benutzer greifenauf die gleichen Daten zu und teilen sich die Daten dadurch (Data Sharing).Beide Methoden werden im folgenden vorgestellt.

Zum Data Exchange existieren die Möglichkeiten

- Offline Übertragung über Diskette, CD, Magnetband usw. und

- Übertragung über Datenleitungen.

Bei der Nutzung von Datenleitungen können Daten auf Basis geeigneter Über-tragungsprotokolle direkt von einem System in das andere übertragen werden.Mögliche Datenleitungen sind das Telefonnetz oder das Internet.

16 IGES – Initial Graphics Standard: Standard zur Beschreibung von 2D- und 3D-

Geometriedaten.

17 VDA-FS – Verband der Automobilindustrie – Flächenschnittstelle: Geometrieschnittstelle

zum Austausch von vorwiegend Flächendaten.

18 DXF – Drawing Exchange Format: Standard zum Austausch von 2D-Geometriedaten.


Neben dem Data Exchange gewinnt das Data Sharing immer mehr an Bedeu-tung. Hierbei verbleiben die Daten an einem Ort und werden lediglich vonmehreren Systemen gemeinsam genutzt (MAK 1998). Gibt ein Auftraggeberbeispielsweise eine Bestellung über Data Sharing in das PPS-System eines Zu-lieferers ein, so wird diese Transaktion vom eigenen System nicht erfaßt. Derwesentliche Vorteil dieses Verfahrens liegt in der Redundanzfreiheit und stän-digen Aktualität der verfügbaren Daten, weshalb Data Sharing für Daten, diehäufig geändert werden, eine bessere Eignung aufweist als das Data Exchange-Verfahren. Data Sharing wird nach LINDEMANN & K LEIN (1998) auch in Da-tentransferkonzepten verwendet, die mit gemeinsamen Datenbanken undWWW-Applikationen aufgebaut sind19.

DatenaustauschwerkzeugeZum Austausch von Daten zwischen Unternehmen mit verschiedenen CAD-,PDM- oder PPS-Systemen sind die wichtigsten Schritte:

1. Export der Daten aus dem System

2. Zusammenstellung der zu übertragenden Daten

3. Konvertierung der Daten in ein für den Empfänger geeignetes oder neutralesFormat

4. Übertragung der Daten an den Empfänger

Jeder dieser Schritte setzt ein umfangreiches Spezialwissen voraus. Da nichtalle Anwender über dieses Wissen verfügen, ist es notwendig, die Aufgabe desDatenaustauschs in einem Unternehmen zu teilautomatisieren. Dadurch lassensich die einmal eingebrachten Spezifika der Konverter, Dateiformate und benö-tigten Protokolle durch alle Mitarbeiter parallel nutzen. (BROCKHAUS &FUHRMEISTER 1998)

Diese Aufgabe wird von Datenaustauschwerkzeugen übernommen. Sie sindüblicherweise so aufgebaut, daß bei der Übertragung von Daten durch die Mit-arbeiter eines Unternehmens nur der Empfänger und unbedingt erforderliche

19 Ein typisches Beispiel ist der E-Commerce über das Internet. Hier gibt der Besteller die

Bestellung direkt in die Software des Internet-Kaufhauses ein.


Angaben gemacht werden müssen. Alle übrigen Funktionen werden zentralvorgegeben und laufen automatisch ab (LEBER 1998). Bild 3-18 zeigt das Prin-zip von Datenaustauschwerkzeugen mit entsprechenden Werkzeugen. Daten-austauschwerkzeuge müssen aufwendig für jeden Kooperationspartner konfigu-riert werden und lohnen sich deshalb nur für langfristige Kooperationen(HAGEN & BRANDNER 1998).

CAD/CAM-System

PDM-System

AdapterQualitäts-prüfungSplitter/Merger

Pre-/Post-processor

Qualitäts-prüferAdapterMigrator

ArchivierungKontrolleTransportVerpackungVerwaltung

Prozeßsteuerung

Prozeßsteuerung

Pre-/Post-processor

Visuali-sierenEditierenAdaption

nativeDatei

nativeDatei’

neutraleDatei

neutraleDatei’

nativeDatei

neutraleDatei

neutraleDatei’

Datenaustauschmanager

PDM-Tools

CAD-Tools

Bild 3-18: Datenaustausch bei PDM Systemen (Quelle PROSTEP)


PDM-Systeme stellen umfangreiche Funktionen für das Produktdatenmanage-ment und für bestimmte Anwendungen des Prozeßmanagements zur Verfü-gung. Unternehmensinternen Ansprüchen und langfristigen Kooperationen ge-nügen die vorhandenen PDM-Systeme, Austauschformate und Datenaustausch-werkzeuge. PDM-Systeme ermöglichen externen Projektbeteiligten mittler-weile den Zugriff auf Produktdaten über Internet-Browser.


Für den Einsatz in virtuellen Fabriken sind allerdings Defizite erkennbar. Sowerden im Bereich des Prozeßmanagements ausschließlich Standardgeschäfts-prozesse im Änderungs- und Freigabewesen unterstützt. Ad-hoc Prozesse, wiesie bei virtuellen Fabriken vorherrschen, werden nicht berücksichtigt. Der un-ternehmensübergreifende Informationsfluß bleibt damit intransparent. Weiter-hin sind keine unternehmensübergreifend nutzbaren Projektmanagementfunkti-onen integriert, so daß keine Durchgängigkeit zwischen den Prozessen auf deroperationalen und der taktischen Ebene gegeben ist.

3.5 Grenzen der Ansätze und Handlungsbedarf

Die vorangegangen Ausführungen verdeutlichen den komplexen Charakter vonProjektabwicklungen in virtuellen Fabriken unter dem Aspekt des Produktda-ten- und Prozeßmanagements. Um den Handlungsbedarf aufzuzeigen und dieAnforderungen an das Konzept zum integrierten Produktdaten- und Prozeßma-nagement in virtuellen Fabriken auszuarbeiten, wird im folgenden der Stand derTechnik kurz zusammengefaßt.

Virtuelle Fabriken stellen eine neue Organisationsform dar, mit der vor allemkleinen und mittleren Unternehmen aus der Produktionstechnik neue Potentialeeröffnet werden. Virtuelle Fabriken haben die Herausforderung, daß sie in ver-teilten Umgebungen, trotz heterogener Organisations-, Software- und Daten-strukturen sowie der daraus resultierenden Schnittstellenprobleme, Projekteschnell und effizient in unterschiedlichen Unternehmenskonstellationen abwi-ckeln müssen. Die heutige Projektabwicklung in virtuellen Fabriken ist aller-dings durch hohe Reibungsverluste geprägt. Die Gründe hierfür sind

- mangelnde Übersicht über den Projektverlauf,

- mangelnde Transparenz über die im Gesamtprojekt fließenden Informatio-nen,

- ineffiziente Verwaltung und aufwendiger Austausch von Produktdaten so-wie

- frühes Einbringen des Know-hows der Projektmitarbeiter ist nur sehrschwer möglich.

58 3.5 Grenzen der Ansätze und Handlungsbedarf

In konventionellen Organisationsformen werden hauptsächlich Projektmana-gementsysteme, Geschäftsprozeßmanagementsysteme und Produktdatenmana-gementsysteme eingesetzt, um Projekte effizient abzuwickeln. Alle verfügbarenkommerziellen Lösungen sowie die vorgestellten Forschungsansätze könnendie beschriebenen Defizite für virtuelle Fabriken nicht beseitigen.

So sind beispielsweise Projektmanagementsysteme von ihrem Aufbau und ihrerLeistungsfähigkeit her im wesentlichen für einfach strukturierte und determi-nierbare Vorgänge geeignet. Die Dynamik der Prozesse in virtuellen Fabrikenund die zur Lösung des Schnittstellenproblems notwendige Planung des Infor-mationsflusses wird von diesen Systemen allerdings nicht unterstützt. In derForschung sind zwar Lösungsansätze bekannt, die den Informationsfluß be-trachten, allerdings sind die Ansätze vorwiegend für die unternehmensinterneProjektabwicklung konzipiert. Eine Verknüpfung der Prozeßdaten mit den Pro-duktdaten in verteilten und heterogenen Organisationen wird ebenfalls nichtberücksichtigt.

Verfügbare Methoden zum Geschäftsprozeßmanagement unterstützen die ope-rationale Ebene durch die Modellierung, Bewertung und Optimierung von Pro-zessen. Erweitert werden die bekannten Ansätze in letzter Zeit dahingehend,daß unternehmensübergreifende Schnittstellenprozesse in die Optimierung ein-bezogen werden. Im Mittelpunkt der Betrachtung stehen aber Standardabläufeund nicht die für virtuelle Fabriken typischen ad-hoc-Abläufe. Deshalb liegenauch keine Beschreibungsmethoden und Vorgehensweisen zur dezentralen, ei-genverantwortlichen Prozeßmodellierung vor. Die Integration der Geschäfts-prozesse mit den Produktdaten in einem heterogenen und verteilten Umfeldwird in den bekannten Ansätzen ebenfalls nicht unterstützt.

Im Bereich des Produktdatenmanagements können mit sogenannten Produkt-datenmanagementsystemen die während des Produktlebenszyklus entstehendenDaten effizient verwaltet werden. Die Systeme bieten auch Funktionen an, umdie Produktdaten durch die einzelnen Aktivitäten der Prozeßkette zu steuern.Allerdings werden hier nur Standardabläufe im Freigabe- und Änderungswesenunterstützt. Die dezentrale Planung von ad-hoc-Prozessen wird genausowenigberücksichtigt wie die Planung von Projektphasen in Unternehmenskooperatio-nen.


Ableitung des Handlungsbedarfs

Heute verfügbare Methoden und Werkzeuge sind für die Heterogenität und Dy-namik von Projektabwicklungen in virtuellen Fabriken nicht geeignet. Um inder zukunftsträchtigen Organisationsform den Effizienzverlust, der durch dieVerteilung von Prozessen auf mehrere Unternehmen entsteht, so gering wiemöglich zu halten und dadurch den Gesamtnutzen zu erhöhen, sind neue Ansät-ze für die Projektplanung und -abwicklung notwendig. Hierbei ist die heutevorzufindende Funktionstrennung zwischen Projektmanagement, Geschäftspro-zeßmanagement und Produktdatenmanagement aufzuheben und ein durchgän-giges unternehmensübergreifendes Datenmodell für diese Funktionsbereiche zuinstallieren.

60 3.5 Grenzen der Ansätze und Handlungsbedarf

4 Anforderungen an das Produktdaten- und

Prozeßmanagement

Auf Basis der bereits vorgestellten Eigenschaften von virtuellen Fabriken undder identifizierten Defizite bei Projektabwicklungen, werden in diesem KapitelAnforderungen an ein Konzept zum integrierten Produktdaten- und Prozeßma-nagement formuliert. Hierbei werden die Möglichkeiten und Grenzen der inKapitel 3 diskutierten Methoden und Werkzeuge berücksichtigt.

Um die heute vorzufindenden Defizite (vgl. Abschnitt 2.5) zu beseitigen, müs-sen folgende Ziele verfolgt werden:

- Effiziente und übersichtliche unternehmensübergreifende Projektplanung,-abwicklung und -steuerung

- Transparenter Informationsfluß über die Unternehmensgrenzen hinweg

- Strukturierte Verwaltung und effizienter Austausch aller im Projekt auftre-tenden Produktdaten

- Detail-Know-how von Projektmitarbeitern muß in virtuelle Fabriken früh-zeitig eingebracht werden können

Aus diesen Zielen werden im folgenden Anforderungen an das Prozeßmanage-ment, Produktdatenmanagement und die DV-technische Umsetzung abgeleitet.Einleitend wird der Einsatzbereich des Konzepts definiert.

4.1 Definition des Einsatzbereichs für das Konzept

Der Haupteinsatzbereich des zu entwickelnden Konzepts sind virtuelle Fabri-ken, die sich auftragsbezogen aus Basisnetzwerken, wie beispielsweise demVirtuellen Markt, der Virtuellen Fabrik Euregio Bodensee oder dem RP-Net.de

bilden20. Das Konzept muß demnach nicht nur in einzelnen Unternehmen, son-

20 vgl. hierzu die Praxisbeispiele in Abschnitt 2.4

62 4.2 Anforderungen an das Prozeßmanagement

dern vor allem in dynamischen Netzwerken effizient eingesetzt werden können.Typisch für den Einsatzbereich sind

- die geographische Verteilung der Projektmitarbeiter,

- heterogene Datenformate und I&K-Technologien sowie

- die regelmäßige Konfiguration neuer virtueller Fabriken.

4.2 Anforderungen an das Prozeßmanagement

Um die Prozesse über die Unternehmensgrenzen hinweg transparent planen zukönnen, sind auf der taktischen Ebene alle Projektbeteiligten in die Planungeinzubeziehen. Sie müssen also Zugriff auf die Planungsdaten haben und ihreeigenen Planungsschritte in einen gemeinsamen Projektplan integrieren kön-nen. Es muß gewährleistet sein, daß der Projektplan vollständig und immer ak-

tuell ist. Projektfortschritte und Projektverzögerungen sollen im Projektplanerkennbar sein. Unterschiedliche Abstraktionsebenen, auf denen die Projektpla-nung in der Regel stattfindet, müssen abgebildet werden können.

Auf der operationalen Ebene ist eine transparente Darstellung des unterneh-mensübergreifenden Informationsflusses notwendig. Informationsflüsse müssendezentral von den Projektmitarbeitern so geplant werden können, daß die je-weiligen Bearbeiter zu Beginn einer Aufgabe alle notwendigen Informationenund Daten im richtigen Format vorliegen haben. Vor allem die zu Reibungs-verlusten führenden Prozesse zwischen Unternehmen müssen hierzu effizientmodelliert werden können. Hierbei ist die Dynamik von virtuellen Fabriken zuberücksichtigen. Durch den schnellen Aufbau der Kooperation, die zeitlich be-fristete Kooperationsdauer und die sich ständig ändernden Unternehmenskons-tellationen ist eine sehr hohe Flexibilität bei der Prozeßgestaltung erforderlich.

Da die Informationen im wesentlichen Produkte beschreiben, erfordert einetransparente Darstellung des Informationsflusses eine Integration der Produkt-daten mit den Prozeßdaten. Die Integration muß so umgesetzt werden, daß dienotwendigen Verknüpfungen einfach abgebildet werden können.

4 Anforderungen an das Produktdaten- und Prozeßmanagement 63

Weiterhin ist eine Möglichkeit zu schaffen, um das Know-how der Projektmit-arbeiter frühzeitig in gemeinsame Projekte einbringen zu können, um so bei-spielsweise fertigungsgerecht entwickeln und konstruieren zu können.

4.3 Anforderungen an das Produktdatenmanagement

Das Ziel einer strukturierten Verwaltung und eines effizienten Austauschs derim Projekt auftretenden Produktdaten, stellt auch Anforderungen an das Pro-duktdatenmanagement. Insbesondere müssen die Daten in die strukturierte

Verwaltung einbezogen werden, die bei Kooperationspartnern lokal gespeichertsind. Zu Berücksichtigen ist hierbei die Heterogenität der Datenformate beiden beteiligten Unternehmen einer virtuellen Fabrik.

Weiterhin ist die Aktualität der Daten zu gewährleisten. Für alle Projektbetei-ligten muß der Zugriff auf die Daten einfach, schnell und unabhängig von denBürozeiten der Projektpartner erfolgen können. Es muß allerdings auch eineMöglichkeit geschaffen werden, wie Zugriffe auf Produktdaten gezielt verhin-

dert werden können, um Mißbrauch zu vermeiden.

4.4 Anforderungen an die DV-technische Umsetzung

Aufgrund der Tatsache, daß die Prozeßdaten unternehmensübergreifend mo-delliert werden sollen und dabei ständigen Änderungen unterworfen sind, bietetsich der Einsatz einer DV-technischen Unterstützung an. Eine DV-technischeUnterstützung hat nach AUGUSTIN (1998) den primären Nutzen, daß aktuelleInformationen schnell und zuverlässig verfügbar gemacht werden können. Sieist in dem hier betrachteten Einsatzbereich auch deshalb sinnvoll, da Produkt-daten in digitaler Form vorliegen und somit nur mit DV-technischen Werkzeu-gen effizient verwaltet werden können. Bei der Umsetzung müssen deshalb fol-gende Anforderungen berücksichtigt werden:

Die geographische Trennung der Projektbearbeiter einer virtuellen Fabrik er-fordert einen unternehmensübergreifenden Einsatz des Softwaresystems. DieUnternehmen, die sich zu einer virtuellen Fabrik zusammenschließen, müssenin kürzester Zeit informationstechnisch vernetzt sein.

64 4.4 Anforderungen an die DV-technische Umsetzung

Heterogene I&K-Technologien in den Unternehmen, wie beispielsweise Be-triebssysteme, Netzwerktechnologien und Anwendersysteme, müssen dabeiberücksichtigt werden. Die Software muß auf allen wichtigen Arbeitsplattfor-

men (Office-PCs, UNIX-Workstations, ...) verfügbar sein.

Ebenso stellt auch die dezentrale Datenhaltung eine Herausforderung dar. Da-durch, daß mehrere Unternehmen gemeinsam Produkte entwickeln und her-stellen, sind die Daten auch auf mehrere Unternehmen verteilt. Die Softwaremuß somit den unternehmensübergreifenden Datenaustausch unterstützen.

Das zu entwickelnde Konzept soll für qualifizierte und eigenverantwortlichhandelnde Projektmitarbeiter ausgelegt werden. Dies eröffnet für die Lösungneue Spielräume, die bei bekannten Lösungsansätzen oft nicht gegeben sind.Durch die aktive Einbindung der Projektbeteiligten vergrößert sich der Nutzer-kreis der Software deutlich, was wiederum zu steigenden Anforderungen be-züglich der Systembedienung führt. Komplexe Expertentools, zu deren Bedie-nung umfangreiches Spezialwissen erforderlich ist, eignen sich nicht für denEinsatz in dynamischen Unternehmenskooperationen. Deshalb muß ein Kom-promiß zwischen einfacher Bedienung und leistungsfähiger Funktionalität ge-funden werden. So sind beispielsweise graphische Benutzeroberflächen fürProzeß- oder Produktstrukturen sind notwendig, um das Projekt übersichtlichdarstellen zu können.

5 Konzept zum integrierten Produktdaten- und

Prozeßmanagement

Nachdem im vorigen Kapitel die Anforderungen formuliert wurden, wird indiesem Kapitel das Konzept zum integrierten Produktdaten- und Prozeßmana-gement in virtuellen Fabriken entwickelt. Einleitend wird der Lösungsansatzvorgestellt. Anschließend folgt die Ausarbeitung des Konzepts auf Basis vonInformationsanalysen. Betrachtet wird hierbei die Planung, Abwicklung, Über-wachung und Steuerung von Projekten.

5.1 Lösungsansatz

Beim konventionellen Vorgehen, das auch in Kapitel 3 ausführlich diskutiertwurde, werden Projekt- und Produktdaten dezentral bei den beteiligten Unter-nehmen verwaltet. Es werden auch individuelle Werkzeuge, wie beispielsweiseProjektmanagementsysteme oder Produktdatenmanagementsysteme eingesetzt.Es findet also eine redundante Planung mit unterschiedlichen Werkzeugen statt.

Das im Rahmen der Arbeit entwickelte Konzept basiert auf dem Ansatz, daßdie Prozeß- und Produktdaten nicht dezentral mit individuellen Werkzeugenverwaltet werden, sondern zentral im Unternehmensnetzwerk. Hierfür werdengemeinsame Methoden und Werkzeuge eingesetzt, so daß unabhängig von derKonstellation einer virtuellen Fabrik einheitliche Tools zur Prozeß- und Pro-duktdatenverwaltung verwendet werden und auch eine integrierte Datenhaltungmöglich wird. Die Bearbeitung der Nutzdaten, wie beispielsweise CAD-Daten,erfolgt nach wie vor mit individuellen Werkzeugen. Die Verwaltung dieserDaten wird allerdings mit den gemeinsamen Tools durchgeführt. Das Konzeptsoll deshalb nicht für den Einsatz in nur einem Unternehmen, sondern für denEinsatz in einem dynamischen Unternehmensnetzwerk ausgelegt werden.

Der Ansatz ähnelt dem Prinzip des standardisierten Datenaustauschs: Durch dieDefinition von Standards können zwischen beliebigen SoftwareprogrammenInformationen einheitlich ausgetauscht werden (Bild 5-1). Es müssen nicht fürjede einzelne Kopplung Anbindungen entwickelt werden, sondern es ist völlig

66 5.1 Lösungsansatz

ausreichend, wenn die Softwareprogramme die standardisierten Daten ein- undauslesen können. Standardisierungen werden genau aus diesem Grund entwi-ckelt und erhöhen dadurch die Flexibilität enorm (TRAUTHEIM 1998).

Viele bidirektionale Abstimmungen Jeweils nur eine Abstimmung

Ohne Standard Mit Standard

System A

System B System D

System C System A

System B System D

System C

Standard

Bild 5-1: Prinzip der Standardisierung beim Datenaustausch zwischen Soft-

waresystemen

Der Austausch von Daten zwischen unterschiedlichen Systemen und die Bil-dung von virtuellen Fabriken auf Basis von Unternehmensnetzwerken habeneines gemeinsam: In beiden Fällen existieren viele Konstellationsmöglichkei-ten. So wie beim Datenaustausch beliebige Systemkonstellationen denkbar sind,treten in Unternehmensnetzwerken beliebige Unternehmenskonstellationen inForm von virtuellen Fabriken auf. In beiden Fällen ist der Aufwand enorm, umalle denkbaren Konstellationen präventiv zu unterstützen.

Deshalb wird das Lösungsprinzip der Standardisierung auf Unternehmensnetz-werke angewendet. Allerdings werden hier nicht nur Daten in standardisierterForm ausgetauscht und verwaltet, sondern es werden vor allem standardisierteMethoden und Werkzeuge im Netzwerk eingesetzt, die das gesamte Produkt-und Prozeßmodell, unabhängig von den beteiligten Unternehmen, verwaltenkönnen. Der Ansatz ist in Bild 5-2 dargestellt.

5 Konzept zum integrierten Produktdaten- und Prozeßmanagement 67

Anwendungs-system A

Anwendungs-system B

Anwendungs-system D

Anwendungs-system C

Zentralesintegriertes Produkt-datenund Prozeß-

management

Planungssystem ADatenverwaltungssystem A

Anwendungssystem A

Planungssystem BDatenverwaltungssystem B

Anwendungssystem B

Planungssystem CDatenverwaltungssystem C

Anwendungssystem C

Planungssystem DDatenverwaltungssystem D

Anwendungssystem D

Konventioneller Ansatz

Neuer Ansatz

Unternehmen C

Unternehmen DUnternehmen B

Unternehmen A

Unternehmen CUnternehmen A

Unternehmen DUnternehmen B

Bild 5-2: Betrachtung des neuen Ansatzes aus der Sicht von Softwaresystemen

Während bei der Bearbeitung von beispielsweise CAD-Daten unterschiedlicheWerkzeuge deshalb eingesetzt werden, weil die Funktionalitäten der CAD-Systeme stark unterschiedlich sind, ist bei der Produktdaten- und Projektver-waltung festzustellen, daß bei den meisten Unternehmen ähnliche Prinzipieneingesetzt werden. Dies zeigt sich auch darin, daß die Standardisierung derProduktdaten im Anwendungsprotokoll AP214 des STEP-Standards sehrschnell voranschreitet und bereits erfolgreich getestet wurde (LEBER 1998). E-

68 5.1 Lösungsansatz

benfalls werden für das Prozeßmanagement in den meisten Unternehmen Stan-dard-Netzplan- oder Balkenplantechniken eingesetzt (STUFFER & K LEEDÖRFER

1997).

Keine Verknüpfungenzwischen Produktdatenund Prozeßdaten

Verknüpfungen zwischen Produktdaten und Prozeßdaten

Konventioneller Ansatz

Neuer Ansatz

Prozesse auf der taktischen Ebene

Produktdaten

Prozesse auf der operationalen Ebene

Bild 5-3: Betrachtung des neuen Ansatzes aus der Sicht der Prozeß- und Pro-

duktdaten


Aufgrund dieser Ähnlichkeiten in den Anwendungen und Datenbeschreibungenist es möglich, innerhalb eines Unternehmensnetzwerks nicht nur die Daten ineinem standardisierten Format zu speichern, sondern auch einheitliche Metho-den und Werkzeuge zum Produktdaten- und Prozeßmanagement zu implemen-tieren.

Der Vorteil dieses Ansatzes liegt darin, daß unabhängig von der Zusammenset-zung der virtuellen Fabrik, die Daten für das komplette Projekt bzw. Produktzentral und integriert verwaltet werden können. Durch die Nutzung gemeinsa-mer Methoden und Werkzeuge für die Projektplanung und Gestaltung von In-formationsflüssen können alle denkbaren Schnittstellenkonstellationen model-liert werden.

Ein weiterer zentraler Aspekt des zu entwickelnden Konzepts liegt darin, daßzusammengehörige Produkt- und Prozeßdaten integriert verwaltet werden. Dieheute vorzufindende Trennung zwischen Prozeßdaten auf der taktischen Ebene,Prozeßdaten auf der operationalen Ebene und den Produktdaten soll aufgeho-ben werden. Bild 5-3 veranschaulicht dieses Lösungsprinzip.

Im Rahmen der Ausarbeitung des Konzepts werden die Funktionsweisen desProzeßmanagements und des Produktdatenmanagements vorgestellt. Anschlie-ßend wird ein Vorgehensmodell erläutert, das beschreibt, wie im Rahmen desneuen Lösungsansatzes Projekte in virtuellen Fabriken geplant und abgewickeltwerden.

5.2 Informationsanalyse

Vor der Ausarbeitung des Konzepts muß ermittelt werden, welche Daten indem zentralen Modell verwaltet werden müssen. Hierzu werden in den folgen-den Abschnitten die Daten, die typischerweise in unternehmensübergreifendenProjektabwicklungen auftreten, gesammelt und strukturiert. Anschließend wer-den aus dem Datenpool die Daten selektiert, die in dem zentralen Modell zuberücksichtigen sind.

70 5.2 Informationsanalyse

Es handelt sich im wesentlichen um Prozeßdaten und Produktdaten. Finanz-und Logistikdaten, die in PPS-Systemen verwaltet und über EDI21-Standards,wie beispielsweise EDIFACT22 oder ODETTE23 online ausgetauscht werden,werden nicht betrachtet. Sie würden den Rahmen der Arbeit sprengen. In weite-ren Ausbaustufen sollten jedoch auch diese Daten in das Konzept integriertwerden.

5.2.1 Prozeßdaten

Unter Prozeßdaten werden in diesem Zusammenhang die Daten verstanden, diedie Entstehung und Verarbeitung der Produktdaten beschreiben. Die Prozeßda-ten können unterteilt werden in Projektdaten und Geschäftsprozeßdaten. Fol-gende Projektdaten sind hierbei von Bedeutung:

- Projektstamm mit Informationen über Projektlaufzeit, Auftraggeber usw.

- Dokument, z. B. Projektbeschreibung, Pflichtenheft oder Projektbericht

- Projektphase, die Inhalte und den zeitlichen und finanziellen Rahmen vonTeilbereichen des Projekts definiert (einschließlich Meilensteinen)

- Phasenplan als Zusammensetzung einzelner Projektphasen

- Person, wie beispielsweise Projektleiter oder Phasenverantwortlicher

Um innerhalb einer Projektabwicklung das Produktmodell und auch das Pro-dukt zu erstellen, muß eine Vielzahl von Geschäftsprozessen durchgeführt wer-den. In dynamischen Unternehmenskooperationen werden die vorwiegend auf-tretenden ad-hoc-Geschäftsprozesse allerdings kaum geplant, da keine geeig-

21 Unter EDI (Electronic Data Interchange) versteht man den elektronisch normierten Daten-

austausch von strukturierten Finanz- und Logistikdaten. Typische Daten sind Bestellungen,

Lieferstatusmitteilungen, Rechnungen, Zahlungsaufträge und Zollformalitäten (vgl. KRILL

1996).

22 EDIFACT – Electronic Data Interchange for Administration, Commerce and Transport.

EDIFACT ist die branchenneutrale EDI-Lösung und das definierte Regelwerk der Vereinten

Nationen für den elektronischen Datenaustausch in Verwaltung, Wirtschaft und Transport.

23 ODETTE – Branchenspezifischer Standard für die Automobilbranche.


neten Methoden und Werkzeuge zur Verfügung stehen (vgl. Abschnitt 3.3). Daim Rahmen des zu entwickelnden Konzepts auch die ad-hoc-Geschäftsprozessegeplant werden sollen, müssen weiterhin folgende Objekte berücksichtigt wer-den:

- Geschäftsprozeß als Basisobjekt für die Bearbeitung und Weitergabe vonInformationen

- Dokument, wie beispielsweise CAD-Datei, das in Geschäftsprozessen bear-beitet und anschließend weitergegeben wird

- Geschäftsprozeßplan, der durch die Zusammensetzung einzelner Geschäfts-prozesse gebildet wird

- Person, die Geschäftsprozesse initiiert, durchführt oder kontrolliert

5.2.2 Produktdaten

Die Klasse Produktdaten beinhaltet alle Daten, die zur vollständigen Beschrei-bung von Produkten und Produktionsmitteln notwendig sind. Weiterhin gehö-ren hierzu auch Daten für die Herstellung und Prüfung von Produkten. Die Da-tenklasse Produktdaten beinhaltet folgende Unterklassen:

- Teilestamm, z. B. Teile-ID, Teilebezeichnung, Werkstoff oder Material

- Produktstruktur, entspricht der Stücklisteninformation des Produkts

- Dokument, z. B. CAD-Modell bzw. -Zeichnung, NC-Programm oder Prüf-protokoll

- Dokumentenstamm, z. B. Dokumentenname, Dokumententyp oder Doku-mentenvorlage

- Dokumentenstruktur, z. B. "NC-Programm gehört zu 3D-Modell"

- Person als Eigner von Teilen oder Dokumenten

72 5.2 Informationsanalyse

5.2.3 Relevante Daten für das Konzept

Die durchgeführte Betrachtung der Produkt- und Prozeßdaten in Projektab-wicklungen zeigt, daß teilweise gleiche Datenobjekte mit unterschiedlichenSystemtypen verwaltet werden.

RelevanteDaten

Teilestamm

Produktstruktur

Dokument

Dokumentenstamm

Dokumentenstruktur

Person

Projektstamm

Dokument

Projektphase

Phasenplan

Person

Dokument

Geschäftsprozeß

Geschäftsprozeßplan

Person

Teilestamm

Produktstruktur

Dokument

Projektphase

Phasenplan

Geschäftsprozeß


Person

Produkt Projekt Geschäftsprozeß

Dokumentenstamm

Dokumentenstruktur Projektstamm

Bild 5-4: Relevante Daten für ein integriertes Produktdaten- und Prozeßmana-

gement in virtuellen Fabriken

Da Geschäftsprozeßdaten Projektphasen untergeordnet sind und in den Ge-schäftsprozessen Produktdaten (beispielsweise Dokumente) verarbeitet werden,ist eine entsprechende Datenintegration zu erzeugen. In Bild 5-4 sind die we-sentlichen Objekte aufgeführt, die bei der Entwicklung des Konzepts zu be-rücksichtigen sind.


5.3 Konzept für das Prozeßmanagement

Im Mittelpunkt des Prozeßmanagements stehen die im vorigen Abschnitt iden-tifizierten Objekte Projektstamm, Projektphase, Phasenplan, Geschäftsprozeß,

Geschäftsprozeßplan und Person. Für eine durchgängige Verwaltung der Pro-zesse von der taktischen bis zur operationalen Ebene, werden Phasen und Ge-schäftsprozesse integriert betrachtet.

5.3.1 Unternehmensübergreifende Phasenplanung

Um die in Abschnitt 4.1 aufgestellten Anforderungen zu erfüllen, ist ein ge-meinsamer Phasenplan erforderlich. Dieser wird zentral im Unternehmens-netzwerk verwaltet und bearbeitet (Bild 5-5).

UnternehmenA

UnternehmenC

UnternehmenB

Basisnetzwerk

Projektphase

MeilensteinL

H G FE

BC

D

JI

K

A Aufbau einervirtuellen Fabrik

Virtuelle Fabrik ABC

zentrale Verwaltung

des Phasenplans

Unternehmen EE

Bild 5-5: Zentraler Phasenplan in der virtuellen Fabrik

Der Phasenplan beinhaltet die einzelnen Projektphasen, die zur Erreichung desProjektziels notwendig sind. Er wird gemeinsam mit der Produktstruktur kon-

74 5.3 Konzept für das Prozeßmanagement

zipiert. Die einzelnen Phasen werden so angeordnet, daß sie einen zeitlichenRahmen für das Projekt vorgeben. Da in der Realität Phasenüberlappungenauftreten24, ist diese Modellierungsform geeigneter als die strenge zeitlicheVerknüpfung von Projektphasen. Um trotzdem die Übergabe von konkretenErgebnissen zu einem bestimmten Termin modellieren zu können, werdenMeilensteine definiert. Bei komplexen Projekten können die Projektphasen aufunterschiedlichen Abstraktionsebenen modelliert werden.

Durch dieses Vorgehen können alle Projektmitarbeiter aktiv in die Planungeinbezogen werden, was dazu führt, daß allen Projektbeteiligten ein aktuellerProjektplan zur Verfügung steht.

5.3.2 Phasenabhängige Zugriffsregelung

In unternehmensübergreifenden Projekten sind nicht alle Beteiligten währenddes gesamten Projekts in die Abwicklung involviert, sondern nur während be-stimmter Projektphasen. In diesen Projektphasen müssen die MitarbeiterZugriff auf das Produkt- und Prozeßmodell haben. In Phasen, in denen sie we-der aktiv Aufgaben durchführen noch an der Prozeßgestaltung mitwirken, ist esausreichend, wenn das Prozeßmodell angezeigt wird. Sind streng vertraulicheInformationen im Prozeßmodell, so muß die Möglichkeit bestehen, diese vorunerlaubten Zugriffen zu schützen.

Mit einer phasenabhängigen Zugriffsregelung kann dies umgesetzt werden.Dabei werden Projektmitarbeitern in unterschiedlichen Phasen unterschiedlicheRechte für Produkt- und Prozeßdaten eingeräumt. Es kann dadurch gesteuertwerden, ob sich ein Projektmitarbeiter aktiv an der Prozeßplanung beteiligenkann, ob er sich nur über den Prozeßplan informieren kann oder ob er auf keineProjektinformationen zugreifen darf.

24 vgl. Simultaneous Engineering


5.3.3 Unternehmensübergreifende Informationsflußmodellierung

Unter der taktischen Ebene ist die operationale Ebene angeordnet. Auf dieserEbene steht die Transparenz im unternehmensübergreifenden Informationsflußim Vordergrund. Um die Dynamik der virtuellen Fabriken zu unterstützen, mußder Ansatz ausreichend flexibel gestaltet werden.

Hierbei wird das Ziel verfolgt, den Projektmitarbeitern alle zur Durchführungeiner Aufgabe notwendigen Informationen zur richtigen Zeit im richtigen For-mat und am richtigen Ort zur Verfügung zu stellen. Um dies zu erreichen, müs-sen die Projektbearbeiter frühzeitig gemeinsam unternehmensübergreifend kri-tische Prozeßschritte einschließlich des Informationsflusses modellieren. Kri-tisch sind vor allem diejenigen Prozesse, die Informationen von anderenProjektmitarbeitern benötigen oder an andere Projektmitarbeiter weitergeben.

Die Modellierung des Informationsflusses erfolgt auf Basis der SADT25-Methode. Sie ist eine sehr verbreitete, graphisch orientierte Methode zur funk-tionalen Modellierung. Als eine Erweiterung der IDEF26-Familie wurde sie zurUnterstützung der Geschäftsprozeßanalyse und -optimierung entwickelt. Sie istnach GRABOWSKI U. A. (1993) eine geeignete Methode zur Abbildung von Pro-zessen sowie ihrer Kontroll- und Informationsflüsse.

ControlControl

InputInput

Ressource

ActivityActivity OutputOutput

Bild 5-6: Beschreibung einer Aktivität in Anlehnung an die SADT-Methode

25 SADT – Structured Analysis and Design Technique

26 IDEF – ICAM Definition Language

76 5.3 Konzept für das Prozeßmanagement

Bild 5-6 stellt das Basiselement der Methode dar. Die Activity27 beschreibt dieAufgabe die durchgeführt werden muß, und der Input beschreibt die Daten, diein der Activity weiterverarbeitet werden müssen (z. B. 3D-CAD-Modell). D.h.diese Daten müssen in einem weiterverarbeitbaren Format zur Verfügung ge-stellt werden. Control liefert dagegen Steuerinformationen, die die Durchfüh-rung der Activity steuern. Diese Informationen müssen nur gelesen und nichtweiterverarbeitet werden können (z. B. Pflichtenheft). Deshalb sind die Anfor-derungen an das Format deutlich geringer als bei Input-Informationen. Als Er-gebnis der Activity entsteht der Output in Form von Informationen, Dateienoder auch physikalischen Objekten. Der Aktivität ist eine Ressource zugewie-sen, in der angegeben ist, welcher Bearbeiter mit welchen Methoden undWerkzeugen die Aktivität ausführt.

UnternehmenA

UnternehmenC

UnternehmenB

Activity Geschäftsprozeß

Input/Output/Control


II

RessourceActivityActivity

Ressource

Ressource

Ressource

O/IO/I

ActivityActivity

O/IO/I

O/CO/C

O/IO/IActivityActivity

ActivityActivity

zentrale Verwaltungder Geschäftsprozesse

Projektphase

Meilenstein

operationaleEbene

taktischeEbene

Bild 5-7: Zentrales Geschäftsprozeßnetz zur Informationsflußplanung

27 Activity wird hier als Synonym für Geschäftsprozeß verwendet


Mehrere Aktivitäten können zu einem Aktivitätennetz verbunden werden.Hierbei werden die Aktivitäten über Output, Input und Control verknüpft. DieModellierung des Prozeßnetzes erfolgt zentral im Netzwerk mit Methoden undProgrammen des Netzwerks (Bild 5-7). Jede Aktivität ist hierbei einer konkre-ten Projektphase untergeordnet.

5.4 Konzept für das Produktdatenmanagement

Im Rahmen des Produktdatendatenmanagements muß die Frage beantwortetwerden, welche Daten und Informationen zentral gehalten und mit gemeinsa-men Methoden und Werkzeugen des Netzwerks bearbeitet werden, und welcheDaten nach wie vor bei den einzelnen Unternehmen verwaltet und mit indivi-duellen Werkzeugen verarbeitet werden.

Unter-nehmen A

Unter-nehmen C

Unter-nehmen B

Basisnetzwerk

Teilestamm

Dokumentenstamm

Physikalische DokumenteL

H G FE

BC

D

JI

K

AAufbau einervirtuellen Fabrik


zentrale Verwaltung

der Produktstrukturund der Dokumente

Unternehmen EE

Bild 5-8: Strukturierte Verwaltung aller Produktdaten

78 5.4 Konzept für das Produktdatenmanagement

Die Anforderung besteht darin, alle Daten des Produkts strukturiert zu verwal-ten und allen Projektbearbeitern zugänglich zu machen. Auf der anderen Seitemuß die Möglichkeit geschaffen werden, heterogene organisatorische Datenabzubilden und bestimmte Datenbereiche gezielt nur ausgewählten Projektpart-nern zur Verfügung zu stellen. Weiterhin muß berücksichtigt werden, daß vieleNutzdaten, wie beispielsweise CAD-Modelle, aus praktikablen Gründen de-zentral bei den einzelnen Unternehmen gespeichert werden müssen (vgl. hierzuFRIEDMANN U. A. 1998).

Um diese Anforderungen für beliebige virtuelle Fabriken, die sich aus einemBasisnetzwerk bilden können, zu unterstützen, wird der in Bild 5-8 dargestellteLösungsansatz gewählt. Bei diesem Konzept werden die Produktstruktur, Tei-lestamm und Dokumentenstamm zentral im Unternehmensnetzwerk in einereinheitlichen Form verwaltet. Zum Anlegen und Bearbeiten dieser Daten ver-wenden alle Projektmitarbeiter das gleiche System, das im Unternehmensnetz-werk installiert ist.

Teile-ID: 4711Bezeichnung: GehäuseKlassifizierung: A-12-34...

Teile-ID: 4711Bezeichnung: GehäuseKlassifizierung: B-56-78...

Sicht auf StammdatenUnternehmen A

Sicht auf StammdatenUnternehmen B

Bild 5-9: Verwaltung von heterogenen Organisationsdaten mit Sichten am Bei-

spiel der Teileklassifizierung

Während die Dokumentenstämme zentral verwaltet werden, werden die physi-kalischen Dokumente allerdings dezentral verwaltet, d. h. diese liegen nach wievor auf den File-Systemen oder in den Datenbanken der beteiligten Unterneh-


men. Diese Dokumente werden aber über entsprechende Verweise im Doku-mentenstamm in die Produktdatenverwaltung einbezogen.

Dadurch können alle Projektbeteiligten in allen Unternehmenskonstellationenan der Modellierung der Produkt- und Dokumentenstruktur teilnehmen. Wei-terhin können sie unabhängig von den Bürozeiten der Partnerunternehmen aufalle zum Projekt gehörenden Produktdaten zugreifen. Die Stammdaten und Do-kumente sind hierbei immer bestimmten Projektmitarbeitern zugewiesen, diedie Zugriffe auf die Daten steuern.

Da auf der einen Seite möglichst alle Produktdaten in die strukturierte Verwal-tung einbezogen werden sollten und auf der anderen Seite bestimmte organisa-torische Daten, wie beispielsweise die Teileklassifizierung, in den einzelnenUnternehmen unterschiedlich sind, werden sogenannte Sichten auf Stammdaten

eingeführt.

Wie in Bild 5-9 dargestellt, werden dadurch je nach zugreifender Organisati-onseinheit entsprechende Informationen angezeigt. Dadurch kann jedes Unter-nehmen beispielsweise nach eigenen Klassifizierungsmerkmalen Bauteile ver-walten und suchen. Durch diesen Ansatz wird die Verwaltung heterogener Or-ganisationen unterstützt (vgl. REINHART & BRANDNER 1996B).

Sicht auf ProduktstrukturUnternehmen A

Sicht auf ProduktstrukturUnternehmen B

Gesamtstruktur

Bild 5-10: Produktstrukturabhängige Steuerung von Zugriffsrechten

80 5.5 Konzept für die Integration

Um den gezielten Zugriff auf Produktdaten steuern zu können, werden weitere,sogenannte produktstrukturabhängige Sichten eingeführt. Über diese Sichtenkönnen Projektmitarbeiter festlegen, welcher Mitarbeiter welche Daten (Pro-duktstruktur, Dokumente usw.) sehen, ändern oder löschen darf. In Bild 5-10 istdas Konzept schematisch aufgezeigt.

Das Produktdatenmanagement weist sowohl auf der taktischen als auch auf deroperationalen Ebene Verbindungen mit dem Prozeßmodell auf. Diese werdenim folgenden erläutert.

5.5 Konzept für die Integration

Da die Projektphasen und Geschäftsprozesse bis jetzt unabhängig von den Pro-duktdaten betrachtet wurden, ist bis jetzt keine Verbindung zwischen den Pro-duktdaten und Prozeßdaten vorhanden. Um allerdings gezielt Produktdatendurch die Geschäftsprozesse zu steuern, ist eine Integration der Partialmodellenotwendig. In diesem Abschnitt soll das Konzept der Integration vorgestelltwerden. Die Umsetzung der Integration erfolgt in Kapitel 6 im Rahmen derDV-technischen Umsetzung.

Die wesentlichen Verbindungen zwischen den Produktdaten und Prozeßdatensind in Bild 5-11 dargestellt.

Die Verbindungen haben folgende Bedeutung:

1. Projektstamm – Teilestamm28: Einem Projekt werden die Stammdaten einesProdukts oder Bauteils zugewiesen.

2. Projektstamm – Dokumentenstamm: Projekte werden mit Dokumenten be-schrieben (z. B. Pflichtenheft). Die Verbindung zwischen Projektstamm undDokument wird hierbei über den Dokumentenstamm realisiert.

3. Projektphase – Teilestamm: Während Projektphasen werden Teile bearbei-tet. An Meilensteinen, als besondere Ausprägung von Projektphasen, müs-sen beispielsweise Teile in einem bestimmten Status vorliegen.

28 Die Teilestämme beziehen sich hier auf Produkte, Baugruppen und Bauteile.


4. Projektphase – Dokumentenstamm: Während Projektphasen werden Doku-mente bearbeitet. An Meilensteinen müssen beispielsweise Dokumente ineinem bestimmten Status vorliegen. Die Verbindung vom Dokumenten-stamm zum Dokument ist hierbei innerhalb der Produktdaten vorhanden.

5. Geschäftsprozeß – Teilestamm: Geschäftsprozessen können Teile als Input-,Output- oder Controlinformationen zugewiesen werden.

6. Geschäftsprozeß – Dokumentenstamm: Geschäftsprozessen können Doku-mentenstämme als Input-, Output- oder Controlinformationen zugewiesenwerden. Über die Verbindung zwischen Dokumentenstamm und Dokumentkönnen Geschäftsprozessen auch Dokumente zugewiesen werden, die bei-spielsweise im Geschäftsprozeß verarbeitet werden müssen.

Teilestamm

Produktstruktur

Dokument

Projektphase

Phasenplan

Geschäftsprozeß


Dokumentenstamm

Dokumentenstruktur

ProduktdatenProzeßdaten

Projektstamm

Bild 5-11: Vereinfachtes Konzept der Integration von Produktdaten mit Pro-

zeßdaten

Bild 5-12 zeigt die Integration zwischen Projektphasen, Geschäftsprozessenund Produktdaten exemplarisch auf.

82 5.5 Konzept für die Integration

UnternehmenA

UnternehmenB

Unter-nehmen C


12

3

Erläuterung von exemplarischen Verbindungen:Zu 1: Am End-Meilenstein muß das Produkt für die Produktion

freigegeben werden.Zu 2: Als Output wird ein Dokument für eine Baugruppe erzeugt, das

als Input in den Folgeprozessen verwendet wird.Zu 3: Der Dokumentenstamm wird in dem zentralen Modell verwaltet

und verweist auf ein physikalisches Dokument.

Projektphasen

Geschäftsprozesse

Produktdaten

Bild 5-12: Zentrale Verwaltung von Produktdaten und Prozeßdaten


Vorteile der Integration bei der PlanungDurch die Integration kann der Informationsfluß der Produktdaten gezielt ge-plant werden, ohne daß Daten redundant sind. Die Verknüpfung der Produkt-daten mit den Prozeßdaten ist vor allem dort sinnvoll, wo Schnittstellen zwi-schen Unternehmen Reibungsverluste verursachen können. Durch die transpa-rente und nachvollziehbare Prozeßdarstellung erhält jeder Mitarbeiter ein klaresVerständnis über den Projektverlauf. Es ist bekannt, wofür welcher Projektmit-arbeiter welche Informationen oder Dateien zu einem bestimmten Zeitpunktbenötigt. Die Transparenz führt auch dazu, daß bei Änderungswünschen schnellersichtlich ist, wer davon betroffen ist und wer bei der Durchführung von Än-derungen informiert werden muß.

Verwaltung der OrganisationseinheitenNeben den Produktdaten und Prozessen spielen auch die Organisationseinheiteneine wesentliche Rolle in Projektplanung und -abwicklung. In virtuellen Fabri-ken treten folgende Organisationseinheiten auf, die zueinander in Beziehungstehen:

- Person

- Abteilung

- Projektteam

- Unternehmen

- Unternehmensnetzwerk

Projektmitarbeiter (Personen) sind i. d. R. für mehrere Teile, Dokumente undGeschäftsprozesse verantwortlich. Der Ausfall eines Mitarbeiters kann dazuführen, daß eine Vielzahl von Verknüpfungen im Gesamtmodell aufwendigangepaßt werden muß.

Um dies zu verhindern, wird die Organisationseinheit Rolle eingeführt. EinerRolle ist mindestens ein Projektmitarbeiter zugeordnet. Ein zweiter Mitarbeiterkann beispielsweise als Stellvertreter zugeordnet werden, auf den die Rechteund Pflichten der Rolle vererbt werden. Änderungen in der Zusammensetzungvon virtuellen Fabriken können dadurch mit wenig Aufwand durchgeführt wer-den, indem andere Mitarbeiter entsprechenden Rollen zugewiesen werden.

84 5.6 Vorgehen beim integrierten Produktdaten- und Prozeßmanagement

5.6 Vorgehen beim integrierten Produktdaten- undProzeßmanagement

In den letzten Abschnitten wurde erläutert, welche Objekte zentral im Netzwerkverwaltet werden müssen und welche Zusammenhänge zwischen Prozeßdatenund Produktdaten bestehen. In diesem Abschnitt wird beschrieben, wie bei derProjektplanung und -abwicklung in virtuellen Fabriken vorgegangen wird. Bild5-13 zeigt die wesentlichen Schritte, die im folgenden ausführlich erläutertwerden.

Schritt 1Phasenplanung

Schritt 1Phasenplanung

Schritt 2Aktivitätenplanung

Schritt 2Aktivitätenplanung

Schritt 3Auftragsabwicklung

Schritt 3Auftragsabwicklung

Bild 5-13: Wesentliche Schritte bei der Projektplanung und -abwicklung

5.6.1 Phasenplanung

Bereits in einer frühen Projektphase sollte ein Projektteam gebildet werden, dasdie Auftragsplanung durchführt (Bild 5-14). Im Projektteam sind sowohl lei-tende Mitarbeiter der einzelnen Unternehmen als auch die späteren Projektbe-arbeiter vertreten. Wie bei allen Projekten wird auch hier ein Projektleiter be-stimmt, der die Projektverantwortung übernimmt. Sollte sich im Projektverlaufdie Konstellation der virtuellen Fabrik ändern, ist das Projektteam entsprechendanzupassen.


Im Anschluß an die Bildung des Projektteams wird die Grobplanung des Pro-jekts in Form einer Phasenplanung durchgeführt. Das Projektteam beginnt mitder Klärung finanzieller, terminlicher und vertraglicher Fragestellungen. Hierbringen sich vor allem die leitenden Mitarbeiter der einzelnen Partnerunter-nehmen ein. Ebenso sind auch organisatorische und I&K-technische Randbe-dingungen abzustimmen, bevor die eigentliche Phasenplanung beginnen kann.

Unternehmen A Unternehmen B Unternehmen C

Projektteam

Taktische Ebene

Operationale Ebene

PL

PL - Projektleiter

Bild 5-14: Bildung eines Projektteams

Hierbei ist folgendes Vorgehen sinnvoll (Bild 5-15):

1. Konzeption der Produktstruktur:

Auf Basis der Vorarbeiten wird eine gemeinsame Produktstruktur aufgestellt, inder die wesentlichen Baugruppen und Einzelteile enthalten sind. Es handelt sichhierbei allerdings nur um ein erstes Konzept, das im Projektverlauf ständig an-gepaßt werden muß.

2. Aufstellen eines Phasenplans:

Im nächsten Schritt werden auf Basis der Produktstruktur die Projektphasendefiniert, die notwendig sind, um das Projektziel zu erreichen. Die Phasen sind


hierbei ebenso wie die Produktstruktur zu einem frühen Planungszeitpunkt sehrvage und müssen in der Regel im Projektverlauf angepaßt werden.

3. Definition der Phasenergebnisse:

Anschließend werden die Ergebnisse definiert, die am Ende der einzelnen Pro-jektphasen vorliegen müssen. Es wird so weit wie möglich beschrieben, wel-cher Projektbeteiligte bis zu welchem Zeitpunkt welchem Mitarbeiter Ergebnis-se zum Projekt liefern muß. Da die Phasenverantwortlichen bereits definiertsind, können sich die Projektbeteiligten untereinander abstimmen. Ebenfallssind innerhalb von Projektphasen Meilensteine zu definieren, an denen Zwi-schenergebnisse vorliegen müssen. Es sollten auch mögliche Sollbruchstellenberücksichtigt werden, an denen das Projekt mit vertretbaren Verlusten ab-gebrochen werden kann.

Konzeption der Produktstruktur

Aufstellen eines Phasenplans

Definition der Phasenergebnisse

Termin:Ergebnis:Dateiformat:...

Bild 5-15: Vorgehen auf der taktischen Ebene


5.6.2 Aktivitätenplanung

Ausgehend von der Phasenplanung wird in diesem Schritt ein Wechsel von dertaktischen in die operationale Ebene vollzogen. Das Ziel in der operationalenEbene ist das Aufstellen eines integrierten Produkt- und Prozeßmodells durchdie Projektbearbeiter. In diesem Modell muß der unternehmensübergreifendeInformationsfluß abgebildet sein.

Die Beteiligten planen hierbei die erforderlichen Aktivitäten eigenverantwort-lich im Rahmen vorgegebener Termine aus dem Phasenplan. Denn nur der je-weilige Bearbeiter oder das Team hat das Detailwissen über die Aktivität,Randbedingungen und Prozeßschnittstellen. Die Prozeßverantwortung bleibtauch während der gesamten Projektlaufzeit beim Projektteam bzw. Prozeßbear-beiter bestehen. Darin sind auch die ständige Aktualisierung des Prozeßplanssowie die Problembehebung eingeschlossen. Die Projektleitung gibt in diesemRahmen nur noch Ecktermine und entsprechende Zusatzinformationen vor.

Im folgenden werden die Einzelschritte der Aktivitätenplanung genauer erläu-tert (Bild 5-16).

1. Unterteilung der Phasen in Aktivitäten:

Die Phasenverantwortlichen definieren gemeinsam mit den ProjektmitarbeiternEinzelaktivitäten, die zur Erreichung des Phasenergebnisses notwendig sind.Das Ziel ist hierbei, möglichst wenige Einzelaktivitäten zu definieren, da diesden Projektüberblick erschwert. Hierbei werden Aktivitäten soweit unterteilt,daß zumindest innerhalb einer Aktivität keine unternehmensübergreifendenSchnittstellen überwunden werden müssen.

2. Planen des Informationsflusses auf Dokumentenebene:

Die Aktivitätenverantwortlichen erweitern die Prozesse um Prozeßergebnisse,die sie von Vorgängerprozessen benötigen, um die eigenen Prozeßergebnisserechtzeitig und in ausreichender Qualität erbringen zu können. Weiterhin wer-den auch die eigenen Prozeßergebnisse vervollständigt. Dieses Vorgehen er-folgt iterativ, d. h. die erforderlichen Input-, Control- oder Output-Informa-tionen werden nach und nach von den Projektbeteiligten dezentral ergänzt. DieProjektbearbeiter haben auch die Möglichkeit, Anforderungen an vorhergehen-de Prozesse zu definieren. So wird beispielsweise die mechanische Bearbeitung


fertigungstechnische Anforderungen an die Konstruktion haben. Diese Anfor-derungen sind teileabhängig und können deshalb nicht im voraus geplant wer-den. Weiterhin wird in diesem Schritt damit begonnen, das Produktmodell auf-zubauen. Hierbei wird die Produktstruktur weiter detailliert, und Metadaten fürBaugruppen und Teile (z. B. Teilebenennung, Klassifizierung, ...) werden ver-geben. Die Produktstruktur wird im Projektfortschritt um Dokumente ergänzt,die das Produkt, die Produktionsmittel und auch den Produktionsprozeß be-schreiben (z. B. CAD-Zeichnungen oder CNC-Programme).

3. Planen des Informationsflusses auf Attributebene:

Die Informationen, die zwischen Prozessen übertragen werden sollen, könnennicht nur auf Teile- oder Dokumentenebene, sondern auch auf Attributebeneabgestimmt werden. Das Informationsobjekt (Output/Input) wird hierbei voneinem Bearbeiter definiert und mit einem beschreibenden Attribut versehen.Anschließend ergänzt ein anderer Bearbeiter das Informationsobjekt um einweiteres Attribut. Durch dieses Vorgehen können beispielsweise geometrischeAnforderungen (Ausformschrägen, Radien, ...) zwischen Geschäftsprozessenabgestimmt werden.


Unterteilung der Projektphasen in Aktivitäten

Planen des Informationsflussesauf Dokumentenebene

VerknüpfungProzeß-Dokument

Prozeß A Prozeß B

Attribut Wert

X x

Attribut Wert

X xY

Bearbeiter A Bearbeiter B

y

Planen des Informationsflusses auf Attributebene

Bild 5-16: Aktivitätenplanung auf der operationalen Ebene


5.6.3 Auftragsabwicklung

Ist die Projektplanung vorerst abgeschlossen, kann das Projekt abgewickeltwerden. Hierbei werden folgende Einzelschritte durchgeführt:

1. Verteilung von Aufgaben:

Aus den Geschäftsprozessen werden sogenannte TODOs bzw. Aufgaben gene-riert, die an die zugewiesenen Bearbeiter verteilt werden. Den TODOs sind ü-ber die Verweise (Input, Output, Control) alle für die Durchführung der Aufga-be notwendigen Informationen zugeordnet. Soll beispielsweise ein 3D-CAD-Modell weiterverarbeitet werden, so ist das entsprechende Dokument über dieDokumentenstammdaten der Produktstruktur als Input zugewiesen und er-scheint in dem TODO als Verweis (Bild 5-17). Über die vorhandenen Verbin-dungen kann diese Datei direkt zum Bearbeiter übertragen werden. Nach derDurchführung der Aufgabe werden die erzeugten bzw. geänderten Daten wie-der in dem zentralen Modell abgelegt.

...

...

...

GP 4...

D2

D3

D4

D4

...

D3

1. ...2. ...3. Augabe 4 (GP 4)4. ...

Auslöser für die Generierungvon Aufgaben:- Starttermin erreicht- Abschluß vorhergehender Prozesse- manuelles Anstoßen

Aufgaben-ListeBearbeiter A

Aufgabe 4ID: 4Input: D3 (Dokument 3)Control: D2 (Dokument 2)Output: D4 (Dokument 4)Aufgabenbeschreibung: ...

Bearbeiter A

GP - GeschäftsprozeßD - Dokumentenstamm

VerknüpfungProzeß-Dokument

aus GP 4 wird Aufgabe 4 generiert

Bild 5-17: Aus Geschäftsprozessen werden Aufgaben (TODOs) generiert und

bei den Projektbearbeitern mit Verweisen auf Dokumente eingelastet


2. Projektüberwachung

Die Integration kann weiterhin für die Projektüberwachung und -steuerungverwendet werden. Hierzu werden bestimmte Stati für Geschäftsprozesse defi-niert, die über den aktuellen Stand der Tätigkeit informieren. Mögliche Statisind:

- nicht verteilt: Dem Prozeßbearbeiter wurde der Prozeß noch nicht als Auf-gabe eingelastet.

- verteilt: Der Prozeßverantwortliche hat den Prozeß als Aufgabe in seinerAufgaben-Liste, hat allerdings noch nicht mit der Durchführung der Aufga-be begonnen.

- in Arbeit: Der Prozeßverantwortliche hat mit der Durchführung der Aufgabebegonnen.

- abgeschlossen: Die Aufgabe ist abgeschlossen.

Der Status eines Geschäftsprozesses kann entweder manuell durch die Projekt-mitarbeiter eingestellt werden, oder es wird ein Automatismus hinterlegt, derbeispielsweise einen Prozeß dann als abgeschlossen kennzeichnet, sobald dieals Output zugewiesenen Dokumente im zentralen Modell freigegeben werden.

abge-schlossen

verteilt

in Arbeit

nichtverteilt

Bild 5-18: Projektüberwachung anhand der Stati von Aktivitäten


3. Projektsteuerung

Der aktuelle Stand der Arbeitspakete wird in das zentrale Prozeßmodell zu-rückgemeldet. Dadurch kann von den Projektbeteiligten, vor allem aber vondem Projektleiter, zu jeder Zeit der aktuelle Projektstand abgefragt werden(Bild 5-18). Projektverzögerungen sind somit schnell zu erkennen. Um aufProjektverzögerungen reagieren zu können, müssen die Projektphasen und Ge-schäftsprozesse sowie deren Strukturen während der Laufzeit geändert werdenkönnen.

Diese Vorgehensweise ermöglicht eine effiziente Projektplanung und -abwick-lung in virtuellen Fabriken unter Einbeziehen des Detail-Know-hows der Pro-jektmitarbeiter.

5.7 Zusammenfassung

Das vorgestellte Konzept geht von drei entscheidenden Ansätzen aus, die auchdie wesentlichen Unterscheidungsmerkmale zum konventionellen Vorgehendarstellen:

1. Alle Daten werden über die Unternehmensgrenzen hinweg strukturiert ineinem logisch zentralen Modell verwaltet. Physikalisch können Dokumenteallerdings nach wie vor lokal bei den Unternehmen gehalten werden.

2. Die Verwaltung der Daten wird mit gemeinsamen Methoden und Werkzeu-

gen des Unternehmensnetzwerks durchgeführt und nicht mit individuellenWerkzeugen der jeweils an einer virtuellen Fabrik beteiligten Firmen. Nurzur Verarbeitung der Daten werden individuelle Anwendersysteme, wie bei-spielsweise CAD-Systeme, eingesetzt.

3. Die Produkt- und Prozeßdaten werden integriert betrachtet und die Funktio-nen zum Produktdaten- und Prozeßmanagement werden auf das integrierteModell angewendet.

Das Konzept ermöglicht somit auch in dynamischen Unternehmenskooperatio-nen eine unternehmensübergreifend strukturierte Verwaltung aller zu einemProjekt oder Produkt gehörenden Daten. Das Projekt wird ebenso wie das Pro-dukt über alle beteiligten Unternehmen hinweg transparent abgebildet.


Der unternehmensübergreifende Informationsfluß kann von allen Projektbetei-ligten gestaltet und modelliert werden. Dadurch, daß die Modellierung direktvon den Projektmitarbeitern durchgeführt wird, können nicht nur Standard-Prozesse, sondern vor allem auch ad-hoc-Prozesse abgebildet werden. Den Ge-schäftsprozessen sind hierbei Produktdaten zugewiesen, die durch die Prozessegeleitet werden. Die Projektmitarbeiter haben durch die Geschäftsprozeßmo-dellierung die Möglichkeit, ihr Detail-Know-how frühzeitig in die Planung ein-zubringen. Die teilautomatische Generierung von Aufgaben aus den Geschäfts-prozessen lastet Arbeitspakete bei den Projektbearbeitern ein. Den Aufgabensind alle zur Durchführung notwendigen Informationen zugewiesen. Durch dieteilautomatische Rückmeldung der Stati von Aufgaben liegt immer eine trans-parente Prozeßübersicht vor, auf der Verzögerungen frühzeitig zu erkennensind.

6 Softwaretechnische Umsetzung

Nachdem das Konzept erläutert wurde, wird in diesem Kapitel die software-technische Umsetzung vorgestellt. Mit der Entwicklung des Software-Prototypen wurde das Ziel verfolgt, die Brauchbarkeit des Ansatzes nachzuwei-sen. Die Umsetzung erfolgt entsprechend der in Abschnitt 4.4 spezifiziertenAnforderungen. Der Prototyp trägt die Bezeichnung UDP (Unternehmensüber-greifendes Daten- und Prozeßmanagement). UDP unterstützt die dezentralePlanung und Abwicklung von Projekten in virtuellen Fabriken. Im folgendenwerden das Datenmodell, die Architektur und die Grundlagen der Implementie-rung vorgestellt. Weiterhin werden das Funktionsmodell und die graphischeBenutzeroberfläche beschrieben.

6.1 Spezifikation des Datenmodells

Das Datenmodell muß in der Lage sein, die notwendigen Produktdaten, Pro-zeßdaten, Vorgehensweisen und Funktionen abzubilden. Auch hier stehen derintegrative Aspekt zwischen Produktdaten- und Prozeßdaten sowie die dynami-sche, unternehmensübergreifende Projektplanung und -abwicklung im Mittel-punkt der Betrachtung.

Der Standard STEP stellt vor allem im Produktdatenbereich ein umfangreichesDatenmodell zur Verfügung. Hierbei liegen bereits einige Ansätze zur Integra-tion zwischen Produktdaten- und Prozeßmodell vor (LEBER 1996). Deshalbwird der STEP-Standard als Ausgangsbasis verwendet und so angepaßt bzw.erweitert, daß das Datenmodell den Anforderungen des entwickelten Konzeptsgenügt. Nach einer kurzen Einführung in den Standard wird das Datenmodellvorgestellt, das in die Partialmodelle Prozeß, Produkt und Organisation aufge-teilt ist.

96 6.1 Spezifikation des Datenmodells

6.1.1 Produktdatennorm STEP

In Abschnitt 3.4.2.7 wurde bereits eine allgemeine Einführung in den Standardgegeben. Deshalb soll im folgenden direkt auf die Vorstellung das ApplicationProtocol AP 214 übergegangen werden, das sich auf die organisatorischen Da-ten konzentriert und als Basis für das zu entwickelnde Datenmodell verwendetwird.

6.1.1.1 Einführung

Das im Rahmen der ISO 10303 entwickelte Application Protocol AP 214 be-schreibt Datenstrukturen, die zur Abbildung von technischen Informationen imKernbereich der mechanischen Entwicklung relevant sind.

Wie in Bild 6-1 abgebildet, können neben CAD-spezifischen Daten zur Abbil-dung von Geometrie und technischen Zeichnungen in den durch das AP 214definierten Datenstrukturen Informationen zu den Bereichen

- Stammdaten (z. B. Freigabe, Version),

- Strukturdaten (z. B. Zusammenbauten, Stücklisteninformation),

- Konfiguration und Aufträge,

- Arbeits- bzw. Methodenpläne,

- Form Features,

- technische Eigenschaften (z. B. Masse, Trägheitsmomente, Material, Re-cyclingeigenschaften, Toleranzen, Oberflächeneigenschaften) sowie zu

- Teilbereichen aus Berechnung bzw. Simulation dargestellt werden (STEP1995).

6 Softwaretechnische Umsetzung 97

Produktgliederung

Konfigurationsdaten

Strukturdaten

Eigenschaften

Teil

Teile-Version

Teile-Beschreibung

Klassifizierungsdaten

Auftragsdaten

Prozeßplandaten

Technische

Externe Dokumente Form Features

Produktgliederung

Konfigurationsdaten

Strukturdaten

Eigenschaften

Teil(Bauteil oder Betriebsmittel)

Teile-Version

Teilesicht(Berechnung, Konstruktion)

Teile-Beschreibung

Klassifizierungsdaten

Auftragsdaten

Stammdaten(Ersteller, Freigabe)

Prozeßplandaten

Dokumentenstrukturen

Technische Zeichnungen

Toleranzen und Oberflächenbeschaff.

Berechnung/Simulation

Externe Dokumente(native Dateien)

Gestaltsdaten(Draht-, Flächen-, Solidgeom.)

Form Features

Anmerkung: Linien repräsentieren Beziehungen zwischen den Datentypen

Bild 6-1: Informationen im Application Protocol AP214 (STEP 1995)

6.1.1.2 Modellierung mit EXPRESS-G

Zur konsistenten, widerspruchsfreien und semantisch eindeutigen Beschreibungdes Produktmodells von STEP wurde die formale BeschreibungsspracheEXPRESS und deren graphische Repräsentation EXPRESS-G definiert.EXPRESS ist Bestandteil von STEP und unter der Nummer ISO 10303-11 ver-öffentlicht. EXPRESS ist eine Spezifikationssprache (keine Programmierspra-che) zur logischen Beschreibung von Informationsmodellen und eignet sichauch zur Informationsmodellierung außerhalb des Gültigkeitsbereichs vonSTEP.


Bild 6-2 erläutert die Konstrukte der EXPRESS-G Notation, die im Rahmender Arbeit eingesetzt werden. Erweiterungen der Norm werden mit einem grau-en Hintergrund gekennzeichnet. Für eine umfassende Einführung in die Daten-modellierung mit EXPRESS sei auf das "EXPRESS Language Reference Ma-nual" (ISO 10303-11) sowie auf die detaillierten Ausführungen zur EXPRESS-Datenmodellierung von SCHENK & W ILSEN (1994) verwiesen.

document_view external_document

external_document_version

external_document_assignment

document_relationship

relating related

assigned_document

relation_type description

role

is_assigned_to

external_document_selectprocess_schema;

activity

process_schema;work_order

id

external_document

id

name description

Erweiterungen des STEP-Standards

Entitäten

Auswahldatentyp SELECT

notwendiges Attribut

optionales AttributSUBTYPE Relation

Verweise zwischen verschiedenen Schemata

Schemaname

Entitätenname

Bild 6-2: Verwendete EXPRESS-G Elemente

6.1.2 Übersicht über das Gesamtmodell

Die Übersicht ist in der graphischen Notation EXPRESS-G dargestellt. DasDatenmodell ist in Module, sogenannte Schemata, bestehend aus logisch grup-


pierten Informationseinheiten (Entities), aufgeteilt. Dabei handelt es sich imwesentlichen um Schemata zur Repräsentation von

- Prozeßdaten (process_schema),

- Produktdaten (product_schema) und

- Organisationsdaten (organization_schema).

Bild 6-3 gibt eine vereinfachte Übersicht über das Modell und läßt die Integra-tion der einzelnen Teilmodelle über den neu hinzugefügten Datentyp as-

signment_element_select gut erkennen. Über Auswahldatentypen können vari-able Verbindungen zwischen unterschiedlichen Entitäten abgebildet werden. Imkonkreten Fall sind folgende Verbindungen möglich:

Vom Partialmodell "Produkt" (product_schema) können die Entitäten item

(Teil), ddid29 (Sicht auf Teil), external_document (Dokument) und docu-

ment_view (Dokumentensicht) mit den Entitäten project (Projekt), activity

(Projektphase bzw. Geschäftsprozeß) und activity_view (Sicht auf eine activity)des Partialmodells "Prozeß" (process_schema) verknüpft werden. Ergänzt wirddas Modell durch eine integrierte Benutzer- und Rollenverwaltung, die im Par-tialmodell "Organisation" (organization_schema) abgebildet ist.

Bei der Erstellung des Datenmodells wurde darauf geachtet, daß diejenigen In-formationen berücksichtigt werden, die in dem gemeinsamen System abgebil-det werden. Alle Informationen, die während der Projektabwicklung über stan-dardisierte Schnittstellen zwischen den Unternehmen ausgetauscht werden,können vernachlässigt werden. So hat das entwickelte Konzept beispielsweisekeinen Einfluß auf den Austausch von Geometriedaten im IGES-, VDA-FS-oder STEP-Format. Diese Geometriedaten werden als Dokumente in dem zent-ralen System verwaltet und können auch über das System ausgetauscht werden.Die Inhalte dieser Dokumente werden allerdings nicht betrachtet. Eine Integra-tion auf dieser detaillierten Ebene ist zwar prinzipiell möglich, für den Einsatzin virtuellen Fabriken würde diese Integrationstiefe allerdings die Flexibilität zusehr einschränken. KAISER (1997) beschreibt beispielsweise eine Integration

29 ddid – design_disciplin_item_definition


zwischen Produkt- und Produktionsdaten auf Feature-Ebene, die in dieser Tiefenicht in dynamischen Unternehmenskooperationen eingesetzt werden kann.

Produktdatenproduct_schema

Prozeßdatenprocess_schema

Organisationorganization_schema

activity_view

person_role

document_view

external_document

project

activity

ddid

item

person

organization

assignment_element_select

object_assignment access_mode

Bild 6-3: Prinzipielle Darstellung der Integration der Produktdaten mit den

Prozeßdaten über die Erweiterung "assignment_element_select" (grau hinter-legte Felder sind Erweiterungen des STEP-Standards)

In den folgenden Abschnitten werden die Schemata des integrierten Produkt-und Prozeßmodells erläutert.

6.1.3 Partialmodell "Prozeß"

Im process_schema, das in Bild 6-4 dargestellt ist, werden Projekte (project)mit geplanten und tatsächlichen Start- und Endzeiten (actual_start_date, actu-


al_end_date, planed_start_date, planed_end_date) verwaltet. Über Beziehun-gen zwischen Projekten (project_relationship) können Projektstrukturen defi-niert werden. Einem Projekt sind Prozesse (activity) zugeordnet. Prozesse stel-len hierbei Projektphasen und auch Geschäftsprozesse dar. Dies wird über denTyp (type) des Prozesses angegeben. Ein Prozeß hat zudem eine Beschreibung(description) und einen Status (status). Prozesse können hierbei die in Kapitel 2beschriebene Stati einnehmen.

Projektphasen können ebenso wie Geschäftsprozesse zueinander in Beziehunggestellt werden (activity_relationship). Prozesse auf einer Ebene können Vor-gänger-Nachfolger-Beziehungen haben. Die Darstellung paralleler Prozesseerfolgt über das Objekt simultaneous_activity.

Prozesse können aber auch ohne Beziehung zueinander stehen, wie dies zumBeispiel bei der Anordnung von Projektphasen sinnvoll ist. Meilensteine sindbesondere Ausprägungen von Prozessen (type = "gateway"). Über Eltern-Kinder-Beziehungen werden Geschäftsprozesse Projektphasen untergeordnet.

Prozesse können mit Teilen (item, wobei ein Teil ein Produkt, eine Baugruppeoder ein Bauteil sein kann) und Teileversionen (item_version) verknüpft wer-den. Den Prozessen sind Rollen (person_role) zugewiesen, welche den Prozeßdurchführen. Es gibt die Möglichkeit, zwischen Prozessen und Organisations-einheiten Verträge (contract, organization) abzuschließen. Prozesse werdenüber einen Auftrag (work_order) bei Bearbeitern eingelastet. Dieser Auftragenthält alle notwendigen Informationen über den durchzuführenden Prozeß.

Um zum einen ein umfassendes transparentes Prozeßmodell zu modellieren undzum anderen vertrauliche Informationen vor unerlaubtem Zugang zu schützen,wurde das STEP-Modell um Sichten auf Prozesse erweitert. Hierfür wurdenmehrere Objekte eingeführt. Das zentrale Objekt ist die activity_view. Sie be-schreibt eine Ansammlung von Prozessen, die Personen oder Organisationenzugewiesen werden kann. Auf diese Weise kann sichergestellt werden, daß je-der Person nur die Informationen über das Prozeßmodell zur Verfügung gestelltwerden, die für diese Person auch bestimmt sind. Über die Zuweisung von E-lementen (activity_view_element) kann gesteuert werden, daß Prozesse zwarsichtbar sind, auf zugewiesene Elemente aber nicht zugegriffen werden kann.


id

name description

work_order

simultaneous_activity

activity_view_assignment

activity_view

activity_access_mode

activity_view_element_select

contract

organization_in_contract

project_relationship

id

version_id description work_order_type

relation_typerelating

related description

id description

organization_schema;date_time

organization_schema;event_or_date_select

organization_schema;period_or_date_select

actual_start_date

actual_end_date

planned_start_date

planned_end_date

actual_start_date

actual_end_date

planned_start_date

planned_end_date

work_program S[0:?]

description

element S[2;?]

organization_schema;person_role

ttype

status

description

id

activity_relationship

related relating

relation_type

description

work_request

product_schema;item_version

organization_schema;date_and_person_to_or

ganisation

integrated_schemaassignment_element_

select

contracted_element_select

contracted_element

contractS[1:?]

organization_schema;organization

id

name type

id

name description

used_activity

project

activity_element

activity_element_select

product_schema;item

used_activity_view

element

access_mode

id

activity

supplying_organization

concerned_organization

type

Bild 6-4: process_schema

Einen wesentlichen Aspekt der vorgestellten Methodik stellt die im Konzeptbeschriebene Abbildung des Informationsflusses auf Basis der SADT-Methodedar. Das STEP-Modell wurde hierfür so erweitert, daß Beziehungen zwischen


Prozeßsichten (activity_view), Dokumentsichten (document_view) und Projek-ten (project) definiert werden können. Unter Einbeziehung des Prozeßelementskönnen die Dokumente den Aufgabenlisten (work_order) zugeordnet werden.Die Benutzer erhalten dadurch in ihren Rollen TODOs eingelastet, denen nebender Aufgabenbeschreibung die notwendigen Dokumente mit den jeweiligenDateinamen und Speicherorten zugeordnet sind.

Weiterhin unterstützt das Modell die Verknüpfung von Prozessen mit Hilfe vonInput-, Control- und Output-Elementen. Hierfür werden den zugeordneten Ob-jekten über das Attribut type des Objektes activity_view_assignment die TypenInput, Output und Control zugewiesen. Möchte ein Projektmitarbeiter bei ei-nem anderen Projektmitarbeiter Informationen bezüglich der Gestaltung einerSchnittstelle anfragen, so wird dies über das Objekt work_request realisiert. DieRelation zum zugehörigen Prozeß sorgt dafür, daß der Bearbeiter weiß, aufwelchen Prozeß sich die Anfrage der gemeinsamen Schnittstellengestaltungbezieht.

6.1.4 Partialmodell "Produkt"

Im product_schema sind Objekte aufgeführt, die im wesentlichen die Produkt-struktur, Teile und Dokumente sowie zugehörige Stammdaten verwalten (Bild6-5).

Produkte, Baugruppen und Bauteile stellt das Objekt item dar, das im folgendenals Teil bezeichnet wird. Für Teile existieren Versionen (item_version), diewiederum zueinander im Verhältnis stehen (item_version_relationship). Da-durch kann die Historie von Teileversionen nachvollzogen werden. Den Teile-versionen sind wiederum Teilesichten bzw. Verwendungszwecke (de-

sign_discipline_item_definition) zugeordnet. Entsprechend einer Aufgabe odereines Zwecks können dadurch gewisse Produktdaten ausgewählt werden.

Zur Beschreibung von Baugruppenstrukturen wird der Objekttypnext_higher_assembly verwendet. Er definiert ein Element der Baukasten-stückliste. Die Baukastenstückliste einer Baugruppe ergibt sich somit durch dieMenge aller Baugruppenstrukturbeziehungen, die zu einer Baugruppe definiertsind. Die Strukturstückliste ergibt sich aus der mehrstufigen hierarchischenAnordnung von Baugruppenstrukturbeziehungen, d. h. der mehrstufigen hierar-


chischen Anordnung von Unterbaugruppen und Einzelteilen. Um für verschie-dene Einsatzbereiche unterschiedliche Baugruppenstrukturen beschreiben zukönnen, bezieht sich der Objekttyp next_higher_assembly auf den ObjekttypVerwendungszweck (design_discipline_item_definition).

Über die STEP-Erweiterung assignment_element_select können Projektbear-beitern unterschiedliche Sichten und Zugriffsrechte auf Bereiche der Produkt-struktur eingeräumt werden. Die Rechte werden vererbt, d. h. wenn eine Bau-gruppe einem Benutzer nicht zur Anzeige freigegeben wird, dann sind auch alleEinzelteile und zugehörigen Elemente der Baugruppe für den Benutzer ge-sperrt.

Produkte, Baugruppen, Bauteile, Produktionsdaten usw. werden häufig mit Hil-fe von Dokumenten beschrieben und abgespeichert. In virtuellen Fabriken wer-den die einzelnen Schritte der Wertschöpfungskette in unterschiedlichen Unter-nehmen durchgeführt und die Dokumente sind deshalb auf mehrere Unterneh-men verteilt. Trotzdem muß aber im integrierten Produktdaten- undProzeßmodell eine integrierte Verwaltung der Dokumente umgesetzt werden.Zu diesem Zweck werden externe Dokumentbeziehungen (exter-

nal_document_assignment) definiert, die auf digitale Dokumente (digi-

tal_model) verweisen. Die digitalen Dokumente besitzen einen Dateinamen(file_name) und einen Speicherort (location), der auf den Daten-Server desUnternehmens zeigt, auf dem dieses Dokument physikalisch gespeichert ist.Dokumente können nach Dokumenttypen (document_type, z. B. CAD-Daten)unterschieden werden und sie können auch versioniert werden (exter-

nal_document_version).

Die Dokumentenverwaltung des AP 214 wurde um Dokumentsichten (docu-

ment_view) erweitert. Dadurch können anwendungsspezifisch unterschiedlicheSichtweisen der Dokumentenstammdaten erzeugt werden, was vor allem auchin Bezug auf die Vertraulichkeit von Informationen von Bedeutung ist. Hierfürsind mit dem Objekt access_mode entsprechende Zugriffsrechte definiert. Do-kumente können nicht nur Teilesichten (ddid) sondern auch Projekten (project)zugeordnet werden. Typische Dokumente, die Projekten zugewiesen werden,sind beispielsweise Produktspezifikationen oder Projektkalkulationen.


document_view

document_view_element

document_view_assignment

external_document

external_document_version

digital_model

external_document_assignment

document_type

document_relationship

design_discipline_item_definition

item_versionitem

item_version_relationship

object_assignment

access_mode

associated_item

relating related

relating related

assigned_document

id

relation_type description

role

is_assigned_to

external_document_select

process_schema;activity

process_schema;project

process_schema;work_order

document_type

id

selected_element

selected_document_view

external_document

file_name

location

associated_item_version

relation_type

used_access

id

id name

description

approval_element_select

id

id name description

process_schema;activity_view_assign

assignment_element_select

organization_schema;person_role


id name description

used_element

is_applied_to S[1:?]

id name

assembly_definition

assembly_component_relationship

specific_higher_usagepromissory_usage next_higher_assembly

upper_usage

1

relating

assembly_type

approval_status

id

name

approvalapproval_

status

relatedrelating

relation_type

approval_relationship

Bild 6-5: product_schema


6.1.5 Partialmodell "Organisation"

Die wesentlichen Objekte im Partialmodell Organisation sind Personen, Rollenund Organisationseinheiten. Das Partialmodell ist in Bild 6-6 dargestellt.

Eine Organisationseinheit (organization) kann ein Unternehmen, eine Abtei-lung oder auch eine virtuelle Fabrik sein. Organisationseinheiten stehen in un-terschiedlichen Beziehungstypen (relation_type bei organization_relationship)zueinander. So ist beispielsweise eine Abteilung einem Unternehmen unterge-ordnet, während ein Unternehmen wiederum Partner in einer virtuellen Fabrikist. In den Organisationseinheiten befinden sich Personen (person), wobei einePerson auch in mehreren Organisationseinheiten vertreten sein kann.

Um die Flexibilität des Gesamtmodells aufrecht zu erhalten, wird das STEP-Modell im Bereich der Personenverwaltung um den Objekttyp Rolle (per-

son_role) erweitert. Eine Person kann beispielsweise in einem Projekt als Pro-jektleiter fungieren und in einem anderen Projekt als Projektmitarbeiter. EinerRolle sind eine oder mehrere Personen zugewiesen.

Rollen können ebenfalls mit Sichten verknüpft werden. Sichten sind sowohl fürdas Produkt- als auch für das Prozeßmodell möglich. Je nach Sichtweise wer-den dem Bearbeiter bestimmte Informationen angezeigt.

Das Partialmodell Organisation beinhaltet weiterhin allgemeine organisatori-sche Daten, wie beispielsweise Datum (date) und Uhrzeit (time), die den unter-schiedlichen Objekten zugewiesen werden können.


person_in_organization

date_and_person_or_organization

organization_relationship

relating related

relation_type

person_or_organization_select

person S[1:?]

organization

organization

person_or_organization

actual_date

assigned_date_time

is_applied_to

assigned_date_and_person

is_applied_to

is_applied_to

assigned_person_or

organization

role

person_role

role_status

actual_status

assigned_person

authorized_release

product_schema;object_assignment

is_approved_by

assigned_person

period_or_date_select event_or_date_select

event_referenceext. reference: G23

value_with_unit

process_schema;organization_in_contract

product_schema;approval

person_role

general_organization_data_select

process_schema;work_request

process_schema;project

process_schema;activity_element

product_schema;item_version


product_schema;external_document

product_schema;item

id

name description

event_type

date_time date time

person

name id

adress

date_and_person_assignment

role

date_time_assignment

role

id

name typeperson_or_organization_assignment

Bild 6-6: organization_schema

108 6.2 Architektur von UDP

6.2 Architektur von UDP

Nach der Beschreibung des Datenmodells wird in diesem Abschnitt die Archi-tektur des Softwarewerkzeugs vorgestellt (Bild 6-7). Den Anforderungen ent-sprechend ist das System durch den Einsatz moderner I&K-Technologien ge-prägt. Den Kern des Systems bildet ein Datenbanksystem mit einem Web-Server, auf dessen Basis das Datenmodell implementiert ist. Auf diesem zent-ralen Server werden die Metadaten des integrierten Produkt- und Prozeßmo-dells gespeichert. Die Nutzdaten liegen in Form von Dokumenten auf denNetzwerksystemen der Partnerunternehmen. Der Server steht bei einem belie-bigen Unternehmen im Unternehmensnetzwerk. Es wäre aber auch denkbar,daß der Server von sogenannten VANS30 betrieben wird.

Bei einer Anfrage über einen UDP-Client werden Metadaten (Teilestamm, Pro-duktstruktur, Dokumentenstamm, Prozeßstruktur, ...) direkt aus dem zentralenDatenserver zum Anwender übertragen. Werden Dokumente angefragt, wirdüber einen Hyperlink auf die Datenbank oder das File-System des Projektpart-ners zugegriffen und die Daten werden über das Internet übertragen. Bei derMetadatenverwaltung wird somit das Prinzip des Data-Sharing, also der ge-meinsamen Nutzung von Daten verfolgt, während bei den Dokumenten nachdem Prinzip des Data-Exchange verfahren wird (vgl. Abschnitt 3.4.2.7).

30 Bei VANS (Value Added Network Services oder auf deutsch Mehrwertdienste) wird die

Datenübertragung von Drittanbietern durchgeführt (MAK 1998).


Programme

// importimport java.appletimport java.awt.*import java.net.*;...

DB/FilesystemvirtuelleFabrik

AB

DB/FilesystemUnternehmen

B

DB/FilesystemUnternehmen

A

Anfrageüber Web-Client

Oracle & Oracle WebSystem

Prozeßdaten

Produktdaten

Dokumente

Dokumenten-anfrage

DownloadFile

ÜbertragungsmediumInternet

JAVA

UDPServer

UDPClient

UDPClient

Bild 6-7: Architektur von UDP

6.3 Grundlagen der Implementierung

6.3.1 Datenbanksystem und Programmiersprache

Im Rahmen der Evaluierung wurde das relationale Datenbanksystem Oracleund der Oracle7 WebServer eingesetzt. Dieser kann durch das dynamische

110 6.3 Grundlagen der Implementierung

Auslesen von Daten aus der Oracle Datenbank dynamische HTML31-Seitenerzeugen. Durch die Übergabe einer URL32 werden PL/SQL33-Prozeduren ge-startet und HTML-Seiten dynamisch generiert.

Die Funktionen zum Modellieren von Prozeß- und Produktstrukturen wurden inder Programmiersprache JAVA umgesetzt. JAVA ist eine noch sehr junge Pro-grammiersprache, die von SUN Microsystems entwickelt wurde. Mit Hilfe vonJAVA können Programme unabhängig vom Betriebssystem und der Hardware-Plattform entwickelt und benutzt werden. Der Grund für diese Eigenschaft istfolgende prinzipielle Funktionsweise von JAVA (vgl. FLANAGAN 1996):

1. Das Programm wird durch den Entwickler zu Byte-Code kompiliert, der andie Anwender verteilt wird.

2. Auf dem Rechner des Anwenders nimmt ein Interpreter34 den kompiliertenByte-Code auf und wandelt ihn in Maschinen-Instruktionen um, die derComputer des Anwenders verstehen kann. Hierfür ist allerdings beim An-wender eine sogenannte Virtual Machine35 erforderlich.

Mit JAVA können zwei unterschiedliche Software-Typen entwickelt werden:Applikationen und Applets. Applikationen sind vollwertige Programme undkönnen ohne Internet-Browser ausgeführt werden. Applets müssen dagegen inWeb-Dokumente integriert werden (FLANAGAN 1996).

31 HTML – Hypertext Markup Language

32 URL – Uniform Ressource Locator: Die URL ist quasi die "Telefonnummer" oder die Adres-

se, um einen bestimmten Rechner bzw. eine bestimmte Information im Internet anzuwählen.

Die URL bestimmt dabei auch das Übertragungsprotokoll, also die Art des Informationsaus-

tausches.

33 PL/SQL – Procedural Language SQL: PL/SQL ist eine modulare Spracherweiterung von

SQL (Structured Query Language) und ermöglicht, daß Datenbankabfragen in eine Ablauflo-

gik innerhalb eines Programms integriert werden können. Hierbei stehen Datentypen zur

Verfügung, die ebenfalls in der Datenbank verwendet werden.

34 unterschiedliche Betriebssysteme erfordern unterschiedliche Interpreter

35 eine Virtual Machine ist eine Software, die den JAVA Byte-Code interpretiert und in be-

triebssystemspezifische Befehle übersetzt


6.3.2 Vorteile durch die eingesetzten Technologien

Die in UDP verwendeten I&K-Technologien führen zu folgenden Vorteilen:

- Weltweite Nutzungsmöglichkeit: In fast jeder virtuellen Fabrik sind unter-schiedliche Unternehmenskonstellationen vorzufinden. Das Internet alsKommunikationsmedium ermöglicht die informationstechnische Verknüp-fung beliebiger Unternehmen.

- Direkter Zugriff auf Datenbankinhalte und externe Dokumente: SogenannteHyperlinks auf beliebige Informationen ermöglichen den direkten Zugriffauf das Produkt- und Prozeßmodell und die darin zugeordneten physikali-schen Dokumente.

- Redundanzfreiheit: Teile- und Dokumentenstamm, Produktstruktur, Pro-zeßmodell und die organisatorischen Daten werden in dem zentralen Modellgespeichert und sind dadurch redundanzfrei.

- Datenaktualität: Durch die logisch zentrale Datenhaltung wird gewährleis-tet, daß alle Benutzer auf dasselbe Modell zugreifen. Werden Modifikatio-nen durch autorisierte Projektmitarbeiter durchgeführt, so stehen diese Än-derungen sofort allen Benutzern zur Verfügung.

- Software-Aktualität: Dadurch, daß bei jedem Aufruf das Applet mitübertra-gen wird, steht jederzeit allen Benutzern die aktuellste Softwareversion zurVerfügung. Allerdings muß berücksichtigt werden, daß dieses Vorgehenauch längere Ladezeiten mit sich zieht.

- Zeit- und Ortsunabhängigkeit: Durch die Nutzung von E-Mail-Funktionenkönnen Informationen von Projektmitarbeitern aktiv angefordert und Auf-gabenpakete aktiv verteilt werden. Liegezeiten von Informationen werdendadurch minimiert. Mitarbeiter können zeit- und ortsunabhängig erreichtwerden.

- Keine Installation auf Seiten der Clients erforderlich: Dadurch, daß dieProgramme zentral auf einem Web-Server installiert werden und dort beiBedarf von den Nutzern heruntergeladen werden, sind auf Client-Seite keineInstallationen erforderlich. Es müssen lediglich ein Standard-Internet-Zugang und ein Standard-Web-Browser vorhanden sein.

112 6.4 Funktionsmodell und graphische Benutzeroberfläche

- Plattformunabhängig: Alle Funktionen können über das Internet aufgerufenund plattformunabhängig genutzt werden. Dadurch kann das System sowohlan einem UNIX-basierten CAD-Arbeitsplatz als auch an einem einfachenPC für Office-Anwendungen genutzt werden. Da die Software sowohl inder taktischen als auch operationalen Ebene eingesetzt wird, ist dies unbe-dingt erforderlich.

6.4 Funktionsmodell und graphische Benutzeroberfläche

Im Funktionsmodell sind die Funktionen abgebildet, die das System zur Verfü-gung stellt. In Bild 6-8 sind die Hauptfunktionen von UDP dargestellt. Die ein-zelnen Funktionsbereiche werden im folgenden erläutert.

Funktionen zur Benutzerverwaltung:Mit den Funktionen der Benutzerverwaltung werden Personen definiert, indemAngaben über die Person sowie über die zugehörige Organisationseinheit ge-macht werden. Die Rollenverwaltung ermöglicht die Definition von projektspe-zifischen Rollen und die Zuordnung von beliebigen Personen zu Rollen. Überdie Rechteverwaltung kann die projektphasen- und produktstrukturabhängigeZugriffsregelung gesteuert werden (vgl. Abschnitt 5.3 und 5.4). Die Funktionender Benutzerverwaltung sind prinzipiell nur für den Systemadministrator zu-gänglich. Dieser ist verantwortlich für die Verwaltung der Personen. Innerhalbeines Projekts hat auch der Projektleiter Zugriff auf die Verwaltungsdaten undkann projektspezifisch Rollen definieren.

Funktionen zur Produktdatenverwaltung:Neben der Benutzerverwaltung ist der zweite Hauptfunktionsbereich die Pro-

duktdatenverwaltung. Mit diesen Funktionen können Produkte, Baugruppenund Bauteile mit definierbaren Attributen, wie beispielsweise "Teilebezeich-nung", "ID", "Klassifizierung", "Status" und "Eigner", angelegt und geändertwerden. Weiterhin besteht die Möglichkeit, Dokumentenstämme anzulegen undmit den beschriebenen Objekten in Verbindung zu setzen. Die Dokumenten-stammdaten beinhalten hier u. a. den Namen und den Speicherort der physikali-schen Datei. Aus Einzelteilen und Baugruppen kann mit einem JAVA-Appleteine Produktstruktur erzeugt und geändert werden (Bild 6-9).


Prozeß-verwaltung

Projektanlegen

Projektanzeigen

Projektändern

Projektlöschen

Prozeßanlegen

Prozeßanzeigen

Prozeß ändern

Prozeß löschen

Aufgabenanlegen

Aufgabenanzeigen

Aufgabenändern

Aufgabenlöschen

Projektstrukturbearbeiten

UDP

Produktdaten-verwaltung

Produktanlegen

Produktanzeigen

Produktändern

Produktlöschen

Baugruppe/Teilanlegen

Baugruppe/Teilanzeigen

Baugrupe/Teiländern

Baugruppe/Teillöschen

Dokumentanlegen

Dokumentanzeigen

Dokumentändern

Dokumentlöschen

Benutzer-verwaltung

Personen-verwaltung

Rollen-verwaltung

Rechte-verwaltung

Produktstrukturbearbeiten

Bild 6-8: Vereinfachtes Funktionsmodell von UDP

114 6.4 Funktionsmodell und graphische Benutzeroberfläche

Stammdaten undVerweise auf externe Dokumente

Produktstruktur

Bild 6-9: Graphische Benutzeroberfläche zum Anlegen und Ändern von Pro-

duktstrukturen

Funktionen zur Prozeßverwaltung:Mit der Funktion Projekt anlegen der Prozeßverwaltung können neue Projektedefiniert werden. Hierfür stehen Attribute, wie beispielsweise "Projektname","Auftraggeber", "beteiligte Unternehmen" sowie "Plankosten" und "Plantermi-ne", zur Verfügung. Dem Projekt können Pflichtenhefte in Form von Doku-menten zugewiesen werden, die mit Funktionen der Produktdatenverwaltungangelegt werden. Die weiteren Projektfunktionen dienen zum Anzeigen, Än-dern und Löschen von Projektstammdaten.

Die Funktion Prozeß anlegen ermöglicht die Definition von Projektphasen oderGeschäftsprozessen. Die Prozesse werden in der Planungsphase durch die"Spezifikation der Aufgabe", "geplante Kosten" und "geplante Dauer" sowiezugeordnete Objekte beschrieben. Die "tatsächlichen Kosten" und "tatsächlicheDauer" werden im Projektverlauf eingetragen. Hierbei können den ProzessenTeile oder Dokumente zugewiesen werden. Prozesse können angezeigt, geän-dert oder gelöscht werden.


Aus mehreren Einzelprozessen kann mit dem JAVA-Applet Prozeßstruktur

bearbeiten ein Prozeßnetz aufgebaut werden. Projektphasen können hierbeigenauso modelliert werden wie Geschäftsprozesse. Hierbei ist es möglich, Vor-gänger-Nachfolger-Beziehungen oder Eltern-Kinder-Beziehungen festzulegen.Bild 6-10 zeigt die Darstellung eines Projektphasenplans in der Balkenplanan-sicht.

Bild 6-10: Graphische Oberfläche eines Prozeßnetzes in der Balkenplanansicht

Neben der Anordnung von Prozessen zueinander dient dieses Applet auch derZuordnung von Rollen und Dokumenten zu Prozessen, wie in Bild 6-11 darge-stellt ist. Weiterhin werden der kritische Pfad berechnet sowie eine Plan- undIst-Kostenberechnung auf Basis der von den Benutzern eingegebenen Angabendurchgeführt. In der Netzplanansicht sind die Stati der Prozesse ausschlagge-bend für die farbliche Darstellung. Daran kann sofort erkannt werden, in wel-chem Status sich ein Prozeß befindet. Die Verteilung der Prozesse in Form vonAufgaben mit allen zu dem Prozeß gehörenden Informationen wird von der so-genannten Workflow-Engine in UDP durchgeführt. Diese generiert aus den Pro-zessen Aufgaben und lastet diese bei Bearbeitern ein (siehe auch Abschnitt5.6.3).


Kritischer Pfad

Projekttermine

Projektkosten

ModellierungsfunktionenDokumente,

Rollen, Prozesse

Bild 6-11: Graphische Benutzeroberfläche zum Anlegen und Ändern von Pro-

zeßstrukturen

Aufgaben können auch jederzeit unabhängig von Projekten definiert werden.Aufgaben werden den Bearbeitern in TODO-Listen vorgelegt. Diese Listenbeinhalten alle für die Durchführung der Aufgabe notwendigen Informationenund Verweise auf Produktdaten und Dokumente.

6.5 Zusammenfassung

Für die DV-technische Umsetzung des entwickelten Konzepts ist ein Datenmo-dell erforderlich. Ausgehend von einem Teilmodell des Application ProtocolAP 214 der Produktdatennorm STEP wurde mit der formalen Spezifikations-sprache EXPRESS-G ein erweitertes Datenmodell entwickelt. Die wesentlichenErweiterungen sind Sichten auf Produktstrukturen, Dokumentenstammdaten


und Prozesse. Weiterhin wurden zusätzliche Verknüpfungen zwischen Pro-duktdaten und Prozeßdaten eingefügt.

Das Datenmodell wurde in einer relationalen Datenbank abgebildet. Der Be-trieb von UDP erfordert einen UDP-Server, der bei einem Partnerunternehmenim Netzwerk oder auch außerhalb des Netzwerks betrieben werden kann. UDP-Clients können aufgrund des konsequenten Einsatzes von Internet-Technologien vollständig über Internet-Browser bedient und dadurch plattform-unabhängig eingesetzt werden. Die eingesetzten Technologien ermöglichensomit einen flexiblen Einsatz des Softwaresystems in beliebigen Unterneh-menskonstellationen.

7 Anwendungsszenario am Beispiel des RP-Net.de

Um das entwickelte Konzept zum integrierten Produktdaten- und Prozeßmana-gement in virtuellen Fabriken zu evaluieren, soll im folgenden ein Anwen-dungsszenario beschrieben werden. Hierzu wird das vom iwb betriebene RapidPrototyping Netzwerk RP-Net.de gewählt, das bereits in Abschnitt 2.4 kurzvorgestellt wurde.

Einleitend folgt zum besseren Verständnis eine Einführung in die TechnologieRapid Prototyping / Rapid Tooling. Anschließend wird erläutert, wie das ent-wickelte Konzept einschließlich des Softwaresystems UDP in dem Netzwerkeingesetzt werden kann.

7.1 Einführung Rapid Prototyping / Rapid Tooling

Unter dem Begriff Rapid Prototyping (RP) werden in der Fachliteratur alleFertigungsverfahren zusammengefaßt, die dreidimensionale Körper durchschichtweisen Aufbau erzeugen. Eingesetzt werden diese Verfahren für denModell- und Prototypenbau von komplexen Bauteilen, um in frühen Entwick-lungsphasen Geometrie-, Design- oder Funktionsprüfungen durchzuführen. DerVorteil von Rapid Prototyping besteht darin, daß ausgehend von den 3D-CAD-Daten in wenigen Stunden Bauteile, unabhängig von der Komplexität, herge-stellt werden können (MACHT 1997).

Rapid Prototyping Verfahren eignen sich für die Herstellung von Bauteilen inder Stückzahl 1. Wird eine höhere Stückzahl eines Modells gefordert, könnenFolgeverfahren, wie beispielsweise das Abformen oder Abgießen, eingesetztwerden (GEUER 1996). Es besteht auch die Möglichkeit, mit Rapid PrototypingVerfahren nicht das Positiv eines Bauteils, sondern das Negativ als Formeinsatzzu fertigen (FÄHRER 1998). Zusammen mit einem Formrahmen wird dann dasPrototypenwerkzeug aufgebaut, und die Bauteile können im Serienverfahrenhergestellt werden. Dieses Vorgehen wird als Rapid Tooling (RT) bezeichnet.Darunter versteht man das schnelle Herstellen von Prototypenwerkzeugen mitHilfe von innovativen Verfahren, wie beispielsweise dem Metall-Lasersintern

120 7.2 Unternehmensnetzwerk RP-Net.de

oder dem High Speed Cutting (HSC36) (REINHART & BREITINGER 1997). MitRapid Tooling können nicht nur frühe Geometrie- und Funktionsüberprüfungenam Bauteil durchgeführt werden, sondern es kann auch derFertigungsprozeß evaluiert werden (BULLINGER U. A. 1996). Sowohl RapidTooling als auch Rapid Prototyping werden typischerweise von externenDienstleistern bezogen. Gründe hierfür sind die hohen Investitionen in RP/RT-Anlagen und das notwendige Spezialwissen zum Bedienen dieser Anlagen(REINHART & BRANDNER 1998).

Mit den technologischen Weiterentwicklungen beim Rapid Prototyping undRapid Tooling wird das Ziel verfolgt, den Einsatzbereich der Prototypen undModelle zu erweitern. Um dieses Ziel zu erreichen, werden ständig neue Mate-rialien und neue Fertigungsprozesse entwickelt. Dies führt zu einer Vielzahlvon Verfahren und Verfahrenskombinationen, die allein in Deutschland aufüber 100 Dienstleister verteilt sind (MACHT 1999). Für die Kunden wird es da-durch zum einen immer schwieriger, das für den jeweiligen Anwendungsfallam besten geeignete Verfahren zu identifizieren und zum anderen denjenigenDienstleister zu finden, der dieses Verfahren einsetzt (BRANDNER 1999).

Es bietet sich deshalb an, alle RP/RT-Technologien dem Kunden gegenübergebündelt anzubieten und dadurch sowohl die Verfahrensauswahl als auch dieWahl des geeigneten Dienstleisters zu unterstützen. Um dies zu erreichen, istein Unternehmensnetzwerk notwendig, in dem möglichst viele RP/RT-Dienstleister zusammengefaßt sind. Das RP-Net.de ist ein solches Netzwerk.Die Organisationsform des RP-Net.de wird auch als kompetenzzentriertes Un-

ternehmensnetzwerk bezeichnet, da alle Netzwerkmitglieder gleiche, ähnlicheoder direkt ergänzende Kompetenzen aufweisen (SCHLIFFENBACHER U. A.1999).

7.2 Unternehmensnetzwerk RP-Net.de

Das RP-Net.de besteht aus Dienstleistern und aus einer Koordinationseinheit.Die Dienstleister haben die Kernkompetenz Rapid Prototyping / Rapid Tooling

36 Hochgeschwindigkeitszerspanung

7 Anwendungsszenario am Beispiel des RP-Net.de 121

oder ergänzende Kompetenzen, wie beispielsweise die Projektierung von RapidTooling Projekten oder die Werkzeugkonstruktion. Die Dienstleister wickelnweniger umfangreiche Rapid Prototyping Aufträge jeweils alleine ab. Umfang-reichere Aufträge, die über die Möglichkeiten eines einzelnen Unternehmenshinausgehen, werden von mehreren Unternehmen des Netzwerks gemeinsam ineiner virtuellen Fabrik abgewickelt.

Die Koordinationseinheit betreibt das Netzwerk und führt in diesem Rahmenauch Standards und Softwarewerkzeuge ein, die von allen beteiligten Unter-nehmen gemeinsam genutzt werden. Z. Zt. wird ein auf Internet-Technologienbasierendes standardisiertes Anfrage- und Angebotswesen betrieben, über dassowohl externe Kunden als auch Unternehmen im Netzwerk Anfragen an dieNetzwerkmitglieder stellen können (BRANDNER 1998A).

7.3 Exemplarische Projektabwicklung

7.3.1 Projektbeschreibung und Aufbau einer virtuellen Fabrik

In dem Beispielszenario erhält das RP-Net.de eine Rapid Tooling Anfrage, umauf Basis von Entwicklungsdaten in wenigen Wochen das Bauteil auszuarbei-ten und metallische Prototypen zu fertigen. Hierbei ist ein seriennahes Verfah-ren einzusetzen, um Prozeßüberprüfungen durchzuführen. Für diesen Auftragsind unterschiedliche Kompetenzen notwendig, so daß mehrere Unternehmendes RP-Net.de kooperieren müssen.

Ein Unternehmen im Netzwerk, das sich auf die Projektierung von Rapid Too-ling Projekten sowie auf die Konstruktion von Spritz- und Druckgußteilen kon-zentriert, nimmt den Auftrag an. Dieses Unternehmen wird im folgenden alsGeneralunternehmer bezeichnet, da es dem Kunden gegenüber als Ansprech-partner auftritt. Die für den Auftrag zusätzlich notwendigen Kompetenzen"Werkzeugkonstruktion", "Werkzeugbau", "Lasersintern" und "Druckgießen"werden an Partner im RP-Net.de vergeben (Bild 7-1). Mit der bereits im Netz-werk installierten Anfrage- und Angebotssoftware findet der Generalunterneh-mer schnell die Partner, die gemeinsam mit ihm eine virtuelle Fabrik zur Ab-wicklung des kompletten Auftrags bilden.

122 7.3 Exemplarische Projektabwicklung

Aufbau einer virtuellen Fabrik

Projektziel definieren

Notwendige Kompetenzen definieren

10 Prototypenseriennahes VerfahrenMaterial: Alu-DruckgußTermin: in 6 Wochen...

Werkzeugkonstruktion

Werkzeugbau

Lasersintern

Druckgießen

Teilekonstruktion

Projektierung

Teilekons./ProjektierungUnternehmen A

WerkzeugbauUnternehmen C

WerkzeugkonstruktionUnternehmen B

LasersinternUnternehmen D

DruckgießenUnternehmen E

Bild 7-1: Aufbau einer virtuellen Fabrik

7.3.2 Phasenplanung

Ist die virtuelle Fabrik aufgebaut, kann die gemeinsame Planung mit UDP be-ginnen. Zuerst muß das Projektteam definiert werden, das gemeinsam das Pro-jekt abwickelt. Hierfür werden im System Rollen angelegt, denen wiederum


Mitarbeiter der beteiligten Unternehmen zugewiesen werden. Im Beispiel wer-den folgende Rollen definiert:

- Rolle "PL" – Projektleiter aus Unternehmen A

- Rolle "TK" – Teilekonstrukteur aus Unternehmen A

- Rolle "WK" – Werkzeugkonstrukteur aus Unternehmen B

- Rolle "WM" – Werkzeugmacher aus Unternehmen C

- Rolle "LS" – Bediener der Lasersinteranlage aus Unternehmen D

- Rolle "DG" – Druckgießer aus Unternehmen E

Anschließend legt der Projektleiter das Projekt in UDP an und erstellt auf Basisder vorhandenen, noch unsicheren Informationen einen ersten Phasenplan mitden Projektphasen Teilekonstruktion, Werkzeugkonstruktion, Werkzeugbauund Druckgießen (Bild 7-2). In den Konstruktionsphasen werden jeweils zweiMeilensteine definiert: Der erste Meilenstein innerhalb der Phasen definiert denZeitpunkt, zu dem die Konstruktionen im Status "Konzept" vorliegen müssen.Die Konzepte sind dann für die Bearbeiter der Folgeprozesse zugänglich undkönnen bzgl. der Fertigungsgerechtheit frühzeitig beurteilt werden. Der jeweilsletzte Meilenstein beschreibt das erwartete Endergebnis der Phasen. Hier sindexakte Anforderungen an das Datenformat und den Speicherort sowie weiteretechnische und wirtschaftliche Anforderungen an das gewünschte Endergebnisdefiniert.

Parallel zur Phasenmodellierung stellt der Projektleiter eine Produktstrukturauf, die im Projektverlauf allerdings noch geändert werden kann. In dieserStruktur sind die Zusammenhänge zwischen Projekt, Produkt, Werkzeug undBaugruppen des Werkzeugs definiert (Bild 7-2). In diesem Schritt werden IDs,Benennungen, Klassifizierungen, Verantwortliche für Teile, geplante Kostenusw. vergeben. Der Projektleiter erzeugt in dieser Phase eine unternehmensspe-zifische Sicht auf die Produktstruktur, in der die Bauteile seinen Anforderungenentsprechend klassifiziert werden.


Produktstruktur

Teilekonstruktion

ID: W-1003Benennung: SchieberStatus: noch unsicherVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: P-1000Benennung: GehäuseStatus: in BearbeitungProjektleiter: PLgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1002Benennung: FormeinsätzeStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: T-1000Benennung: GehäuseStatus: offenVerantwortlich: TKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1001Benen.: WerkzeugrahmenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1006Benennung: Einsatz obenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1007Benennung: Einsatz untenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1000Benennung: WerkzeugStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1004Benennung: OberrahmenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: W-1005Benennung: UnterrahmenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

Projekt

Bauteil Werkzeug

Rolle WK

Rolle WM, LS

Rolle TK

Phasenplan

Status:freigegeben

Status:Konzept

Status:freigegeben

Status:Konzept

Verknüpfungen zwischenMeilensteinen und Produktdaten

Druckgießen

Werkzeugbau

Meilensteine werdenmit Metadaten beschrieben

Rolle DG

Werkzeugkonstrukt.

Teilekonstruktion

Bild 7-2: Planung der Projektphasen und der Produktstruktur

Nach der Grobplanung vergibt der Projektleiter den Rollen der virtuellen FabrikRechte auf das zentrale Phasen- und Produktstrukturmodell. Dadurch erhaltenalle Projektbeteiligten Lese- und Schreibzugriff auf das Modell, um die Mach-barkeit in den geplanten Terminen zu überprüfen und Kapazitäten abzustim-men. Die Projektbeteiligten können dabei dezentral den Phasenplan und auch


die Produktstruktur anpassen. Ist dies geschehen, wird der Phasenplan "einge-froren" und dient als stabile Planungsgrundlage. Änderungen im Projektverlaufkönnen zwar jederzeit vom Projektleiter eingebracht werden, sollten aber wei-testgehend vermieden werden. Bild 7-3 zeigt die Produktstruktur in der graphi-schen Oberfläche von UDP.

WerkzeugW-1000

WerkzeugrahW-1001

OberrahmenW-1004

UnterrahmenW-1005

WerkzeugrahW-1002

OberrahmenW-1004

UnterrahmenW-1005

FormeinsätzeW-1003

WerkzeugW-1000

WerkzeugrahW-1001

OberrahmenW-1004

UnterrahmenW-1005

WerkzeugrahW-1002

OberrahmenW-1004

UnterrahmenW-1005

FormeinsätzeW-1003

Bild 7-3: Darstellung der Produktstruktur und der Teilestammdaten mit Ver-

weisen auf Dokumente

Bis zu diesem Zeitpunkt wurden durch den Einsatz der Methodik folgendeVorteile erzielt:

- Prozeß- und Produktdaten werden redundanzfrei in der virtuellen Fabrikgehalten.

- Alle Projektbeteiligten haben jederzeit Zugriff auf aktuelle Daten und habendadurch den gleichen Informationsstand. Produkt- und Werkzeugkonzeptsind somit allen Projektbeteiligten bekannt.

- Der Projektleiter hat durch den integrierten Phasen- und Produktstrukturplaneine gute Projektübersicht und kann mit den Zugriffseinschränkungen sen-sible Daten vor unerlaubtem Zugriff schützen.


7.3.3 Aktivitätenplanung

Nach der Grobplanung beginnt die Planung der Geschäftsprozesse. Um die de-finierten Ergebnisse der Meilensteine zu erreichen, ist ein umfangreicher undregelmäßiger Informationsaustausch zwischen den Projektbeteiligten notwen-dig. Um diesen Informationsfluß möglichst effizient zu gestalten und im Ge-samtablauf zu optimieren, wird er frühzeitig direkt von den Projektmitarbeiterngeplant.

CAD-KonstruktionBauteil

CAD-KonstruktionFormrahmen

FertigungFormrahmen

NC-ProgrammierungFormrahmen

CAD-Konstruktionoberer Formeinsatz

FertigungFormeinsätze

NC-ProgrammierungFormeinsätze

CAD-Konstruktionunterer Formeinsatz

Fräsen, einpassen,polieren, erodieren

Lasersintern

Bild 7-4: Darstellung des Geschäftsprozeßmodells an einem UDP-Client

Jeder Projektmitarbeiter, der für eine Projektphase zuständig ist, leitet aus dendefinierten Meilensteinergebnissen Geschäftsprozesse ab, die zur Erreichungder Meilensteinergebnisse notwendig sind. So definiert beispielsweise derWerkzeugkonstrukteur ausgehend von dem erwarteten Ergebnis "Werkzeug-konstruktion" die Geschäftsprozesse "CAD-Konstruktion Formrahmen","CAD-Konstruktion oberer Formeinsatz" und "CAD-Konstruktion unterer


Formeinsatz". Als Eingangsinformation benötigt er die CAD-Daten des Bau-teils, weshalb er diesen Geschäftsprozeß als Vorgänger modelliert und als Be-arbeiter die Rolle "TK" zuweist. Der Teilekonstrukteur (Rolle "TK") wird dar-aufhin über diese Zuordnung automatisch vom System informiert und weist denProzessen als Schnittstelleninformation die Stammdaten des 3D-CAD-Modellszu, das er ausarbeiten wird. Das Dokument an sich existiert zu diesem Zeit-punkt noch nicht. Bild 7-4 zeigt das Prozeßnetz in einer Übersicht.

Weiterhin modelliert der Werkzeugkonstrukteur die Folgeprozesse "NC-Programmierung Formrahmen", "NC-Programmierung Formeinsatz" und "La-sersintern" und ordnet sie den verantwortlichen Rollen zu. Er ergänzt die Pro-zeßschnittstellen mit Verweisen auf die Dokumentenstämme der Werkzeug-komponenten. Auf diese Art und Weise wird das Prozeßnetz ausgebaut. Da-durch, daß alle Projektmitarbeiter über Änderungen im Prozeßnetz informiertwerden, haben immer alle Beteiligten den gleichen Informationsstand und einVerständnis für den geplanten Projektverlauf. Auch ohne daß bereits Doku-mente vorhanden sind, können Beziehungen zwischen Dokumentstämmen undProzeßdaten aufgebaut werden.

Im Projektverlauf wird der Werkzeugkonstrukteur automatisch informiert, so-bald die Teilekonstruktion den Konzeptstand erreicht hat. Er kann direkt auf dieCAD-Dokumente zugreifen und beispielsweise die Fertigungsgerechtheit über-prüfen. Sind bestimmte Anforderungen nicht erfüllt, so besteht die Möglichkeit,einen neuen Prozeß zu definieren und als Schnittstelleninformation konkretefertigungstechnische Anforderungen festzulegen (Bild 7-5). Diese Anforderun-gen werden mit dem Teilekonstrukteur iterativ abgestimmt, bis die endgültigenAnforderungen feststehen. Die Prozesse und deren zugeordnete Produktdatenkönnen geschützt werden, indem die Prozeßeigner die Rechte der Rollen aufdiesen Prozeß entsprechend anpassen. So darf beispielsweise die Rolle "WB"nur während der Projektphase "Teilekonstruktion" Anforderungen an die Teile-konstruktion definieren. Nach Beendigung dieser Phase werden diese Rechteautomatisch gesperrt.


Anforderungen anFertigungsgerecht-

heit definieren

Anforderungen anFertigungsgerecht-

heit definierenCAD-Konstruktion

Bauteil


Eigenschaft/Anforderung

Wert

A a

B ?

C ?

Output/Control-DateiFertigungsgerechtheit

Rolle WMUnternehmen C

Attribut Wert

Ausformschrägen 2,5 Grad

Radien R3

Rolle TKUnternehmen A

Bild 7-5: Definieren von Anforderungen in Form von Control-Informationen

Anhand der beiden Prozesse "CAD-Konstruktion unterer Formeinsatz" und"Lasersintern" wird im folgenden die Einbindung von Dokumenten in das Pro-zeßnetz erläutert (Bild 7-6).

Für das Lasersintern ist zum einen ein 3D-CAD-Modell im STL37-Format not-wendig, um die Steuerdateien für den Sinterprozeß generieren zu können, undzum anderen muß eine 2D-Zeichnung vorliegen, um das fertige Teil prüfen zukönnen. Die 3D-CAD-Datei stellt somit eine Output/Input-Verbindung und die2D-CAD-Datei eine Output/Control-Verbindung zwischen den beiden Prozes-sen dar. Beiden Prozessen sind unterschiedliche Projektmitarbeiter über dieRollen "WK" und "LS" zugewiesen. Im Prozeßnetz zeigt ein Verweis auf denDokumentenstamm "D-1007-02" des zentralen Produktmodells. Dieser bein-haltet einen Verweis zu der Datei "D-1007-02" auf dem WWW-Server desPartnerunternehmens "B". Ähnlich verhält es sich mit der 2D-CAD-Zeichnungmit der ID "D-1007-01". Auf diese Art und Weise verbinden die Projektbear-beiter das Prozeßmodell mit dem Produktmodell.

37 STL – Standard Transformation Language: Triangulierte Darstellung der Oberfläche eines

Bauteils. Dieses Format wird benutzt, um CAD-Modelle für RP/RT-Anlagen aufzubereiten.


Ausschnitt ausdem Prozeßnetz

ID: W-1007Benennung: Einsatz untenStatus: offenVerantwortlich: WKgeplante Kosten: ...tatsächliche Kosten: ...

ID: D-1007-01 ID: D-1007-02

Lagerort: https://serverb/...Benennung: Einsatz untenDateityp: 3D-CADErzeugersystem: System AStatus: offen

DokumentenstammBauteil

Ausschnitt ausden Metadaten desProduktmodells

WWW-ServerUnternehmen B

Verknüpfung der Dokumentenstammdaten

mit der externen Datei

LasersinternCAD-Konstruktion

unterer FormeinsatzVerweis auf: D-1007-02

Verweis auf:D-1007-01

Rolle WKUnternehmen A

Verknüpfung von Output/Input/Control mit den Dokumenten- stammdaten des Produktmodells

Rolle LSUnternehmen D

Bild 7-6: Integration der Produktdaten mit den Prozeßdaten

7.3.4 Auftragsabwicklung

Sobald die 3D- und 2D-CAD-Datei den Status "freigegeben" erreicht haben,was durch die Rolle "WK" und bei Bedarf durch einen weiteren Prüfer gesteu-ert wird, lastet die Workflow-Engine den Geschäftsprozeß "Lasersintern" derRolle "LS" ein. In der Aufgaben- bzw. TODO-Liste der Rolle "LS" erscheintdie Aufgabe "Lasersintern" mit einer Beschreibung der Tätigkeit und des er-warteten Ergebnisses (Output) sowie Verweisen auf die Input- und Control-Dateien (Bild 7-7).


Lasersintern

Brandner

Mechan. Fertigung

Gehäuse

12.06.1999

SNI

Projektleiter

freigegeben

Werkzeugbau

30.06.1999

Sintern des unteren Formeinsatzes und Abstimmen mit dem Formrahmen sowie mitdem oberen Formeinsatz und dem Schieber.

D_1007-01

D_1007-02

Lasersintern

Verweise auf Dateien

Status der Dateien

Bild 7-7: Generierung von TODOs aus Geschäftsprozessen – Input- und

Control-Dateien sind über Hyperlinks zugeordnet

Über Hyperlinks kann der Projektbearbeiter jederzeit die aktuellsten Versionender Dokumente von dem WWW-Server des Partnerunternehmens "B" in seinenlokalen Arbeitspeicher laden. Ihm stehen dadurch alle notwendigen Informatio-nen zur Verfügung, so daß er sofort und idealerweise ohne Rückfragen mit derDurchführung der Aufgabe beginnen kann.

Durch die Prozeßtransparenz und Verknüpfung der Prozeß- mit den Produkt-daten kann der Projektmitarbeiter der Rolle "D" auch schon vor der Teilefrei-gabe auf die CAD-Daten zugreifen und die Fertigungsgerechtheit überprüfen.Er kann auch gemeinsam mit anderen Projektbeteiligten in die Freigabeprozes-se von Teilen und Dokumenten eingebunden werden.



CAD-KonstruktionFormrahmen

FertigungFormrahmen

NC-ProgrammierungFormrahmen

CAD-Konstruktionoberer Formeinsatz

FertigungFormeinsätze

NC-ProgrammierungFormeinsätze

CAD-Konstruktionunterer Formeinsatz

Fräsen, einpassen,polieren, erodieren

Lasersintern

Abgeschlossen

In Bearbeitung

Verteilt

Offen

Prozeßstatus:

Bild 7-8: Graphische Überwachung des Projektfortschritts

Die Workflow-Engine verteilt alle Geschäftsprozesse, die zur Bearbeitung frei-gegeben sind, in Form von TODOs an die Bearbeiter. Über die TODO-Listemelden die Bearbeiter den aktuellen Stand an das Prozeßnetz zurück. Die Akti-vitäten nehmen je nach Status eine bestimmte Farbe an. Der aktuelle Pro-jektstand kann somit jederzeit sofort erkannt und auf Verzögerungen kann früh-zeitig reagiert werden (Bild 7-8).

8 Bewertung und Diskussion des Konzepts

Entscheidend für die Brauchbarkeit des entwickelten Konzepts sind die Poten-tiale, die mit dem Ansatz ausgeschöpft werden können. Der mögliche Nutzenmuß höher sein als der Zusatzaufwand, der durch den Einsatz der Vorgehens-weise entsteht. Im folgenden wird der Aufwand und Nutzen des Konzepts dis-kutiert. Hierbei werden zwei konkrete Rapid Tooling Projekte betrachtet. Imzweiten Teil dieses Kapitels wird aufgezeigt, welchen Einfluß das Konzept aufMensch, Organisation und Technik hat.

8.1 Aufwand/Nutzen-Abschätzung

8.1.1 Aufwand

Betrachtet man den Zusatzaufwand, der durch den Einsatz des Konzepts imVergleich zur konventionellen Vorgehensweise entsteht, so sind folgende Fak-toren zu berücksichtigen:

1. Hard- und Softwarekosten (einschließlich Betreiberkosten)

2. Zusatzaufwand in der Planung

Das Konzept kann ohne eine Softwareunterstützung nicht ausreichend effizienteingesetzt werden (vgl. Abschnitt 4.4). Da ein entsprechendes Softwarewerk-zeug noch nicht kommerziell verfügbar ist, ist die Entwicklung eines speziel-len, netzwerkspezifischen Softwaresystems notwendig. Aus der Erfahrung mitder Konzeption und Entwicklung des Softwareprototypen UDP wird für dienetzwerkspezifische Softwareentwicklung ein Aufwand von ca. 400 Manntagenà 8 Stunden angesetzt. Bei einem Stundensatz von DM 150,- ergibt sich einBetrag von DM 300.000,- für die komplette Softwareentwicklung. Bei einemangenommenen Abschreibungszeitraum von 3 Jahren müssen jedes Jahr DM100.000,- abgeschrieben werden. Hinzu kommen branchenübliche Software-wartungskosten in Höhe von jährlich 10% des abzuschreibenden Betrags sowieBetreiberkosten (Hardware, Internet-Zugang, Datenübertragung) in Höhe von

134 8.1 Aufwand/Nutzen-Abschätzung

ca. DM 20.000,- pro Jahr. Damit ergibt sich insgesamt ein Betrag von DM130.000,- pro Jahr, den alle Unternehmen eines Netzwerks gemeinsam finan-zieren müssen. Verteilt man diesen Betrag auf 25 Unternehmen (vgl. die Pra-xisbeispiele in Abschnitt 2.4) entfallen auf jedes Unternehmen im NetzwerkFixkosten in Höhe von DM 5.200,- pro Jahr.

Neben den Fixkosten fallen zusätzlich variable Kosten an. So steigt durch denEinsatz des Konzepts der Planungsaufwand deutlich an. Durch das Vorgehensind die Mitarbeiter gezwungen, sich frühzeitig über den Informationsfluß imProjekt konkrete Gedanken zu machen, sich gegenseitig abzustimmen und ge-plante Schnittstellenergebnisse zu modellieren. Deshalb wird in der Kostenab-schätzung von einem Planungsanteil von 10% der normalen Arbeitszeit ausge-gangen. Darin enthalten ist eine projektbegleitende Schulung bzw. Betreuungder Systembediener.

8.1.2 Nutzen

Durch das integrierte Produktdaten- und Prozeßmanagement in virtuellen Fab-riken werden folgende wesentlichen Vorteile erwartet:

1. Schnellere und effizientere Projektabwicklung

2. Höhere Qualität des Endprodukts

Die schnellere und effizientere Projektabwicklung soll vorwiegend dadurcherreicht werden, daß der Datenfluß über das Gesamtprojekt frühzeitig abge-stimmt und optimiert wird. Diese Optimierung vermeidet eine wiederholteAufbereitung bzw. Nacharbeitung von Daten (Bild 8-1). Ebenfalls werden mitder unternehmensübergreifenden Projektübersicht Probleme im Projektverlauffrüher erkannt. Änderungen können dann in Geschäftsprozesse eingebrachtwerden, bevor Arbeitszeit in nicht mehr aktuelle Aufgaben investiert wird. DieProjektabwicklung wird zusätzlich dadurch beschleunigt, daß auf viele Projekt-informationen unabhängig von den Bürozeiten der Projektpartner zugegriffenwerden kann. Die aktive Verteilung von Aufgaben an die Projektbearbeitervermeidet Liegezeiten von Informationen.

8 Bewertung und Diskussion des Konzepts 135

Bild 8-1: Projektverlauf mit und ohne Reibungsverlust (schematische Darstel-

lung)

Neben den zeitlichen Vorteilen, werden mit dem Konzept auch qualitative Ver-besserungen am Endprodukt erwartet. Die Qualität steigt durch das frühe Ein-bringen des Detail-Know-hows der Projektmitarbeiter. Sie können ihre Anfor-derungen formulieren und in dem Prozeßmodell abbilden. Anforderungen vonnachgeschalteten Bereichen werden dadurch frühzeitig berücksichtigt und er-höhen die Qualität der Geschäftsprozesse, was sich auch auf die Qualität desEndprodukts auswirkt. Der Einfluß von Änderungen kann auf Basis des integ-rierten Produktdaten- und Prozeßmodells besser abgeschätzt werden. DieZugriffsmöglichkeiten auf das komplette Produktmodell führen zu fundierterenEntscheidungen bei Änderungen und verbessern dadurch auch die Qualität derGeschäftsprozeßergebnisse.

Bei der Analyse von zwei typischen Rapid Tooling Projekten (geplante Pro-jektlaufzeit: je 8 Wochen; geplante investierte Arbeitszeit: je 2 Personen zu100% entspricht insgesamt 80 Manntagen) in jeweils unterschiedlichen virtu-ellen Fabriken, zeigten sich folgende Probleme in der Projektabwicklung:

1. Nacharbeiten führten zu einem Zusatzaufwand von jeweils ca. 25 Mannta-gen.

Notwendige Tätikgkeiten

Nacharbeit bzw. mehrfache Datenaufbereitung

Zu spätes Reagieren auf Probleme im Projektverlauf

Wartezeit auf Informationen

Idealisierter Projektverlauf ohne Reibungsverlust

Projektverlauf mit Reibungsverlust

Einsparpotential

136 8.1 Aufwand/Nutzen-Abschätzung

2. Projektverzögerungen um ca. 2 Wochen führten zu einer tatsächlichen Pro-jektlaufzeit von 10 Wochen.

3. Es entstanden Zusatzkosten durch Ausschuß in Höhe von jeweils ca. DM7.000,-.


Stellt man den Aufwand dem möglichen Nutzen für die untersuchten Projektegegenüber, dann ist folgender Sachverhalt aus der Sicht des Rapid ToolingUnternehmens zu erkennen:

Geschätzter Zusatzaufwand Mögliche Einsparpotentiale

Fixkosten anteilig: 867,-

(5.200,- anteilig für 8 Wochen)

Ausschuß: 7.000,-

Planungsaufwand (8 MT): 6.400,-

(10% von 80 Manntagen)

Nacharbeiten (25 MT): 20.000,-

Summe: 7.267,- 27.000,-

Grundlagen der Berechnung: Es wird davon ausgegangen, daß das System UDP von dem

betrachteten Unternehmen bei allen Projekten eingesetzt wird. Weiterhin gilt: 1 Manntag

(MT) = 8 Arbeitsstunden; Kosten einer Arbeitsstunde: DM 100,-; Kosten für einen Manntag:

DM 800,-.

Der rechnerische Break-Even wird erreicht, wenn von den möglichenDM 27.000,- ca. DM 7.300,- eingespart werden, dies entspricht einem zu reali-sierenden Potential von ca. 27%. Zusätzlich zu dem finanziellen Vorteil sindauch die kürzere Projektlaufzeit und die besseren Projektergebnisse zu berück-sichtigen. Beide Vorteile führen zu einer steigenden Kundenzufriedenheit, wassich mittelfristig ebenfalls positiv auf die Unternehmensergebnisse auswirkt.


8.2 Auswirkungen auf Mensch, Organisation und Technik

Die angestrebten Einsparungen und Qualitätsverbesserungen können allerdingsnur erreicht werden, wenn die durch das entwickelte Vorgehen beeinflußtenFaktoren mitberücksichtigt werden (Bild 8-2).

Mensch

• Denken in Prozessen• Informationstransparenz durch Anreize• dezentrale Informationsbereitstellung• qualifizierte Mitarbeiter• selbstverantwortlich handeln• gegenseitiges Vertrauen

Organisation

• Prozeßorganisation• Unternehmensschnittstellen als Chance• Harmonisierung der Informationsbeschreibung• Aufbau von Basisnetzwerken

Technik

• Internet-Zugang für alle Projektmitarbeiter• WWW-Server

Bild 8-2: Neue Lösungen erfordern Änderungen bei Mensch, Organisation und

Technik

Der Mensch als eine tragende Säule der virtuellen Fabrik muß lernen, mit denneuen Methoden und Techniken umzugehen. Wesentlich ist hierbei das Denkenin Prozessen und das eigenverantwortliche Handeln aller Projektmitarbeiter.Projektmitarbeiter müssen davon überzeugt werden, daß das Bereitstellen vonInformationen allen Projektbeteiligten Vorteile bringt. Nur unter dieser Voraus-setzung kann das Detail-Know-how der Projektmitarbeiter auf breiter Basis indie Planung und Abwicklung einbezogen werden. Grundlage hierfür ist aucheine Vertrauensbasis zwischen den Projektbeteiligten.

138 8.2 Auswirkungen auf Mensch, Organisation und Technik

Als zweiter Faktor werden die Ablauf- und Aufbauorganisationen maßgeblichdurch das neue Vorgehen beeinflußt. Prozeßorientierte Organisationsformensind eine Voraussetzung, um den streng ablauforientierten Ansatz zu unterstüt-zen. Nur dann können die Mitarbeiter schnell in die dynamischen Prozeßnetzevirtueller Fabriken eingebunden werden. Die Prozeßschnittstellen zwischenUnternehmen dürfen nicht mehr als unangenehme Hürde angesehen werden,sondern müssen als Chance für die Nutzung großer Einsparpotentiale und Er-schließung neuer Technologien erkannt werden. Deshalb müssen die Unter-nehmen ihre Schnittstellen nach außen analysieren und gezielt den neuen An-forderungen anpassen. Im Vordergrund steht hierbei unter anderem die Art undWeise der Speicherung und Verwaltung von Informationen: Es ist nicht mehrausreichend, wenn unternehmensintern Dokumente ausgetauscht werden kön-nen, auch die gemeinsame Bearbeitung von Dokumenten mit anderen Unter-nehmen muß stärker als bisher berücksichtigt werden. Dadurch löst man diewirklichen Ursachen vieler Probleme der Projektabwicklung.

Schnittstellen zwischen Unternehmen können wesentlich besser aufeinanderabgestimmt werden, wenn die potentiellen Partner eines Netzwerks in einemsogenannten Basisnetzwerk zusammengeschlossen sind, wie es beispielsweiseder Virtuelle Markt, die Virtuelle Fabrik Euregio Bodensee oder das RP-Net.de

darstellen (siehe auch Abschnitt 2.4). Durch das Ziel der an einem Basisnetz-werk beteiligten Unternehmen, regelmäßig mit anderen Unternehmen desNetzwerks zu kooperieren, ist der Aufwand für netzwerkspezifische Standardi-sierungen gerechtfertigt. Im RP-Net.de wurde dieser Ansatz konsequent umge-setzt. Weiterhin ist zu erwarten, daß sich innerhalb eines Netzwerks Lernkurveneinstellen, was sich direkt auf die Effizienz der Auftragsabwicklung auswirkenkann.

Auch die Technik bleibt von dem vorgestellten Vorgehen nicht unberührt. Allean virtuellen Fabriken beteiligten Arbeitsplätze müssen einen Internet-Anschluß haben, um auf die Prozeß- und Produktdaten zugreifen zu können.Auch an der CNC-Maschine, in der Gießerei und bei den Montageplätzen müs-sen Projektmitarbeiter über entsprechende I&K-Voraussetzungen verfügen.Unternehmen, die eigene Dokumente für externe Projektmitarbeiter zur Verfü-gung stellen möchten, benötigen darüber hinaus einen WWW-Server, über dendie Dokumente von den Projektpartnern abgerufen werden können.


Als Fazit kann zusammengefaßt werden, daß die Organisationsform der virtu-ellen Fabrik, neue Verhaltensweisen bei den Mitarbeitern und Führungskräftenin den Unternehmen fordert. Weiterhin sind die notwendigen Änderungen imorganisatorischen und technischen Bereich von Beginn an in den Ände-rungsprozeß einzubeziehen.

140 8.2 Auswirkungen auf Mensch, Organisation und Technik

9 Zusammenfassung und Ausblick

Virtuelle Fabriken sind ein vielversprechender Ansatz für kleine und mittlereUnternehmen, um den steigenden Anforderungen des globalen Wettbewerbsbegegnen zu können. Die Konzentration auf Kernkompetenzen führt zu einerVerteilung der Wertschöpfungskette auf mehrere Unternehmen und bringt vorallem in informationsintensiven Prozeßschritten hohe Reibungsverluste mitsich.

Die kommerziell verfügbaren und in der Literatur vorgeschlagenen Methodenund Werkzeuge zur Verwaltung der Prozeß- und Produktdaten sind nicht fürdie Heterogenität und Dynamik von Projektabwicklungen in virtuellen Fabri-ken ausgelegt, weshalb die Forderung nach neuen Lösungen gestellt werdenmuß.

Im Rahmen der Arbeit wurde ein Konzept zum integrierten Produktdaten- undProzeßmanagement in virtuellen Fabriken entwickelt, das sich in folgendenwesentlichen Punkten von bekannten Ansätzen unterscheidet:

- Die Produkt- und Prozeßdaten werden integriert betrachtet.

- Alle Produkt- und Prozeßdaten werden über die Unternehmensgrenzen hin-weg strukturiert in einem logisch zentralen Modell verwaltet.

- Die Verwaltung der Produkt- und Prozeßdaten wird in Unternehmensnetz-werken mit gemeinsamen Methoden und Werkzeugen durchgeführt.

- Die Prozesse werden dezentral und eigenverantwortlich direkt von denProjektmitarbeitern modelliert.

Das vorgestellte Konzept stellt einen Denkrahmen für die Entwicklung neuerVorgehen und Softwareprogramme für virtuelle Fabriken dar. Es unterstützt dieProjektplanung und -abwicklung durchgängig von der taktischen bis zur opera-tionalen Ebene. Das Konzept berücksichtigt die räumliche Verteilung der Pro-jektpartner, die Heterogenität in organisatorischen Daten und I&K-Systemen,die dezentrale Verwaltung von Nutzdaten sowie die Dynamik von Projektab-wicklungen in virtuellen Fabriken. Im Rahmen der Arbeit wurde auch ein Vor-

142 9 Zusammenfassung und Ausblick

gehen vorgestellt, wie das integrierte Produktdaten- und Prozeßmanagement inder Praxis eingesetzt werden kann.

Das Konzept wurde zu Evaluierungszwecken in dem Softwarewerkzeug UDP(Unternehmensübergreifendes Daten- und Prozeßmanagement) unter Einsatzvon Internet-Technologien prototypisch umgesetzt. Grundlage hierfür ist einDatenmodell, das auf dem Application Protocol AP 214 des Produktdatenstan-dards STEP basiert. Das STEP-Modell wurde um Konstrukte erweitert, so daßdie Integration zwischen Produkt- und Prozeßmodell entsprechend den Anfor-derungen von virtuellen Fabriken realisiert werden konnte.

Anhand eines Anwendungsszenarios am Beispiel eines Unternehmensnetz-werks für Rapid Prototyping wurde der Einsatz des Konzepts diskutiert. An-schließend wurde eine Aufwand-Nutzen-Abschätzung durchgeführt. Hierbeistehen Hard- und Softwarekosten sowie zusätzlicher Planungsaufwand demmöglichen Nutzen einer effizienteren Projektabwicklung und qualitativ besse-ren Endprodukten gegenüber.

In der logischen Weiterführung dieses Ansatzes kann der Anwendungsbereichausgedehnt werden. So sollten in einem ganzheitlichen Ansatz zusätzlich zuden Produkt- und Prozeßdaten auch Geschäfts- und Logistikdaten (z. B. Be-stellungen, Rechnungen, Lieferabruf) betrachtet werden. Weiteres Potentialbirgt die gemeinsame Kapazitätsplanung in virtuellen Fabriken in sich. Durchdie Projektplanung mit einem gemeinsamen Werkzeug entsteht eine Kapazi-tätsübersicht über das ganze Unternehmensnetzwerk. Diese Informationenkönnten bei der Projektplanung im Sinne eines Multiprojektmanagements au-tomatisch berücksichtigt werden.

Prinzipiell sollten in jedem Unternehmensnetzwerk alle Informationen folgen-den kritischen Fragen unterzogen werden:

- Warum werden diese Daten individuell und nicht zentral gespeichert?

- Welchen Vorteil hat der Einsatz individueller Methoden und Werkzeuge zurBearbeitung der Daten? Ist dieser Vorteil größer als der Nachteil, der durchdie Reibungsverluste entsteht?

Das "Wir-Gefühl" der virtuellen Fabrik darf nicht nur im zwischenmenschli-chen und organisatorischen Bereich betrachtet werden, sondern muß auf Me-

143

thoden und Werkzeuge konsequent ausgedehnt werden. Dann hat die virtuelleFabrik gute Chancen, in Zukunft neue Maßstäbe in der Entwicklung und Her-stellung von kundenindividuellen Produkten zu setzen.

144 9 Zusammenfassung und Ausblick

Literaturverzeichnis

ANDREWS 1996

Andrews, M.: Establishing an Effective Infrastructure for PDM. In:Christman, A. (Hrsg.): PDM Conference, Boca Raton/USA. Ann Ar-bor: CIMDATA 1996.

ARNOLD & HÄRTLING 1995

Arnold, O.; Härtling, M.: Virtuelle Unternehmen: Begriffsbildung und-diskussion. Arbeitspapier der Reihe "Informations- und Kommunika-tionssysteme als Gestaltungselement Virtueller Unternehmen" Nr.3/1995, Institut für Wirtschaftsinformatik der Universität Bern. Bern1995.

AUGUSTIN 1998

Augustin, R.: Integrierte Planung der Anwendung von Informations-und Kommunikationstechnologie (IKT): Eine Methode zur Priorisie-rung von IKT-Verbesserungen für produzierende Unternehmen. Aa-chen: Shaker Verlag 1998. (Darmstädter Forschungsberichte für Kon-struktion und Fertigung)

BAUHOFER & K NECHTEL 1997

Bauhofer, M.; Knechtel, U.: Integration von PDM- mit CAE-Systemen. EDM-Report (1997) 3, S. 50-52.

BAUNACH 1996

Baunach, S.: Intranet/Internet Integration with EDM/PDM. In: Intra-net/Internet Strategies for Engineering and Manufacturing 1996, Or-lando. Boston: Daratech Inc. 1996.

BERK 1996

Berk, B.: PDM as an Enabling Tool for Concurrent Engineering. In:Christman, A. (Hrsg.): PDM Conference, Boca Raton/USA. Ann Ar-bor: CIMDATA 1996.

146 Literaturverzeichnis

BRANDNER 1996

Brandner, S.: EDM-Definition und Überblick. In: Reinhart, G.(Hrsg.); Milberg, J. (Hrsg.): EDM – Engineering Data Management,Augsburg. München: Herbert Utz Verlag Wissenschaft 1996, S. 7-29.(iwb-Seminarberichte 24)

BRANDNER 1997

Brandner, S.: Internetbasierte Planung und Abwicklung von unter-nehmensübergreifenden Entwicklungsprozessen. In: EDM-Sympo-sium, Stuttgart: Fraunhofer Institut für Arbeitswissenschaft und Orga-nisation (IAO), Stuttgart 1997.

BRANDNER 1998A

Brandner, S.: Rapid Prototyping Netzwerk RP-Net.de. In: Reinhart, G.(Hrsg.); Milberg, J. (Hrsg.): Rapid Prototyping – Effizienter Einsatzvon Modellen in der Produktentwicklung. München: Herbert UtzVerlag Wissenschaft 1998, S. 8-1 - 8-18. (iwb-Seminarberichte 38)

BRANDNER 1998B

Brandner, S.: Funktionen und Nutzen der EDM-Technologie In: Rein-hart, G. (Hrsg.); Milberg, J. (Hrsg.): Engineering Data Management –Erfahrungsberichte und Trends, Augsburg. München: Herbert UtzVerlag Wissenschaft 1998, S. 7-26. (iwb-Seminarberichte 31)

BRANDNER 1999

Brandner, S.: RP-Net.de - Rapid Prototyping Netzwerk für produzie-rende Unternehmen. In: Kongress Virtuelle Unternehmen, Mannheim:Technische Akademie Mannheim 1999.

BROCKHAUS & FUHRMEISTER 1998

Brockhaus, R.; Fuhrmeister, K.: EDM/PDM-integrierter Datenaus-tausch in der Automobilzulieferindustrie. EDM-Report (1998) 4, S.34-39.

BULLINGER U. A. 1996

Bullinger, H.-J. u. a.: Rapid Product Development. VDI-Z 138 (1996)5, S. 38-41.

Literaturverzeichnis 147

DIN 69900

DIN 69900: Projektwirtschaft. Netzplantechnik. Berlin: Beuth 1987.

EHRLENSPIEL 1995

Ehrlenspiel, K.: Integrierte Produktentwicklung – Methoden für Pro-zeßorganisation, Produkterstellung und Konstruktion. München: Han-ser 1995.

EIGNER & HAESNER 1998

Eigner, M.; Haesner, D.: Konfigurationsmanagement als integrierterTeil von PDM. EDM-Report (1998) 3, S. 24-28.

EIGNER 1996

Eigner, M.: Technische Informationssysteme – Stand der Technik amBeispiel eines PDM/EDM-Systems. ZWF 91 (1996) 9, S. 395-397.

EIGNER U. A. 1991

Eigner, M.; Hiller, C.; Schindewolf, S.; Schmich, M.: EngineeringDatabase – Strategische Komponente in CIM-Konzepten. München:Hanser 1991.

EVERSHEIM 1996

Eversheim, W. (Hrsg.): Prozessorientierte Unternehmensorganisation:Konzepte und Methoden zur Gestaltung schlanker Organisationen. 2.Aufl. Berlin: Springer 1996.

FÄHRER 1998

Fährer, J.: Rapid Prototyping und Rapid Tooling in der Produktent-wicklung. In: Reinhart, G. (Hrsg.); Milberg, J. (Hrsg.): 3D-CAD:Mehr als nur eine dritte Dimension, Augsburg. München: Herbert UtzVerlag Wissenschaft 1998, S. 7-1 – 7-18. (iwb-Seminarberichte 33)

FLANAGAN 1996

Flanagan, D.: Java in a Nutshell - A Desktop Reference for Java Pro-grammers. Cambridge: O'Reilly & Associates 1996.


FRIEDMANN U. A. 1998

Friedmann, T.; Jungfermann W.; Schmid, C.: Global Engineering –Welchen Beitrag leisten EDM-Systeme und das Internet? EDM-Report (1998) 4, S. 40-43.

FUCHS 1995

Fuchs, J.: Wege zum vitalen Unternehmen: Die Renaissance der Per-sönlichkeit. Wiesbaden: Gabler 1995.

FURRER 1998

Furrer, M.: Prozesse beherrschen - Marktübersicht Projekt-/Prozeß-Management-Systeme. EDM-Report (1998) 3, S. 60-64.

GAITANIDES U. A. 1994

Gaitanides, M.; Scholz, R.; Vrohlings, A.; Raster, M.: Prozeßmana-gement – Konzepte, Umsetzungen und Erfahrungen des Reenginee-ring. München: Hanser 1994.

GEUER 1996

Geuer, A.: Einsatzpotentiale des Rapid Prototyping in der Produktent-wicklung. Berlin: Springer 1996. (iwb Forschungsberichte 100)

GOLDMAN U. A. 1994

Goldman, S. L.; Nagel, R. N.; Preiss, K.: Agile Competitors and Vir-tual Organizations: Strategies for Enriching the Customer. New York:Van Nostrand Reinhold 1994.

GOLDMAN U. A. 1996

Goldmann, S. L.; Nagel, R. N.; Preiss, K., Warnecke, H.-J.: Agil imWettbewerb: Die Strategie der virtuellen Organisation zum Nutzendes Kunden. Berlin: Springer 1996.

GRABOWSKI U. A. 1993

Grabowski, H.; Anderl, R.; Polly, A.: Integriertes Produktmodell.Berlin: Beuth 1993.


GROH & GUTSCH 1982

Groh, H.; Gutsch, R. W.: Netzplantechnik – Eine Anleitung zum Pro-jektmanagement für Studium und Praxis. Düsseldorf: VDI-Verlag1982.

GROSSMANN 1997

Grossmann, W.: Life Cycle of PDM Data: From Concept Definitionto Document Generation. In: Mit der Schlüsseltechnologie EDM zumLife Cycle Management, Mainz. Wiesbaden: CSC Ploenzke 1997.

HAGEN & BRANDNER 1998

Hagen v. d., F.; Brandner, S.: Studie zum unternehmensübergreifen-den Austausch von Produkt- und Geschäftsdaten. iwb Augsburg: In-terner Projektbericht 1998.

HAMMER & CHAMPY 1994

Hammer, M.; Champy, J.: Business Reengineering. Frankfurt: Cam-pus 1994.

HIRSCHMANN 1998

Hirschmann, P.: Kooperative Gestaltung unternehmensübergreifenderGeschäftsprozesse. Wiesbaden: Gabler 1998.

HOFER-ALFEIS U. A. 1999

Hofer-Alfeis, J. (Hrsg.): Geschäftsprozeßmanagement – innovativeAnsätze für das wandlungsfähige Unternehmen. Markburg: TectumVerlag. (Veröffentlichung des Forschungsprojekts GIPP – Ge-schäftsprozeßgestaltung mit integrierten Prozeß- und Produktmodel-len)

ISO 10303-11

N.N.: ISO 10303-11: Industrial Automation Systems and Integration –Product Data Representation and Exchange – Part 11: DescriptionMethods: The Express Language Reference Manual. 1994.

KAESELER 1997

Kaeseler, J.: Geschäftsprozeßoptimierung und Veränderungsprozesse.In: Industrie Management 13 (1997) 5. S. 56-59.


KAISER 1997

Kaiser, J.: Vernetztes Gestalten von Produkt und Produktionsprozeßmit Produktmodellen. Berlin: Springer 1997. (iwb Forschungsberichte111).

KAMM 1999

Kamm, O.: Produktentwicklung im Anlagengeschäft. In: Hofer-Alfeis,J. (Hrsg.): Geschäftsprozeßmanagement – innovative Ansätze für daswandlungsfähige Unternehmen. Marburg: Tectum 1999, S. 260-270.(Reihe Softwaretechnik 9)

KELCH 1998

Kelch, M.: Konzeption, Auswahl und Einführung eines PDM-Systems. In: Reinhart, G. (Hrsg.); Milberg, J. (Hrsg.): EngineeringData Management – Erfahrungsberichte und Trends, Augsburg. Mün-chen: Herbert Utz Verlag Wissenschaft 1998, S. 27-65. (iwb-Seminarberichte 31)

KERZNER & THAMHAIN 1986

Kerzner, H.; Thamhain, H.: Project management operating guidelines.New York: Van Nostrand Reinhold 1986.

KLEEDÖRFER 1998

Kleedörfer, R.: Prozeß- und Änderungsmanagement der IntegriertenProduktentwicklung. München: Lehrstuhl für Produktentwicklung1998. Vorabdruck zur Dissertation.

KONRADT 1999

Konradt, U.: Partner im virtuellen Unternehmen. In: Harvard BusinessManager (1999) 3, S. 103-107.

KOSCHEL & WALLRATH 1995

Koschel, A.; Wallrath, M.: Ist die Zukunft der Datenbanken objektori-entiert? In: EDM-Report (1995) 2, S. 62-71.

KRAUS & WESTERMANN 1995

Kraus, G.; Westermann, R.: Projektmanagement mit System: Organi-sation, Methoden, Steuerung. Gabler: Wiesbaden 1995.


KRILL 1996

Krill, O.: EDI – eine Voraussetzung für eine sequenzgerechte Beliefe-rung der Automobilindustrie. In: Industrie Management (1996) 6, S.47-50.

LEBER 1996

Leber, M.: EDM auf der Grundlage genormter Produktdatenmodelle.In: Reinhart, G. (Hrsg.); Milberg, J. (Hrsg.): EDM – Engineering DataManagement, Augsburg. München: Herbert Utz Verlag Wissenschaft1996, S. 164-179. (iwb-Seminarberichte 24)

LEBER 1998

Leber, M.: PDM-Systeme und Datenaustausch – Ein aktueller Status-bericht. Produktdaten Journal (1998) 2, S. 42-44.

LINDEMANN & K LEEDÖRFER 1997

Lindemann, U.; Kleedörfer, R.: Erfolgreiche Produkte durch integ-rierte Produktentwicklung. In: Reinhart, G. (Hrsg.); Milberg, J.(Hrsg.): Münchner Kolloquium ´97, München. Landsberg am Lech:verlag moderne industrie 1997, S. 115-136.

LINDEMANN & K LEIN 1998

Lindemann, M.; Klein, S.: Die Nutzung von Internet-Diensten imRahmen des elektronischen Datenaustauschs. Institut für Wirtschafts-informatik, Universität St. Gallen, März 1998.

LINDO 1996

Lindo, W.: Workflow-Management und Optimierung der Geschäfts-prozesse. ZWF 91 (1996) 9, S. 419-420.

LOZINSKI & SCHMIDT 1998

Integration der logistischen Kette und der Entwicklung. EDM-Report(1998) 1, S. 44-47.


MACHT 1997

Macht, M.: Möglichkeiten und Grenzen des Rapid Prototyping. In:Reinhart, G. (Hrsg.); Milberg, J. (Hrsg.): Rapid Prototyping – Mitneuen Technologien schnell vom Entwurf zum Serienprodukt, Augs-burg. München: Herbert Utz Verlag Wissenschaft 1997, S. 5-23. (iwb-Seminarberichte 27)

MACHT 1999

Macht, M.: Leitfaden Rapid Prototyping. München: Institut für Werk-zeugmaschinen und Betriebswissenschaften 1999. Vorabdruck zurDissertation.

MADAUSS 1994

Madauss, B. J.: Handbuch Projektmanagement. Stuttgart: SchaeffelPoeschel Verlag 1994.

MALONE & L AUBACHER 1999

Malone T.; Laubacher, R.: Vernetzt, klein und flexibel – die Firma des21. Jahrhunderts. In: Harvard Business Manager (1999) 2, S. 28-36.

MAN 1999

Managementsoftware Informationszentrum, http://www.management-software.de/management.htm, 10.07.1999.

MARCIAL 1997

Marcial, F.: Entwicklung von Datenmodellen für ein objektorientiertesEngineering Data Management System zur Unterstützung von team-orientierten Organisationsformen. Berlin: Springer 1997.

MAYER 1998

Mayer, R.: Ein Kooperationsnetzwerk zur Zusammenschaltung vonKernkompetenzen in der Entwicklung. In: Reinhart, G. (Hrsg.); Mil-berg, J. (Hrsg.): Erfolgreich kooperieren in der produzierenden Indust-rie – Flexibler und schneller mit modernen Kooperationen, Augsburg.München: Herbert Utz Verlag Wissenschaft 1998, S. 3-1 – 3-31.(iwb-Seminarberichte 40)


MEHLER & REINHART 1998

Mehler, B. H.: Reinhart, G.: Building the Virtual Factory – Manufac-turing in Dezentralized Networks: In: Proceedings of the 31st Interna-tional Seminar on Manufacturing Systems, Berkeley, CA. Internatio-nal Institution of Production Engineering Research (CIRP) 1998, S.81-86.

MENDEL 1997

Mendel, A.: Der Einfluß des Internet auf PDM-Systeme. EDM-Report(1997) 3, S. 44-49.

MERTENS 1995

Mertens, P.: Virtuelle Unternehmen – eine Organisationsstruktur fürdie Zukunft. Technologie und Management 44 (1995) 2, S. 61-68.

MERTINS & JOCHEM 1995

Mertins, K.; Jochem, R.: Integrated Enterprise Modelling for BusinessProcess Reengineering. In: Jansen H. (Hrsg.); Krause F.-L. (Hrsg.):Life-Cycle Modelling for Innovative Products and Processes. Berlin:Chapman & Hall 1995, S. 589-600.

MERTINS & JOCHEM 1998

Mertins, K.; Jochem, R.: Business Process Modelling – Ways andMethods for the Management of Change. In: Uhlmann, E. (Hrsg.),Spur G. (Hrsg.): IX. Internationales Produktionstechnisches Kolloqu-ium PTK 98 – Technologiemanagement, Berlin: Fraunhofer Institutfür Produktionsanlagen und Konstruktionstechnik, Institut für Werk-zeugmaschinen und Fabrikbetrieb der Technischen Universität Berlin1998, S. 453-462.

MILBERG 1998

Milberg, J.: Perspektiven für die Produktion aus der Sicht des Fahr-zeugbaus – Agilität als Wettbewerbsfaktor. In: Uhlmann, E. (Hrsg.),Spur G. (Hrsg.): IX. Internationales Produktionstechnisches Kolloqu-ium PTK 98 – Technologiemanagement, Berlin: Fraunhofer Institutfür Produktionsanlagen und Konstruktionstechnik, Institut für Werk-zeugmaschinen und Fabrikbetrieb der Technischen Universität Berlin1998, S. 29-39.


MILLARG 1998

Millarg, K.: Virtuelle Fabrik - Gestaltungsansätze für eine neue Orga-nisationsform in der produzierenden Industrie. St. Gallen: TransferVerlag 1998.

MILLARG 1999

Millarg, K.: Virtuelle Fabrik Euregio Bodensee - Neue Marktchancenfür die produzierende Industrie. In: Kongress Virtuelle Unternehmen,Mannheim: Technische Akademie Mannheim 1999.

MILLER U. A. 1994

Miller, E.; u. a.: PDM Buyer's Guide. Michigan: CIMdata 1994.

MÜLLER 1993

Müller, S.: Entwicklung einer Methode zur prozeßorientierten Reor-ganisation der technischen Auftragsabwicklung komplexer Produkte.Aachen: Shaker 1993. (Berichte aus der Produktionstechnik, Band1/93)

MURR 1999

Murr, O.: Management von integrierten Entwicklungs- und Pla-nungsprozessen am Beispiel komplexer Serienprodukte. München:Institut für Werkzeugmaschinen und Betriebswissenschaften 1999.Vorabdruck zur Dissertation.

NIKOL 1998

Nikol, G.: Viewer für EDM-Systeme - Die Anforderungen werdenmeist unterschätzt. EDM-Report (1998) 3, S. 40-42.

OLBRICH 1994

Olbrich, T.: Das Modell der "Virtuellen Unternehmen" als unterneh-mensinterne Organisations- und unternehmensexterne Kooperations-form. Information Management (1994) 4, S. 28-36.

PICOT & ROHRBACH (1995)

Picot, A.; Rohrbach, P.: Organisatorische Aspekte von Workflow-Management-Systemen. Information Management 10 (1995) 1, S. 28-35.


PICOT U. A. 1996

Picot, A.; Reichwald, R.; Wigand, R. T.: Die grenzenlose Unterneh-mung. 2. Aufl. Wiesbaden: Gabler 1996.

PLATZ 1995

Platz, J.: Projektmanagement für Ingenieure. München: TU, Institutfür Werkzeugmaschinen und Betriebswissenschaften, Umdruck zurVorlesung Projektmanagement 1995.

PÖRTNER 1998

Pörtner R.: Daten im Entwicklungsprozeß durchgängig nutzen. EDM-Report (1998) 3, S. 38-42.

REICHERT 1994

Reichert, O.: Netzplantechnik. Braunschweig: Vieweg 1994.

REINHART & BRANDNER 1996A

Reinhart, G.; Brandner, S.: Prozeßmanagement im Engineeringbe-reich mit PDM-Systemen. m&c – Management & Computer 4 (1996)3, S. 133-140.

REINHART & BRANDNER 1996B

Reinhart, G.; Brandner, S.: Integration von Zulieferern in das Daten-und Prozeßmanagement – Neue Möglichkeiten auf Basis des Internet.ZWF 91 (1996) 9, S. 391-394.

REINHART & BRANDNER 1998

Reinhart, G.; Brandner, S.: Process Management in Virtual Factories.In: Uhlmann, E. (Hrsg.); Spur, G. (Hrsg.): IX. Internationales Pro-duktionstechnisches Kolloquium PTK 98 – Technologiemanagement,Berlin: Fraunhofer Institut für Produktionsanlagen und Konstrukti-onstechnik, Institut für Werkzeugmaschinen und Fabrikbetrieb derTechnischen Universität Berlin 1998, S. 305-314.


REINHART & BREITINGER 1997

Reinhart, G.; Breitinger, F.: Rapid Tooling for Simultaneous Productand Process Development. In: Dickens, M. u. a. (Hrsg.): 6th Euro-pean Conference on Rapid Prototyping and Manufacturing, Notting-ham, UK. 1997, S. 179 -192.

REINHART & GRUNWALD 1999

Reinhart, G.; Grunwald, S.: Mit einer Kernkompetenzanalyse zurrichtigen Strategie für Produktionsunternehmen. Industrie Manage-ment (1999) 2, S. 57-61.

REINHART & SCHLIFFENBACHER 1997

Reinhart, G.; Schliffenbacher K.: Zehn Unternehmen erproben inAugsburg den Verbund auf Zeit. Blick durch die Wirtschaft.26.11.1997, S. 6.

REINHART U. A. 1996

Reinhart, G.; Mehler, B.; Schliffenbacher, K.: Virtuelle Unternehmen– Chance für produzierende Unternehmen in Deutschland. IndustrieManagement (1996) 6, S. 6-8.

RUDORFER 1998

Rudorfer, W.: Fit für Kooperationen - Anpassung von Unternehmenan die Anforderungen bei verteilter Produktion. In: Reinhart, G.(Hrsg.); Milberg, J. (Hrsg.): Erfolgreich kooperieren in der produzie-renden Industrie - Flexibler und schneller mit modernen Kooperatio-nen, Augsburg. München: Herbert Utz Wissenschaft 1998, S. 7-1 - 7-22. (iwb-Seminarberichte 40)

SANTELL 1996

Santell, M.: A Global Component Information System. In: Christman,A. (Hrsg.): PDM Conference, Boca Raton/USA. Ann Arbor:CIMDATA 1996.

SCHÄFER 1998

Schäfer, H.: Auf dem Weg zur prozeßorientierten Organisation. In-dustrie Management 14 (1998) 2, S. 71-74.


SCHEER 1995

Scheer, A.-W.: Wirtschaftsinformatik – Referenzmodelle für indus-trielle Geschäftsprozesse. Berlin: Springer 1995.

SCHENK & W ILSEN (1994)

Schenk, D.; Wilson, P.: Information Modelling the EXPRESS Way.Oxford: Oxford University Press 1994.

SCHITTKO 1997

Schittko, K.: Kopplung von EDM und PPS. Industrie ManagementSpezial: Engineering Management 1997/1998. S. 55-57.

SCHLIFFENBACHER U. A. 1999

Schliffenbacher, K.; Rudorfer, W.; Reinhart, G.: Configuration ofvirtual value chains. In: Mertins, K. (Hrsg.); Krause, O. (Hrsg.);Schallock, B. (Hrsg): International Conference on Advances in Pro-duction Management Systems – Global Production Management,Berlin: Fraunhofer Institut für Produktionsanlagen und Konstrukti-onstechnik 1999. Boston: Kluwer Academic Publishers 1999, S. 399-407.

SCHMALZL 1996

Schmalzl, B.: Ein Projektleitsystem im integrierten Produkterstel-lungsprozeß. Düsseldorf: VDI Verlag 1996. (VDI-Fortschritts-berichte, Reihe 20 – Rechnergestützte Verfahren)

SCHUH U. A. 1996

Schuh, G.; Krumm, S.; Boseske S.: Evolutionäres Reengineering füreuropäische Unternehmen. ZWF 91 (1996) 9, S. 406-409.

SCHUH U. A. 1998

Schuh, G.; Millarg, K.; Göransson, A.: Virtuelle Fabrik: Neue Markt-chancen durch dynamische Netzwerke. München: Hanser 1998.

SEMICH 1994

Zitiert in: Sieber, P.: Virtualität als Kompetenzfaktor. In: KongressVirtuelle Unternehmen, Mannheim: Technische Akademie Mann-heim 1999.


STEP 1995

N. N.: Schulung S22 – Austausch und Verwaltung organisatorischerDaten nach AP 214. Schulungsunterlagen der ProSTEP GmbH, 1995.

STUFFER & K LEEDÖRFER 1997

Stuffer, R.; Kleedörfer R.: Prozeßmanagement im Wandel – zeitge-rechte Ansätze zur Prozeßplanung und -steuerung. EDM-Report(1997) 2, S. 42-47.

TRAUTHEIM 1998

Trautheim, A.: Die Produktdatennorm STEP und der Nutzen fürPDM. In: Reinhart, G. (Hrsg.); Milberg, J. (Hrsg.): Engineering DataManagement – Erfahrungsberichte und Trends, Augsburg. München:Herbert Utz Verlag Wissenschaft 1998, S. 135-160. (iwb-Seminarberichte 31)

VERSTEEGEN 1995

Versteegen, G.: Alles im Fluß – Die Ansätze der Workflow Manage-ment Coalition. iX (1995) 3, S. 152-160.

WARNECKE U. A. 1998

Warnecke, G. u. a.: Evolutionskonzept für Referenzmodelle. IndustrieManagement 14 (1998) 2, S. 60-64.

WHEELWRIGHT & CLARK 1994

Wheelwright, S. C.; Clark, K. B.: Revolution der Produktentwick-lung, Spitzenleistung in Schnelligkeit, Effizienz und Qualität durchdynamische Teams: Frankfurt am Main: Campus 1994.

WIENDAHL U. A. 1996

Wiendahl, H.-P. u. a.: Kooperatives Management in wandelbarenProduktionsnetzen. Industrie Management 12 (1996) 6, S. 23-28.

WISCHNEWSKI 1992

Wischnewski, E.: Modernes Projektmanagement. Braunschweig:Vieweg 1992.

KYD�(QTUEJWPIUDGTKEJVG�$CPF��_��

*GTCWUIGDGT��2TQH��&T��+PI��,��/KNDGTI�WPF�2TQH��&T��+PI��)��4GKPJCTV��+PUVKVWV�HÒT

9GTM\GWIOCUEJKPGP�WPF�$GVTKGDUYKUUGPUEJCHVGP�FGT�6GEJPKUEJGP�7PKXGTUKV·V�/ÒPEJGP

$CPF��_��GTUEJKGPGP�KO�5RTKPIGT�8GTNCI��$GTNKP��*GKFGNDGTI�WPF�UKPF�KO�'TUEJGKPWPIULCJT�WPF�FGP�HQNIGPFGP

FTGK�-CNGPFGTLCJTGP�GTJ·NVNKEJ�KO�$WEJJCPFGN�QFGT�FWTEJ�.CPIG��5RTKPIGT�� 1VVQ�5WJT�#NNGG��_��$GTNKP

� 5VTGKHKPIGT� '�

$GKVTCI \WT 5KEJGTWPI FGT <WXGTN·UUKIMGKV WPF8GTHÒIDCTMGKV OQFGTPGT (GTVKIWPIUOKVVGN�� #DD� � �� 5GKVGP � +5$0 ��

� (WEJUDGTIGT� #�

7PVGTUWEJWPI FGT URCPGPFGP $GCTDGKVWPI XQP -PQEJGP�� #DD� � �� 5GKVGP � +5$0 ��

� /CKGT� %�

/QPVCIGCWVQOCVKUKGTWPI CO $GKURKGN FGU 5EJTCWDGPUOKV +PFWUVTKGTQDQVGTP�� #DD� � �� 5GKVGP � +5$0 ��:

� 5WOOGT� *�/QFGNN \WT $GTGEJPWPI XGT\YGKIVGT #PVTKGDUUVTWMVWTGP�� #DD� � �� 5GKVGP � +5$0 ��

� 5KOQP� 9�'NGMVTKUEJG 8QTUEJWDCPVTKGDG CP 0%�5[UVGOGP�� #DD� � �� 5GKVGP � +5$0 ��

� $ÒEJU� 5�#PCN[VKUEJG 7PVGTUWEJWPIGP \WT 6GEJPQNQIKG FGT-WIGNDGCTDGKVWPI�� #DD� � �� 5GKVGP � +5$0 ��

� *WP\KPIGT� +�

5EJPGKFGTQFKGTVG 1DGTHN·EJGP�� #DD� � �� 5GKVGP � +5$0 ��

� 2KNNCPF� 7�

'EJV\GKV�-QNNKUKQPUUEJWV\ CP 0%�&TGJOCUEJKPGP�� #DD� � �� 5GKVGP � +5$0 ��

� $CTVJGNOG� 2�

/QPVCIGIGTGEJVGU -QPUVTWKGTGP FWTEJ FKG +PVGITCVKQPXQP 2TQFWMV� WPF /QPVCIGRTQ\GIGUVCNVWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 4GKVJQHGT� 0�

0WV\WPIUUKEJGTWPI XQP HNGZKDGN CWVQOCVKUKGTVGP2TQFWMVKQPUCPNCIGP�� #DD� � �� 5GKVGP � +5$0 ��

�� &KGUU� *�4GEJPGTWPVGTUVÒV\VG 'PVYKEMNWPI HNGZKDGNCWVQOCVKUKGTVGT /QPVCIGRTQ\GUUG�� #DD� � �� 5GKVGP � +5$0 ��

�� 4GKPJCTV� )�

(NGZKDNG #WVQOCVKUKGTWPI FGT -QPUVTWMVKQP WPF (GTVKIWPIGNGMVTKUEJGT .GKVWPIUU·V\G�� #DD� � �� 5GKVGP � +5$0 ��

�� $ÒTUVPGT� *�

+PXGUVKVKQPUGPVUEJGKFWPI KP FGT TGEJPGTKPVGITKGTVGP2TQFWMVKQP�� #DD� � �� 5GKVGP � +5$0 ��

�� )TQJC� #�

7PKXGTUGNNGU <GNNGPTGEJPGTMQP\GRV HÒT HNGZKDNG(GTVKIWPIUU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

�� 4KGUG� -�

-NKRUOQPVCIG OKV +PFWUVTKGTQDQVGTP�� #DD� � �� 5GKVGP � +5$0 ��

�� .WV\� 2�

.GKVU[UVGOG HÒT TGEJPGTKPVGITKGTVG #WHVTCIUCDYKEMNWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� -NKRRGN� %�

/QDKNGT 4QDQVGT KO /CVGTKCNHNW GKPGU HNGZKDNGP(GTVKIWPIUU[UVGOU�� #DD� � �� 5GKVGP � +5$0 ��

�� 4CUEJGT� 4�'ZRGTKOGPVGNNG 7PVGTUWEJWPIGP \WT 6GEJPQNQIKG FGT-WIGNJGTUVGNNWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� *GWUNGT� *��,�

4GEJPGTWPVGTUVÒV\VG 2NCPWPI HNGZKDNGT /QPVCIGU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

�� -KTEJMPQRH� 2�

'TOKVVNWPI OQFCNGT 2CTCOGVGT CWUªDGTVTCIWPIUHTGSWGP\I·PIGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 5CWGTGT� %J�

$GKVTCI HÒT GKP <GTURCPRTQ\GOQFGNN /GVCNNDCPFU·IGP�� #DD� � �� 5GKVGP � +5$0 ��

�� -CTUVGFV� -�

2QUKVKQPUDGUVKOOWPI XQP 1DLGMVGP KP FGT /QPVCIG� WPF(GTVKIWPIUCWVQOCVKUKGTWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 2GKMGT� 5V�'PVYKEMNWPI GKPGU KPVGITKGTVGP 0%�2NCPWPIUU[UVGOU�� #DD� � �� 5GKVGP � +5$0 ��

�� 5EJWIOCPP� 4�0CEJIKGDKIG 9GTM\GWICWHJ·PIWPIGP HÒT FKGCWVQOCVKUEJG /QPVCIG�� #DD� � �� 5GKVGP � +5$0 ��

�� 9TDC� 2�

5KOWNCVKQP CNU 9GTM\GWI KP FGT *CPFJCDWPIUVGEJPKM�� #DD� � �� 5GKVGP � +5$0 ��:

�� 'KDGNUJ·WUGT� 2�

4GEJPGTWPVGTUVÒV\VG GZRGTKOGPVGNNG /QFCNCPCN[UGOKVVGNU IGUVWHVGT 5KPWUCPTGIWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 2TCUEJ� ,�

%QORWVGTWPVGTUVÒV\VG 2NCPWPI XQP EJKTWTIKUEJGP'KPITKHHGP KP FGT 1TVJQR·FKG�� #DD� � �� 5GKVGP � +5$0 ��

��6GKEJ� -�

2TQ\GMQOOWPKMCVKQP WPF 4GEJPGTXGTDWPF KP FGT2TQFWMVKQP

�� #DD� � �� 5GKVGP � +5$0 ��

��2HTCPI� 9�

4GEJPGTIGUVÒV\VG WPF ITCRJKUEJG 2NCPWPI OCPWGNNGT WPFVGKNCWVQOCVKUKGTVGT #TDGKVURN·V\G

�� #DD� � �� 5GKVGP � +5$0 ��

��6CWDGT� #�/QFGNNDKNFWPI MKPGOCVKUEJGT 5VTWMVWTGP CNU -QORQPGPVGFGT /QPVCIGRNCPWPI�� #DD� � �� 5GKVGP � +5$0 ��:

��,·IGT� #�

5[UVGOCVKUEJG 2NCPWPI MQORNGZGT 2TQFWMVKQPUU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

��*CTVDGTIGT� *�

9KUUGPUDCUKGTVG 5KOWNCVKQP MQORNGZGT2TQFWMVKQPUU[UVGOG

�� #DD� � �� 5GKVGP � +5$0 ��

��6WE\GM� *�

+PURGMVKQP XQP -CTQUUGTKGRTGVGKNGP CWH 4KUUG WPF'KPUEJPÒTWPIGP OKVVGNU /GVJQFGP FGT $KNFXGTCTDGKVWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��(KUEJDCEJGT� ,�2NCPWPIUUVTCVGIKGP \WT UVÌOWPIUVGEJPKUEJGP1RVKOKGTWPI XQP 4GKPTCWO�(GTVKIWPIUIGT·VGP�� #DD� � �� 5GKVGP � +5$0 ��:

��/QUGT� 1�

�&�'EJV\GKVMQNNKUKQPUUEJWV\ HÒT &TGJOCUEJKPGP�� #DD� � �� 5GKVGP � +5$0 ��

��0CDGT� *�

#WHDCW WPF 'KPUCV\ GKPGU OQDKNGP 4QDQVGTU OKVWPCDJ·PIKIGT .QMQOQVKQPU� WPF/CPKRWNCVKQPUMQORQPGPVG

�� #DD� � �� 5GKVGP � +5$0 ��

��-WRGE� 6J�9KUUGPUDCUKGTVGU .GKVU[UVGO \WT 5VGWGTWPI HNGZKDNGT(GTVKIWPIUCPNCIGP�� #DD� � �� 5GKVGP � +5$0 ��

��/CWNJCTFV� 7�

&[PCOKUEJGU 8GTJCNVGP XQP -TGKUU·IGP�� #DD� � �� 5GKVGP � +5$0 ��

��)ÌV\� 4�

5VTWMVWTKGTVG 2NCPWPI HNGZKDGN CWVQOCVKUKGTVGT/QPVCIGU[UVGOG HÒT HN·EJKIG $CWVGKNG

�� #DD� � �� 5GKVGP � +5$0 ��

��-QGRHGT� 6J�

�&�ITCHKUEJ�KPVGTCMVKXG #TDGKVURNCPWPI � GKP #PUCV\ \WT#WHJGDWPI FGT #TDGKVUVGKNWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJOKFV� /�-QP\GRVKQP WPF 'KPUCV\RNCPWPI HNGZKDGN CWVQOCVKUKGTVGT/QPVCIGU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

��$WTIGT� %�

2TQFWMVKQPUTGIGNWPI OKV GPVUEJGKFWPIUWPVGTUVÒV\GPFGP+PHQTOCVKQPUU[UVGOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��*QOCPP� ,�

/GVJQFKM \WT 2NCPWPI FGT CWVQOCVKUEJGP /QPVCIG XQPPKEJV HQTOUVCDKNGP $CWVGKNGP

�� #DD� � �� 5GKVGP � +5$0 ��

��2GVT[� /�

5[UVGOCVKM \WT 'PVYKEMNWPI GKPGU OQFWNCTGP2TQITCOODCWMCUVGPU HÒT TQDQVGTIGHÒJTVG -NGDGRTQ\GUUG

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJÌPGEMGT� 9�

+PVGITKGTVG &KCIPQUG KP 2TQFWMVKQPU\GNNGP

�� #DD� � �� 5GKVGP � +5$0 ��

��$KEM� 9�

5[UVGOCVKUEJG 2NCPWPI J[DTKFGT /QPVCIGU[UVGOG WPVGT$GTÒEMUKEJVKIWPI FGT 'TOKVVNWPI FGU QRVKOCNGP#WVQOCVKUKGTWPIUITCFGU�� #DD� � �� 5GKVGP � +5$0 ��

��)GDCWGT� .�

2TQ\GWPVGTUWEJWPIGP \WT CWVQOCVKUKGTVGP /QPVCIG XQPQRVKUEJGP .KPUGP

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJTÒHGT� 0�

'TUVGNNWPI GKPGU �&�5KOWNCVKQPUU[UVGOU \WT 4GFW\KGTWPIXQP 4ÒUV\GKVGP DGK FGT 0%�$GCTDGKVWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��9KUDCEJGT� ,�/GVJQFGP \WT TCVKQPGNNGP #WVQOCVKUKGTWPI FGT /QPVCIGXQP 5EJPGNNDGHGUVKIWPIUGNGOGPVGP�� #DD� � �� 5GKVGP � +5$0 ��

��)CTPKEJ� (�

.CUGTDGCTDGKVWPI OKV 4QDQVGTP�� #DD� � �� 5GKVGP � +5$0 ��

��'WDGTV� 2�

&KIKVCNG <WUVCPFGUTGIGNWPI GNGMVTKUEJGT8QTUEJWDCPVTKGDG

�� #DD� � �� 5GKVGP � +5$0 ��

��)NCCU� 9�

4GEJPGTKPVGITKGTVG -CDGNUCV\HGTVKIWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��*GNON� *�,�

'KP 8GTHCJTGP \WT 1P�.KPG (GJNGTGTMGPPWPI WPF &KCIPQUG

�� #DD� � �� 5GKVGP � +5$0 ��

��.CPI� %J�

9KUUGPUDCUKGTVG 7PVGTUVÒV\WPI FGT8GTHÒIDCTMGKVURNCPWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJWUVGT� )�4GEJPGTIGUVÒV\VGU 2NCPWPIUU[UVGO HÒT FKG HNGZKDGNCWVQOCVKUKGTVG /QPVCIG�� #DD� � �� 5GKVGP � +5$0 ��

��$QOO� *�

'KP <KGN� WPF -GPP\CJNGPU[UVGO \WO+PXGUVKVKQPUEQPVTQNNKPI MQORNGZGT 2TQFWMVKQPUU[UVGOG

�� #DD� � �� 5GKVGP � +5$0 ��

��9GPFV� #�

3WCNKV·VUUKEJGTWPI KP HNGZKDGN CWVQOCVKUKGTVGP/QPVCIGU[UVGOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��*CPUOCKGT� *�4GEJPGTIGUVÒV\VGU 8GTHCJTGP \WT )GT·WUEJOKPFGTWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��&KNNKPI� 7�2NCPWPI XQP (GTVKIWPIUU[UVGOGP WPVGTUVÒV\V FWTEJ9KTVUEJCHVUUKOWNCVKQPGP�� #DD� � �� 5GKVGP � +5$0 ��

��5VTQJOC[T� 4�

4GEJPGTIGUVÒV\VG #WUYCJN WPF -QPHKIWTCVKQP XQP<WDTKPIGGKPTKEJVWPIGP

�� #DD� � �� 5GKVGP � +5$0 ��:

��)NCU� ,�

5VCPFCTFKUKGTVGT #WHDCW CPYGPFWPIUURG\KHKUEJGT<GNNGPTGEJPGTUQHVYCTG

�� #DD� � �� 5GKVGP � +5$0 ��

��5VGVVGT� 4�4GEJPGTIGUVÒV\G 5KOWNCVKQPUYGTM\GWIG \WT'HHK\KGP\UVGKIGTWPI FGU +PFWUVTKGTQDQVGTGKPUCV\GU�� #DD� � �� 5GKVGP � +5$0 ��

��&KTPFQTHGT� #�

4QDQVGTU[UVGOG \WT HÌTFGTDCPFU[PEJTQPGP /QPVCIG�� #DD� � �� 5GKVGP � +5$0 ��

��9KGFGOCPP� /�

5KOWNCVKQP FGU 5EJYKPIWPIUXGTJCNVGPU URCPGPFGT9GTM\GWIOCUEJKPGP

�� #DD� � �� 5GKVGP � +5$0 ��

��9QGPEMJCWU� %J�

4GEJPGTIGUVÒV\VGU 5[UVGO \WT CWVQOCVKUKGTVGP �&�.C[QWVQRVKOKGTWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��-WOOGVUVGKPGT� )��&�$GYGIWPIUUKOWNCVKQP CNU KPVGITCVKXGU *KNHUOKVVGN \WT2NCPWPI OCPWGNNGT /QPVCIGU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

��-WIGNOCPP� (�

'KPUCV\ PCEJIKGDKIGT 'NGOGPVG \WT YKTVUEJCHVNKEJGP#WVQOCVKUKGTWPI XQP 2TQFWMVKQPUU[UVGOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJYCT\� *�

5KOWNCVKQPUIGUVÒV\VG %#&�%#/�-QRRNWPI HÒT FKG �&�.CUGTDGCTDGKVWPI OKV KPVGITKGTVGT 5GPUQTKM

�� #DD� � �� 5GKVGP � +5$0 ��

��8KGVJGP� 7�5[UVGOCVKM \WO 2TÒHGP KP HNGZKDNGP (GTVKIWPIUU[UVGOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��5GGJWDGT� /�#WVQOCVKUEJG +PDGVTKGDPCJOGIGUEJYKPFKIMGKVUCFCRVKXGT <WUVCPFUTGINGT�� #DD� � �� 5GKVGP � +5$0 ��:

��#OCPP� 9�

'KPG 5KOWNCVKQPUWOIGDWPI HÒT 2NCPWPI WPF $GVTKGD XQP2TQFWMVKQPUU[UVGOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��5EJÌRH� /�

4GEJPGTIGUVÒV\VGU 2TQLGMVKPHQTOCVKQPU� WPF-QQTFKPCVKQPUU[UVGO HÒT FCU (GTVKIWPIUXQTHGNF

�� #DD� � �� 5GKVGP � +5$0 ��

��9GNNKPI� #�'HHK\KGPVGT 'KPUCV\ DKNFIGDGPFGT 5GPUQTGP \WT(NGZKDKNKUKGTWPI CWVQOCVKUKGTVGT *CPFJCDWPIUXQTI·PIG�� #DD� � �� 5GKVGP � +5$0 ��

��<GVNOC[GT� *�

8GTHCJTGP \WT UKOWNCVKQPUIGUVÒV\VGP2TQFWMVKQPUTGIGNWPI KP FGT 'KP\GN� WPF-NGKPUGTKGPRTQFWMVKQP

�� #DD� � �� 5GKVGP � +5$0 ��

��.KPFN� /�#WHVTCIUNGKVVGEJPKM HÒT -QPUVTWMVKQP WPF #TDGKVURNCPWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��<KRRGT� $�

&CU KPVGITKGTVG $GVTKGDUOKVVGNYGUGP � $CWUVGKP GKPGTHNGZKDNGP (GTVKIWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��4CKVJ� 2�

2TQITCOOKGTWPI WPF 5KOWNCVKQP XQP <GNNGPCDN·WHGP KPFGT #TDGKVUXQTDGTGKVWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��'PIGN� #�5VTÌOWPIUVGEJPKUEJG 1RVKOKGTWPI XQP2TQFWMVKQPUU[UVGOGP FWTEJ 5KOWNCVKQP�� #DD� � �� 5GKVGP � +5$0 ��

��<·J� /� (�

&[PCOKUEJGU 2TQ\GOQFGNN -TGKUU·IGP�� #DD� � �� 5GKVGP � +5$0 ��

��<YCP\GT� 0�

6GEJPQNQIKUEJGU 2TQ\GOQFGNN HÒT FKG-WIGNUEJNGKHDGCTDGKVWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��4QOCPQY� 2�

-QPUVTWMVKQPUDGINGKVGPFG -CNMWNCVKQP XQP9GTM\GWIOCUEJKPGP

�� #DD� � �� 5GKVGP � +5$0 ��

��-CJNGPDGTI� 4�+PVGITKGTVG 3WCNKV·VUUKEJGTWPI KP HNGZKDNGP(GTVKIWPIU\GNNGP�� #DD� � �� 5GKVGP � +5$0 ��

��*WDGT� #�

#TDGKVUHQNIGPRNCPWPI OGJTUVWHKIGT 2TQ\GUUG KP FGT*CTVDGCTDGKVWPI

�� #DD� � �� 5GKVGP � +5$0 ��:

��$KTMGN� )�

#WHYCPFUOKPKOKGTVGT 9KUUGPUGTYGTD HÒT FKG &KCIPQUG KPHNGZKDNGP 2TQFWMVKQPU\GNNGP

�� #DD� � �� 5GKVGP � +5$0 ��

��5KOQP� &�(GTVKIWPIUTGIGNWPI FWTEJ \KGNITÌGPQTKGPVKGTVG 2NCPWPIWPF NQIKUVKUEJGU 5VÌTWPIUOCPCIGOGPV�� #DD� � �� 5GKVGP � +5$0 ��

��0GFGNLMQXKE�)TQJC� 8�

5[UVGOCVKUEJG 2NCPWPI CPYGPFWPIUURG\KHKUEJGT/CVGTKCNHNWUVGWGTWPIGP

�� #DD� � �� 5GKVGP � +5$0 ��

��4QEMNCPF� /�

(NGZKDKNKUKGTWPI FGT CWVQOCVKUEJGP 6GKNDGTGKVUVGNNWPI KP/QPVCIGCPNCIGP

�� #DD� � �� 5GKVGP � +5$0 ��

��.KPPGT� 5V�-QP\GRV GKPGT KPVGITKGTVGP 2TQFWMVGPVYKEMNWPI

�� #DD� � �� 5GKVGP � +5$0 ��

��'FGT� 6J�+PVGITKGTVG 2NCPWPI XQP +PHQTOCVKQPUU[UVGOGP HÒTTGEJPGTIGUVÒV\VG 2TQFWMVKQPUU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

��&GWVUEJNG� 7�

2TQ\GQTKGPVKGTVG 1TICPKUCVKQP FGT #WHVTCIUGPVYKEMNWPIKP OKVVGNUV·PFKUEJGP 7PVGTPGJOGP

�� #DD� � �� 5GKVGP � +5$0 ��

��&KGVGTNG� #�

4GE[ENKPIKPVGITKGTVG 2TQFWMVGPVYKEMNWPI

�� #DD� � �� 5GKVGP � +5$0 ��

�� *GEJN� %JT�

2GTUQPCNQTKGPVKGTVG /QPVCIGRNCPWPI HÒT MQORNGZG WPFXCTKCPVGPTGKEJG 2TQFWMVG�� #DD� � �� 5GKVGP � +5$0 ��

�� #NDGTV\� (�

&[PCOKMIGTGEJVGT 'PVYWTH XQP 9GTM\GWIOCUEJKPGP �)GUVGNNUVTWMVWTGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 6TWP\GT� 9�5VTCVGIKGP \WT 1P�.KPG $CJPRNCPWPI DGK 4QDQVGTP OKV�&�-QPVWTHQNIGUGPUQTGP�� #DD� � �� 5GKVGP � +5$0 ��:

�� (KEJVOÒNNGT� 0�

4CVKQPCNKUKGTWPI FWTEJ HNGZKDNG� J[DTKFG /QPVCIGU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��

�� 6TWEMU� 8�

4GEJPGTIGUVÒV\VG $GWTVGKNWPI XQP )GVTKGDGUVTWMVWTGP KP9GTM\GWIOCUEJKPGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 5EJ·HHGT� )�

5[UVGOCVKUEJG +PVGITCVKQP CFCRVKXGT2TQFWMVKQPUU[UVGOG�� #DD� � �� 5GKVGP � +5$0 ��:

�� -QEJ� /� 4�#WVQPQOG (GTVKIWPIU\GNNGP � )GUVCNVWPI� 5VGWGTWPI WPFKPVGITKGTVG 5VÌTWPIUDGJCPFNWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� /QEVG\WOC FG NC $CTTGTC� ,�.�

'KP FWTEJI·PIKIGU 5[UVGO \WT EQORWVGT� WPFTGEJPGTIGUVÒV\VGP %JKTWTIKG�� #DD� � �� 5GKVGP � +5$0 ��

�� )GWGT� #�

'KPUCV\RQVGPVKCN FGU 4CRKF 2TQVQV[RKPI KP FGT2TQFWMVGPVYKEMNWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 'DPGT� %�)CP\JGKVNKEJGU 8GTHÒIDCTMGKVU� WPF 3WCNKV·VUOCPCIOGPVWPVGT 8GTYGPFWPI XQP (GNFFCVGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 2KUEJGNVUTKGFGT� -�

5VGWGTWPI CWVQPQOGT OQDKNGT 4QDQVGT KP FGT 2TQFWMVKQP�� #DD� � �� 5GKVGP � +5$0 ��

�� -ÌJNGT� 4�

&KURQUKVKQP WPF /CVGTKCNDGTGKVUVGNNWPI DGK MQORNGZGPXCTKCPVGPTGKEJGP -NGKPRTQFWMVGP�� #DD� � �� 5GKVGP � +5$0 ��

�� (GNFOCPP� %J�

'KPG /GVJQFG HÒT FKG KPVGITKGTVG TGEJPGTIGUVÒV\VG/QPVCIGRNCPWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� .GJOCPP� *�+PVGITKGTVG /CVGTKCNHNW� WPF .C[QWVRNCPWPI FWTEJ-QRRNWPI XQP %#&� WPF #DNCWHUKOWNCVKQPUU[UVGO�� #DD� � �� 5GKVGP � +5$0 ��

�� 9CIPGT� /�

5VGWGTWPIUKPVGITKGTVG (GJNGTDGJCPFNWPI HÒTOCUEJKPGPPCJG #DN·WHG�� #DD� � �� 5GKVGP � +5$0 ��

�� .QTGP\GP� ,�

5KOWNCVKQPUIGUVÒV\VG -QUVGPCPCN[UG KPRTQFWMVQTKGPVKGTVGP (GTVKIWPIUUVTWMVWTGP�� #DD� � �� 5GKVGP � +5$0 ��

�� -TÌPGTV� 7�

5[UVGOCVKM HÒT FKG TGEJPGTIGUVÒV\VG �JPNKEJVGKNUWEJGWPF 5VCPFCTFKUKGTWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 2HGTUFQTH� +�

'PVYKEMNWPI GKPGU U[UVGOCVKUEJGP 8QTIGJGPU \WT1TICPKUCVKQP FGU KPFWUVTKGNNGP 5GTXKEG�� #DD� � �� 5GKVGP � +5$0 ��

�� -WDC� 4�+PHQTOCVKQPU� WPF MQOOWPKMCVKQPUVGEJPKUEJG+PVGITCVKQP XQP /GPUEJGP KP FGT 2TQFWMVKQP�� #DD� � �� 5GKVGP � +5$0 ��

�� -CKUGT� ,�

8GTPGV\VGU )GUVCNVGP XQP 2TQFWMV WPF2TQFWMVKQPURTQ\G OKV 2TQFWMVOQFGNNGP�� #DD� � �� 5GKVGP � +5$0 ��

�� )G[GT� /�

(NGZKDNGU 2NCPWPIUU[UVGO \WT $GTÒEMUKEJVKIWPIGTIQPQOKUEJGT #URGMVG DGK FGT 2TQFWMV� WPF#TDGKVUU[UVGOIGUVCNVWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� /CTVKP� %�

2TQFWMVKQPUTGIGNWPI � GKP OQFWNCTGT� OQFGNNDCUKGTVGT#PUCV\�� #DD� � �� 5GKVGP � +5$0 ��

�� .ÌHHNGT� 6J�

#MWUVKUEJG ªDGTYCEJWPI CWVQOCVKUKGTVGT (ÒIGRTQ\GUUG�� #DD� � �� 5GKVGP � +5$0 ��:

�� .KPFGTOCKGT� 4�

3WCNKV·VUQTKGPVKGTVG 'PVYKEMNWPI XQP /QPVCIGU[UVGOGP�� #DD� � �� 5GKVGP � +5$0 ��

�� -QGJTGT� ,�

2TQ\GQTKGPVKGTVG 6GCOUVTWMVWTGP KP $GVTKGDGP OKV)TQUGTKGPHGTVKIWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� 5EJWNNGT� 4� 9�.GKVHCFGP \WO CWVQOCVKUKGTVGP #WHVTCI XQPJQEJXKUMQUGP &KEJVOCUUGP�� #DD� � �� 5GKVGP � +5$0 ��

�� &GDWUEJGYKV\� /�

+PVGITKGTVG /GVJQFKM WPF 9GTM\GWIG \WTJGTUVGNNWPIUQTKGPVKGTVGP 2TQFWMVGPVYKEMNWPI�� #DD� � �� 5GKVGP � +5$0 ��

�� $CWGT� .�

5VTCVGIKGP \WT TGEJPGTIGUVÒV\VGP 1HHNKPG�2TQITCOOKGTWPI XQP �&�.CUGTCPNCIGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 2HQD� '�/QFGNNIGUVÒV\VG #TDGKVURNCPWPI DGK(GTVKIWPIUOCUEJKPGP�� #DD� � �� 5GKVGP � +5$0 ��

�� 5RKV\PCIGN� ,�

'THCJTWPIUIGNGKVGVG 2NCPWPI XQP .CUGTCPNCIGP�� #DD� � �� 5GKVGP � +5$0 ��

5GOKPCTDGTKEJVG�KYD

JGTCWUIGIGDGP�XQP�2TQH��&T��+PI��)WPVJGT�4GKPJCTV��+PUVKVWV�HÒT�9GTM\GWIOCUEJKPGP

WPF�$GVTKGDUYKUUGPUEJCHVGP�FGT�6GEJPKUEJGP�7PKXGTUKV·V�/ÒPEJGP

5GOKPCTDGTKEJVG� KYD�UKPF�GTJ·NVNKEJ�KO�$WEJJCPFGN�QFGT�DGKO

*GTDGTV�7V\�8GTNCI��/ÒPEJGP��(CZ��WV\"WV\XGTNCI�EQO

� +PPQXCVKXG /QPVCIGU[UVGOG � #PNCIGPIGUVCNVWPI� �DGYGTVWPIWPF �ÒDGTYCEJWPI�� 5GKVGP � +5$0 ��

� +PVGITKGTVGU 2TQFWMVOQFGNN � 8QP FGT +FGG \WO HGTVKIGP 2TQFWMV�� 5GKVGP � +5$0 ��

� -QPUVTWMVKQP XQP 9GTM\GWIOCUEJKPGP � $GTGEJPWPI� 5KOWNCVKQPWPF 1RVKOKGTWPI�� 5GKVGP � +5$0 ��

� 5KOWNCVKQP � 'KPUCV\OÌINKEJMGKVGP WPF 'THCJTWPIUDGTKEJVG�� 5GKVGP � +5$0 ��

� 1RVKOKGTWPI FGT -QQRGTCVKQP KP FGT 2TQFWMVGPVYKEMNWPI�� 5GKVGP � +5$0 ��

� /CVGTKCNDGCTDGKVWPI OKV .CUGT � XQP FGT 2NCPWPI \WT #PYGPFWPI�� 5GKVGP � +5$0 ��

� &[PCOKUEJGU 8GTJCNVGP XQP 9GTM\GWIOCUEJKPGP�� 5GKVGP � +5$0 ��

� 3WCNKV·VUOCPCIGOGPV � FGT 9GI KUV FCU <KGN�� 5GKVGP � +5$0 ��

� +PUVCNNCVKQPUVGEJPKM CP 9GTM\GWIOCUEJKPGP � #PCN[UGP WPF-QP\GRVG�� 5GKVGP � +5$0 ��

�� &�5KOWNCVKQP � 5EJPGNNGT� UKEJGTGT WPF MQUVGPIÒPUVKIGT \WO <KGN�� 5GKVGP � +5$0 ��

�� 7PVGTPGJOGPUQTICPKUCVKQP � 5EJNÒUUGN HÒT GKPG GHHK\KGPVG2TQFWMVKQP�� 5GKVGP � +5$0 ��

�� #WVQPQOG 2TQFWMVKQPUU[UVGOG�� 5GKVGP � +5$0 ��

�� 2NCPWPI XQP /QPVCIGCPNCIGP�� 5GKVGP � +5$0 ��

�� (NGZKDNG HNWKFG -NGD�&KEJVUVQHHG � &QUKGTWPI WPF 2TQ\GIGUVCNVWPI�� 5GKVGP � +5$0 ��

�� 6KOG VQ /CTMGV � 8QP FGT +FGG \WO 2TQFWMVKQPUUVCTV�� 5GKVGP � +5$0 ��

�� +PFWUVTKGMGTCOKM KP (QTUEJWPI WPF 2TCZKU � 2TQDNGOG� #PCN[UGPWPF .ÌUWPIGP�� 5GKVGP � +5$0 ��

�� &CU 7PVGTPGJOGP KO +PVGTPGV � %JCPEGP HÒT RTQFW\KGTGPFG7PVGTPGJOGP�� 5GKVGP � +5$0 ��

�� .GKVVGEJPKM WPF +PHQTOCVKQPUNQIKUVKM � OGJT 6TCPURCTGP\ KP FGT(GTVKIWPI�� 5GKVGP � +5$0 ��

�� &G\GPVTCNG 5VGWGTWPIGP KP 2TQFWMVKQPUCPNCIGP � 2NWI � 2NC[ �8GTGKPHCEJWPI XQP 'PVYKEMNWPI WPF +PDGVTKGDPCJOG�� 5GKVGP � +5$0 ��

�� 4CRKF 2TQVQV[RKPI � 4CRKF 6QQNKPI � 5EJPGNN \W HWPMVKQPCNGP2TQVQV[RGP�� 5GKVGP � +5$0 ��

�� /KMTQVGEJPKM HÒT FKG 2TQFWMVKQP � )TGKHDCTG 2TQFWMVG WPF#PYGPFWPIURQVGPVKCNG�� 5GKVGP � +5$0 ��

�� '&/ 'PIKPGGTKPI &CVC /CPCIGOGPV�� 5GKVGP � +5$0 ��

�� 4CVKQPGNNG 0WV\WPI FGT 5KOWNCVKQPUVGEJPKM � 'PVYKEMNWPIUVTGPFUWPF 2TCZKUDGKURKGNG�� 5GKVGP � +5$0 ��

�� #NVGTPCVKXG &KEJVWPIUU[UVGOG � -QP\GRVG \WT &KEJVWPIUOQPVCIGWPF \WO &KEJVOKVVGNCWHVTCI�� 5GKVGP � +5$0 ��

�� 4CRKF 2TQVQV[RKPI � /KV PGWGP 6GEJPQNQIKGP UEJPGNN XQO 'PVYWTH\WO 5GTKGPRTQFWMV�� 5GKVGP � +5$0 ��

�� 4CRKF 6QQNKPI � /KV PGWGP 6GEJPQNQIKGP UEJPGNN XQO 'PVYWTH \WO5GTKGPRTQFWMV�� 5GKVGP � +5$0 ��

�� +PUVCNNCVKQPUVGEJPKM CP 9GTM\GWIOCUEJKPGP � #DUEJNWUGOKPCT�� 5GKVGP � +5$0 ��

�� 'PIKPGGTKPI &CVC /CPCIGOGPV '&/� � 'THCJTWPIUDGTKEJVG WPF6TGPFU�� 5GKVGP � +5$0 ��

�� &�%#& � /GJT CNU PWT GKPG FTKVVG &KOGPUKQP�� 5GKVGP � +5$0 ��

�� .CUGT KP FGT 2TQFWMVKQP � 6GEJPQNQIKUEJG 4CPFDGFKPIWPIGP HÒTFGP YKTVUEJCHVNKEJGP 'KPUCV\�� 5GKVGP � +5$0 ��

�� #DNCWHUKOWNCVKQP � #PNCIGP GHHK\KGPV WPF UKEJGT RNCPGP WPFDGVTGKDGP�� 5GKVGP � +5$0 ��

�� /QFGTPG /GVJQFGP \WT /QPVCIGRNCPWPI � 5EJNÒUUGN HÒT GKPGGHHK\KGPVG 2TQFWMVKQP�� 5GKVGP � +5$0 ��

�� 9GVVDGYGTDUHCMVQT 8GTHÒIDCTMGKV � 2TQFWMVKXKV·VUVGKIGTWPIFWTEJ VGEJPKUEJG WPF QTICPKUCVQTKUEJG #PU·V\G�� 5GKVGP � +5$0 ��:

�� 4CRKF 2TQVQV[RKPI � 'HHK\KGPVGT 'KPUCV\ XQP /QFGNNGP KP FGT2TQFWMVGPVYKEMNWPI�� 5GKVGP � +5$0 ��

�� 4CRKF 6QQNKPI � 0GWG 5VTCVGIKGP HÒT FGP 9GTM\GWI� WPF(QTOGPDCW�� 5GKVGP � +5$0 ��

�� 'THQNITGKEJ MQQRGTKGTGP KP FGT RTQFW\KGTGPFGP +PFWUVTKG � (NGZKDNGTWPF UEJPGNNGT OKV OQFGTPGP -QQRGTCVKQPGP�� 5GKVGP � +5$0 ��:

�� +PPQXCVKXG 'PVYKEMNWPI XQP 2TQFWMVKQPUOCUEJKPGP�� 5GKVGP � +5$0 ��

�� 5VÒEM\CJNHNGZKDNG /QPVCIGU[UVGOG�� 5GKVGP � +5$0 ��

�� 2TQFWMVKXKV·V WPF 8GTHÒIDCTMGKV � ��FWTEJ -QQRGTCVKQP UVGKIGTP�� 5GKVGP � +5$0 ��

�� #WVQOCVKUKGTVG /KMTQOQPVCIG � *CPFJCDGP WPF 2QUKVKQPKGTGP XQP/KMTQDCWVGKNGP�� 5GKVGP � +5$0 ��

�� 2TQFW\KGTGP KP 0GV\YGTMGP � .ÌUWPIUCPU·V\G� /GVJQFGP�2TCZKUDGKURKGNG�� 5GKVGP � +5$0 ��

�� 8KTVWGNNG 2TQFWMVKQP � #DNCWHUKOWNCVKQP�� 5GKVGP � +5$0 ��

�� 8KTVWGNNG 2TQFWMVKQP � 2TQ\G� WPF 2TQFWMVUKOWNCVKQP�� 5GKVGP � +5$0 ��:

�� 5KEJGTJGKVUVGEJPKM CP 9GTM\GWIOCUEJKPGP�� 5GKVGP � +5$0 ��

�� 4CRKF 2TQVQV[RKPI � /GVJQFGP HÒT FKG TGCMVKQPUH·JKIG2TQFWMVGPVYKEMNWPI�� 5GKVGP � +5$0 ��

�� 4CRKF /CPWHCEVWTKPI � /GVJQFGP HÒT FKG TGCMVKQPUH·JKIG2TQFWMVKQP�� 5GKVGP � +5$0 ��:

�� (NGZKDNGU -NGDGP WPF &KEJVGP � 2TQFWMV�� 2TQ\GIGUVCNVWPI�/KUEJXGTDKPFWPIGP� 3WCNKV·VUMQPVTQNNG�� 5GKVGP � +5$0 ��

(QTUEJWPIUDGTKEJVG�KYD

JGTCWUIGIGDGP�XQP�2TQH��&T��+PI��)WPVJGT�4GKPJCTV��+PUVKVWV�HÒT�9GTM\GWIOCUEJKPGP

WPF�$GVTKGDUYKUUGPUEJCHVGP�FGT�6GEJPKUEJGP�7PKXGTUKV·V�/ÒPEJGP

(QTUEJWPIUDGTKEJVG� KYD�CD�$CPF��UKPF�GTJ·NVNKEJ�KO�$WEJJCPFGN�QFGT�DGKO

*GTDGTV�7V\�8GTNCI��/ÒPEJGP��(CZ��WV\"WV\XGTNCI�EQO

�� $WTIJCTF 5EJPGKFGT

2TQ\GUUMGVVGPQTKGPVKGTVG $GTGKVUVGNNWPI PKEJV HQTOUVCDKNGT $CWVGKNG�� 5GKVGP � �� #DD� � �� 6CD� � �� +5$0 ��

�� $GTPF )QNFUVGKP

/QFGNNIGUVÒV\VG )GUEJ·HVURTQ\GIGUVCNVWPI KP FGT 2TQFWMVGPVYKEMNWPI�� 5GKVGP � �� #DD� � �� +5$0 ��

�� *GNOWV '� /ÌOGT

/GVJQFG \WT UKOWNCVKQPUDCUKGTVGP 4GIGNWPI \GKVXCTKCPVGT 2TQFWMVKQPUU[UVGOG�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� 4CNH�)WPVGT )T·UGT

'KP 8GTHCJTGP \WT -QORGPUCVKQP VGORGTCVWTKPFW\KGTVGT 8GTHQTOWPIGP CP +PFWUVTKGTQDQVGTP�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� *CPU�,ÒTIGP 6TQUUKP

0WV\WPI FGT �JPNKEJMGKVUVJGQTKG \WT /QFGNNDKNFWPI KP FGT 2TQFWMVKQPUVGEJPKM�� 5GKVGP � �� #DD� � �� 6CD� � �� +5$0 ��

�� &QTKU -WIGNOCPP

#WHICDGPQTKGPVKGTVG 1HHNKPG�2TQITCOOKGTWPI XQP +PFWUVTKGTQDQVGTP�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��:

�� 4QNH &KGUEJ

5VGKIGTWPI FGT QTICPKUCVQTKUEJGP 8GTHÒIDCTMGKV XQP (GTVKIWPIU\GNNGP�� 5GKVGP � �� #DD� � �� +5$0 ��

�� 9GTPGT '� .WNC[

*[DTKF�JKGTCTEJKUEJG 5KOWNCVKQPUOQFGNNG \WT -QQTFKPCVKQP VGKNCWVQPQOGT 2TQFWMVKQPUUVTWMVWTGP�� 5GKVGP � �� #DD� � �� 6CD� � �� +5$0 ��

�� 1VVQ /WTT

#FCRVKXG 2NCPWPI WPF 5VGWGTWPI XQP KPVGITKGTVGP 'PVYKEMNWPIU� WPF 2NCPWPIURTQ\GUUGP�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� /KEJCGN /CEJV

'KP 8QTIGJGPUOQFGNN HÒT FGP 'KPUCV\ XQP 4CRKF 2TQVQV[RKPI�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� $TWPQ *� /GJNGT

#WHDCW XKTVWGNNGT (CDTKMGP CWU FG\GPVTCNGP 2CTVPGTXGTDKPFWPIGP�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� -PWV *GKVOCPP

5KEJGTG 2TQIPQUGP HÒT FKG 2TQFWMVKQPUQRVKOKGTWPI OKVVGNU UVQEJCUVKUEJGT /QFGNNG�� 5GKVGP � �� #DD� � �� 6CD� � �� +5$0 ��

�� 5VGHCP $NGUUKPI

)GUVCNVWPI FGT /CVGTKCNHNWUVGWGTWPI KP F[PCOKUEJGP 2TQFWMVKQPUUVTWMVWTGP�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

�� %CP #DC[

0WOGTKUEJG 1RVKOKGTWPI OWNVKXCTKCVGT OGJTUVWHKIGT 2TQ\GUUG CO $GKURKGN FGT *CTVDGCTDGKVWPI XQP +PFWUVTKGMGTCOKM�� 5GKVGP � �� #DD� � � 6CD� � �� +5$0 ��

Integriertes Produktdaten- und Prozeßmanagement …...Lehrstuhl für Betriebswissenschaften und...

Documents

Transcript of Integriertes Produktdaten- und Prozeßmanagement …...Lehrstuhl für Betriebswissenschaften und...