Über die Einführung eines PLM-Systems und der Herausforderungen, denen sich das Projektteam dabei stellen muss, ist schon viel geschrieben und debattiert worden. Ein Punkt wird dort immer wieder genannt, der als einer der größten Hemmschuhe für den Erfolg von PLM-Projekten gesehen wird: die mangelnde Benutzerakzeptanz. Ich möchte in meinem heutigen Blogbeitrag einen weiteren Aspekt dieser Diskussion beifügen, der am Anfang eines PLM-Projektes steht: Die Anforderungsanalyse.

In ihr sollen die funktionalen und nicht-funktionalen Anforderungen der künftigen Benutzer des PLM-Systems aufgenommen werden. Sie wird oft etwas stiefmütterlich behandelt, da sie noch wenig konkrete und benutzbare Ergebnisse für die späteren PLM-Anwender bringt. Mit virtuellen Datenmodellen, Anwendungsfalldiagrammen, Prozessbeschreibungen und weiteren Dokumenten kann noch kein Lebenslauf eines realen Produktes gemanagt werden.

Ich möchte aber eine Lanze für eine genaue und saubere Anforderungsanalyse brechen. Sie definiert, wie das PLM-System den Anwendern zur Verfügung stehen wird. Mit der Anforderungsanalyse wird die Basis gelegt, die später in Funktionen und Methoden im PLM-System abgebildet wird und dann für eine deutliche Optimierung des gesamten Engineeringprozesses sorgen soll. Denn aus diesem Grund „macht man ja PLM“, oder?

Somit sind diese Diskussionen und Workshops am Anfang des Projektes nicht vertane Zeit, an der nur die externen Berater verdienen. Der Aufwand für Nacharbeiten, die durch falsch interpretierte Anforderungen des Kunden nötig werden, ist deutlich höher als der für die Erarbeitung eines eindeutigen Verständnisses im Rahmen einer Anforderungsanalyse. Und eine Funktion im PLM-System, die am zukünftigen Endanwender „vorbeiprogrammiert“ wurde, trägt keinesfalls zur Akzeptanz des Systems bei. Und hier schließt sich der Kreis von den ersten Schritten im PLM-Projekt zur Benutzerakzeptanz im laufenden Betrieb.