Michael Wendenburg

Datei- oder datenbankorientiert – ist das die Frage?

Auf dem diesjährigen ProSTEP iViP-Symposium hatte ich das Plaisir, einen ziemlich erbosten Dominique Florack zu interviewen. “Wenn die europäischen Unternehmen nicht endlich verstehen, dass die Zukunft der PLM-Technologie im datenbankorientierten Arbeiten liegt, setzen sie ihre internationale Wettbewerbsfähigkeit aufs Spiel”, meinte der Mann, der als Senior Vice President Research & Development bei Dassault Systèmes maßgeblich für die Entwicklung der 3DExperience-Plattform verantwortlich ist. ERP- oder CRM-Systeme arbeiteten schließlich auch datenbankgestützt.

Foto_database — Mit freundlicher Genehmigung Danilo Rizzuti, FreeDigitalPhotos.net

Obwohl ich Florack prinzipiell durchaus zustimmen würde, muss ich zu bedenken geben, dass die Frage des datei- oder datenbankorientierten Arbeitens in erster Linie eine Frage der Autorensysteme ist. Solange CAD-Systeme die Arbeitsergebnisse als Files ablegen, bleibt den PDM/PLM-Lösungen nichts viel anderes übrig, als sie dateibasiert zu verwalten. Aber genau da liegt der Hase im Pfeffer: Was Florack den bockigen Kunden (und uns Journalisten) mit der Cloud im Hinterkopf eigentlich sagen will ist, dass die Zukunft der CAD-Technologie im datenbankorientierten Arbeiten liegt. Um CAD in der Cloud betreiben zu können, brauche man eine andere Software-Architektur.

Auch dagegen wäre prinzipiell nichts einzuwenden, wenn es einen allgemein akzeptierten Standard dafür gäbe, wie der Content einer CAD-Konstruktion datenbankgestützt zu verwalten ist. Oder wenn die CAD-Hersteller ihre Verwaltungsstrukturen offen legen würden. Dann wäre der Kunde nicht gezwungen, ein bestimmtes Datenmanagementsystem (nämlich das seines CAD-Lieferanten) einzusetzen, um aus einzelnen Elementen wieder ein digitales Produktmodell aufzubauen, und er könnte sie auch datenbankgestützt austauschen. Denn es macht keinen Sinn, bei verteilten Entwicklungsprojekten erst datenbankorientiert zu konstruieren, um die Konstruktionen den Partnern in der Zulieferkette dann doch wieder dateibasiert zur Verfügung zu stellen. Dann wären wir wieder in den Anfangszeiten der 3D-Konstruktion, als die Modelle immer wieder platt geklopft wurden, um sie mit den Zulieferern zeichnungsbasiert austauschen zu können.

Ehrlich gesagt, bin ich skeptisch, dass wir einen solchen Standard und/oder das nötige Maß an Offenheit je sehen werden. Zwar haben inzwischen alle namhaften PLM-Hersteller den berühmten Codex of PLM Openness unterzeichnet, der in den letzten Jahren maßgeblich vom ProSTEP iViP-Verein vorangetrieben wurde, doch bezeichnenderweise wurde der CPO auf dem diesjährigen Symposium nicht mit einem Wort erwähnt. Oder wenn, dann so leise, dass ich es nicht vernommen habe. Man hätte gerne gewusst, welche Fortschritte Anwender und Anbieter bei der Umsetzung in den letzten 12 Monaten gemacht haben. Ist die PLM-Welt dadurch ein bisschen offener geworden?

Was das Thema Standardisierung anbelangt, erwähnte Florack STEP AP 242 als mögliche Referenz für die datenbankorientierte Engineering Collaboration; man müsse den Standard nur endlich richtig implementieren, statt ihn auf seine Funktionen für den (dateibasierten) Geometriedatenaustausch zu reduzieren. Das mag wohl sein, aber mir wäre nicht bekannt, dass Dassault ihren Kunden inzwischen die Möglichkeit bietet, CATIA V6-Daten STEP AP242-konform mit einem anderen PDM-System als ENOVIA V6 zu verwalten. Aber was nicht ist, kann ja noch werden, wenn die ISO-Normierung des neuen STEP-Standards erst einmal abgeschlossen ist.

