PLM überwindet kulturelle Barrieren

Die Vereinheitlichung von Systemen und Prozessen ist eine große Herausforderung bei PDM/PLM-Projekten und zugleich eine ihrer Zielsetzungen. Je größer und globaler die Unternehmen und je gewachsener um nicht zu sagen verwachsender ihre Strukturen, desto schwieriger erscheint diese Integrationsaufgabe. Zu den technisch-organisatorischen Hürden gesellen sich oft noch Sprachbarrieren und kulturelle Unterschiede. Dazu braucht man nicht in die Ferne zu schweifen – selbst unmittelbare Nachbarn unterscheiden sich in punkto Mentalität: Wo für uns „Piefkes“ die Lage ernst, aber nicht hoffnungslos ist, ist sie für Österreicher allenfalls hoffnungslos, aber niemals ernst.

Die berühmte Verballhornung preußischen Denkens ist in der Alpenrepublik gelebte Wirklichkeit wie ich vor kurzem beim Besuch eines großen Österreichischen Konzerns feststellen konnte. Die Firma führt gerade im zweiten Anlauf PDM ein: Nicht mehr ein konzernweites System, sondern drei verschiedene Systeme, weil man erkannt hat, dass sich der Aufwand für die Vereinheitlichung nicht lohnt. Also hat man den Geschäftsbereichen die Systemwahl freigestellt, und einer hat sich für das Produkt entschieden, das bei der deutschen Tochtergesellschaft schon im Einsatz war.

Die Österreicher, das zeigte das Gespräch, sehen viele Dinge gelassener und handeln entsprechend pragmatisch, um nicht zu sagen hemdsärmelig. Das macht sie gerade so sympathisch. Wir Deutschen neigen dazu, unsere Prozesse viel stärker zu formalisieren, so dass sie sich wunderschön vereinheitlichen und in einer PDM-Lösung abbilden lassen. Natürlich sind wir dadurch in der Regel sehr effizient, was unsere Nachbarn durchaus anerkennen, aber wir verlieren auch ein Stück Spontaneität und Flexibilität. Dafür haben wir dann unsere Ad-hoc-Workflows.

Ein interessanter Aspekt bei dem standortübergreifenden PDM-Projekt des Österreichischen Unternehmens war, dass die harmonische Zusammenarbeit des Projektteams aus Mitarbeitern unterschiedlicher Ländern mehr zur Vereinheitlichung der Vorgehensweisen beigetragen hat als die jahrelangen Versuche, per ordre de mufti ein einheitliches System einzuführen. Das bedeutet nicht unbedingt das Ende aller Unterschiede, aber doch ein besseres gegenseitiges Verständnis dafür, warum die Kollegen an der anderen Standorten bestimmte Dinge so und nicht anders machen. Und auch die Bereitschaft, voneinander zu lernen. So werden die Österreicher bestimmte Zusatzfunktionen des Systems nutzen, die ursprüngliche für die deutsche Tochtergesellschaft entwickelt wurden.

Von anderen zu lernen, ist leider nicht unbedingt eine deutsche Tugend. Wir belehren lieber als dass wir uns belehren lassen – daran hat sich von Bismarck bis Merkel nicht viel geändert.  Dabei ließen sich aus dem ersten PDM-Anlauf der Österreicher durchaus Lehren für die erfolgreiche Abwicklung von großen IT-Projekten ableiten. Zum Beispiel dass die Harmonisierung kein Selbstzweck ist, sondern sich rechnen muss. Oder dass ein zentrales System, das es allen recht machen soll, leicht zu einem nicht mehr bedienbaren Moloch wird.

Gerade wir Deutschen sollten öfter mal die Schlagbäume hochreißen und hinschauen, wie die Anderen es machen. Wenn wir nämlich versuchen, Unternehmen in anderen Ländern zackzackig unsere Denk- und Arbeitsweisen überzustülpen, geht das meistens schief. Dafür gibt es prominente Beispiele, gerade aus der Automobilindustrie mit ihren straffen Strukturen: BMWs geplatzte Hochzeit mit Rover, Daimlers jahrelanger Ehekrieg mit Chrysler… Uns fehlt einfach das habsburgische Herrschaftswissen unserer Österreichischen Nachbarn, die sich vor kurzen in x-ter Ehe mit einem deutschen Unternehmen vermählt haben: Bella gerant alii, tu felix Austria nube – Kriege mögen andere führen, Du glückliches Österreich heirate.

