Mit PLM lassen sich mechanische und elektrische Baugruppen verwalten, warum nicht auch Software?
Wäre es nicht am besten, wenn alle mit denselben Tools arbeiten würden?
Eine erste Teilantwort lautet: Nein, denn schon zwischen den beiden „anfassbaren“ Disziplinen Mechanik und Elektrik/Elektronik unterscheidet sich die Sprache und Arbeitsweise der Beteiligten so sehr, dass unterschiedliche Prozesse zum Einsatz kommen. Der Entwicklungsprozess von Software ist nochmals völlig anders, was ein System notwendig macht, das diese Eigenarten abdecken kann. PLM ist auf die Verwaltung von Bauteilen und Baugruppen optimiert, ALM auf die Verwaltung von Software. Im Idealfall lassen sich die Datenbestände beider Systeme verknüpfen, so dass jeder Entwickler in der für seine Anforderungen optimierten Umgebung arbeiten kann, aber alle auf den gesamten Datenbestand zugreifen können.

Der fundamentale Unterschied zwischen dem PLM- und dem ALM-Prozess ist die Iteration. In der Mechanik ist das Ziel, dass der erste Prototyp schon möglichst seriennah ist, in der Softwareentwicklung wird – vor allem mit modernen Entwicklungsmethodiken wie Agile oder Scrum – sofort ein erster Prototyp erstellt und dieser immer wieder überarbeitet und neu geschaffen.

Das liegt ganz einfach daran, dass ein Prototyp aus Mechanik und Elektrik/Elektronik real gebaut werden muss. Das kostet viel Zeit und Geld. Das Ziel der gesamten Entwicklung ist es also zum einen, so lange wie möglich im virtuellen Prozess zu bleiben und erst am Ende in den realen Prototypen zu wechseln. Zum anderen werden Änderungen umso teurer, je weiter vorangeschritten der Entwicklungsprozess ist. So gibt es bei vielen Produkten sogenannte Langläufer, das sind Bauteile oder Rohteile, die eine sehr lange Lieferfrist haben und bestellt werden müssen, wenn die Konstruktion noch ganz am Anfang steht.

Diese Langläufer „zementieren“ oft den Entwicklungsprozess soweit fest, dass die anderen Baugruppen um diese Langläufer „herumkonstruiert“ werden – jede neue Idee wird danach beurteilt, ob sie mit den bestellten Bauteilen kompatibel ist. Ist dies nicht der Fall, wird es schwer sein, die neue Idee umzusetzen. Zusammengefasst: Relativ wenige oder gar keine Iterationsschleifen, das Ziel ist es, beim ersten Versuch das Optimum zu erreichen.

In der Softwareentwicklung geht es völlig anders zu: Prototypen entstehen einfach durch einen Kompilierlauf. Dieser kann länger werden, wenn die Software im Laufe der Entwicklung komplexer wird – aber die Unterschiede sind gering. Man kann jederzeit einen neuen Prototypen erschaffen, der quasi nichts kostet. In vielen Entwicklungen werden Nightly Builds eingesetzt, also über Nacht der jeweils am Abend vorliegende Stand durchkompiliert. Das bedeutet extrem kurze und extrem viele Iterationsschleifen. Auch tiefgreifende Änderungen können – im Verhältnis zur Mechanik – schnell und einfach umgesetzt werden, auch in späten Entwicklungsphasen. Die Verwaltungssoftware muss diesen fundamentalen Unterschied abbilden und unterstützen.

Moderne Softwareentwicklung ist stark anforderungsgetrieben: Zu Beginn definiert man, welche Funktionen die Software haben soll und bildet daraus Komponenten, die wiederum mit fest definierten Schnittstellen verbunden sind. So können sich einzelne Entwickler oder kleine Teams jeweils um eine Komponente kümmern und diese unabhängig von anderen Komponenten entwickeln – solange die Anforderungen erfüllt und die Schnittstellen richtig implementiert sind, wird die Software am Ende funktionieren. Dies kann auch während des gesamten Prozesses sichergestellt werden, indem der jeweilige Stand – beispielsweise der Nightly Build – gegen die Anforderungen und Schnittstellen getestet wird. Diese Tests wiederum sind gut automatisierbar und können ständig parallel zum Prozess laufen. Im Gegensatz dazu lässt sich eine Maschine erst testen, wenn der letzte Hebel modelliert und die letzte Schraube positioniert ist.

Eine Auswirkung dieser Besonderheiten des Softwareentwicklungsprozesses ist Branching/Merging. Man verfolgt eine neue Idee, indem man einen bestimmten Softwarestand als Knotenpunkt definiert und von diesem abzweigt. Die normale Entwicklung kann weiterlaufen, währen im Zweig die neue Idee ausprogrammiert wird. Am Ende, wenn die Idee tatsächlich überzeugt, wird sie wieder in den Haupt-Entwicklungszweig „gemergt“, also integriert.

Interessanterweise übernimmt der Mechanikbereich immer stärker Ideen und Methoden aus den Bereichen Elektronik und Softwareentwicklung – Systems Engineering ist im Prinzip nichts anderes als die Umsetzung des Elektronik-Entwicklungsprozesses in die Mechanikwelt: Die Elektroniker arbeiten zunächst in einem Schaltplan, in dem nur Funktionen miteinander verbunden werden. Der Schaltplan enthält beispielsweise keinerlei Positionsinformationen. Objekte, die im Schaltplan nebeneinanderliegen, können im späteren Produkt sehr weit auseinanderliegen – oder sich im selben Chip wiederfinden. Analog dazu enthält der Funktionsplan des Systemingenieurs zu Beginn keine Informationen zur späteren Umsetzung.

Auch agile Ansätze, also das frühzeitige Testen von Komponenten, das im Softwarebereich Alltag ist, werden immer stärker in den Mechanikbereich übernommen, umgesetzt in Simulationen des digitalen Zwillings. Sogar Branching/Merging ist inzwischen in einigen CAD-Systemen implementiert. So gesehen nähern sich die Bereiche an, aber es wird in absehbarer Zeit genügend Unterschied verbleiben, um getrennte Systeme – ALM und PLM – zu rechtfertigen.

 

 

 

BCT steht Ihnen als Experte im Bereich PLM gerne beratend auf dem Weg zum digitalen Unternehmen zur Seite.

Kontaktieren Sie uns für ein unverbindliches und kostenfreies Beratungsgespräch:

Jasmin Meier
Tel: +49 7852 996-253
jmeier(at)bct-technology.com

 

 

  Die Datenschutzerklärung habe ich zur Kenntnis genommen und bin damit einverstanden, dass meine Daten zu Zwecken der Kontaktaufnahme per Brief, Telefon und/oder E-Mail gespeichert und genutzt werden.

Kontakt

BCT steht Ihnen als Experte im Bereich PLM / ALM gerne beratend auf dem Weg zum digitalen Unternehmen zur Seite.

Kontaktieren Sie uns für ein unverbindliches und kostenfreies Beratungsgespräch:

Jasmin Meier
Tel: +49 7852 996-253
jmeier(at)bct-technology.com

Alternativ können Sie auch unser Kontaktformular verwenden.

Weitere Informationen

zu ALM mit Polarion