Neue Kriterien für die Systemauswahl gefragt
Auch künftig ist zu erwarten, dass Technologie eine wesentliche Rolle bei der Implementierung von PLM einnehmen wird. Beim Auswahlprozess sollte nicht nur Wert auf den Funktionsumfang gelegt werden. Immer wieder konzentriert sich die Aufmerksamkeit bei der Bewertung der verschiedenen Systeme auf die Analyse der technischen Funktionen. Dabei kommen es nicht selten zu Unterschieden in der Bewertung in der zweiten Kommastelle – das ist praxisfremd, zumal häufig Funktionen getestet werden, die nicht unbedingt der späteren Anwendung entsprechen. Die gängigen PLM-Lösungen sind sich funktional sehr ähnlich. Die Unterschiede finden sich in den Randgebieten der Lösungen, die in der Regel nur von ‚Power Usern‘ eingesetzt werden und in der Handhabung der Bedienoberfläche, die für die spätere Akzeptanz der Anwender eine wesentliche Rolle spielt. Relevant für den späteren Einsatz ist jedoch auch die Wahl der Klasse der PLM-Lösung. Handelt es sich um eine Autorensystem-orientierte Verwaltung von CA-Daten, um eine im Entwicklungs- und Konstruktionsprozess eingesetzte Lösung mit dem Schwerpunkt auf maximal zwei Disziplinen oder um eine unternehmensweit integrierte PLM-Lösung? Wesentlichen Einfluss auf die Eignung für das dritte Einsatzgebiet haben Mechanismen für möglichst einfaches Customizing und den Erhalt der Aufwärtskompatibilität der angepassten Systeme. Gerade PLM-Lösungen werden meist unternehmensspezifisch angepasst.
Außer bei reinen TDM-Anwendungen ist die Vision einer OOTB – einer Out-of-the box-Lösung – aktuell eher unrealistisch. Am Ende des technischen Auswahlprozesses sollten für die PLM-Systemarchitektur die Einsatzgebiete, die Integrationsschnittstellen und das grobe Daten- und Prozessmodell feststehen. Gleiches gilt für die Definition, auf welcher Architekturebene welche Daten und Prozesse abgebildet sind. Es liegen leider keine aktuellen Statistiken über den Einführungstand von PLM vor. Schätzungen zufolge ist der Anteil der fehlgeschlagenen oder nur Teilziele erreichenden PLM-Einführungen hoch. Einer der Hauptgründe ist sicher, dass die Einführung zu technisch getrieben wird. Die übergeordneten Geschäftsziele und -prozesse werden häufig ignoriert und PLM als technische Insellösung der Produktentwicklung implementiert. Mangelnde Customizing-Fähigkeiten vieler Systeme behindern zudem die breite strategische Integration in einen interdisziplinären Produktentwicklungsprozess. Werden PLM-Lösungen in einer insgesamt komplexen PLM-Umgebung oder in kleineren Anwendungen auf der Ebene Team Datenmanagement (TDM) eingesetzt, dann können die OOTB-Lösungen durchaus ausreichen. Die PLM-Technologie sollte darauf ausgerichtet werden, dass diese OOTB-Anwendungen zumindest rudimentär angepasst werden. Der Gesamtaufwand kann sich entscheidend begrenzen lassen, wenn die Upgrade-Fähigkeit trotz Systemanpassungen erhalten bleibt.
Der erste Teil des Fachbeitrags lieferte Informationen, welchen Wandel der Produktentstehungsprozess vielerorts durchläuft und an welchen Stellen Product Lifecycle Management-Software – auch mittels Customizing – Unternehmen dabei unterstützen kann, die damit verbundene Komplexität in den Griff zu bekommen.
