Business first! Die Softwarearchitektur entscheidet über Kosten und Erfolg von Apps in der Industrie

• Um Kosten für digitale Offerings gering zu halten und den wirtschaftlichen Erfolg zu sichern, muss die Softwarearchitektur optimal zum geplanten Use Cases passen. 

• Entscheidungen zur Softwarearchitektur müssen aus strategischer Business-Perspektive getroffen werden. 

• Vertriebsteams spielen eine zentrale Rolle: Sie müssen entsprechend strukturiert und geschult werden, um den erfolgreichen Vertrieb der neuen Services sicherzustellen. 

Neue, digitale Use Cases wie Apps oder Software-Add-ons werden in der Industrie zunehmend zum unverzichtbaren Erfolgsfaktor. Leider musste ich in den letzten Jahren immer wieder mit ansehen, dass – aus Business-Sicht – wichtige und vielversprechende Projekte aufgrund von zu hohen Aufwänden in der Umsetzung wirtschaftlich scheitern. Laut einer Zühlke-Studie rechnen sich lediglich 5 Prozent aller IoT-Projekte. Die Zukunft der Industriebranche hängt aber davon ab, Digitalisierungsprojekte erfolgreich umzusetzen. Dieser Blog zeigt daher, welche Fragen Sie sich für eine erfolgreiche Realisierung stellen müssen. 

Im ersten Blogartikel unserer Reihe (”Apps in der Industrie: Innovative Produkt-USPs und neue, digitale Geschäftsmodelle”) haben wir das hohe Potenzial von Apps und digitalen Erlösmodellen in der Industrie gezeigt. Dieser Post beleuchtet die konkrete Erarbeitung der Softwarearchitektur und beantwortet die Frage, welche Business-Aspekte für die wirtschaftlich erfolgreiche Umsetzung von App- bzw. Softwareprojekten in der Industrie zu klären sind.  

Architekturtreiber für App- und Softwareprojekte in der Investitionsgüterindustrie 

Die meisten wichtigen Treiber bei der Erarbeitung einer neuen Softwarearchitektur sind wirtschaftlicher Natur. Erst, wenn diese wirtschaftlichen Aspekte geklärt sind, kann unter Berücksichtigung der bestehenden Architektur und anderer unternehmensspezifischer technischer Restriktionen die Softwarearchitektur für neue digitale Offerings erarbeitet werden.  

Um die Kosten in der Entwicklung, aber auch im späteren Betrieb, möglichst gering zu halten und den Erfolg von Apps zu sichern, muss die Softwarearchitektur optimal zum geplanten Use Cases passen. Passt die Architektur nicht zum Anwendungsfall oder die Anwendung nicht zur Architektur, können bei der technischen Umsetzung, der Weiterentwicklung und im Betrieb unnötig hohe Kosten, z. B. durch Anpassungen entstehen. Diese unnötigen Ausgaben für die Software können den gesamten Business Case gefährden. Tatsächlich ist diese Diskrepanz zwischen technischer Umsetzung und Anwendung einer der häufigsten Ursachen für das Scheitern von Digitalisierungsprojekten in der Industrie, wie die Zühlke-Studie “Data-driven Companies: Der Weg zur strategischen Nutzung von Daten” zeigt. Umgekehrt ist eine passende Softwarearchitektur die Basis für nachhaltigen wirtschaftlichem Erfolg in der neuen, digitalen Welt.  

Funktionen und Apps für einzelne Maschinen oder Maschinengruppen 

Eine erste zentrale Frage für die Gestaltung einer passenden Architektur eines neuen Softwareangebots lautet: Soll mit den zusätzlichen Funktionen der Nutzen einer einzelnen Maschine erweitert werden oder sind Funktionen geplant, die sich aus der Vernetzung mehrerer Maschinen ergeben? Im ersten Fall werden nur die Einzelmaschine bzw. nur die Aspekte betrachtet, für die eine Vernetzung mit anderen Maschinen irrelevant ist. Softwarearchitekturen für Offerings, die das Zusammenspiel mehrerer Maschinen unterstützen, sind in der Regel aufwendiger und teurer in der Entwicklung und im Betrieb. 

Kompatibilität der Apps: Ausschließlich Neugeschäft oder auch Nachrüstung? 

