ALM + PLM – Liebe auf den zweiten Blick...?

Der Newsletter für nachhaltige Transformation Made in Germany 🇩🇪

Über den Standort Deutschland wird viel geklagt. Doch Jammern bringt uns nicht weiter – Handeln schon!

Die globalen Rahmenbedingungen können wir kaum beeinflussen. Was wir beeinflussen können, ist wie gut Unternehmen digital, agil und zukunftsfähig aufgestellt sind.

In diesem Newsletter reflektiere ich wöchentlich meine Erfahrungen, Erkenntnisse und Impulse aus Digital-, Transformations- und Change-Projekten.

✔️Prägnant ✔️Praxisnah ✔️ Pro Bono.

Mein Antrieb: Viele kleine, konsequente Schritte können große Wirkung entfalten.

📣 Lass uns gemeinsam was bewegen!

Herzlich willkommen zu einer neuen Ausgabe von der Transformator:

Cyber-Physical Systems (CPS) verändern, wie Unternehmen Produktentwicklung, Softwareentwicklung und Lifecycle Management denken müssen. Moderne Produkte bestehen nicht mehr nur aus Mechanik, Elektronik und Stücklisten, sondern aus dem Zusammenspiel von Embedded Software, Steuerungstechnik, Sensorik, Konnektivität, Daten und digitalen Services.

Damit verschiebt sich auch das Verständnis von ALM und PLM: Entscheidend wird die durchgängige Verbindung von Anforderungen, Funktionen, Systemverhalten, Hardware- und Softwareständen, Varianten, Tests und Freigaben.

Mit AI-Native SAFe kommt nun eine weitere Dimension hinzu — und damit ein guter Grund, dieses Thema im Kontext von Transformation genauer zu betrachten.

Application Lifecycle Management, kurz ALM, darf im Kontext von Cyber-Physical Systems nicht mehr als reines Software-Lifecycle-Management verstanden werden. Die „Application“ ist hier häufig keine einzelne Softwarekomponente, sondern eine domänenübergreifende Systemfunktion: ein Regelalgorithmus, eine Diagnosefunktion, eine Safety-Funktion, ein IoT-Service oder das koordinierte Zusammenspiel aus Sensorik, Aktorik, Steuerung und Cloud-Anbindung. ALM wird damit zum Lifecycle Management von Funktionen, Verhalten, Anforderungen, Implementierung, Tests und Releases eines vernetzten technischen Systems.

Für CTOs und technisch Verantwortliche ist diese Erweiterung entscheidend. Die Differenzierung vieler Produkte entsteht immer stärker über Systemverhalten und digitale Funktionalität. Entscheidend ist daher nicht nur, ob eine Softwareversion korrekt verwaltet wird. Entscheidend ist, ob nachvollziehbar bleibt, welche Anforderung durch welche Systemfunktion umgesetzt wurde, welche Hardware- und Elektronikabhängigkeiten bestehen, welche Tests den Nachweis liefern und welche Produktvariante mit welchem Funktions- oder Softwarestand ausgeliefert wurde.

Moderne ALM-Tools bilden diese Zusammenhänge über Requirements Engineering, Systemarchitektur, Modellierung, Versionsverwaltung, Testmanagement, Traceability, Safety- und Security-Nachweise sowie Release-Management ab.

In CPS-Umgebungen geschieht das jedoch selten in einem einzigen Werkzeug. Vielmehr entsteht eine Toolchain aus ALM-Plattformen, Modellierungswerkzeugen, Simulationsumgebungen, Code-Repositories, Testsystemen sowie HiL- und SiL-Umgebungen.

Parallel dazu bleibt Product Lifecycle Management, kurz PLM, die zentrale Disziplin zur Verwaltung des Produkts als freigegebenes, herstellbares und wartbares Gesamtsystem. PLM beantwortet die Frage, was das Produkt ist: aus welchen Komponenten es besteht, welche Stückliste gilt, welche Variante freigegeben ist, welche Zeichnungen, Spezifikationen, Dokumente und Zertifikate gültig sind und welche Änderungen über den Produktlebenszyklus vorgenommen wurden.

Auch PLM erweitert sich im CPS-Kontext deutlich. Das Produkt besteht nicht mehr nur aus mechanischen Baugruppen und Elektronik, sondern umfasst Firmware, Embedded Software, Parameter, Konfigurationsdaten, Kommunikationsmodule, digitale Services und zunehmend auch Datenmodelle oder digitale Zwillinge.

PLM wird damit zur Plattform für die Produktwahrheit. Es verbindet Entwicklung, Industrialisierung, Einkauf, Produktion, Qualität, Service und teilweise auch Vertrieb.

Bei Cyber-Physical Systems müssen beide Perspektiven konsistent zusammengeführt werden. Eine Änderung an einer Diagnosefunktion kann neue Anforderungen, Softwareanpassungen, veränderte Parameter, zusätzliche Tests, neue Servicedokumentation und gegebenenfalls Änderungen an Elektronik oder Produktstruktur auslösen. Genau hier entscheidet sich, ob ein Unternehmen Komplexität beherrscht — oder ob sie in Workarounds, Schattenprozessen und manuellen Abstimmungen verschwindet.

Ohne integrierte ALM-PLM-Prozesse entstehen Medienbrüche, unklare Verantwortlichkeiten und erhebliche Risiken für Qualität, Compliance, Safety und Cybersecurity. Ein Blick in die reale Toollandschaft vieler Unternehmen zeigt: Diese Landschaften sind selten aus einem Guss entstanden. Sie sind historisch gewachsen — und fast immer liegt der Bruch genau dort, wo ALM und PLM ineinandergreifen müssten.

