Was die eigentliche PLM-Einführung betrifft, sind sich die Experten der unterschiedlichen Lager indes weitgehend einig: Nicht die IT-Infrastruktur ist für einen Projekterfolg ausschlaggebend, sondern methodische und organisatorische Vorarbeiten. Bereits im Vorfeld sollte zum Beispiel geklärt sein, wie die Praxis im Entwicklungs-, Änderungs- und Freigabeprozess eines Unternehmens aussehen soll, welche Systematik zur Nummerierung und Klassifikation von Dokumenten und Teilen gebräuchlich ist oder wie man sich den Aufbau eines digitalen Archivs vorstellt.
Es geht um eine Formalisierung von Prozessen, die gerade im Mittelstand oft noch fehlt. Eine Analyse des aktuellen Zustands ist deshalb die erste Hürde, fördert sie doch unter Umständen recht unangenehme Selbsterkenntnisse zu Tage. Auch wenn ein „Chaos“ innerhalb der betrieblichen Abläufe den Unternehmen sehr viel Flexibilität und damit Wettbewerbsvorteile beschert hat, an einem Mindestmaß an Ordnung kommt man bei einer PLM-Einführung nicht vorbei. Sonst besteht die Gefahr, PLM als Scheinwelt neben der realen zu etablieren.
Zwei weitere große Hürden, an denen PLM-Projekte scheitern können, nennt IBM-Mann Wedel. Zum einen sei die Frage zu klären, wie ein Unternehmen mit seinen Altdaten umgehen will. Der Mittelstand arbeite vielfach noch mit Zeichnungsarchiven, die Informationen ausschließlich auf Papier vorhalten.Um den Migrationsaufwand nicht ins Uferlose steigen zu lassen, empfehle sich hier eine genaue Analyse darüber, welche Altdaten wirklich noch benötigt werden. Dabei sei auch zu entscheiden, ob ein Lesezugriff und damit eine einfache Digitalisierung ausreichen oder ob die Daten als Grundlage für darauf aufbauende Konstruktionen dienen sollten. Dann müssten die Zeichnungen in 3D-Systemen nachmodelliert und mit Kontextinformationen in die PLM-Lösung eingepflegt werden.
Effizienter kommunizieren
Das zweite Problem ist, so Wedel, rein organisatorischer Natur. Da PLM eine Horizontalfunktion darstellt, die sich im Idealfall über das gesamteUnternehmen von der Entwicklung über die Produktion bis hin zu Vertrieb, Einkauf und Service spannt, gebe es keine hauptverantwortliche Abteilung. Damit werde das Thema zwangsläufig zur Chefsache, doch der habe oft weder das Interesse noch die Zeit, sich die dafür erforderlichen technischen Kenntnisse anzueignen. Deshalb sollte er die betroffenen Abteilungsleiter und Mitarbeiter zur Zusammenarbeit verpflichten - und diese Kollaboration auch überwachen. Schließlich gehe es darum, die bislang von Medienbrüchen geprägte Kommunikation auf Basis eines durchgängigen Informationsflusses effizienter zu gestalten.
Weshalb die Management-Unterstützung so wichtig ist, lässt sich an einem klassischen Problem erkennen: Jede Abteilung ist bemüht, ihre Abläufe und Prozesse zu optimieren - daran wird sie schließlich gemessen. Doch sie kann die Informationen noch so schnell erzeugen, der im Prozess nachfolgenden Abteilung nutzt dies wenig, wenn die Daten dort nicht in einer verwertbaren Form vorliegen. Die Summe der isolierten Einzeloptima stellt also nicht zwangsläufig die beste Situation für den Gesamtprozess dar. Hier ist die Vogelperspektive des Geschäftsführers oder eines Projektverantwortlichen gefragt.
Ebenso sollte das Management den Projektfortschritt im Auge behalten, denn Konfliktstoff im Team gibt es reichlich. So fällt ein großer Teil des PLM-Aufwands üblicherweise in einer sehr frühen Phase des Produktlebenszyklus an, also meist im Engineering, wo die Daten sauber in das System eingepflegt werden müssen, während nachfolgende Prozessbeteiligte den Nutzen daraus ziehen. Außerdem gilt es, die in den einzelnen Abteilungen unterschiedlich verwendeten Nomenklaturen weitgehend zu vereinheitlichen. Zwar zeigen sich PLM-Werkzeuge in ihren Bezeichnungsmöglichkeiten äußerst flexibel, dennoch ist es sinnvoll, wenn sich die Abteilungen aufeinander zubewegen und Kompromisse für Namensstandards finden.
In Bezug auf PLM-Projekte gibt SAP-Experte Bössmann noch weitere Tipps: Statt PLM in einem Kraftakt über die gesamte Prozesskette zu implementieren, empfehle sich oftmals ein Vorgehen in überschaubaren Schritten. So ließen sich zunächst die Konstruktions- und Dokumentationsabteilungen an das System bringen, während zum Beispiel die Materialwirtschaft und Produktion erst in einer späteren Projektphase folgen. Wo die PLM-Einführung starten soll, lässt sich aus denGesprächen mit den involvierten Abteilungen identifizieren. Es kann sich zum Beispiel herausstellen, dass ein erfolgreich arbeitender Unternehmensbereich an der PLM-Einführung nicht sonderlich interessiert ist, während etwa die Dokumentation zugibt, allmählich den Überblick zu verlieren, und deshalb großen Bedarf anmeldet.