Daneben geschossen – Ziele in Entwicklungsprojekten

FreeDigitalPhotos.net
FreeDigitalPhotos.net

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.

Viel Lärm um Nichts

Von meiner letzten Reise in die USA habe ich ein tolles, neues Schlagwort mitgebracht: Servitization. Es beschreibt die beinahe kafkaeske Verwandlung von Produkten, die immer mehr eingebettete Software enthalten und über das Internet der Dinge miteinander kommunizieren, in hybride Produkt- und Serviceangebote. Im Extremfall kauft der Gebäudebetreiber keine Klimaanlage mehr, sondern zahlt für die Klimatisierung eines bestimmten Raumvolumens. Der Hersteller übernimmt die Verantwortung für die korrekte Auslegung der Klimatechnik und die Wartung der Anlage. Sie ist mit zig Sensoren ausgestattet und meldet Unmengen an Daten zurück, aus denen intelligente Software-Lösungen dann die Auffälligkeiten (z. Bsp. ein offenes Fenster) herausfiltern.

An diese Brave New World musste ich denken, als ich in meinem Appartementzimmer in New York morgens um 5 Uhr durch die ratternde Klimaanlage geweckt wurde. Genau genommen wurde ich nicht durch sie geweckt, sondern durch den Verkehrslärm auf der 3rd Avenue, der etwa ab dieser Uhrzeit die Klimaanlage übertönte. Wer New York kennt, kennt auch die etwas vorsintflutliche Gebäudetechnik: Die mehrfach verglasten Schiebefenster werden einfach hochgeschoben und fest arretiert, um die kastenförmigen Klimaanlagen einzubauen, womit zwar das Leben des Untermieters gesichert ist, nicht aber das eigene Überleben im Brandfall, weil der Zugang zur traditionellen Feuerleiter vor dem Fenster blockiert ist. Es sei denn, man schafft es, sich durch den engen Spalt rechts oder links des Geräts zu zwängen, der nur mit einer dünnen Plastikblende verschlossen ist. Schall- und Wärme-Isolierung gleich null.

Image
Alte und neue Fassaden in New York. Bild: Wendenburg

Vergeblich versuchte ich, den Kopf unter das Kopfkissen zu stecken und noch ein bisschen weiter zu schlafen. Mein unsanft aufgeweckter Geist suchte fieberhaft nach einer innovativen Lösung zur Senkung des Geräuschpegels. Kissen in die Aussparungen rechts und links neben der Klimaanlage zu knuffen, war weder besonders innovativ noch effektiv. Mir kam der Vortrag eines hochrangigen Airbus-Mitarbeiters über des Kabinenkonzept für das Jahr 2050 in den Sinn: Die komfortablen Sitze im Airbus der Zukunft sollen durch Gegenschallwellen von plärrenden Kindern und schnarchenden Nachbarn abgeschottet werden. Wenn man doch die amerikanischen Klimaanlagen mit Geräuschsensoren ausstatten und die Schallwellentäler des notorischen Brummens mit den Wellenbergen des Straßenlärms synchronisieren könnte? Das wäre wirklich mal eine Innovation, die diesen Namen verdient, mit schön viel Elektronik und eingebetteter Software.

Man könnte die Vision noch weiter spinnen und aus den Big Data sämtlicher New Yorker Klimaanlagen und ihren Positionsinformationen die Verkehrsdichte der jeweiligen Avenue berechnen, um die Verkehrströme in der Stadt besser zu lenken. Das Verkehrschaos in New York ist zu bestimmten Zeiten nämlich unbeschreiblich. Die Klimaanlage würde zum Herzen eines komplexen cyberphysischen Verkehrsleitsystems. Es darf nur keiner auf die Idee kommen, den Straßenbelag auszubessern, um den Geräuschpegel zu senken. Das würde die Berechnung total verfälschen.

Was ich eigentlich damit sagen will, ist dass die technischen Innovationen im allgemeinen und ganz besonders das Internet der Dinge mit einer gewissen Zwanghaftigkeit zur Entwicklung von immer komplexeren Systemen führt. Das mag zwar gut sein für die Hersteller von PLM- und Service Lifecycle Management-Systemen, die davon leben, diese Komplexität wieder beherrschbar zu machen. Aber manchmal fragt man sich wirklich, ob es unbedingt notwendig ist, auch noch die letzte Glühbirne mit Internet-IP und Wifi-Ersatz auszustatten, um sie über eine App in unserem Smartphone individuell ansteuern zu können? Auch ohne den ökologischen Fußabdruck mit PLM berechnet zu haben, bin ich mir ziemlich sicher, dass Entwicklung und Fertigung dieser smarten Produkte mehr Gehirnschmalz und Energie verbraucht haben als sie je in ihrem Lifecycle einsparen werden.

Homo informaticus hat ein quasi sado-masochistisches Verhältnis zur Komplexität. Wir jammern ständig darüber, dass alles immer komplexer wird, lassen uns aber wollüstig stöhnend von Complexitas in Ketten legen. Zum Glück gibt es Rettung. Im Jahr 2020 sollen bereits 70 Prozent der weltweiten Nachfrage nach Gütern und Dienstleistungen aus den Emerging Countries kommen. Im Zuge von Globalisierung und Personalisierung der Produktentwicklung bringen die Unternehmen immer mehr Produkte für diese Länder auf den Markt, deren Innovation im wesentlichen darin besteht, dass sie einfacher und kostengünstiger sind. Und plötzlich stellt man fest, dass es in unserer entwickelten Welt dafür einen Markt gibt und importiert sie zurück. Auch dafür haben die Amis ein schönes Schlagwort kreiert: Reverse Innovation.

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.

Image
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.