Unternehmen müssen sich die Frage stellen, ob und wie sie die bestehenden digitalen Schnittstellen zu den Maschinen erweitern müssen. Dabei gilt es abzuwägen, wie mit verschiedenen Generationen von Maschinen umgegangen wird. Das Unterstützen von alten Generationen kann die Kosten so stark in die Höhe treiben, dass sich für die geplanten Apps kein Business Case mehr ergibt, zum Beispiel: Die Nutzung der App steigt nur um 10%, wenn sie auch zu den alten Maschinengenerationen kompatibel sein soll. Gleichzeitig verdoppeln sich die Kosten für die Anbindung der älteren Maschinen, da der Aufwand des Anbindens älterer Maschinen sehr hoch ist. Aus wirtschaftlicher Perspektive spricht also alles dafür, nur die aktuelle Maschinengeneration einzubinden. Sehr wichtig ist es auch, Schnittstellenspezifikationen festzulegen, die möglichst lange Bestand haben. Spätere Änderungen können hohe Folgekosten verursachen und müssen daher gut überlegt sein.  

Schnittstellen zu den Maschinen für Apps und Add-ons: Kommunikationsstandards wie OPC UA vs. Branchenstandards 

Nutzen Sie unternehmensspezifische Schnittstellen? Dann stellen Sie sich die Frage, ob Sie diese weiterhin verwenden möchten, oder ob Sie die Chance ergreifen, zu branchenspezifischen Standards zu wechseln. Die Voraussetzung für den Zugang zu Maschinen verschiedener Hersteller ist die Unterstützung aller herstellerspezifischen Schnittstellen, oder aber die Nutzung von Standards, wie z. B. OPC UA. In der Praxis zeigt sich: Häufig ist es notwendig, beide Varianten abzudecken: Die wichtigsten etablierten Schnittstellen und auch die aktuellen branchenspezifischen Standards oder Industriestandards wie OPC UA. Um die Entscheidung final treffen zu können, lassen Sie im nächsten Schritt erfahrene Softwarearchitekten untersuchen, welche Kosten für solche Schnittstellen bei der Entwicklung und im Betrieb zu erwarten sind.  

Mobilplattformen wie Android oder iOS für Apps 

Grundsätzlich ist es möglich, Standards wie Android für ein Bedieninterface zu verwenden oder sogar mobile Endgeräte wie iPads, Android oder Windows-Tablets einzusetzen, wenn diese zur Bedienung geeignet sind. Der Vorteil: Durch den Einsatz von Standards können Sie zur Verteilung der Software ggfs. auch die sogenannten Deployment-Funktionen dieser nutzen. Dies kann einerseits Entwicklungszeit einsparen, andererseits aber zu einer höheren Abhängigkeit von den Anbietern führen. Wichtig ist, diese Abhängigkeiten auch aus der Businessperspektive zu hinterfragen und sich nicht allein auf Empfehlungen des Softwareteams zu verlassen. Unterschiedliche Perspektiven reduzieren die Gefahr subjektiver Entscheidungen, sie können beispielsweise das Risiko minimieren, dass Teams Entscheidungen auf Basis persönlicher Präferenzen für bestimmte Technologien treffen.  

Verwendung von IoT-Plattform: Kosten vs. Akzeptanz 

Zühlke hat für ein deutsches Unternehmen untersucht, welche IoT-Plattform der drei großen Anbieter AWS, Microsoft und Google am besten für das Unternehmen geeignet ist. Dazu haben wir zum einen die zu erwartenden Cloud-Betriebskosten für die geplante Anwendung ermittelt - für diesen Business Case eine zentrale Information. In Puncto Kosten gab es aber keine relevanten Unterschiede zwischen den Anbietern. Daher haben wir einen weiteren elementaren Aspekt betrachtet: Pro Anbieter haben wir untersucht, mit welcher Akzeptanz das Unternehmen durch den Einsatz des Anbieters bei seinen internationalen Kunden in deren spezifischer Branche rechnen kann. Einige der drei großen Anbieter sind neben dem reinen Cloudgeschäft in weiteren Geschäftsfeldern aktiv und aufgrund unterschiedlicher Strategien in verschiedenen Industrien teils mehr oder weniger akzeptiert. Am Ende hat unser Kunde den Anbieter ausgewählt, bei dem die höchste Kunden-Akzeptanz zu erwarten war.  

Externe Softwareanbieter von Apps: Mehrwert oder Risiko? 

Auch externe Softwareanbieter können für Ihre Kunden interessante Mehrwerte schaffen, die damit auch den Wert Ihrer Produkte erhöhen. So kann ein digitales Ökosystem rund um die eigenen Maschinen entstehen. Sie sollten sich frühzeitig die Frage stellen, ob Sie von Fremdanbietern eine anteilige Marge oder eine feste Gebühr verlangen möchten. Beides würde zu zusätzlichen Einnahmen führen, andererseits kann es die Motivation externer Softwareanbieter für Ihr Ökosystem bremsen und so zum Nachteil für Sie werden. Denn gibt es zu Ihren Maschinen nützliche Fremdsoftware, so erhöht sich der Marktwert des eigenen Produkts. Bedenken Sie aber auch die Kehrseite der Medaille: Schlechte bzw. unpassende externe Softwarelösungen können negativ auf die eigenen Produkte und die eigene Marke ausstrahlen. Neben dem Imageverlust kann dies den Aftersales-Service durch Reklamationen belasten und zu aufwändigen Untersuchungen führen, ob die Fremdsoftware oder die eigenen Produkte die Fehler verursachen.  

Sonderfall Mitbewerber-Apps: Bedrohung oder Chance für zusätzliche Erlöse? 

Besonders heikel wird es, wenn Mitbewerber externe Software liefern. Entscheiden Sie daher, ob auch Mitbewerber übergeordnete Softwareangebote anbieten dürfen oder ob nur deren Maschinen angebunden werden sollen. Werfen Sie bei der geplanten neuen digitalen Positionierung Ihrer Firma einen Blick auf Ihre derzeitige Marktmacht im Vergleich zu Ihren Mitbewerbern.

Wenn Sie nicht aus der Marktführerposition starten, bedenken Sie bitte, dass der Versuch, die bisherigen Marktführer durch neue digitale Offerings aus dem Markt zu drängen, nur selten von Erfolg gekrönt ist. Im Gegenteil: Oft führt dieser Versuch zum Misserfolg der eigenen digitalen Lösung. Befinden Sie sich hingegen selbst bereits in einer starken Position, fällt es leichter, bei digitalen Angeboten neue Standards zu bestimmen und festzulegen, wer welche Rolle einnehmen darf.  

Um die Vorteile von extern entwickelten Apps zu nutzen, aber die Risiken zu minimieren, kann man sich konkret das Software-Ökosystem von Apple ansehen: Externe Softwareanbieter können ihre Apps nur über den App-Store anbieten. Vor der Veröffentlichung im Store hat Apple so die Möglichkeit, wesentliche Funktionen zu testen und die Software auf mögliche Sicherheitslücken zu untersuchen. Zugleich erfolgt bei Apple der Verkauf der Software über den App-Store und Apple hat die Möglichkeit, eine Marge von 30 % einzubehalten.

Voraussetzung für ein erfolgreiches digitales Ökosystem nach diesem Prinzip ist, dass es für Unternehmen ausreichend attraktiv ist, Apps auf der proprietären Plattform des Maschinenherstellers anzubieten und dadurch entsprechend viele potenzielle Player auf diese Plattform gezogen werden. Je maschinenspezifischer die Plattform ist, umso weniger erfolgversprechend ist dies in der Regel. 

Für eine abschließende Entscheidung, ob Sie externen Zugang zu Ihren Maschinen ermöglichen möchten, gibt es also einige Fragen zu klären: 

• Sollen externe Anbieter Apps anbieten können und in welchem Umfang?  
• Soll dies allen Marktteilnehmern erlaubt werden? 
• Sollen Mitbewerber ausgeschlossen werden? 
• Erfolgt eine Qualitätssicherung externer Apps durch das eigene Unternehmen? 
• Sollen diese Apps nur über einen eigenen Store angeboten werden und die externen Anbieter eine Marge abführen? 

Updates und Safety-Strategie für Apps: Klare Trennung zwischen kritischen Funktionen und Mehrwertfunktionen 

Ein wesentlicher Mehrwert von Apps und Software-Add-ons auf Maschinen: Sie können die Lebensdauer der Maschinen verlängern, da sie mit neuen Funktionen an neue Gegebenheiten angepasst werden können. Eine tragende Rolle bzgl. der Aktualität und Flexibilität spielen Updates. Es müssen Fragen wie “In welcher Form sollen die Software und die optionalen Softwareerweiterungen angeboten werden”, “Wie können Apps auf der Maschine aktualisiert werden – per Update oder Over the Air?” und “Wie zeitkritisch sind Softwareapps?”  

