Systems Engineering Brücke zwischen ALM und PLM für bessere Integration

Anbieter zum Thema

Transition Technologies PSC Germany GmbH

MPDV Mikrolab GmbH

CADFEM Germany GmbH

Die zentrale Herausforderung im Engineering und in der Produktentwicklung: Integration von Software, Elektronik, Mechanik und Co. zu einem konsistenten Produkt ohne Informationsverluste - im Spannungsfeld von ALM versus PLM.

Doch es geht längst nicht mehr um „entweder – oder“, sondern um „sowohl – als auch“. Die entscheidende Schnittstelle ist das Systems Engineering – eine Disziplin, die noch immer zu oft unterschätzt oder zu eng interpretiert wird: ALM und PLM – zwei Perspektiven, ein Ziel, heißt die Devise. Application Lifecycle Management (ALM) steuert auf der einen Seite die Entwicklung von Software sowie das Anforderungs- und Testmanagement von Produkten. Auf der anderen Seite hingegen verwaltet Product Lifecycle Management (PLM) physische Produkte – Konstruktionsdaten, Versionen, Stücklisten, Zulieferinformationen und Serienfertigung. Was häufig übersehen wird: Heute existieren kaum Produkte ohne Software. Ob Fahrzeug, Haushaltsgerät oder Industrieanlage – Software ist entscheidend für Funktion, Anpassungsfähigkeit und Nutzererlebnis.
 Daraus ergibt sich eine grundlegende Frage: Was unterscheidet Software von einer Komponente im Systemkontext? Funktional betrachtet – nichts. Das Produkt ist die zentrale Einheit, und alle Bestandteile – ob Software, Hardware oder Mechanik – müssen gemeinsam funktionieren und gemeinsam gemanagt werden. Nur so wird eine hohe Kundenzufriedenheit, Qualität und Markterfolg erreicht. Ein modernes Systems Engineering muss daher beide Welten – die strukturell geprägte PLM-Logik und die agile Softwareentwicklung – in einem gemeinsamen Produkt zusammenführen.

Systems Engineering ist Teamarbeit, keine Toolfrage

Ein weit verbreitetes Missverständnis ist, Systems Engineering auf Tools oder Methodenkataloge zu reduzieren. In Wahrheit ist es ein organisatorischer, kultureller disziplinenübergreifender und strategischer Rahmen. Effiziente Produktentwicklung braucht mehr als gut funktionierende Einzeldisziplinen – sie verlangt abteilungsübergreifende Abstimmung, gemeinsame Ziele und eine gemeinsame Datenbasis. Ob Systemarchitekt, Softwareentwickler, Konstrukteur, Fertigungsplaner oder Qualitätsverantwortlicher – sie alle müssen zur richtigen Zeit die relevanten Informationen im richtigen Kontext erhalten. Dabei ist nicht die Menge an Daten entscheidend, sondern deren Struktur, Verknüpfung und Relevanz.

Traceability als Rückgrat für Entscheidungsfähigkeit

Um diese Verknüpfung zu ermöglichen, braucht es Traceability – die durchgängige Rückverfolgbarkeit von Anforderungen, Arbeitsergebnissen, Entscheidungen und Änderungen über den gesamten Produktlebenszyklus. Dies wird durch sogenannte Traces, die Anforderungen mit Architektur, Komponenten, Tests, Fehlern, Änderungen und Zulassungsunterlagen verknüpfen, erreicht. Ziel ist ein Digital Thread – ein digitaler roter Faden, der alle Informationen entlang des Entwicklungs- und Produktprozesses intelligent verbindet. Dieser macht die steigende Komplexität der Produktentwicklung beherrschbar.
 Ein technischer Standard zur Umsetzung ist OSLC (Open Services for Lifecycle Collaboration). Auf Basis von REST und RDF erlaubt OSLC die lose Kopplung von IT-Systemen unterschiedlicher Hersteller – ohne zentrale Datenspeicherung. In der Praxis entstehen jedoch oft Schwierigkeiten durch eine unterschiedliche Auslegung des Standards und fehlende Strukturierung von Traces, das zu einem hohen manueller Aufwand bei Pflege und Interpretation sowie Frust statt Effizienzgewinn führt.

