Software- und Produktlebenszyklus durchgängig managen

Produktsoftware gehört heute vollwertig zum Produkt. Entsprechend wird die Integration von ALM und PLM für viele produzierende Unternehmen zunehmend wichtiger. Entscheidend für ein durchgängiges Management sind eine gemeinsame Datenbasis, abgestimmte Prozesse und eine domänenübergreifende Sicht.

Veränderungen in der mechatronischen Produktentwicklung

Vier Trends erhöhen die Komplexität und den Software-Anteil mechatronischer Produkte und damit die Notwendigkeit einer durchgängigen Integration:

• Autonomer Betrieb: Maschinen übernehmen zunehmend Aufgaben, die früher Menschen erledigten. Künstliche Intelligenz in cyberphysischen Systemen (etwa in autonomen Fahrzeugen oder Industrierobotern) macht sicherheitskritische Software zum Herzstück des Produkts.
• Konnektivität: Vernetzte Produkte kommunizieren heute mit Backend-Systemen, anderen Maschinen und dem Kunden selbst. Fernwartung und Industrial IoT machen Software unverzichtbar.
• Elektrifizierung: Neue Antriebs- und Maschinenkonzepte verändern die Hardware-Architektur grundlegend. Hardware und Software sind viel enger verzahnt; das gesamte Steuergeräte-Ökosystem muss neu gedacht werden.
• Servitization: Beim Service-Modell endet die Entwicklungsverantwortung nicht mit der Auslieferung. Over-the-Air-Updates und digitale Zugangstechnologien verlängern Lebenszyklus und Verantwortung gleichermassen.

ALM und PLM mit unterschiedlichen Arbeitsweisen

Application Lifecycle Management (ALM) bezeichnet den strukturierten Umgang mit Software über ihren gesamten Lebenszyklus: von der ersten Anforderung über Design, Implementierung und Test bis zu Release, Betrieb und Ablösung. Product Lifecycle Management (PLM) verwaltet Konstruktionsdaten, Stücklisten, Dokumente und Änderungsprozesse. Die Hauptherausforderung liegt in den unterschiedlichen Arbeitsweisen der zwei Domänen. PLM setzt auf den klassischen Stage-Gate-Prozess mit klar definierten Phasen und dokumentierten Übergangsentscheidungen. Dagegen arbeiten Software-Teams agil und iterativ, mit dynamisch wechselnden Anforderungen.

Beide Arbeitsweisen sind richtig für ihre jeweilige Domäne. Das Problem entsteht, wenn ALM und PLM ein gemeinsames Produkt bauen. Die Frage ist, wie sich sinnvolle Verbindungspunkte zwischen den Welten definieren lassen. Und zwar ohne dass eine der Domänen verlangsamt wird oder Kompromisse machen muss.

Integration löst Koordinationsprobleme

In vielen Projekten ergeben sich regelmässig Koordinationsprobleme zwischen ALM und PLM. Ein typisches Szenario: Mechanische Konstruktion und Softwareentwicklung laufen parallel in getrennten Systemen. Die ausgelieferte Maschine trägt Softwarestand 3.7; das PLM kennt erst Version 2.1. Die Rückverfolgbarkeit ist – etwa bei einer Kundenreklamation – nicht gegeben. Erst die Integration durch die Verbindung der crossfunktionalen Bereiche ermöglicht es, Software und Hardware als gemeinsames Produkt zu managen.

Was Integration konkret bedeutet

Die Integration von ALM und PLM ist keine technische Pflichtübung, sondern eine strategische Entscheidung. Integration bedeutet: Ohne manuelle Datenpflege und ohne Medienbrüche ist jederzeit nachvollziehbar, welche Softwareversion auf welchem Gerät oder in welcher Produktvariante läuft. Mit Tools allein lässt sich diese Herausforderung nicht bewältigen. Das eigentliche Ziel ist Systemdurchgängigkeit und die Verlinkung von zwei Domänen, die verschiedene Sprachen sprechen und unterschiedliche Prozesse haben.

Crossfunktionale Bereiche als Schlüssel

Bereiche wie Anforderungsmanagement, Änderungsmanagement und Konfigurationsmanagement existieren in beiden Welten, werden aber typischerweise in getrennten Prozessen und Systemen gemanagt. Das führt zu Doppelspurigkeiten und mangelnder Transparenz. Natürlicher Einstiegspunkt für jede Integration sind die crossfunktionalen Bereiche zwischen ALM und PLM; die Werkzeuganbindung kommt danach. Drei Use Cases zeigen die Vorteile der Integration:

