Practice

Daneben geschossen – Ziele in Entwicklungsprojekten

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.

PLM – ein Werkzeug für den Werkzeugbau?

Dass Unternehmen neben ihren Produktdaten auch ihre Werkzeugdaten, NC-Programme, Arbeitspläne und andere fertigungsrelevante Unterlagen mit einer zentralen PLM-Lösung verwalten, damit die Mitarbeiter an anderen Produktionsstandorten auf diese Informationen zugreifen können, sieht man nicht oft. Ich habe eine diese Raritäten neulich in der Hinterpfalz entdeckt. Die Werkzeugbauer des betreffenden Unternehmens waren sogar treibende Kraft bei der PLM-Einführung, wenngleich sie das Projekt nicht ohne Unterstützung der Produktentwicklung und IT hätten durchsetzen können.

Mit freundlicher Genehmigung von Grant Cochrane auf FreeDigitalPhotos.net

Als ich den Systemadministrator im Werkzeugbau nach dem Funktionsumfang des Produktdatenmanagements fragte, korrigierte er mich höflich aber (pfälzisch) bestimmt: Wir reden bei uns nicht von PDM, sondern lieber von PLM, weil wir mit der Lösung die Prozesse über den gesamten Lifecycle der Werkzeuge unterstützen wollen. Er hatte völlig Recht: Bei der Firma können zum Beispiel auch die Mitarbeiter, die sich in den Werken um die Wartung der Werkzeuge kümmern, über Viewer auf die für sie relevanten Informationen zugreifen. Künftig sollen sie sogar per Mark-up auf den Dokumenten vermerken, was sie am Werkzeug geändert haben, damit die Konstrukteure das bei neuen Projekten berücksichtigt können.

Ich war erstaunt, dass Mitarbeiter im Werkzeugbau eines (zugegebenermaßen größeren) mittelständischen Unternehmens eine so klare Vorstellung davon haben, was PLM für ihre Organisation an Vorteilen bedeutet. Allerdings war sich der Leiter der Abteilung auch der Herausforderung bewusst, die der PLM-Einsatz für seine Mitarbeiter bedeutet. Um die Akzeptanz dauerhaft sicher zu stellen, müsse man die Anwender abholen und auf dem Weg begleiten, damit sie die Technologie verinnerlichten, wofür eigentlich mehr Personal erforderlich sei, meinte er.

Die größte Hürde für eine konsequente Nutzung der PLM-Technologie im Werkzeugbau des Unternehmens ist jedoch eine andere: Das Outsourcing. Die Unternehmensleitung hat vorgegeben, dass mehr als die Hälfte der Werkzeuge aus Kosten- und Kapazitätsgründen extern konstruiert und gefertigt wird. Die Lieferanten setzen jedoch nicht notwendigerweise das gleiche CAD/CAM-System ein wie die hauseigenen Werkzeugbauer, wenn sie die Werkzeuge überhaupt schon durchgängig in 3D modellieren. Dadurch ist der Import der fremden Werkzeugdaten ist mit einem Riesenaufwand verbunden – stücklistenrelevanten Informationen müssen praktisch von Hand eingegeben werden. Eigentlich bräuchte man einen portablen PLM-Client oder eine Art PLM-Portal, damit die Zulieferer ihre (Meta-)Daten selbst einpflegen können, aber dafür fehlt dem Unternehmen die IT-Infrastruktur.

Der PLM-Einsatz soll bei der Firma die Durchlaufzeiten verkürzen – auch im Werkzeugbau. Das wird man wohl erreichen, auch wenn ein Teil der Zeiteinsparungen durch die mangelnde Integration der Zuliefererdaten wieder aufgezehrt wird. Ihre uneinheitliche Qualität erschwert zudem das Lifecycle-Management der Werkzeuge, die im Laufe der (relativ langen) Produktlebenszyklen immer wieder repariert und überholt werden, und verursacht im späteren Werkzeugleben höhere Kosten. Das aber interessiert normalerweise den Einkauf nicht, da die Betriebskosten auf einer anderen Kostenstelle verbucht werden als die Anschaffung. Hier ist also die Unternehmensleitung gefordert, unter dem Gesichtspunkt der Total Cost of Ownership klare Vorgaben für die Zusammenarbeit mit Lieferanten zu machen.

Wenn einer eine Reise macht …

Image courtesy of Photokanok / FreeDigitalPhotos.net.

…dann kann er was erzählen. In einem aktuellen Beitrag im 2PLM Newsletter überträgt Scott Cleveland das Bild: „PLM is a … journey“. Das Bild passt, denn ehrlich gesagt, Durchmärsche bei der Umsetzung von PLM-Strategien sind mir nicht bekannt. Scott dazu:

“PLM implementation is an on-going journey, not a destination. You can’t just install PLM and stop, you have to walk on.

Once implemented in a company, a PLM solution should function as intended. However, over time, the company will change. That means its requirements for PLM will change. And implementation will continue … [this] means you will have ongoing costs. But the rewards are there – I’ve often performed ROI analysis and the resulting ROI was always greater than 100%.”

Unsere Branche hat mit diesem Bild allerdings ihre Probleme, wenn Einkäufer Turn-Key und Festpreis lieber hören als alles andere. Ob die Baubranche nicht zum (schlechten) Vorbild wird, bei der sich unrealistisch knappe Kalkulationen und absehbare Nachtragsforderungen zu einer auf Dauer ungesunden Praxis mischen?

Dagegen helfen nur klare Ziele und Anforderungen oder bewährte Verfahren wie z.B. Prototyping, um diese festzulegen, meine ich. Gibt man beim Google Übersetzer „PLM is a journey“ ein, kommt raus: „PLM heißt Realismus und harte Arbeit. Aber die Aussicht lohnt sich“.