Integration ist für die Fachabteilungen oft ein ungeliebtes Wort, weil mit diesem Begriff verschiedene negative Erwartungen verbunden sind. Doch Integration ist ohne Mittarbeit der Fachabteilungen nicht möglich. Johann Frey* diskutiert in seinem Beitrag das Management von CAx-Integrationsprojekten.

Die Komplexität, Mächtigkeit und Qualität spezieller EDV-Anwendungen steigen ständig. Immer mehr -Fachbereiche werden durch immer bessere Software-Pakete unterstützt. Betrachtet man dagegen die Verbindungen zwischen diesen qualitativ hochwertigen Inseln, so muß man feststellen, daß sowohl der Austausch an Informationen oft unsystematisch, unvollständig und wenig effizient ist, als auch ein gesicherter Zugriff auf konsistente Daten nicht immer gewährleistet ist. Der Integration der verschiedenen Anwendungen kommt hohe Bedeutung zu ñ die weltweite Diskussion und Entwicklung auf dem Gebiet des CIM (Computer Integrated Manufacturing) unterstreicht diese Bedeutung.

Integration auch auf der Daten-Ebene

Wenn wir CIM grob mit der Formel CIM = CAD + CAE + CAM + CAPP + CAQ + PPS beschreiben, haben wir die wesentlichen CAx-Anwendungsgebiete** versammelt, über die wir in diesem Rahmen sprechen.

Die CAx-Anwendungen als Bausteine des CIM müssen miteinander verknüpft werden.

Integration kann als Zustand, als Ergebnis des Vorgangs "Zusammenfassen" betrachtet werden oder als der Vorgang der Zusammenfassung von Teilen zu einem Ganzen als aktiver Prozeß. Nachdem es CIM als Zustand noch nicht gibt, sprechen wir bei der CAx-Integration von den Aktionen, CIM-Bausteine miteinander zu verknüpfen. Die Integration findet dabei sowohl auf der funktionalen als auch auf der Daten-Ebene Statt.

CIM ist heute eine Herausforderung und eine strategische Disziplin. CIM ist eine langfristige, konzeptionell orientierte Aufgabe mit einer Vielzahl von Teilaufgaben, die im Rahmen einer übergeordneten CIM-Architektur gelöst werden müssen.

Ein Projekt dagegen ist keine Disziplin, sondern eine zeitlich begrenzte Aufgabe. Diese Aufgabe ist im Rahmen eines vorgegebenen Budgets zu lösen. Die Integration verschiedener CAx-Bausteine kann als Projekt organisiert werden.

Im Rahmen einer ganzheitlich orientierten Projektleitung lassen sich die Aufgaben des Projektmanagements gliedern:

- fachliche Steuerung,

- administrative Steuerung,

- Organisation und strukturelle Voraussetzungen,

- Führungsverhalten.

a) Der Projektleiter braucht fachliche Kompetenz ebenso wie Organisationsmethoden, EDV-bezogene Techniken und Vorgehensweisen, um Projekte inhaltlich planen und steuern zu können.

b) Methoden der Ressourcenplanung und -kontrolle sowie Methoden und Instrumente der Projektablauforganisation (zum Beispiel Phasenkonzepte, Dokumentationsmethoden) gehören zum administrativen Projektmanagement.

c) Eine Projektorganisation mit klaren Kompetenzen und geregelten Entscheidungsprozessen ist eine strukturelle Voraussetzung für eine erfolgreiche Projektarbeit.

d) Innerhalb der Projektarbeit sind "Führen" und "Motivieren" wichtige Faktoren, die den Projektfortschritt durch Vermeidung/Abbau von Spannungen, Widerständen oder

Konkurrenzdenken positiv beeinflussen.

Ein CAx-Integrationsprojekt ist

demnach eine abgeschlossene Aufgabe innerhalb der Disziplin CIM, bei der punktuell Bausteine von CIM in einer vorgegebenen Zeit mit einem vorgegebenen Kostenrahmen realisiert werden sollen.

