Das primäre Ziel eines Unternehmens, einen Mehrwert zu erbringen und dafür (meist) von Kunden bezahlt zu werden, gilt unabhängig der Branche und dem dahinterstehenden Produkt oder Service. Viele Firmen fokussieren auf die Kernkompetenz, einen Mehrwert mit den dafür eingesetzten Ressourcen möglichst effizient bereitstellen zu können. In Anbetracht dessen, dass bisher die Wettbewerbsfähigkeit eines Unternehmens massgeblich durch die Kostenvorteile definiert wurde, ist dies eine absolut verständliche Ausrichtung. Gerade Unternehmen in der Hardware-Industrie haben in den vergangenen 50 Jahre hocheffiziente und -komplexe Wertschöpfungsketten etabliert, welche sehr spezifisch auf ein Produkt oder Service ausgelegt sind. Um diese kapitalkapitalintensiven Produktionsketten noch effizienter zu gestalten, gibt es "jüngere" Konzepte wie Lean Manufacturing, Kanban Systeme oder Shopfloor Management. Diese reduzieren zwar das gebundene Kapital, nicht aber die Komplexität.
Eine andere, eminente Herausforderung sind die zeitintensiven Entwicklungszyklen neuer Produkte. Es dauert oft Jahre, bis ein neues Produkt oder Service fertig entwickelt ist. Bisher waren lange Produktlebenszyklen kein Problem und die Unternehmen hatten Zeit für Innovationen. Viele Firmen haben deshalb nach wie vor lineare, komplexe sowie isolierte Entwicklungsprozesse. Die logischen Folgen daraus sind risikobehaftete Entwicklungen neuer Versionen oder Produkte mit langen Feedback-Zyklen. In der heutigen Zeit aber ist der Druck gestiegen, aufgrund neuer Kundenbedürfnisse oder Technologien laufend und schnell innovative Produkte und Services zu entwickeln. In immer unberechenbarer und volatiler werdenden Märkten ist die Anpassungsgeschwindigkeit an Änderungen ein immer wichtiger werdender Wettbewerbsvorteil.
Quelle: Unsplash
Problem 1:
Entwicklung in starren und langen Phasen ist nicht reaktionsfähig und ein Feedback-Killer!
Die Entwicklung von Hardware Produkten oder Services ist in vielen Unternehmen klassisch organisiert. Das Produkt wird initial spezifiziert sowie geplant und anschliessend sequenziell ausgeführt. Dies ist teilweise dadurch bedingt, dass die ausgelagerte Entwicklung einzelner Komponenten "harte" Abhängigkeiten darstellen. Teilweise aber auch dadurch, dass dies lange schlicht DIE Vorgehensweise war. Wird aber ein Produkt isoliert und in Phasen entwickelt, entsteht die Problematik, dass nicht involvierte Personen die Entwicklung als intransparent empfinden und es zu Transferverlusten bei Handovers in den Entwicklungsphasen kommen kann. Unglücklicherweise ist eine häufige Folge davon, dass die Spezifikationen nie fixiert werden oder während der Entwicklung undokumentiert angepasst werden. In diesem Fall spricht man von «Floating Specs», welche nie wirklich fertig werden. Dieses Phänomen kann auch die Ursache haben, dass es während langen Entwicklungsphasen zu Änderungen im Scope oder personellen Besetzung des Entwicklungsteams kommt. All dies liegt nicht an den beteiligten Personen oder dem Unternehmen, sondern in der Natur des Vorgehensmodells. Der Entwicklungsprozess nach klassischen Vorgehensschema hat dadurch inhärent den Nachteil, dass schnelle und direkte Feedbackzyklen verunmöglicht werden. Die Frage ist deshalb berechtigt, ob die traditionelle Art der Planung und Entwicklung noch geeignet ist für die Entwicklung von komplexen Hardware-Produkten.
- Lösungshypothese: Entwicklungsphasen auflösen und in Iterationen denken - kürzere Entwicklungszyklen und schnelleres Feedback!
Problem 2:
Spezialisierte und dedizierte Entwicklungsteams können die heutige Komplexität der Produktentwicklung nicht mehr ausreichend abbilden!
In der heutigen Welt gibt es kaum noch komplexe Produkte, die keine Kombination aus Hardware, Software und Firmware sind. Wird die Produktentwicklung anhand dieser Komponenten oder Schnittstellen gegliedert, führt dies häufig spätestens bei der Integration zu unvermeidbaren Problemen. Auch beim Transfer des Produkts von der Entwicklung in die Serienproduktion bringt häufig ungeahnte Herausforderungen mit sich. Leider werden häufig interne Rahmenbedingungen wie z.B. die Herstellbarkeit oder Aspekte des fortlaufenden Services unbeabsichtigt in der Entwicklungsphase vernachlässigt. Eine ganzheitliche Betrachtung des Produktlebenszyklus ist für Teams mit reinen Entwicklungsspezialisten (Ingenieure, Designer, etc.) verständlicherweise nur schwierig abzudecken. Werden die jeweiligen Experten zu einem späteren Zeitpunkt in die Produktentwicklung einbezogen, kann dies zu vermeintlich kleinen Änderungen führen, welche durchaus sehr umfangreiche Auswirkungen haben können. Die Schwierigkeit, dabei die Kontrolle über das gesamte Produkt (Architektur, Funktionalität, Herstellfähigkeit, etc.) zu behalten, ist nicht zu unterschätzen. Allzu häufig führt dies zu ungewollten Verzögerungen oder zu kurskorrigierenden Taskforces, welche niemand wirklich wollte.
- Lösungshypothese: Entwicklungsteams mit Personen aus allen Bereichen und Disziplinen zusammenstellen - und zwar ab Tag 1!
Fazit
Aus unserer Sicht spielt es keine Rolle was das Endprodukt ist: Software, Hardware oder Services. Das primäre Ziel, Erarbeiten von Mehrwert, ist identisch. Die dabei zugrundeliegende Arbeitsmethodik, -kultur und Organisation sind viel entscheidender als die Art des Produkts. In der heutigen Zeit ist es für Firmen zwar nach wie vor wichtig, Kostenvorteile und -effizient zu erreichen, aber es wird immer wichtiger, schnell und richtig reagieren zu können. Unternehmen, welche sich konsequent und regelmässig hinterfragen, was ihre Kunden wollen sowie welchen Mehrwert erbracht werden kann, gehören immer häufiger zu den Besten. Unserer Meinung nach wird in Zukunft der Wettbewerbsvorteil eines Unternehmens dadurch definiert, wie reaktionsfähig die Produktentwicklung ist. Interessiert Sie dieses Thema und haben Sie bei ihrer Arbeit selbst Erfahrungen zu «Agilität in der Hardwareentwicklung» gesammelt? Uns interessiert Ihr Wissen und wir würden uns freuen, wenn Sie an unserem virtuellen SwissQ Event «Agile@Hardware Development» am 18. November 2020 teilnehmen würden.