Beim Systems Engineering menschelt es

Wenn man verstehen will, warum Systems Engineering so in Mode ist, braucht man sich nur Produkte anzuschauen, mit denen wir uns täglich umgeben. Nicht nur im Automobil, sondern auch in Hausgeräten, medizintechnischen Apparaten oder Maschinen und Anlagen stecken immer mehr Funktionen, die durch Elektronik und Software gesteuert werden. Von elektronischen Konsumgütern ganz zu schweigen. Damit sind Elektronik und Software auch zur wichtigsten Ursache möglicher Fehler und Fehlfunktionen geworden.

Ein Beispiel? Mit meinem neuen Smartphone kann man kommunikationstechnisch so ziemlich alles machen, was man sich vorstellen kann – nur eines nicht: Telefonieren. Die Sprachqualität ist so hundsmiserabel, dass man sie nicht mal mit dem Umstand entschuldigen kann, dass es sich um ein vergleichsweise kostengünstiges Einsteigermodell handelt. Im Vergleich dazu bietet selbst mein dummes altes Finnen-Handy geradezu HiFi-Klangqualität. Nun frage ich mich natürlich, wer dieses Desaster zu verantworten hat?

cellphones
Immer mehr funktionsfähige Mobiltelefone werden ausrangiert. (Bild: iStocks)

Schuld bin natürlich in erster Linie ich selbst, weil ich die Katze im Sack gekauft habe bzw. den wohlwollenden Kritiken bei Amazon & Co. vertraut habe. Die waren bestimmt gesponsert. Aber in welchem Handyladen kann man die Geräte überhaupt noch testen? Geschweige den so ein ausgefallenes Gerät wie mein Dual Sim-Handy, das die Möglichkeit bietet, parallel zwei SIM-Karten zu betreiben. (Na ja, nicht wirklich parallel, wie ich inzwischen weiß). So ein Gerät scheuen die Provider wie der Teufel das Weihwasser, weshalb man sie auch nie im normalen Sortiment findet.

Der Hauptschuldige ist allerdings der Hersteller, dessen koreanischen Namen ich an dieser Stelle verschweigen möchte. Oder genauer gesagt, die Produktentwickler des betreffenden Unternehmens, die das Systems Engineering, das heißt die interdisziplinäre Entwicklung von komplexen mechatronischen oder cybertronischen Produkten wohl noch nicht so ganz beherrschen. Wobei kurioserweise die cybertronischen Systemkomponenten, die mein Handy wunderbar mit anderen Systemen vernetzen, wesentlich besser funktionieren als so banale Bauteile wie Mikrofon oder Lautsprecher. Von der Kameralinse ganz zu schweigen, die man getrost vergessen kann.

An welcher Stelle im Systems Engineering-Prozess das Desaster bei der Sprachübertragung meines Handys seinen Ausgang nahm, ist mir nicht ganz klar. Ich vermute mal schon im Requirements Engineering bzw. bei der Definition der Testkriterien zur Absicherung der Anforderungen. Vielleicht haben die Systemingenieure auch bei der Modellierung der Systemarchitektur mit SysML übersehen, dass sie die vorhandenen Systemfunktionen für die Sprachübertragung in einem neuen Kontext nicht einfach wieder verwenden können, sondern simulieren müssen, ob sie Zusammenspiel mit den neuen Funktionen noch ihren Dienst versehen. Dabei sollte doch klar sein, dass ein leistungsfähiges Konfigurationsmanagement der Schlüssel zur Wiederverwendung der SE-Artefakte darstellt.

Ich möchte an dieser Stelle also mal einen Engineering Change Request stellen, mit der Bitte, die Funktionen zur Sprachübertragung meines Handys in der nächsten Generation deutlich zu verbessern. Sonst muss ich schon wieder den Hersteller wechseln, was immer mit einem riesigen Aufwand für die Datenmigration verbunden ist. Nicht dass ich große Hoffnungen hege, dass mein ECR zügig in einen Änderungsantrag einfließen wird. Und selbst wenn, dann hätte die Änderung wahrscheinlich ungeahnte Folgen für andere Systemfunktionen. Dann könnte man vielleicht wieder wunderbar telefonieren, aber nicht mehr so gut navigieren.

