Diese Erklärungen sind bequem — und weitgehend falsch.
Das Problem war nie Software. Es war die fehlende Transformation der internen Ordnungsrahmen.
Die erste Phase der industriellen Digitalisierung basierte auf der Idee der horizontalen Industrie 4.0 Plattformen. Die Vision war überzeugend: eine universelle Schicht, die Maschinen, Daten, Anwendungen und Kunden unternehmensweit verbindet. Bestehende Industriegiganten versuchten, die Skaleneffekte klassischer Enterprise-Software in die Industrie zu übertragen. Was sie unterschätzten, war die strukturelle Realität industrieller Organisationen: autonome Geschäftseinheiten mit eigenen Architekturen, Anreizsystemen, Preislogiken und Kundenbeziehungen. Integration war teuer, Adoption freiwillig, Wertschöpfung diffus. Plattformteams optimierten für architektonische Eleganz — während Budgets und Verantwortlichkeiten strikt vertikal verankert blieben.
Als der wirtschaftliche und operative Druck stieg, ließ sich dieser Zielkonflikt nicht länger ignorieren. Die Geschäftseinheiten kehrten zu dem zurück, was sie kontrollierten — und wofür Kunden tatsächlich zu zahlen bereit waren. Priorisiert wurden Lösungen, die an konkrete Workflows, Assets und Ergebnisse gekoppelt waren. Die universelle Plattform verschwand nicht, aber sie wurde neu zugeschnitten. In vielen Fällen wurde sie zum Integrations-Backbone oder zu einem architektonischen Rahmenwerk — notwendige Infrastruktur, aber nicht mehr der Wachstumsmotor, zu dem sie ursprünglich auserkoren war.
Die Wertschöpfung verlagerte sich nach oben, näher an die geschäftliche Verantwortung. Vertikale Software — Manufacturing Execution, Asset Performance Management, Simulation, Digital Twins und Optimierung — zog zunehmend echte Budgets und Aufmerksamkeit des Managements auf sich. Nicht weil sie technologisch ausgefeilter war, sondern weil sie dazu passte, wie industrielle Kunden kaufen, steuern und Wert messen. Die Industrie 4.0 Plattformvision ist an organisatorischen Realitäten gescheitert, für die sie nie ausgelegt war.
Die Industriekonzerne, die am weitesten kamen, erkannten das früh — und reagierten nicht mit besserer Technologie, sondern mit einer neuen Struktur. Statt Software innerhalb hardwaredominierter Organisationen „reifen“ zu lassen, trennten sie die Steuerung, ohne die Domänentiefe zu verlieren. Software-Assets wurden konsolidiert, erhielten eigenständige Geschäftsmodelle und konnten mit eigenen Budgetverantwortlichkeiten, Talentstrategien und Marktnarrativen skalieren. Erst als diese Fähigkeiten ausgereift waren, wurden sie wieder integriert — nicht als experimentelle Anhängsel, sondern als laufende Geschäfte. Diese Transformation war nicht zufällig. Sie war bewusst gestaltet.
Nirgends ist diese Governance-Lücke deutlicher als im Vertrieb. Industriekonzerne sind seit Jahrzehnten darauf getrimmt, Hardware und Embedded Software in Capex-getriebenen, projektbasierten Modellen zu verkaufen — aufbauend auf technischer Glaubwürdigkeit und Nähe zum Engineering. Software as a Service (SaaS) kehrt diese Logik um. Budgets wandern Richtung Opex, Vertriebszyklen werden kürzer, und Erfolg wird erst nach Vertragsabschluss über Adoption, Retention und Expansion gemessen. Wert muss in Geschäftsergebnissen beschrieben werden, nicht in Spezifikationen. Der Käufer sitzt sich häufig nicht mehr im Werk, sondern in der zentralen IT und Digitaler Transformation. SaaS einfach über bestehende Vertriebsorganisationen zu legen, ohne Anreize, Eigentümerschaft und Verantwortlichkeiten zu verändern, erzeugt Reibung, die kein Produkt der Welt „wegoptimieren“ kann. Was wie ein Technologieproblem aussieht, ist fast immer ein kommerzielles.
Diese Spannungen kulminieren letztlich in einer organisatorischen Frage, der kein Industrievorstand ausweichen kann: Soll Software das Kerngeschäft Hardware verstärken — oder soll sie selbst zum Kerngeschäft werden? Manche Unternehmen betten Software eng in die Divisionen ein, bewahren Kundennähe, begrenzen jedoch Skalierung und Geschwindigkeit. Andere schaffen zentrale Software-Einheiten mit unabhängiger Governance, gewinnen Fokus und Bewertungslogik, riskieren jedoch kulturelle Distanz. Keine dieser Entscheidungen ist per se richtig oder falsch. Doch die Entscheidung zu vermeiden, ist teuer.
Deshalb stehen Industriekonzerne trotz ähnlicher Rhetorik an sehr unterschiedlichen Punkten ihrer Softwaretransformation. Der Unterschied liegt nicht in technologischer Raffinesse, sondern darin, wie viel echte Autonomie eine Softwareeinheit erhalten hat: Entscheidungskompetenz, Kapitalallokationsmacht und ein eigenes Go-to-Market-Modell. Wo diese Voraussetzungen existieren, skaliert Software. Wo sie fehlen, bleibt sie durch Hardware-Logik begrenzt — unabhängig von Ambitionen.
Die aktuelle Begeisterung über künstliche Intelligenz droht denselben Fehler zu wiederholen. KI wird industrielle Digitalstrategien nicht retten, wenn Datenmodelle inkonsistent, Eigentümerschaft unklar und Anreize nicht zielgerichtet sind. KI verstärkt, was bereits vorhanden ist und ohne einen neuen Ordnungsrahmen beschleunigt sie Fragmentierung, statt sie aufzulösen.
Die nächste Phase industrieller Software wird daher nicht durch Plattformen, Clouds oder Algorithmen definiert werden. Sie wird durch Ordnungsrahmen und Steuerungsmechanismen definiert: Wer besitzt Softwarebudgets? Wer kontrolliert Roadmaps und Kapitalallokation? Wer trägt Verantwortung über den initialen Verkauf hinaus? Unternehmen, die diese Fragen explizit beantworten, können nachhaltige Softwaregeschäfte aufbauen. Unternehmen, die es nicht tun, werden weiterhin technologische Symptome diagnostizieren — und die organisatorischen Ursachen unangetastet lassen.
Die Zukunft industrieller Technologie wird nicht dadurch entschieden, wieviele Maschinen miteinander verbunden werden. Sie wird erst dann erreicht, wenn Firmen ihre Softwarestrategie mit organisatorischer Verantwortung verknüpfen.
No comments:
Post a Comment