Organisation und Struktur-Voraussetzungen

Der Idealfall der strukturellen Voraussetzungen für ein CAx-Integrationsprojekt sieht also so aus, daß ein schlagkräftiges Team in einer strategischen Organisationseinheit CIM betreibt.

Ergebnisse dieser CIM-Arbeit sind

ñ die Erstellung eines Rahmenkonzepts für CIM-Architektur;

ñ die Bewertung der daraus abzuleitenden Einzelprojekte;

ñ die Installation dieser Einzelprojekte;

ñ Rahmenrichtlinien für die Durchführung der Projekte;

- Vorgabe, Koordinierung, Auswahl von übergreifenden Tools (zum Beispiel Datenbank);

- Koordination eines CIM-relevanten Datenkatalogs, der möglichst unternehmensweit gültig ist;

- Hardware-Konzept (Host, Abteilungsrechner, Workstation) etc.

Ausgehend von dieser qualifizierten Basis können Bausteine, Teilprojekte mit klaren Zielsetzungen und Vorgaben definiert werden, die dennoch komplex genug sind, um ausreichend Freiraum für innovative Lösungen zu bieten. Beispiele für CAx-Integrations-Projekte:

þCAE/CAD-Integration

- vertikale und horizontale Integration von CAE- und CAD-Programmsystemen, beispielsweise für die CAE-Bereiche Aerodynamik, Strukturmechanik/-optimierung, Vorkonstruktion, Ausrüstungseinbauten etc. unter Berücksichtigung der Datengenerierung, des Datenaustausches; und einer eindeutigen Archivierung der Daten in einer "Engineering Database".

þGeometrie-Integration

ñ Trotz ihrer enormen Leistungsfähigkeit decken die heutigen CAD/CAE/CAM-Systeme die Anforderungen der Fachabteilungen nicht vollständig ab. Solche Technologie-Nischen müssen unter Berücksichtigung der Weiterentwicklung der Kaufsoftware zukunftssicher durch eigene Spezialentwicklungen aufgefüllt werden, um die durchgängige Verwendung und Verwaltung der Geometrie vom Vorentwurf bis zur Fertigung zu realisieren.

þCAD/CAM-Integration

ñ Lösung spezieller Datenintegrationsprobleme zwischen CAD-Systemen und den Fertigungsanforderungen für NC-Programmierung, neue Werkstoffe wie CFK-Fertigung etc. sind die Anforderungen des Datenaustausches zwischen Konstruktion und Fertigung.

Jedes Teilprojekt, das im Rahmen einer übergeordneten CIM-Architektur abgewickelt werden soll, muß eine eigene Projektorganisation mit den für die Durchführung der Aufgaben notwendigen und ausreichenden Vollmachten und Kompetenzen für das Projekt-Management haben.

Die interne Struktur des Projektes ist heterogen, da bei Integrationsaufgaben immer mehrere Fachbereiche betroffen sind. Da es im allgemeinen unmöglich ist, ein Team zusammenzustellen, das ausschließlich in einem Integrationsprojekt arbeitet, ist eine Organisationsform notwendig, welche die begrenzte Verfügbarkeit insbesondere der Fachabteilungsmitarbeiter berücksichtigt. Darüber hinaus muß das Projektmanagement in die Lage versetzt werden, die konkurrierenden Anforderungen, Prioritäten und Zeitvorstellungen verschiedener Fachbereiche aus unterschiedlichen Ressorts oder Unternehmensgruppen zu koordinieren.

Managementprobleme von Integrationsprojekten

Die administrativen Aufgaben des Projektmanagements sind hinreichend bekannt: Projekt einrichten, planen (Phasenkonzept), überwachen, steuern und koordinieren abschließen. Die Führungsaufgabe des Projektmanagements sind Führen, Entscheiden, Verantworten und Motivieren.

Die Schwierigkeiten, die bei der Abwicklung von Integrationsprojekten auftreten (können), werden nachfolgend dargestellt.

Integrationsbewußtsein vertiefen