Ein Tipp an den Hersteller: Um die Auswirkungen von solchen Änderungen frühzeitig beurteilen zu können, müssten die Werkzeuge und Methoden des Systems Engineering nahtlos in die PLM-Umgebung integriert werden, mit der die Änderungsprozesse gesteuert werden. Das weiß man zwar, aber davon sind die meisten Unternehmen noch ziemlich weit entfernt. Oder wie einer meiner Gesprächspartner neulich sagte: „Human Based Systems Systems Engineering machen wir schon lange. Jetzt geht es darum, in den IT-Systemen bzw. den zugrunde liegenden Modellen die Traceablílity zu erreichen.“

PLM-Einführung ist ein Mannschaftssport

Man sollte meinen, dass die PLM-Einführung dank vorkonfigurierter Software-Lösungen und standardisierter Middleware-Technologie für die Integration der Anwendungen einfacher geworden sei. Wenn man einigen Herstellern glauben darf, funktionieren ihre Lösungen sozusagen out of the box, das heißt man braucht sie nur noch auszupacken und einzuschalten. Leider sieht die Realität anders aus: „Der Leidensdruck hat eher noch zugenommen“, urteilte Prof. Martin Eigner der auf dem diesjährigen PROSTEP iViP-Symposium einen Workshop zum Thema „Future PLM“ koordinierte. Im Rahmen dieses Workshops wurden die Teilnehmer aus der Automobil- und Luftfahrtindustrie befragt, wo sie der Schuh am meisten drückt: Ein wunder Punkt ist und bleibt die Implementierung, das heißt die vielen Systeme, Schnittstellen, Migrationen oder Inkompatibilitäten.

Image

Der Grund für den scheinbaren Widerspruch ist relativ simpel: Zwar lassen sich die PLM-Lösungen heute einfacher und schneller implementieren, aber gleichzeitig haben Umfang und Komplexität der Implementierungen deutlich zugenommen, weil die Lösungen mehr leisten und mehr leisten sollen als noch vor zehn Jahren. Die Kunden sind anspruchsvoller geworden: Es geht nicht mehr nur ein bisschen lokale CAD-Datenverwaltung, sondern um die Unterstützung des gesamten Entwicklungsprozesses unter Einbeziehung verschiedener Disziplinen (Stichwort Mechatronik-Entwicklung), Standorte und gegebenenfalls auch der externen Partner. Das untermauern die anspruchsvollen PLM-Projekte, die heute in der Industrie realisiert werden.

Vor kurzem habe ich einen renommierten Automobilzulieferer besucht, der gerade seine alte Zeichnungsverwaltung durch eine umfassende PLM-Lösung ersetzt hat. Multi-CAD-Datenmanagement, Stammdatenverwaltung mit ERP-Anbindung, Dokumentenmanagement mit Office- und Email-Integrationen, Projektverwaltung, Freigabe- und Änderungswesen etc. wurden auf einen Schlag an mehreren Standorten weltweit eingeführt, weil die Anwender bei vielen Projekten standortübergreifend zusammenarbeiten. Ein riesiger Berg an CAD-Daten und anderen Unterlagen musste dazu in die neue PLM-Umgebung übernommen werden, was natürlich mehr Zeit in Anspruch nahm als geplant. Der Aufwand für die Datenmigration wird bei PLM-Implementierungen immer noch gerne unterschätzt.

PLM-Projekte dieser Größenordnung mit Beteiligten aus unterschiedlichen Abteilungen, Standorten und Ländern und Kulturkreisen erfordern ein effizientes Projektmanagement, um sie erfolgreich umzusetzen. Der Zusammenhalt des Projektteams, der Rückhalt im Management und die kompetente Unterstützung durch den Systemlieferanten sind wichtige Erfolgsfaktoren. Als ich den Projektleiter fragte, was er beim nächsten Mal anders machen würde, sagte er, er würde es stärker in Teilprojekte mit separaten Projektverantwortlichen unterteilen, um die parallel laufenden Aktivitäten besser koordinieren zu können. Und er würde die ausländischen Kollegen noch frühzeitiger ins Boot holen. Ein gut funktionierendes Team ist für den Projekterfolg fast wichtiger als die beste Software, so einfach sie auch zu implementieren sein mag. Und der gemeinsame Erfolg stärkt das „Wir-Gefühl“ im Unternehmen – über die PLM-Implementierung hinaus.