Letztlich geht es aber nicht um die Frage, ob man PLM datei- oder datenbankorientiert betreibt, sondern darum, wie zugänglich die Informationen in der Datenbank sind – für den Erzeuger, dessen geistiges Eigentum sie sind, für seine Partner, die mit den Daten weiter arbeiten sollen, für künftige Anwender, die vielleicht auch noch in 50 Jahren noch darauf zugreifen müssen, und letztlich auch für andere PLM-Hersteller, die diese Daten eventuell in ihre IT-Lösungen migrieren sollen. Solange diese Offenheit nicht gegeben ist, werden die Unternehmen dem datenbankorientierten PLM-Ansatz misstrauen.

Multiprojektmanagement fängt beim Einzelprojekt an

Es gibt viele, durchaus erfolgreiche Unternehmen, in denen die Geschäftsleitung nicht genau weiß, wie viele Entwicklungsprojekte gerade laufen und wann welche Ressourcen wieder frei werden, um gegebenenfalls neue Projekte einlasten zu können. Und das liegt nicht nur an den so genannten U-Boot-Projekten, die vom Management-Periskop nicht erfasst werden. Gerade in mittelständischen Unternehmen ist das Projektmanagement oft noch sehr hemdsärmelig, das heißt die Projekte werden ohne jede IT-Unterstützung abgewickelt, wenn man mal von den klassischen Excellisten absieht. Entsprechend aufwendig ist es, zuverlässige Informationen über den Stand der Projekte zusammenzutragen.

Mit freundlicher Genehmigung www.FreeDigitalPhotos.net — Mit freundlicher Genehmigung von Stuart Miles, FreeDigitalPhotos.net

Für ein Unternehmen, das eine Handvoll Projekte im Jahr abwickelt, mag das angehen. Aber das ist nicht die Regel. Zumindest nicht bei deutschen Mittelständlern, deren Stärke ja gerade darin besteht, viele kundenspezifische Entwicklungsprojekte gleichzeitig abzuwickeln – und das mit manchmal atemberaubender Geschwindigkeit. Solange alles nach Plan läuft, ist das kein Problem. Problematisch wird es immer dann, wenn Projekte aus dem Ruder laufen, das heißt nicht rechtzeitig fertig werden und/oder mehr Budget als geplant verschlingen. Ohne entsprechende IT-Lösungen hat die Geschäftsleitung kaum Möglichkeiten, solche Abweichungen frühzeitig zu entdecken und sofort gegenzusteuern.

Bei der Auswahl der entsprechenden IT-Lösung stehen die Unternehmen vor der Wahl, ein allgemeines Projektmanagement-System einzuführen, oder aber das Projektmanagement in ihre PLM-Lösung zu implementieren. Für erstere Option spricht, dass in den Unternehmen normalerweise nicht nur Entwicklungsprojekte, sondern auch eine Vielzahl von anderen Projekte abgewickelt werden. Deshalb bevorzugen sie verständlicherweise eine Lösung, die für Mitarbeiter unterschiedlicher Disziplinen und Abteilungen nutzbar und einfach zu bedienen ist. Für die Implementierung des Projektmanagements in die PLM-Lösung spricht hingegen, dass die Steuerung von Entwicklungsprojekten normalerweise besonders anspruchsvoll ist, gerade was das Management der Arbeitsfortschritte angeht. Diesen Anforderungen werden allgemeine Projektmanagement-Lösungen vielfach nicht gerecht.

Ein Projektmanagement zur Unterstützung des Entwicklungsprozesses muss die Möglichkeit bieten, neben den Kosten und Terminen auch die Qualität der Arbeitsergebnisse (Deliverables) zu kontrollieren. Dazu müssen sie notwendigerweise im Projektkontext verwaltet werden. Ohne Kenntnis des Umfangs und Reifegrads der Ergebnisse lässt sich nämlich nur schwer beurteilen, ob ein Projekt hinsichtlich Terminen und Kosten noch im grünen Bereich ist. Ein effizientes Management von Kosten, Terminen und Ergebnissen auf Einzelprojektebene ist letztlich die Grundlage für ein Multiprojektmanagement, das Programm- und Portfoliomanager oder die Geschäftsleitung mit belastbaren Informationen über den tatsächlichen Stand der Projekte versorgt. Dabei geht es nicht nur darum, Projekte in Schieflagen frühzeitig zu identifizieren, sondern auch Aussagen über die zu erwartende Geschäftsentwicklung zu treffen.