In der Entwicklung arbeiten Teams beispielsweise mit Codebeamer, Jira oder vergleichbaren ALM- und Kollaborationswerkzeugen. Darum herum entstehen Repositories, Build-Systeme, Testumgebungen und CI/CD-Pipelines.

Gleichzeitig sind Einkauf, Produktion, Qualität, Product Care und Service stark auf ERP- und PLM-nahe Systeme ausgerichtet. Häufig gilt dort: Ohne SAP geht nichts.

Beide Welten erfüllen wichtige Aufgaben. Kritisch wird es an der Schnittstelle!

Dieser blinde Fleck zwischen ALM und PLM ist in der Praxis besonders spannend — und besonders riskant. Dort entstehen Workarounds, die kurzfristig helfen, langfristig aber Transparenz und Steuerbarkeit untergraben. Software-Binaries werden beispielsweise an Hardware-Stücklisten in SAP angehängt, Firmwarestände in Dokumentenlisten gepflegt oder Systemfreigaben über manuelle Referenzen, Excel-Listen und informelle Abstimmungen abgesichert.

Solche Konstruktionen wirken pragmatisch, sind für Cyber-Physical Systems aber kaum belastbar. Sobald Mechanik, Elektronik, Embedded Software, Parameter, Konfigurationen und digitale Services gemeinsam ein Produktverhalten erzeugen, reicht eine lose Verknüpfung nicht mehr aus. Unternehmen müssen eindeutig beantworten können, welche Softwareversion zu welcher Hardware-Revision gehört, welche Anforderungen und Tests diesen Systemstand absichern, welche Variante an welchen Kunden ausgeliefert wurde und welche Auswirkungen eine Änderung auf Produktstruktur, Fertigung, Service und Feldbestand hat.

Genau hier setzt AI-Native SAFe an. Die Continuous Innovation Delivery Pipeline kann als methodischer Rahmen verstanden werden, um die gesamte Wirkkette aus ALM, PLM, Systems Engineering, Entwicklung, Validierung, Freigabe und Betrieb konsequent zu vernetzen. Es geht nicht mehr nur darum, Arbeit schneller durch eine Organisation zu bewegen. Es geht darum, Innovation kontinuierlich, nachvollziehbar und verantwortungsvoll zu liefern — KI-unterstützt entlang des gesamten Wertstroms.

Der zentrale Unterschied: Diese Wirkkette wird nicht nur digital integriert, sondern zunehmend intelligent assistiert. KI kann Anforderungen analysieren, Abhängigkeiten zwischen Systemelementen sichtbar machen, Änderungsfolgen bewerten, Testabdeckung prüfen, Risiken erkennen, Varianten vergleichen und Erkenntnisse aus Felddaten zurück in die Entwicklung bringen.

AI-Native SAFe schafft dafür den methodischen und organisatorischen Rahmen: eine skalierbare Arbeitsweise, in der Strategie, Portfolio, Architektur, Entwicklung, Qualitätssicherung, Governance und kontinuierliches Lernen enger zusammenrücken.

Bei reinen Softwareprodukten ist dieser Weg vergleichsweise gut vorgezeichnet. Plattformen wie GitHub, Atlassian, GitLab, Azure DevOps oder vergleichbare Ökosysteme bieten bereits viele Bausteine, um Anforderungen, Code, Builds, Tests, Deployments und Feedbackzyklen durchgängig abzubilden. Die Toolketten sind standardisierter, stärker automatisiert und näher an etablierten DevOps-Prinzipien.

Bei Cyber-Physical Systems ist die Ausgangslage deutlich komplexer. Hier treffen Mechanik, Elektronik, Embedded Software, Firmware, Steuerungstechnik, Simulation, Produktionsdaten, Serviceprozesse, Safety, Security und regulatorische Anforderungen aufeinander.

Die Toollandschaft ist fragmentierter, historisch gewachsen und selten vollständig „off the shelf“ integrierbar. Deshalb wird die saubere Verbindung von ALM und PLM zu einer strategischen Fähigkeit — nicht zu einem reinen IT-Integrationsprojekt.

Wer diese Landschaft im Sinne eines konsequenten Enterprise Architecture Managements (EAM) gestaltet, ist klar im Vorteil. EAM schafft Transparenz über Anwendungen, Datenflüsse, Schnittstellen, Verantwortlichkeiten und Zielarchitekturen. Es hilft, Brüche zwischen Engineering, IT, Produktion, Einkauf, Qualität und Service systematisch zu schließen und eine belastbare Architektur für die nächste Generation von Entwicklungsprozessen aufzubauen.

Fazit:

Wer die konsequente Vernetzung von ALM und PLM nicht zur Chefsache macht, sollte bei Cyber-Physical Systems mit AI-Native SAFe gar nicht erst beginnen.

Denn AI-Native SAFe kann seine Wirkung nur entfalten, wenn die digitale Wirkkette im Engineering belastbar ist. Ohne klare Verbindung zwischen Anforderungen, Systemfunktionen, Softwareständen, Hardware-Revisionen, Produktstrukturen, Varianten, Tests, Freigaben und Felddaten bleibt KI lediglich ein Beschleuniger bestehender Brüche. Sie macht fragmentierte Prozesse nicht automatisch konsistent — sie skaliert im Zweifel nur deren Unschärfen.

Die eigentliche Hausaufgabe liegt daher vor der KI: Unternehmen müssen ALM und PLM architektonisch, prozessual und organisatorisch sauber verbinden. Erst dann entsteht die Grundlage, auf der AI-Native SAFe bei Cyber-Physical Systems echten Mehrwert stiften kann: schnellere Lernzyklen, bessere Nachweisfähigkeit, robustere Qualität und skalierbare Innovation.

Quellen: