Share ZU:
20 January 2015 @ Eva-Maria Meindl

ALM vs. PLM – Das Gleiche, aber nicht dasselbe

ALM vs. PLMSowohl das Application Lifecycle Management (ALM) wie auch das Product Lifecycle Management (PLM) betrachten ein Produkt über den gesamten Lebenszyklus – beginnend mit der Idee bis hin zum ausgelieferten Produkt, darüber hinaus mit der Betrachtung des Supports und Services, abrundend mit der Weiterentwicklung oder der End-of-Life-Phase eines Produktes.

Doch wie unterscheiden sich ALM und PLM? Oder ist es dasselbe? Und wozu brauche ich das überhaupt?

Dies sind die Fragen mit denen sich ein „Frischling“ in unserem Fachgebiet auseinandersetzt. Mit dem Unterschied bzw. NICHT-Unterschied wollen wir uns in diesem Blog-Beitrag unter dem Aspekt der Produktwahrnehmung und Reklamation befassen.

Beim PLM wird ein physisches Produkt betrachtet. Also ein Produkt, das der Nutzer quasi in der Hand halten kann. Das kann ein Auto, eine Zahnbürste oder eine Waschmaschine sein.

Beim ALM hingegen wird eine Software betrachtet. Im Prinzip kein Gegenstand, das der Nutzer greifen kann. Je nach Perspektive kann eine Software natürlich auch ein Produkt bzw. in einem Produkt enthalten sein, doch gibt es kleine Unterschiede.

Betrachten wir dazu folgenden Fall:

Unser physisches Produkt wurde an mehrere verschiedene Kunden ausgeliefert. Aufgrund von Reklamationen stellt sich jedoch heraus, dass das Produkt einen Fehler in der Serie aufweist. Im Vergleich dazu weist auch unsere Software einen Fehler auf. Wie wird mit den Fehlern umgegangen? Und wie sieht es mit dem Image des Produktes und somit des Herstellers aus?

Wenn wir unterstellen, dass wir bei unserem physischen Produkt nicht wissen, wer unsere konkreten Kunden sind, muss der Fehler aktiv, zum Beispiel durch Rundschreiben oder in den Nachrichten, kommuniziert werden. D.h. jeder Nutzer des Produktes muss darüber informiert werden, dass sein Produkt fehlerhaft ist. Nun ist der Nutzer selbst dafür verantwortlich, die erforderlichen Maßnahmen zu ergreifen um den Fehler am Produkt beheben zu lassen. Im einfachsten Fall, kann der Nutzer das Produkt an den Hersteller per Post zurückschicken. Größere Produkte wie z.B. ein Auto müssen in eine vom Hersteller vorgegebene Werkstatt geliefert werden. Der Nutzer hat also zusätzlich zu dem fehlerhaften Produkt noch einen großen Aufwand um den Fehler zu beseitigen. Dies kann im schlimmsten Fall einen Imageschaden des Herstellers nach sich ziehen und der Kunde wird sich überlegen, ob er nochmals Produkte vom Hersteller kauft.

Natürlich müssen auch die Nutzer einer fehlerhaften Software über den Fehler informiert werden, doch geschieht dies meist nur durch den Beschreibungstext oder den Patch Notes eines Updates bzw. eines Hotfixes. Der Aufwand, den Nutzer über seine fehlerhafte Software zu informieren, ist also wesentlich geringer und erfolgt meist gleichzeitig mit der Behebung des Fehlers. In seltenen Fällen wird der Fehler der Software publik gemacht, doch geschieht dies nicht immer freiwillig von der Herstellerseite, wie man am aktuellen Beispiel des von Google publizierten Bugs von Windows Betriebssystem erkennen kann. Auch hier ist der Nutzer in einer Holschuld zur Beseitigung des Fehlers, d.h. der Nutzer ist dafür verantwortlich, das erforderliche Update zu installieren. Das ist sehr bequem für den Nutzer, da er dies Zuhause relativ einfach selber durchführen kann, wenn die Software nicht sogar vollkommen automatisch das Update installiert und ggf. anschließend nur einen Neustart fordert. Die Hersteller einer fehlerhaften Software können also oft ohne einen großen Imageschaden davon kommen.

Wie das Beispiel gezeigt hat, ist der Umgang und die Beseitigung von Fehlern sowohl Teil des ALM als auch des PLM, doch wird auf unterschiedliche Weise auf den Fehler reagiert. Dementsprechend sind wir der Ansicht, das Application Lifecycle Management und Product Lifecycle Management doch gar nicht so verschieden sind, aber eben nicht genau dasselbe. Wenn Sie mehr zum Thema „Application Lifecycle Management“ erfahren wollen, besuchen Sie doch hier unsere Schulung.

Eva-Maria Meindl

Kontaktieren Sie Eva-Maria Meindl

Eva-Maria Meindl ist als Consultant im Bereich Requirements Engineering tätig. Ihre Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge wie zum Beispiel DOORS von IBM. Zu ihren Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, sowie die Erstellung von objektorientierten Modellen.