Über Collaborative Engineering in der Automobilindustrie habe ich ja schon einmal geschrieben. Das Thema lohnt aber, auch noch aus anderen Perspektiven betrachtet zu werden. Neben dem Prozess- und dem Organisationsaspekt sind es vor allem die Daten in der Produktentwicklung, auf die es ankommt. Komplexe Produkte wie Autos mit all ihren Systemen werden schon langem nicht mehr über eine Ansammlung einzelner Dokumente beschrieben. Moderne Produktdaten-Management-Systeme (PDM) sind in der Lage, unterschiedliche Informationsarten zu jedem einzelnen Bauteil zu speichern und bereitzustellen. Verwalten PDM-Systeme nicht “nur” Konstruktionsdaten sondern Informationen entlang der Lebendauer der Teile, spricht man von Produkt-Lebenszyklus-Systemen (PLM).

Das ist nichts Neues. Wie kommen aber all die Daten zusammen? Sie werden ja von unterschiedlichen Akteuren während der (Konstruktions-)Prozesse zusammengetragen, sie hängen voneinander ab, sie haben wechselnde Versions- und Freigabestände, sind mit unterschiedlichen Systemen erstellt worden oder werden in unterschiedlicher Weise benötigt.

PDM-Systeme in collaborativen Umgebungen müssen zunächst einmal eine gemeinsame “Sprache” sprechen. Diesen Aspekt kann man zum Glück heute durch die jahrelangen Standardisierungsbemühungen im STEP-Umfeld zu semantischen Beschreibungen als gelöst ansehen (STEP AP214, PDTnet Schema, PDM Services usw.). Aktueller sind Bestrebungen, das Arbeiten in verteilten Teams als solches zu organisieren, um einheitliche Ergebnisse (nämlich die Produktdaten) zu erhalten. Das Internet als Trägermedium hat sich hier durchgesetzt, natürlich über abgesicherte, verschlüsselte Hochgeschwindigkeitsnetze (etwa über ENX). Heterogene PDM-Anwendungsumgebungen können heute auch dank einer ganzen Zahl von Bemühungen leichter gekoppelt werden, etwa um Daten auszutauschen. Hier hat die Einführung von SOA-Architekturen viel bewirkt.

Schwachpunkt in collaborativen Umgebungen bleibt weiterhin das gemeinsame Arbeiten als solches. Dies ist weniger ein Problem der Informationstechnologie als ein organisatorisches Thema. Schließlich kommen die Mitglieder des Teams in der Regel aus unterschiedlichen Firmen, zumindest aber Abteilungen. Sie haben unterschiedliche Vorgaben, müssen sich vielleicht in einer gemeinsamen Sprache (Englisch?) unterhalten, die nicht alle gleich gut beherrschen, arbeiten nicht zuletzt in unterschiedlichen Zeitzonen dieser Welt oder sehen die konstruktiven Probleme aus unterschiedlichen Perspektiven. Dennoch sind die Teams aufgefordert, in sich stimmige Produktdaten abzuliefern. Berater können hier unterstützend eingreifend, indem sie die Rolle von Moderatoren oder “organisatorischen Katalysatoren” übernehmen.

Was aber haben nun Köche und Ingenieure gemeinsam?