Requirements Management

Im PLM liegen Systemanforderungen als Spezifikationen; im ALM finden sich Software-Anforderungen, User-Storys und Akzeptanzkriterien. Ohne Integration werden geänderte Systemanforderungen selten in beiden Welten nachgezogen. Wenn überhaupt, läuft das manuell – und entsprechend fehleranfällig – per E-Mail oder auf Zuruf. Eine crossfunktionale Verknüpfung ermöglicht automatisierte Impact-Analysen. Ändert sich eine Anforderung, zeigt das System sofort, was auf der anderen Seite betroffen ist, wer informiert werden und was neu getestet werden muss. In regulierten Branchen wie der Automobilindustrie (ISO 26262) schafft das die Grundlage für auditierbare und reproduzierbare Produktzulassungen.

Change und Release-Management

Wenn im PLM eine Engineering Change Order (ECO) initiiert wird, sollte im ALM automatisch ein Change Request ausgelöst werden. Beide Änderungen fliessen in ein gemeinsames Review; am Ende sind Hardware-Revision und Software-Version miteinander verknüpft. Heute läuft das in vielen Unternehmen noch getrennt: Hardware-Teams haben ihren ECO-Prozess, Software-Teams ihr Ticket-System; der Abgleich funktioniert auf Zuruf. Eine definierte Prozessschnittstelle ist der erste messbare Integrationsschritt.

Konfigurationsmanagement

Eine neue Hardware-Revision löst automatisch neue Software-Tests aus. Das Ergebnis ist eine aktualisierte Kompatibilitätsmatrix, die jederzeit zeigt, welche Software-Version auf welcher Hardware-Revision läuft – geprüft und auditierbar. So entsteht After-Sales-Qualität mit höherer Sicherheit bei Software-Updates im Feld und einem skalierbaren Vorgehen über Produktfamilien hinweg.

Das Produkt bestimmt die Integrationsanforderungen

ALM- und PLM-Integration ist kein Tool-Projekt. Bevor die erste Schnittstelle gebaut wird, gilt es, grundlegende Fragen zu beantworten: Was wird im PLM abgebildet, was im ALM, und wie sieht der crossfunktionale Bereich aus? Wer ist für welche Daten verantwortlich? Für eine erfolgreiche Integration sind diese fünf Voraussetzungen zwingend:

1. Fokus auf organisatorische Transformation

ALM- und PLM-Integration ist kein «Tool-Projekt» – strukturelle Probleme müssen über das Betriebsmodell nachhaltig adressiert werden

2. Geschäftsfunktion als Orientierung

Prozesshoheit muss geklärt werden (was muss im PLM abgebildet werden, was im ALM und wie sieht der crossfunktionale Bereich aus)

3. Single Source of Truth

Data Ownership muss vor der Tool-Anbindung definiert sein. Jede Information muss einen Ursprung und ein Autorensystem haben.

4. Use-case-getriebenes Vorgehen

Integrationsanforderungen entstehen aus dem Produkt, nicht aus Tool-Funktionalitäten.

5. Stärkenorientierte Architektur

Verlinkung von Informationen erfolgt auf Software- und Technologie-Standards – Informationen werden verlinkt und nicht zwingend migriert.

Unternehmen, die ALM und PLM heute getrennt betreiben, riskieren Lücken in der Rückverfolgbarkeit und Compliance-Probleme. Wer sich dagegen für eine strukturierte Integration entscheidet, sichert sich entscheidende Wettbewerbsvorteile:
• Das Produkt ist als Ganzes steuerbar
• Beide Domänen – PLM und ALM – entwickeln schneller
• Die Plattformstrategie wird durchgängig, d. h. die Wiederverwendung von Hardware- und Softwarekomponenten setzt sich über die Produktfamilien hinweg fort
• Resilienz gegen regulatorische Veränderungen (Compliance-Nachweise lassen sich schnell und reproduzierbar realisieren)

PLM Open Hour: Slides & Aufzeichnung

ALM und PLM

In dieser PLM Open Hour beleuchteten wir die Grundlagen des Application Lifecycle Management (ALM), zeigen Berührungspunkte und Abgrenzungen zu PLM auf und diskutierten praxisnahe Ansätze für eine schrittweise Integration beider Disziplinen. Dabei gingen wir auf organisatorische und auf technologische Fragestellungen ein.

Laden Sie sich hier die Präsentation zum Webinar herunter:

Wir haben das Webinar «ALM und PLM» aufgezeichnet. Melden Sie sich dazu hier an und Sie erhalten den Zugang zur Aufzeichnung: