• Wie softwareorientierte Entwicklung die komplette Produktentwicklung schlanker macht.

• Lernen Sie eine bessere Methode kennen, um wichtige von unwichtigen Produktmerkmalen zu unterscheiden.

• Sparen Sie Hardwarekosten und vermeiden Sie teure und zeitaufwändige Hardware-Iterationen in der Produktentwicklung.

Aus Ideen erfolgreiche Produkte zu machen, kann eine Herausforderung sein. Es gilt, knappe Termine einzuhalten und bestmögliche Kompromisse einzugehen. Und auch der Wettbewerb ist mit ähnlichen Produktideen und -designs nie weit weg.

Softwareorientierte Entwicklungskonzepte können angesichts dieser Notwendigkeiten von großem Vorteil sein – auch bei der Entwicklung physischer Produkte.

Schon vor zehn Jahren prognostizierte Marc Andreessen in seinem Essay „Software eats everything“ im Wall Street Journal, dass Software „alles verschlingen“ werde. Mit der stetigen Zunahme von Mobile und Cloud Computing hat sich das sicher bewahrheitet. Gerade bei der Entwicklung physischer Produkte spielt Software eine immer größere Rolle.

In diesem Beitrag stellen wir Ihnen ein aktuelles Beispiel aus unserer Projektarbeit vor.

Die Antwort ist ein klares Nein. Ein Kunde, der im Bereich technischer Produkte tätig ist, trat mit dem Auftrag an uns heran, als Startpunkt eines neuen Entwicklungsprojekts ein Labormuster zu bauen, das seine neueste Produktidee abbildete. Bei der Durchsicht des Lastenhefts stießen wir auf diverse Herausforderungen, die nicht nur terminlicher, sondern auch technischer Natur waren.

Zu Beginn drehte sich unser gesamtes Denken im Wesentlichen darum, wie dieses physisches Labormuster zu bauen sei. Mit physisch meine ich alle Arten von konkreten Teilen, wie Steuerplatine, Display, ein paar Tasten, Aktoren, Sensoren, Rahmen, Gehäuse und so weiter. Natürlich wäre für den Prototypen auch ein wenig Software nötig, aber die Betonung lag auf „wenig“, also nur zur Steuerung der inneren Prozesse und um eine Schnittstelle bereitzustellen.

Außerdem sollten für das Labormuster sorgfältig ausgewählte Hardwarekomponenten verwendet werden, von denen man annahm, dass sie erfolgskritisch seien. Der Aufbau eines Labormusters ist das, was man in der Regel im Frühstadium einer Produktentwicklung macht – wir haben das Vorgehen also erstmals nicht in Frage gestellt.

Der Wendepunkt kam, als der Kunde uns mitteilte, er habe festgestellt, dass das Alleinstellungsmerkmal seines neuen Produkts doch nicht durch diese speziellen Hardwarekomponenten definiert sei. Aha!

Wichtig seien vielmehr die Benutzerführung und die allgemeine Flexibilität und Steuerbarkeit des Geräts. Für uns bedeutete das den sofortigen Wechsel vom Labormuster zum softwareorientierten Innovationsdenken und zur softwareorientierten Entwicklung. Wir schlugen vor, die Labormuster für später beiseite zulegen und stattdessen mit der Software zu beginnen. Die Software würde mit einem Mix an verschiedenen bestehenden Produkten vernetzt werden. Hierfür mussten diese Produkte lediglich an die Software angebunden und im Programm Zugriff auf die Aktoren und Sensoren ermöglicht werden. Fehlt nur noch eine Automatisierungsschicht mit Scripting, Statusüberwachung und domänenspezifischem Logging und eine Steuerungsschicht – fertig ist das Setup, das der Kunde für Experimente mit einem Produkt nutzen kann, das physisch (noch) nicht existiert.

Durch die Automatisierung mit vollem Hardwarezugriff und die umfassende Flexibilität einer Scripting-Umgebung lässt sich mit dem „Laborsoftwareprodukt“ herausfinden, welche Funktionen relevant sind und was bei deren Realisierung wichtig ist und was nicht.

Zum Beispiel war man davon ausgegangen, dass das Einbinden von Zubehör komplex sein würde. Aus informationstechnischer Sicht wäre eine der geplanten Zubehörkomponenten (ein zusätzlicher Temperatursensor) lediglich eine weitere Datenquelle für den Regelkreis des Hauptaktors. Außerdem kann die zusätzliche Datenquelle nun, je nach Zustand des auszuführenden Prozesses, verwendet oder ignoriert werden. Um herauszufinden, wann die Verwendung sinnvoll ist und wann nicht, kann man beliebig viele Flows schreiben, die Log-Ausgaben sowie die physischen Ergebnisse analysieren und die Parameter entsprechend anpassen. Wenn das nicht ausreicht, können die Log-Daten in der Genauigkeit korrigiert und mit Zeitstempeln oder anderen Metadaten versehen werden. Wenn Sie die Protokolldaten in einem Data Analytics-Tool laden, lassen sich neue Erkenntnisse und Zusammenhänge finden.

Bislang haben wir viel über Software gesprochen, aber wie geht es jetzt weiter?

Sobald die Flows und Use Cases auf der provisorischen Hardware laufen, können Sie die Hardwareanforderungen ableiten. In der Praxis können Sie so Hardwarekosten sparen und teure, zeitaufwändige Hardware-Iterationen in der Produktentwicklung vermeiden.

Sie beginnen dann mit der Hardwareentwicklung und portieren die Software schrittweise auf die „echte“ Hardware. Und um den Erfolg zu testen, haben Sie bereits ein Referenzsystem, mit dem die Ergebnisse verglichen werden können. Es bleibt also nichts weiter zu tun, als die agile Produktentwicklung wie gewohnt fortzusetzen. Hiermit gilt für die Zukunft: „Hardware folgt Software“.