Die Bedeutung des Integrationsgedankens muß von der Leitung getragen und die Integration muß von der Leitung her durchgesetzt werden.

Probleme: Unter Termindruck - und der verstärkt sich immer mehr - wird der Produktion beziehungsweise der Produktentwicklung Vorrang vor der Integration gegeben ("wir leben von den Produkten, nicht von der Integration"). Kurzfristige Aufgaben verhindern die längerfristig dringend notwendige Integration.

Ist der Lenkungsausschuß des Projektes überwiegend aus produktverantwortlichen Führungspersonen besetzt, dann wird die Entscheidung über den Mitarbeitereinsatz (fast) immer zugunsten der Aufgaben und gegen die Integration getroffen ñ der Einsatz in Integrationsprojekten wird in "ruhigeren" Zeiten wohlwollend geduldet.

Als Folge davon ist die Bereitschaft ,der Fachabteilungs-Mitarbeiter, an Integrationsprojekten mitzuarbeiten, sehr gering. Die Wertschätzung dieser Aufgaben als "nicht so wichtig", "Lückenfüller", "keine dauerhafte Aufgabe" etc. spiegelt sich dann im Engagement und in der Motivation der Mitarbeiter wider ñ und natürlich im Ergebnis.

Deshalb muß gefordert werden, daß Integrationsprojekte mit genügend Finanzmitteln ausgestattet sind, um die Fachabteilungsmitarbeiter für die Projektdauer (fast) ausschließlich für die Integrationsaufgaben zur Verfügung zu stellen, was die Motivation und das Ergebnis enorm verbessern kann.

Integrationsarchitektur muß vorhanden sein

Das CIM-Rahmenkonzept muß vorhanden sein. Aus diesem Rahmenkonzept heraus werden die Einzelvorhaben angestoßen, Datenmodelle beziehungsweise mindestens die Tools für die Datenkataloge sollten vorgegeben sein.

Probleme: Der Anstoß für Teilprojekte erfolgt zum Teil von der Basis und nicht "top down". Das bedeutet, daß aus Sicht eines Teilprojektes Funktionen und Datenmodelle in eine unvollständige Architektur hineingestellt werden müssen, statt daß aus übergeordneter Sicht eine integrierte Funktions- und Datenstruktur abgeleitet wird.

Die Folge eines fehlenden Rahmens ist ein erhöhter Aufwand, zum die notwendigen Informationen zu sammeln ñ Funktionen, insbesondere jedoch Datenmodelle, -strukturen und -kataloge der betroffenen, auch der benachbarten Fachabteilungen.

Zusätzlich kann mit Sicherheit gesagt werden, daß aus dieser begrenzten Sicht heraus Doppelarbeit unvermeidlich ist, Lücken vorprogrammiert sind und dringend notwendige Abstimmungen mit Nachbarprojekten nicht oder zumindest nicht ausreichend stattfinden. Dadurch wird eine "sogenannte" Integration über zum Teil überflüssige Interfaces holprig zusammengebastelt. Erfolgreiche Integration geht (fast) nur mit "Top-down"-Konzepten ñ aus der begrenzten Sicht von Fachabteilungen überwiegt immer der Gedanke der Eigeninteressen und des Eigennutzen. Daraus kann eine sehr gute Teillösung resultieren ñ jedoch keine richtige Integration.

Prioritäten von Integrationsaufgaben

Wer legt die Prioritäten von Aufgaben fest? Die zu realisierenden Funktionen müssen vom Fachbereich spezifiziert und innerhalb eines Fachbereichs geordnet werden. Bei Integrationsprojekten sind mehrere verschiedene Fachbereiche beteiligt ñ die Prioritätenfindung muß übergeordnet stattfinden.

Der Fachprojektleiter kommt in der Regel aus einem beteiligten Fachbereich. Deshalb besteht prinzipiell das Problem, daß die Eigeninteressen, mit der Koordinationsfunktion kollidieren und daß Entscheidungen durch diese Doppelfunktion ungünstig beeinflußt werden.

