Autor: Roland Drewinski

Zugegeben: Das Ensemble aus Daten, Prozessen, Compliance-Richtlinien, Tool- und Systemintegration, Multidiziplinarität, Know-how Schutz usw. macht PLM kompliziert. Da kann es passieren, den Wald vor lauter Bäumen aus den Augen zu verlieren. Aber was ist denn erst mal das Wesentliche?

Jamie Gooch setzt zum Jahresauftakt in seinem Beitrag “Don’t Dismiss Data Duties – Take an active role in data management decisions before they are decided for you” in der aktuellen Ausgabe des Desktop Engineering ein Ausrufungszeichen hinter die Rolle des Produktdaten-Managements: “Chances are, someone has taken a look at the hodgepodge of data floating around your company – concepts, CAD models, test results, analyses, market intelligence, renderings – and decided to implement a way to organize it all. … If everyone in your company is using the data management system properly – whether it’s product data management, document management, product lifecycle management, or any other company-wide platform for organizing and sharing data – you’re way ahead of the game.

Die Praxis zeigt: Ja, das ist die Voraussetzung für alles weitere und verschafft alleine schon mal Zugang zu den „low hanging fruits“. Die große IPK/VDI Umfrage aus dem letzten Jahr hat das Potential dafür unterstrichen: 2/3 der befragten Ingenieure stehen 20% und weniger Zeit für die Kernaufgaben Entwickeln, Konstruieren und Absichern zur Verfügung!

Gooch dazu: “Properly implemented, supported and maintained, data management can drastically reduce design cycle times, reduce frustrations associated with engineering change orders, and ultimately improve your company’s time to market. Without the right guidance, those benefits can disappear. The need for data management isn’t going away. It’s only going to increase. You can take the lead or you can take your chances.”

In der aktuellen Ausgabe der „Projektmanagement aktuell“, herausgegeben von der Gesellschaft für Projektmanagement findet sich eine sehr lesenswerter Artikel zu den Hintergründen aktueller Großprojekte, die in drastische Schieflage geraten sind. Natürlich geht es dabei um den Berliner Flughafen und die Elbphilharmonie. Interessant ist, welche Bedeutung dabei zum einen Technische  Änderungen einnehmen, und zum anderen klare bzw. weniger klare Zielvorgaben als Teil des Projektauftrags. Lesen Sie hier die Bewertung von Rainer Schofer, Vorsitzender des Verbands der Projektmanager in der Bau- und Immobilienwirtschaft.

Interessant ist auch der Zusammenhang mit Entwicklungsprojekten in „unserer“ Domäne. Nach der reinen Lehre werden Gebäude ja gebaut, nachdem der Plan – die Blaupause  – entwickelt wurde. Schließlich ist dieser die Grundlage für alle Arten von Bau- und Betriebsgenehmigungen. Wie die Beispiele zeigen, kann die Realität ganz anders aussehen. Ohne bewährte Steuerungsverfahren, wie sie z.B. die Automobilindustrie kennt, kommt man dann nicht da an, wo man eigentlich hin will.

Schofer dazu: „Der Projektmanager analysiert gewünschte Änderungen sorgfältig hinsichtlich der Technik, des Budgets und des Zeitplans; er gibt Änderungen erst frei, wenn wirklich alles abgestimmt ist.“  Und zu den Zielen sagt Schofer: „… man muss die Ziele genau ermitteln. Also nicht nur den Bau eines Flughafens als Ziel vorgeben, sondern das Ziel präzisieren und auffächern.“

Verbindliche Anforderungen, Quality Gates und Deliverables könnten da helfen! Und im Falle von Änderungen ein transparentes  Engineering Change Management, angestoßen durch Change Request. Solche Bauwerke sind zuallererst und immer noch Produkte von professionellen Ingenieuren und es sollten dann auch deren Methoden und Verfahren  eingesetzt werden. Wie man auf etwas anderes kommen kann, ist schon erstaunlich, vor allem wenn man den Artikel gelesen hat. Meine Meinung.