Auch die Safety-Strategie spielt in diesem Zusammenhang eine zentrale Rolle für die Architektur von Apps und digitalen Angeboten.  So dürfen manche Anwendungen nicht mit Updates versehen werden, da diese auf einem Softwarestand zertifiziert werden. Dies ist vor allem in sicherheitskritischen Anwendungen der Fall. Möchten Unternehmen dennoch auch für diese Anwendungen appbasierte Dienste anbieten, so kann dies durch eine saubere Trennung zwischen kritischen Funktionen und Mehrwertfunktionen gelingen. Ein Beispiel: Im Pkw werden die Airbagsteuergeräte getrennt von den Infotainmentsystemen vernetzt. Übergabepunkte zwischen den getrennten Funktionen gibt es dann nur an wenigen, gut kontrollierten Stellen. Gibt es hier von Anfang an eine klar vorgegebene Strategie, kann diese im Rahmen der Softwarearchitektur entsprechend umgesetzt werden. 

Vertrieb von Apps und Software: Häufig unterschätzter Stolperstein 

Ein Bereich, der oft nicht direkt mit der Umsetzung von Digitalisierungsprojekten in Verbindung gebracht wird, ist der Vertrieb. Nicht zuletzt deshalb ist der Vertrieb einer der größten Stolpersteine, wenn es um die erfolgreiche Monetarisierung von Software in der Industrie geht. Der Vertrieb von Investitionsgütern wie Maschinen und Anlagen erfolgt heute in der Regel durch ein Außendienstteam und dessen persönliche Beratung.

Diese erfahrenen Teams haben in der Regel sehr tiefes Maschinen- und Branchenwissen, aber häufig noch wenig Erfahrung im Verkauf von Software. Die Nutzung einer Vertriebsorganisation intern, oder im Export häufig auch extern, senkt aufgrund der Vertriebskosten die Verkaufsmarge auch für digitale Produkte. In der Zühlke-Studie “Radikale Innovation: Warum scheitern Unternehmen und wie kann sie gelingen?” sind über 90 Prozent der befragten Unternehmen der Meinung, dass ihre bestehende Vertriebsorganisation ihr neues digitales Produkt oder ihre neue Dienstleistung nicht verkaufen kann.

In der Automobilbranche erfolgt der Vertrieb von digitalen Offerings im After-Market in der Regel direkt ohne Beteiligung der Händler, was die Marge der Automobilkonzerne erhöht aber auch eine entsprechende IT-Infrastruktur erfordert. Bei Investitionsgütern muss zudem geklärt sein, wer die Nachkaufentscheidungen treffen darf. Sollen alle Nutzer einer Maschine Funktionen freischalten können oder erfordert es Berechtigungsstrukturen? Und wie soll die Abrechnung erfolgen? All diese Punkte sollten klar geklärt sein, da sie die Softwarearchitektur beeinflussen werden.  

Strategische Business-Entscheidungen bestimmen die Softwarearchitektur, nicht umgekehrt 

Bei der Beantwortung der oben gestellten Fragen wird klar: Entscheidungen zur Softwarearchitektur dürfen nicht allein aus technischer Sicht erfolgen. Es sind strategische Business-Entscheidungen, die die Vorgaben zur Entwicklung einer wirtschaftlichen Softwarearchitektur machen. Beziehen Sie also frühzeitig alle Stakeholder im Unternehmen mit ein. Das betrifft auch die Unternehmens-IT. Denn diese muss entscheiden, ob sie von Beginn an den Betrieb der Infrastruktur übernehmen möchte, oder ob der Betrieb zunächst durch einen Partner realisiert werden soll.  

Die finalen Entscheidungen können je nach Unternehmensorganisation zum Beispiel im Produktmanagement für digitale Produkte erfolgen. Wichtiger als die Abteilung ist aber sicher die Kompetenz der Beteiligten. Da für die Entscheidungsfindung sowohl Business-Know-how als auch technisches Verständnis für Softwarearchitekturen gefragt ist, setzen wir in unseren Projekten auf gemischte Teams aus unseren Digital Consultants und Softwarearchitekten. Diese beraten unsere Kunden und entwickeln gemeinsam die zum Use Case passende Softwarearchitektur.

Im folgenden Blogartikel „Wie entwickeln Sie eine wirtschaftlich erfolgreiche Softwarearchitektur?“ werden wir daher tiefer in die konkrete Projektarbeit eintauchen und aufzeigen, wie und mit welchen Methoden wir Sie auf Basis der Businessvorgaben dabei unterstützen können, die Architektur zu entwickeln und dabei möglichst früh die Kostenbudgets für die Entwicklung und den Betrieb abzuschätzen.