Wenn Maschinenbauer und Softwareentwickler zusammenarbeiten, treffen zwei Welten aufeinander», sagt Martin Jud, Informatikdozent am Departement Technik & Architektur der Hochschule Luzern. Auf der einen Seite sind da die Ingenieurinnen und Ingenieure, die ihre Maschinen sequenziell entwickeln – am Anfang steht der Entwurf, dann folgen eventuell Simulation und Korrektur, schliesslich geht die Zeichnung in die Werkstatt. Hier entsteht der Prototyp, der von Anfang an funktionieren sollte. «First time right» lautet die Maxime, alles andere kostet zu viel Geld. Auf der anderen Seite sind da die Informatikerinnen und Informatiker ohne Schnittstelle zur Produktion. Wer Software konzipiert, «produziert» sie auch, indem er den Code schreibt. Informatikfachleute nähern sich schrittweise, mit kontinuierlichen Verbesserungen der endgültigen Lösung. Sie arbeiten iterativ. «Eine Vorgehensweise, die manchen Maschinentechnikingenieur auf die Palme bringt», sagt Jud.
Mehrkosten und Verspätungen verhindern
Im Lauf der Zeit intensivierte sich die Zusammenarbeit zwischen den beiden Berufsgattungen. Die Softwarekosten machen heute rund die Hälfte der Herstellungskosten einer Maschine aus. Maschinenherstellern fehlen jedoch oft tiefergehende Informatikkenntnisse, um die Steuerung der Maschine selbst zu programmieren. «Eine eigene Softwareabteilung aufzubauen, macht betriebswirtschaftlich aber keinen Sinn, weil ein neuer Maschinentyp nur alle drei bis vier Jahre entwickelt wird», erklärt Jud. So vergeben die Anlagebauer die IT-Arbeiten extern. Diese Zusammenarbeit verläuft oft alles andere als problemlos, wie das Beispiel der Luzerner Firma Profin zeigt. Das KMU produziert Maschinen, die Flächen, Kanten und Konturen in einem hochgenauen Prozess – dem Flakkotieren – abschleifen. Profin baut Maschinen unter anderem für Werkzeughersteller, Autobauer oder Triebwerkproduzenten.
Bei der Entwicklung der Software für ihre Produkte machte die Firma sehr schlechte Erfahrungen. «War ein Softwarefehler an einem Ort behoben, kamen vier weitere an einem anderen Ort zum Vorschein», erzählt Inhaber und Firmenchef Josef Vogel. «Das führte zu massiven Verspätungen und Mehrkosten von rund zwei Millionen Franken», sagt Vogel. Dem Familienunternehmen ging das an die Substanz. Nach diesem «Desaster» suchte Profin-Chef Vogel Rat beim Kompetenzzentrum Distributed Secure Software Systems (D3S) der Hochschule Luzern. Mit Martin Jud fand er den richtigen Mann. Der Dozent ist Experte für Schnittstellen zwischen Maschine und Software. Im KTI-Projekt «Software-Vergabe und Co-Entwicklung» (SoVeCo) begleiteten Jud und sein Team die Entwicklung einer neuen Maschinengeneration bei Profin und fanden so neue Wege, die Zusammenarbeit zwischen Maschinenbauern und Softwareentwicklern zu verbessern.
Arbeitsweisen der anderen Disziplin kaum bekannt
Sie identifizierten vier Faktoren, die über Erfolg oder Misserfolg entscheiden. «Softwareentwickler und Maschinenbauer wissen oft wenig über die andere Seite», sagt Martin Jud. Während Maschinenbauern die Methoden und Vorgehensweisen der Software- Entwicklung weitgehend unbekannt sind, hätten diese üblicherweise kaum klare Vorstellungen davon, wofür der Endkunde die Maschine, für die sie die Software schreiben, überhaupt einsetzen wolle. Der zweite Faktor ist die Komplexität. Für die Entwicklung einer Maschine lässt sich wohl ein Rahmenplan definieren. Es ist jedoch so gut wie unmöglich, jeden Schritt von A bis Z durchzuplanen. «Oft ergibt erst ein Schritt die relevanten Fragen für den nächsten», so Jud. Weil gegenseitige Abhängigkeiten beständen, dürfe die Detailplanung deshalb nicht in Stein gemeisselt sein. Sie sollte sich vielmehr flexibel dem Projektfortschritt anpassen.
Dafür – das ist der dritte Punkt – bedarf es eines gewissen Masses an Vertrauen unter den Partnern, weil die Leistungen nicht im Voraus fixiert werden können. Ein Controlling ist dennoch möglich und wichtig. Martin Jud und sein Team empfehlen, «Hard- und Software- Rendezvous» zu definieren. Meilensteine, an denen sowohl lauffähige Software wie auch geeignete Funktionsmuster der Maschine vorliegen, deren Zusammenspiel sich dann testen lässt. «Denn bis zum eigentlichen Test auf der Maschine gleicht das Softwarecontrolling einem Blindflug», sagt Martin Jud.
Die Verträge sollten dynamisch sein
Die vierte Erkenntnis betrifft die Gestaltung der Verträge. «Zu Beginn des Vertragsverhältnisses ist das Endprodukt noch nicht vollumfänglich definiert; ein üblicher Werkvertrag, bei dem ein Endergebnis definiert wird, ist deshalb nicht die richtige Wahl für eine Co-Entwicklung», sagt Reto Fanger, Anwalt und Dozent am Departement Wirtschaft der Hochschule Luzern. Er entwickelte verschiedene Musterverträge, die modulartig miteinander kombiniert werden können: Vorprojektvertrag, Rahmenvertrag sowie ergänzende Einzelverträge. Reto Fanger: «Der dynamische Entwicklungsprozess und die verschiedenen Projektstadien lassen sich damit auch vertraglich abbilden.»
Profin-Chef Vogel liess die Erkenntnisse des SoVeCo-Projekts bereits in die Entwicklung der nächsten Maschinengeneration einfliessen. Und er stellte auch einen Software-Ingenieur ein. «Er funktioniert als Brückenbauer zwischen uns Maschinenbauern und dem Softwareentwicklungsteam.»