Da nicht alle relevanten Aufgaben parallel bearbeitet werden können stellt sich bei Abteilungen, deren Aufgaben niedrigere Priorität haben, die Frage "warten oder selbst machen". Meistens sind die Aufgaben dringlich und werden dann innerhalb der Fachabteilung gelöst ñ schnell, aber nicht integrationskonform.

Als Folge läuft die Schere zwischen der Integration und dem internen "FA-Programmpool" ständig weiter auseinander.

Probleme bei der Projektarbeit

Integration bedeutet Neuland für die betroffenen Bereiche und zum Teil Mehraufwand, der anderen Abteilungen Nutzen bringt. Dies erfordert von den Mitarbeitern Lern- und Einsatzbereitschaft, die nicht verordnet werden kann. An einigen Beispielen werden nun Probleme der Integrationsarbeit aufgezeigt.

In der Vergangenheit wurden Daten im Entwicklungszyklus oft auf Zuruf zwischen verschiedenen Abteilungen ausgetauscht und danach weiterverarbeitet.

Die Datenverwaltung war innerhalb jedes Fachbereichs mehr oder weniger zuverlässig gelöst, jedoch ohne übergreifende Systematik. Dadurch waren eine zuverlässige Versionskontrolle, Informationen über die Veränderung von Ausgangsdaten an die betroffenen Benutzer etc. kaum oder nur unvollständig möglich. Nach Meinung der Fachabteilungen ist dieses Vorgehen ausreichend, nach Integrationsgesichtspunkten jedoch nicht. Modernere Archivierungskonzepte, die auf relationalen Datenbanken beruhen, sollen diese spezifischen Lösungen durch eine einheitliche Systematik ablösen. Ziele sind dabei

þeine lückenlose Dokumentation, welche zeitlichen und funktionalen Abhängigkeiten zwischen den verwendeten Daten bestehen,

þgezielte Informationsmöglichkeiten bei Veränderungen von Ausgangsdaten,

þkonsistente Datenhaltung und Zugriffsschutz in Datenbanken.

Seitens der Fachabteilung werden solchen Veränderungen Widerstände entgegengesetzt:

ñ die eigene Kontrolle über die Datenbestände scheint verlorenzugehen;

ñ der Ablauf verändert sich, neue Namenskonventionen müssen eingehalten werden;

ñ der DV-Technologie-Datenbank wird Mißtrauen entgegengebracht;

ñ Speichertechniken, wie der Differenzenmethode, wo zur Reduzierung des Speicherplatzes nur die Veränderung zum vorherigen Zustand gespeichert wird, werden abgelehnt.

Relationale Datenbanken führen ins Neuland

Bei der gemeinsamen Definition des Archivierungskonzeptes zwischen Fach- und DV-Abteilung müssen die Widerstände durch Prototyp-Entwicklung, Pilotanwendungen und Überzeugungsarbeit der DV-MA langsam abgebaut weren. Das setzt seitens der DV-MA Ausdauer und Motivation voraus, da der Einsatz relationaler Datenbanken für technisch orientierte Bereiche auch methodisch ins Neuland führt.

Der Weg ins Neuland ist natürlich immer mit Unsicherheiten behaftet. Diese Unsicherheit steigert das Vertrauen der FA in die DV-Abteilung nicht, so daß eine gewisse Skepsis durchaus verständlich wird. Die Risiken der Entwicklung eines solchen Archivierungskonzeptes sollen durch ein schrittweises Vorgehen möglichst klein gehalten werden.

Die Informationen werden zunächst als "BIack Box" in einem Umschlag versteckt archiviert, und nur die Adressen der Umschläge werden mit ihren relevanten Daten (Ersteller, Datum, Datenbezeichnung, Projektcode etc.) in der Datenbank verwaltet, so daß Informationsketten bezüglich der zeitlichen und funktionalen Abhängigkeit der Daten abgefragt werden können.

In späteren Projektphasen sollen dann Beziehungen, die zwischen den Inhalten der Umschläge bestehen, in Informationsmodellen abgebildet und zur Reduktion von Redundanzen verwendet werden. Hier sind verschiedene Abstufungen zwischen dem gewünschten und dem möglichen Detaillierungsgrad denkbar. Die tatsächliche Realisierung hängt dann auch stark von der Entwicklung der Datenbanken und der Hardware ab.

Die Einführung des Archives läßt schon eine Abfrage auf den realen Datenfluß zu und macht das Zustandekommen von Berechnungsergebnissen aufgrund der Eingabedaten transparent.

Abfrage auf den realen Datenfluß

Ein weiterer Arbeitspunkt ist die Umsetzung der gelieferten Daten in die Eingabedaten für das nächste Programm. Im Idealfall sind die Datenstrukturen gleich, dann ist kein interfaceprogramm nötig. Im Normalfall werden die Daten umformatiert (und eventuell ergänzt oder erweitert). Durch Einführung einer gemeinsamen Datenstruktur (Informationsmodell) in den beteiligten Programmen wird das Interface-Programm überflüssig. Integrationsrelevante Programme sollten sukzessive mit modernem SW-Engineering von der DV-Abteilung unter diesen Gesichtspunkten überarbeitet werden. Im allgemeinen sind Fachabteilungen jedoch nur ungern bereit, ihre eigenentwickelten Programme zugänglich zu machen, da sie oft undokumentierte und unter Zeitdruck entstandene Problemlösungen sind, die zudem geändert werden und keiner Versionskontrolle unterliegen.

Trotz der rasanten fortschreitenden Entwicklung der CAD-Systeme bleiben viele Anwenderwünsche unberücksichtigt. Zum Beispiel ist die Geometrie, die in der Aerodynamik oder in der Strukturmechanik verarbeitet wird, eine Panelgeometrie, die aus Punkten besteht, die auf den Original-CAD-Flächen liegen sollen. Die interaktive Erzeugung solcher abhängigen Geometriedaten einschließlich der Weitergabe an nachfolgende Berechnungsprogramme ist eine interessante Anwendung aus CAx-Integrationsprojekten.

Probleme: Die Anforderungen an den DV-Mitarbeiter sind sehr vielfältig.

þDie Funktionen können vom Anwender meist nur vage umschrieben werden, das heißt, die Dialogstruktur wird vom Systementwickler durch Prototyping entworfen.

þDer Systementwickler muß die interaktive Dialogsprache des CAD-Systems beherrschen.

þEs wird vertiefte Kenntnis des CAD-Systems vorausgesetzt.

þZur Generierung zusätzlicher Geometrie muß der Systementwickler die Mathematik des CAD-Systems verstehen.

In diesem Bereich sind die Motivationsprobleme gering. Im allgemeinen sind die MA für solche innovativen und abwechslungsreichen Aufgaben durch die Vielfalt der Aufgabenstellungen hinreichend motiviert. Die fortschreitende Entwicklung der CAD-Systeme zwingt den Systementwickler jedoch ständig, diese Zukunftsperspektiven zu berücksichtigen und die Programm-Module den neuen System-Releases anzupassen (= relativ hoher Wartungsaufwand). Neben diesen SW-Randbedingungen müssen auch die Hardware-Voraussetzungen wie Workstations, Rechnervernetzung etc. im Auge behalten werden.

Der Datenaustausch mit Partnerfirmen und zwischen verschiedenen Anwendungen ist bei weitem nicht

generell gelöst. Jedoch fehlt es beim Management und den Fachabteilungen oft am Bewußtsein für dieses Problem, da die Begriffe der Austauschstandards IGES, SET, VDAFS bekannt sind und der Eindruck entsteht, als wären damit alle Probleme gelöst. Tatsache ist jedoch, daß aufgrund der unterschiedlichen Verfügbarkeit und Qualität der Prozessoren eine detaillierte Kleinarbeit notwendig ist, ehe ein Datenaustausch-Verfahren zwischen Partnerfirmen eingeführt werden kann. Ein rechtzeitiges Einschalten der entsprechenden Spezialisten kann hier eine Menge Ärger und Hektik vermeiden.

Falls der Datenaustausch zwischen zwei Partnerfirmen für eine begrenzte Anzahl von Elementen stattfindet, sind oft speziell geschriebene Prozessoren schneller und qualitativ besser als der Einsatz von Standardschnittstellen. Sind jedoch mehr als zwei Partner beteiligt oder eine Vielzahl von Elementen auszutauschen, wird der Nutzen einer genormten Schnittstelle schnell deutlich.

Im Rahmen von europäischen Luft- und Raumfahrtprojekten wird dabei im allgemeinen dem SET der Vorzug der IGES gegeben:

þdie Prozessoren sind qualitativ besser (Elementübertragung und Rechenzeit) und

þAerospatiale ist Hauptentwickler der Norm und mehrerer Prozessoren.

Falls nun Aerospatiale Projektpartner ist, ist bei auftretenden Problemen eine schnelle Hilfe und Korrekturmöglichkeit gewährleistet.

Noch einige Bemerkungen zur internationalen Normung von Produktdaten: Die Zusammenführung von IGES, SET, VDAFS, PDES etc. zur gemeinsamen internationalen ISO-Norm STEP (Standard for Exchange of Product Data) macht gute Fortschritte.

Die Definition verschiedener Leistungsklassen und anwendungsspezifischer Elementklassen (wie zum Beispiel FEM) sowie die Entwicklung der entsprechenden Prozessoren für eine Vielzahl von CAD-Systemen wird jedoch noch lange Zeit in Anspruch nehmen. Das Endergebnis ist sicherlich ein brauchbarer Standard für den externen Datenaustausch ñ für die firmeninterne Integration und Archivierung CIM-relevanter Daten wird er in absehbarer Zeit nicht eingesetzt werden können.

Integration ist für Fachabteilungen oft ein ungeliebtes Wort, da verchiedene negative Erwartungen mit diesem Begriff verbunden sind:

þarbeitsmäßiger und konzeptioneller Zusatzaufwand, der für andere Abteilungen einen nicht transparenten Nutzen bringen soll,

þdrohender Verlust von Selbständigkeit für den Mitarbeitertyp "alles selber machen",

þAußenstehenden muß Einblick in interne Abläufe und Programme gewährt werden.

Voraussetzungen sind oft nicht ideal

Integration ohne Mitarbeit der Fachabteilungen ist jedoch nicht möglich. Deshalb ist die Arbeit des Projektmanagements und der DV-Mitarbeiter oft dadurch belastet, daß die durch dieses Negativ-Image der Integration aufgebauten Widerstände in geduldiger Überzeugungsarbeit in gemeinsame Integrationsmotivation verändert werden müssen.

Die Voraussetzungen der CAx-Integration sind oft nicht ideal. Die Projektorganisation, die eingeschränkte Verfügbarkeit, insbesondere der Fachabteilungs-Mitarbeiter, unvollständige CIM-Rahmenarchitektur, fehlendes Bewußtsein für die Bedeutung der Integration etc. erschweren die Durchführung der Projekte. Dennoch müssen die Integrationsprojekte als Bausteine einer umfassenden CIM-Lösung im Rahmen der vorgegebenen Randbedingungen durchgeführt werden. Die Qualität der Ergebnisse hängt stark von der Qualifikation der Mitarbeiter und deren Bereitschaft ab, trotz manchmal widriger Randbedingungen die Integration mit Motivation voranzutreiben.

An der Integration kommt kein Unternehmen vorbei, und sie muß im Unternehmen konzipiert und durchgeführt werden.

*Johann Frey ist Projektleiter CAE/CAD-Integration bei der Messerschmitt-Bölkow- Blohm GmbH, Ottobrunn bei München.

**CAD ñ Computer Aided Design

CAE ñ Computer Aided Engineering

CAM ñ Computer Aided Manufacturing

CAPP ñ Computer Aided Process Planning

CAQ ñ Computer Aided Quality Assurance

(PPS ñ Projekt-Planung und -Steuerung)