Erfolgsgeheimnis eines von den Mitarbeitern akzeptierten und gelebten Multiprojektmanagements ist die Nutzung von bereits vorhandenen Informationen bzw. von Informationen, die gewissermaßen beiläufig während der täglichen Projektarbeit erhoben werden. Dadurch reduziert sich für das „Fußvolk“ der Aufwand für die Pflege der Informationen. Sie brauchen nur noch gefiltert, verdicht und grafisch aufbereitet zu werden, um den Managern einen schnell verständlichen Überblick über das aktuelle Projektgeschehen in dem tatsächlich benötigten Detaillierungsgrad zu geben. Dank ihrer engen Verzahnung mit dem Produktentstehungsprozess bieten PLM-Lösungen die Möglichkeit, sowohl produkt- als auch prozessrelevante Kennzahlen automatisch zu erheben und auszuwerten. Ein Grund mehr für die PLM-Integration des Projektmanagements.

Hintertürchen zur Collaboration

Engineering Collaboration, die Zusammenarbeit von Unternehmen bei der Produktentwicklung, ist eigentlich nichts Neues. Es gibt das Thema schon solange wie es das Outsourcing gibt. Umso verwunderlicher ist, dass die wesentliche Herausforderung bei der Collaboration immer noch einer Lösung harrt: Die Einbettung der unternehmensübergreifenden Austausch- und Abstimmungsprozesse in die PDM/PLM-Lösungen, mit denen die Produktentwicklung in den Unternehmen gesteuert wird.

An fehlenden Tools liegt es wahrlich nicht – im Gegenteil: die Landschaft der Collaboration-Anwendungen ist dank Cloud und Social Media eher noch bunter geworden. Das eigentliche Problem ist die Integration dieser Tools in die IT-Infrastrukturen und Geschäftsprozesse des jeweiligen Unternehmens. Aus Sicherheitsgründen scheuen

PLM_portal — Mit freundlicher Genehmigung Gualberto107 / FreeDigitalPhotos.net

die IT-Spezialisten davor zurück, ihre Enterprise Anwendungen nach außen zu öffnen. Das führt oft zu der absurden Situation, dass Daten und Know-how im Unternehmen bombensicher sind, dann aber schnell mal per Email ausgetauscht werden, weil die Ingenieure ja irgendwie ihre Entwicklungsarbeit erledigen müssen. Und die verteilt sich heute nun mal über eine immer längere Supply Chain. Selbst in der sicherheitsbewussten Automobilindustrie tauschen 45 Prozent der Unternehmen ihre Produktdaten mit Auftraggebern und Zulieferern noch vorwiegend per Email aus. Da reiben sich neugierige Nachrichtendienste und andere Datenpiraten freudig die Hände.

In Anbetracht der Tatsache, dass die Collaboration weiter zunimmt und immer globalere Züge annimmt, ist es vielleicht an der Zeit, mal über eine Neugewichtung nachzudenken. Das heißt mit anderen Worten: auf das letzte Quäntchen an innerer Sicherheit zu verzichten, indem man die PLM-Lösung gezielt für den Zugriff von außen öffnet, um dadurch Datensicherheit und Know-how-Schutz bei der Zusammenarbeit mit externen Partnern zu steigern. Insgesamt würde sich die Sicherheitsbilanz bei der verteilten Produktentwicklung dadurch spürbar verbessern. Man muss ja nicht gleich ein großes Portal aufreißen – mit einem Hintertürchen wäre den Projektverantwortlichen manchmal schon gedient.

Eine wesentliche Anforderung an eine solche Collaboration-Lösung ist, dass sie sowohl für die Auftraggeber, als auch für ihre Zulieferer von Nutzen ist. Allzu oft wurden in der Vergangenheit gerade im Automotive-Umfeld Lösungen implementiert, die die Last der Datenkommunikation einseitig den Partnern aufbürdete. Sie mussten für jeden Auftraggeber eine andere Anwendung implementieren und betreiben – oft ohne Integration in ihre Backend-Systeme. Die Daten wurden weitgehend von Hand in die Auftraggeber-Systeme eingepflegt.

Ganz wichtig ist natürlich auch, dass die Lösung unterschiedliche Szenarien der Zusammenarbeit unterstützt. Die Anforderungen bei einem Standardprozess wie zum Beispiel der Angebotseinholung (Request for Quotation) sind andere als bei einem gemeinsamen Entwicklungsprojekt, bei dem die Partner ihre Dateien idealerweise in eine gemeinsame Projektablage einstellen und dadurch die Arbeitsfortschritte online verfolgen. Asynchrone Workflows bieten die Möglichkeit, den Umfang an bereit gestellten Daten und PLM-Funktionen gezielt auf die Empfänger zuzuschneiden. Sie sind gewissermaßen das Hintertürchen der Collaboration, das man dann schrittweise zu einem Portal für die synchrone Zusammenarbeit bei Entwicklungsprojekten ausbauen kann.