Wenn Traceability zur Bürde wird

Auch bei technisch korrekt implementierten Lösungen bleibt Traceability im Alltag oft ungenutzt. Der Grund: fehlende Anwenderfreundlichkeit und fehlender Fokus auf die aktuelle Aufgabenstellung. Entwickler sehen sich mit einer Vielzahl an Änderungsmarkern (Suspekt Flags) und Verlinkungen konfrontiert, ohne den Kontext oder die Relevanz beurteilen zu können. In großen Systemen mit tausenden Artefakten wird Traceability so zur Überforderung.
 Ein Beispiel: Ändert sich eine Anforderung, wird automatisch ein Marker bei allen Artefakten gesetzt, die diese Anforderung betreffen. Doch statt einer fundierten Prüfung wird dieser aus Routine oder Zeitdruck erst einmal ignoriert. Im Softwarekontext mag das durch die Buildroutine und Tests im nächsten Build noch abfangbar sein – im PLM-Umfeld jedoch kann eine geänderte Komponente nach ihrer separaten Verwendungsfreigabe sofort produktionswirksam werden, ohne weitere Prüfung des gesamten Produktes.
 Um das zu verhindern, werden entweder komplexe Änderungsprozesse etabliert – mit vielen Beteiligten und langen Durchlaufzeiten – oder jede Änderung zieht eine neue Teilenummer nach sich. Letzteres bedeutet: alle Stücklisten müssen aktualisiert, geprüft und neu freigegeben werden. In der Theorie robust – in der Praxis extrem aufwendig und fehleranfällig, insbesondere bei Massenänderungen. Oft werden hier tausende von Verwendungen automatisiert aktualisiert, ohne den Einfluss im Einzelnen prüfen zu können – was man eigentlich verhindern wollte.

The PLM journey made simple(r)

PLM-Fachbuch: Product-Lifecycle-Management besser verstehen

Digital Thread: Navigationshilfe statt Datenlast

Wie kann man dieser Komplexität begegnen? Die Antwort ist ein anwenderorientierter Digital Thread. Nicht nur die bloße Existenz von Traces ist entscheidend – sondern ihre strukturelle Einbindung in die Arbeitsabläufe. Die Informationen müssen aufgabenbezogen gefiltert, visuell aufbereitet und kontextsensitiv für die agierende Rolle bereitgestellt werden. Im Kontext der Aufgabenstellung sollte nun der Anwender direkt seine Aufgabe erledigen können, ohne Daten mühsam hin und her zu kopieren oder zwischen IT-Systemen hin und her zu springen.
 Das Ziel ist nicht, alle Informationen irgendwie in IT-Systemen abzulegen, sondern diese so aufzubereiten und anzureichern das sie systemübergreifend verwendet werden können. Ein funktionierender Digital Thread hilft den Mitarbeitenden, sich der Auswirkungen jeder Änderung bewusst zu sein, fundierte Entscheidungen zu treffen und gleichzeitig die regulatorische Nachvollziehbarkeit sicherzustellen.

Fazit: Systems Engineering als Integrationsmotor

Die Diskussion „ALM vs PLM“ lenkt vom eigentlichen Problem ab. Moderne Produktentwicklung benötigt keinen Kampf der Disziplinen, sondern eine Brücke zwischen ihnen. Diese Brücke ist das Systems Engineering – nicht als Toolverwalter, sondern als gestaltende Instanz der Informationsarchitektur und des gesamten Produkts. Traceability und Digital Thread sind keine Selbstzwecke. Sie müssen praxisgerecht, nutzbar und integriert sein. Nur dann entstehen daraus Mittarbeitermotivation und Wettbewerbsvorteile – in Form von Qualität, Geschwindigkeit und Innovationskraft. Systems Engineering ist dann erfolgreich, wenn es Transparenz schafft, Zusammenarbeit stärkt und Komplexität beherrschbar macht.

Wolfgang Rüdell ist Principal Business Analyst bei Transition Technologies PSC.