Es ist unausweichlich, dass die Software einen immer größeren Anteil der Maschinenfunktionalität darstellt. Dabei geht es gar nicht darum, elektrische oder mechanische Funktionen zu ersetzen. Die mechanischen Kurvenscheiben und Steuerketten haben vielerorts schon seit geraumer Zeit modernen programmierbaren Servoantrieben weichen müssen, fest in Platinen gegossene Logik wurde durch flexible SPSen ersetzt. Heute ist es meist vielmehr so, dass die Softwarefunktionen in ungebremster Geschwindigkeit einfach zum bestehenden System oder den Maschinensteuerungen dazukommen. Zudem multipliziert sich oftmals der Aufwand, da dieselbe Funktionalität in unterschiedlichen softwaretechnischen Varianten aufgrund von Inkompatibilitäten zwischen Standards oder unterschiedlichen Softwareversionen angeboten werden muss, wie:
- die Kommunikation und Vernetzung auf Sensor- und Maschinenebene mit unterschiedlichen und derzeit meist nicht ohne zusätzliche Aufwände kombinierbaren Formaten,
- die Datenanbindungen zu unterschiedlichen MES- und ERP-Systemen sowie Datenbanken über der Maschinenebene,
- Cloud-basierte Services mit konkreten Steuerungsfunktionen bis hin zu übergreifenden Informations-Mesh-Ups für die taktische Optimierung des Maschinenverhaltens und der übergeordneten Maschinen- und Anlagenorchestrierung,
- die Funktionen zur Selbstoptimierung basierend auf maschinellem Lernen und vorausschauender Wartung
- und viele unterschiedliche Benutzerschnittstellen basierend auf der bekannten 2D-Fenstertechnik ergänzt um 3D-Darstellungen, Videoinformationen und natürlich sprachliche Kommunikationsschnittstellen in allen möglichen Varianten – von der Anzeige auf der Smartwatch, Smartphone, Augmented-Reality-Display, auf dem Tablet, Laptop oder PC, und das wiederum in der Form einer für das jeweilige System nativen Anwendung oder als Web-Applikation.
Die Vorstellung, dass in Zukunft die mechanischen Konstrukteure Softwarethemen abdecken werden, ist damit eher unwahrscheinlich. Aber: Wer bei der Mechanik nicht Schritt hält und die erforderlichen grundlegenden konstruktiven, produktionstechnischen und logistischen Abläufe aus dem Auge verliert, verliert auch seine Systembasis. Die Software wird definitiv neue Türen in allen Belangen öffnen – im Maschinenbau wird aber das physisch-mechanische System immer den Ausgangspunkt für ein erfolgreiches Produkt darstellen.
Entwicklungskapazität wächst mit der Systemkomplexität
Um diese Herausforderung zu schaffen, wird die erforderliche Entwicklungskapazität also insgesamt wachsen müssen. Ein Umschichten von Kapazität aus den mechanischen und elektrischen Disziplinen wird selten sinnvoll sein. Zu groß wären die Lücken die dadurch in wesentliche Grundeigenschaften der Maschinen gerissen würden. Am konkreten Beispiel bedeutet das: Nur weil eine Maschine eine hübsche Benutzerschnittstelle hat und in der Lage ist, Daten in die Cloud zu senden, die dort über vorausschauende Analysen kritische Betriebszustände erkennen lassen, darf die Standzeit der Maschine aufgrund eines suboptimal ausgelegten mechanischen Maschinengestells nicht insgesamt geringer sein. Ein höherer Softwareanteil in den Systemen bedeutet schlichtweg mehr beteiligte Entwickler – intern in der Entwicklungsabteilung oder in Form von externen Dienstleistungen.
Aufgaben der Softwareentwickler
Was werden die Softwareentwickler eines Maschinenbauers dann eigentlich konkret machen? Sie werden den Software-Kit liefern – für noch mehr Software, die von Zulieferern kommt. So wie sich heute die Fertigungstiefe in der physischen Produktion laufend verringert und vielerorts der Fokus auf der Montage liegt, so wird sich auch die Fertigungstiefe im Softwarebereich den Anforderungen anpassen. Wer hat heute schon noch eine eigene vollumfängliche Metallbearbeitung im Haus? Wer eine Elektronikfertigung? Genau so wird man sich Softwareseitig fragen müssen: Wer programmiert noch ein eigenes Rezeptsystem? Wer entwirft noch ein eigenes Kommunikationsprotokoll? Oder wer leistet sich eine eigene Cloud-Entwicklung? Zum Softwareerstellungsprozess werden die Koordinationsprozesse zwischen den Softwarezulieferern erfolgsentscheidend werden, und vor allem die begleitenden Prüfprozesse, um die Qualität der extern erstellten Software sicherzustellen. Die Aufgaben einer Softwareentwicklung werden sich somit ein Stück wandeln: von der Vorstellung, alles selbst zu entwickeln, hin zu einem System- und Lieferantenmanagement. Das hat wiederum große Konsequenzen auf die heutige Zusammensetzung von kleinen Softwareteams, die oftmals keine besondere Differenzierung der Entwicklerrollen haben und vielleicht auch noch nicht benötigen. Das häufig anzutreffende Organisationsmodell lautet: ein Entwickler – eine Maschine. Abgesehen von den generellen Problemen, die so eine Vorgehensweise mit sich bringt, ist es für eine absehbare Zukunft mit großen komplexen Softwaresystemen, die aus unterschiedlichen Softwaretechnologien bestehen, eine Sackgasse. Es werden Teams erforderlich sein, die einerseits eine gewisse Aufgabendifferenzierung der Rollen hinsichtlich Technologie, Architektur und Test aufweisen werden. Zudem ist viel zu investieren, um das gewonnene Wissen über das gesamte Team zu verteilen.
Schnelle Anpassung durch systematisches Lernen
Trotz aller Schwierigkeiten und Herausforderungen ist die Softwareentwicklung kein gordischer Knoten. Stark vereinfacht gesagt: Eine gute Softwareentwicklung mit all ihren Facetten lebt von der zwischenmenschlichen Kommunikation und von der Möglichkeit, sich laufend und flexibel auf Veränderungen in der Organisation, der Technologie, den Kundenanforderungen und die verfügbaren Werkzeuge einstellen zu können. Softwareentwickler brauchen den Freiraum und die Kultur, um miteinander sprechen zu können. Das mag einfach klingen, ist aber essenziell wichtig: Wer ist mit dem Blick auf die Softwareentwickelnden Kollegen nicht schon mal der Versuchung erlegen, zu denken: „Nun treffen sich die schon wieder – die sollten doch besser mal was arbeiten!“ Und genau das ist das Problem: Softwarefragestellungen lösen sich erfahrungsgemäß im Team schneller und besser als eigenbrötlerisch vor dem Rechner. Aber Freiräume zu schaffen, darf nicht mit Laissez-faire verwechselt werden oder damit, die Zügel aus der Hand zu geben. Freiräume müssen zielgerichtet genutzt werden, um die Lerngeschwindigkeit der Teams messbar zu erhöhen. Der Kommunikationssand im Entwicklungsgetriebe muss sichtbar werden, um ihn effektiv beseitigen zu können. Eine inzwischen auch für industrielle Abläufe bewährte Vorgehensweise, ursprünglich aus dem Start-up-Umfeld kommend, findet sich unter dem Begriff lean Start-up von Eric Ries. Diese Vorgehensweise ist für organisatorische Veränderungsmaßnahmen ebenso anwendbar wie bei Prozessveränderungen, Qualifizierungsmaßnahmen oder Tool-Einführungen.
