How a board should govern innovation it cannot predict (6/6)

Supervisory boards are designed to control risk, ensure accountability, and protect long term value. That logic works well for established businesses whose performance can be forecast and audited, the typical public company or private equity owned shop. 

Transformation initiatives are different. Their outcomes cannot be predicted, only managed probabilistically. 

When both activities are governed identically, boards unintentionally force management to either hide uncertainty or avoid it. Core governance expects reliable plans, budget adherence, and variance explanations. Venture activity produces evolving plans, changing strategy, and learning instead of predictability. So management adapts and presents exploration as execution which leads to late surprises, sudden write-offs, loss of trust. 

A board should never approve innovation projects. They cannot evaluate uncertain outcomes. Instead, they can evaluate whether uncertainty is being reduced responsibly and should ensure capital exposure is bounded, learning velocity is high, and escalation rules are clear. 

A board should only oversee three things:

1. Portfolio exposure
   How much capital is at risk simultaneously
   
   
2. Funding discipline
   Continuation only after evidence
   
   
3. Separation of logic
   Exploration metrics that are not mixed with operational KPIs
   
   

Board should never ever select ideas, approve technical directions, demand detailed forecasts, integrate ventures prematurely. These actions destroy optionality. 

But when governed correctly, downside is limited, upside remains uncapped, and management credibility increases. Transformation becomes auditable without becoming a foregone conclusion. 

No industrial company fails to transform because they lack ideas, talent, or technology. 

They fail because they apply operational governance to exploratory activities. 

Once the board governs uncertainty instead of trying to eliminate it, transformation stops being a gamble and becomes a managed asset class. 

Why industrial startups don't scale like software, and why that matters for corporate strategy (5/6)

Over the last decade, industrial companies have tried to adopt startup methods like agile teams, MVPs, incubator and venture units with the expectation that small teams could rapidly build scalable businesses, just like in software. Yet most industrial digital initiatives plateaued in the same place where successful pilots never became large businesses. The explanation is usually organizational. But the pattern is too consistent to be cultural. 

In SaaS, the sequence was to build product, find users, scale distribution and optimize economics. In industrial systems the sequence is to prove technical reliability in reality, integrate into operations, earn organization trust, and scale commercially. Applying the former to the latter leads to the stereotypical "pilot purgatory', and the product market fit only comes later. 

The Lean Startup thinking has popularized the concept of a minimum viable product. And in fact, the advent of LLMs, vibe coding and agents have made building software MVPs easier than ever. But an industrial MVP still requires safety acceptance, workflow integration, downtime risk, and operator trust. Learning cycles are constrained by operations, not coding speed and the experimentation bandwidth massively narrows. As opposed to software which scales with distribution, industrial solutions scale with deployment capacity from integrators, commissioning, change management, training, and liability acceptance.
Therefore growth is stepwise, not exponential.

Because risk reduces differently in industrial systems, stage gates must evaluate different evidence. Early stages must mitigate technical and operational risk, later stages market and commercial risk. 

Industrial transformation will not be driven by apps on top of factories. It will instead be driven by systems that cross the boundary between software and operations. And the highest value companies in the next industrial cycle will control operational feedback loops, not dashboards. 

Next article (6/6)

Board governance for industrial transformation - managing two business models inside one company.

How to run a corporate venture portfolio without becoming a venture capital firm (4/6)

Operational companies run on annual planning cycles. 

Venture building runs on learning cycles. 

Trying to manage the second with the first results in one of two predictable outcomes. Either the initiatives are frozen by planning, or they run outside governance entirely. 

The solution does not lie in creating a new department, but in implementing a different decision cadence that funds increasingly expensive questions

1. Technical feasibility
   
   
2. Real customer usage (-> viability)
   
   
3. Repeatable deployment (-> product market fit)
   
   
4. Scalable economics

Funding should not be a commitment to success belief, but a purchase of evidence. Capital should only be provided when uncertainty decreases. 

Most companies have steering committees, project reviews, and budget committees to evaluation progress against plan. In contrast, a venture forum evaluates risk versus evidence and is characterized as follows

• Frequent meetings (6-10 weeks)
  
  
• Very small group 
  
  
• Authority to stop initiatives
  
  
• No project ownership
  
  
• Compares initiatives against each other
  
  

This forum manages allocations, not execution. It is making kill decisions based on transparent stop conditions: 

• No repeatable customer usage
  
  
• No technical feasibility
  
  
• No economic faith
  

Because the conditions are agreed beforehand, stopping is not political. And the organization can celebrate disciplined termination more than heroic persistence. 

This requires a clear delineation of roles and responsibilities. Leadership controls the funding continuation, the strategic direction, and the portfolio size. The teams control the solution, the iterations and the learning speed. Corporate burden is reduced and outcomes are improved. 

The role of the executive changes from approving projects to continuously reallocating capital. 


All of this may sound like software venture building, but industrial initiatives behave differently:

• hardware dependencies
  
  
• pilot purgatory
  
  
• deployment friction
  
  
• long validation cycles
  
  

and so the operating model must adapt. 


Next article (5/6)

Why industrial ventures are structurally different from software - and why most corporate playbooks fail here 

Innovation culture doesn't exist - governance and incentives do (3/6)

When industrial innovation initiatives stall, the diagnosis is almost always cultural: risk aversion, silo thinking, lack of entrepreneurial mindset. 

This diagnosis is not wrong, and companies respond predictably by launching training programs, incubators, intrapreneurships, innovation days et cetera et cetera et cetera. And yet the same patterns reappear where promising initiatives expand too early, weak ones linger, and transformational ones rarely scale.

If behavior does not change after repeated cultural interventions, the cause is probably structural rather than psychological. Managers optimize for what is rewarded - approval, budget adherence, and avoiding visible failure - and thus produce optimistic forecasts, broad roadmaps and incremental proof. Clearly this is rational behavior, and the organization punishes the alternative. 

This governance creates a doom loop: An upfront business case plan is created with massive amounts of detail and the team commitments to such plan. But then the evidence contradicts the plan and the team is forced to defend rather than adapt. The funding continues to protect prior decisions, and terminations happen late and are expensive. It is the ultimate irony that nobody chose this insane path, but the governance enforced it. 

There is a better way. Instead of asking people to think like entrepreneurs, the corporation should adopt a system with three mechanisms which reward and entrepreneurial behavior:  

1. Mile stone funding focused on progress
   
   
2. Predefined kill criteria that make stopping a successful outcome
   
   
3. An independent decision forum to separate continuation decisions from project sponsors
   

An organization will always behave rationally within the rules it is given.
The leaderships job is not selecting ideas, it is designing decision environments.

Most companies understand they need a portfolio logic, but few understand how to operationalize it without losing control. 


Next article (4/6)

How to actually run a corporate venture portfolio

Every industrial company already runs a venture fund - just without the rules (2/6)

If innovation outcomes cannot be predicted upfront, funding decisions have to stop being project approvals and become probabilistic bets. At that moment, the management domain changes from operational planning to portfolio allocations. 

Yet most companies never acknowledge the transition. They still ask each initiative to justify itself individually, even though statistically only a minority of ventures will succeed. In this obviously paradoxical world, they demand certainty from activities whose economics are defined by uncertainty. 

In an industrial world, machines are expected to perform as planned. Variation is noise. Deviation is undesirable. Contrast that with new technology ventures where most create little to no value, and only very few lead to disproportionate outcomes. And if returns concentrate in very few successes, evaluating initiatives individually guarantees systematic underinvestment in winners and overinvestment in mediocrity. 

Projects are being evaluated by expected ROI, NPV and payback periods. Those metrics are appropriate when variance is small. But with high uncertainty, the expected value does not equal the average outcome and managers unintentionally end up favoring safe outcomes, resulting in incremental projects being passed and transformational ones being failed. 

Funding innovation outcomes requires a mental shift from funding initiatives to funding learning paths where capital is released to answer progressively expensive questions: 

1. Is it technically possible? 
   
   
2. Does anyone need it? 
   
   
3. Will they pay? 
   
   
4. Can it scale? 
   
   

Because success is concentrated, funding decision must compare options, not plans. Persistence without evidence of progress and customer traction destroys returns, killing projects early increases returns. The purpose of an innovation portfolio is not to avoid failure, but to make failure cheap enough so that success becomes more likely. 

Once innovation behaves like a portfolio, the organization needs new rules: 

• Who decides continuation? 
  
  
• When is stopping success? 
  
  
• How independent can the teams be? 
  
  
• What replaces annual budgets?

Those questions are governance questions, not innovation questions.


Next article (3/6)

Why culture programs fail and governance determines behaviors
 

Digital initiatives don’t fail — capital allocation does (1/6)

Industrial innovation companies have more innovation activity than ever - accelerators, labs, venture arms, partnerships - yet the economic impact remains marginal. Yet, years later, most executives struggle to point to measurable impact on growth or valuation. 

The usual explanations are cultural: risk aversion, legacy thinking, slow decision making. But those explanations don't survive scrutiny. The same organizations successfully execute billion dollar plant expansions and platform transitions. 

The real difference is more mundane: Industrial innovation inside corporations is financed like a product development program, economically is behaves like a venture investment. And it is this very mismatch that determines the outcome long before the technology reaches maturity. 


The vast majority of executives are being told they are running a portfolio, but in reality they are managing a bunch of projects and apply a project logic consisting of fixed budgets and predefined deliverables where success is measured against plan and deviations are branded as failures. Often corporate innovation projects are expected to prove they work even before funding.

Venture logic of staged capital, frequent pivots, and unknown outcomes is fundamentally different where success is measured by learning and termination is success if risk is removed. The ventures are funded to discover whether something works.

The symptoms are only to well known and are directly related to the lack of stage gates and kill criteria. Because companies require certainty upfront, business cases are inflated, teams optimize for approval and not truth, cancellations get pushed off, and scaling happens either too later or never. 

The most common questions I have encountered is "how do we make innovation succeed in my company?".

The better question would be "how should we govern investments with unknown outcomes"?

What Industrial Leaders Should Do Now About Humanoid Robots

In the recent interview Elon Musk gave on the Cheeky Pint + Dwarkesh podcast, he laid out the path forward for Tesla’s Optimus humanoid robot. 

That path also translates into five practical implications for industrial leaders who want to utilize humanoids

• First, map your 24/7 tasks.
  Humanoids will enter where operations are continuous, repetitive, and stable. Start where uptime matters and variability is low.
  
  

• Second, identify hand-complexity tasks.
  If a job requires dexterity but limited judgment, it is a prime candidate. Fine manipulation without deep contextual reasoning is the early sweet spot.
  
  

• Third, redesign future lines to be robot-friendly.
  Clearances, modular stations, standardized interfaces, digital twins. The factories that win will not retrofit blindly; they will architect for humanoid coexistence.
  
  

• Fourth, invest in simulation capability.
  Sim-to-real transfer is the gating constraint. Organizations that build internal simulation pipelines now will compress deployment cycles later.
  
  

• Fifth, secure exposure to critical components.
  Actuators, precision gears, motors, rare materials. Manufacturing scale — not AI demos — will determine who ramps first.

Points one, two, and three squarely fall into the hands of industrial leaders.
Point five is a selection criterion for their humanoid robotics providers.

The hardest problem for humanoids to be fully adopted is closing the sim-to-real gap and the scale required.

Musk was explicit about the magnitude of that challenge:

“For the robot, what we’re going to need to do is build a lot of robots and put them in a kind of Optimus Academy so they can do self-play in reality… We can have at least 10,000 Optimus robots, maybe 20–30,000, that are doing self-play and testing different tasks.”

Industrial leaders should ask themselves now: Which of our production systems are humanoid-ready - and which ones are structurally not?

Three challenges for robotics founders

Recently, Elon Musk gave a wide ranging interview in the Cheeky Pint + Dwarkesh podcast where they covered all activities Musk is involved is.

Musk gave a master class on how he is constantly addressing the limiting factor and allocating his time to it, and applied this thinking to identify three main challenges for humanoids: 

1. Real-world Intelligence

Robots must convert massive sensor input into reliable physical action. Teslas already compress gigabytes of perception into a few kilobytes of control, but robots face far higher degrees of freedom, far less data, and far less safe data collection. The bottleneck is building a repeatable learning look that closes the sim-to-real gap. 

2. Hand gripper

Dexterous interaction with the physical world requires actuators, sensing, power density, and controls that currently have no mature supply chain. This is a first-principles engineering problem, not a software abstraction layer. 

3. Manufacturing at scale

A working prototype proves feasibility, but it takes millions of unites to create a category. The constraints shift from AI capability to cost, reliability, and year. Most robotics companies still operated in R&D mode while describing mass markets. 


The first viable markets will not be general labor or households. They will be high utilization, continuous  and repetitive operations in environments designed around competition. 

Musk has a plethora of assets at his disposal which the typical startup founder doesn't. 

Founders in the robotics space need to be ruthless about prioritizing their use case and apply Musk's key principles of challenging all assumptions, deleting what is not necessary, avoiding overthinking and simplifying as much as possible while reasoning at the right risk level, accelerating using 50th percentile deadlines, and then automating to scale. 

Software Portfolio Playbook: How Industrial Companies Can Turn Digital Ambition into Scalable Businesses

For more than a decade, industrial companies have pursued the same ambition: to become serious software players. Some have made real progress. Many have not.

The pattern is clear: software outcomes are not primarily determined by technology choices. They are determined by portfolio governance—how decisions are made, how resources move, and where accountability sits.

 

The core mistake is treating software as a collection of initiatives. The companies that win treat software as a portfolio—a set of fundamentally different businesses, each requiring different operating models, metrics, and leadership attention. Because disruption does not replace the old business overnight; it forces enterprises to run multiple business logics simultaneously.

Why a portfolio playbook is now essential

The most useful starting point is the concept of technology lifecycle zones—popularized through several management frameworks (including BCG and Geoffrey Moore’s “Zone to Win”). The specifics differ, but the management implication is consistent: leaders must actively govern four distinct zones in parallel, each with its own mandate and success measures .

In practice, these zones typically include some version of

• Protect the core (where cash is generated)

• Manage the base business (where efficiency and resilience matter)

• Fuel growth to scale (where new software engines are built)

• Incubate future options (where learning and experimentation dominate)

This is not a semantic exercise. The purpose is to enable what industrial organizations often struggle to do: prioritize go-to-market resources and engineering capacity across competing demands .

Without an explicit portfolio view, resource allocation becomes path-dependent and political. With it, trade-offs become visible and executable.

The CEO’s job: make the big bet and arbitrate across zones

A credible portfolio playbook ultimately is a CEO responsibility. The CEO must place the big bet on the next growth engine—what “fuel growth to scale” means in that enterprise—and continually arbitrate between the zones as evidence evolves.

This arbitration cannot be delegated to the technology function alone. The center of gravity is not architectural, it is commercial. Software scale requires decisions about

• where to invest and where to stop

• which businesses merit priority access to distribution

• which initiatives are strategic, versus merely interesting

• how much risk the enterprise is willing to carry

The strongest operators institutionalize this discipline by having the CEO and CFO set funding envelopes annually across the zones and adjust them through a lightweight corporate system—rather than trying to “align” continuously through discussions that lack decision rights. 

Portfolio management rationale: turning strategy into execution

Portfolio management exists for one reason: to connect strategy to capital and accountability.
Every material investment is explicitly linked to a strategic initiative. This eliminates the common pattern of “digital projects” that are directionally plausible but strategically unowned.

A strong portfolio system delivers three outcomes

1. Align strategy and investments
   
   

2. Convert strategic objectives into execution
   Strategy becomes measurable actions. Leaders gain mechanisms to challenge, re-prioritize, and re-allocate.
   
   

3. Create transparency and discipline
   Category leaders are held accountable, and the portfolio view becomes visible across the organization, reducing the ability to hide behind narratives.

This requires managing across three horizons: a multi-year strategic view, an annual resource allocation cycle, and quarterly reviews. This sequencing matters. Multi-year direction without annual resource allocation becomes aspiration. Annual allocation without quarterly learning becomes rigidity.

What separates mature portfolio management from periodic planning is fact-based discipline. Funding decisions are tied to capability needs, competitor moves, and risk—not to organizational persuasion.

Decision rights: the missing operating system

Most portfolio systems fail because they are treated as a governance overlay. In reality, portfolio management is a decision system. Without explicit decision rights, it becomes performance theater.

A scalable portfolio model establishes three clear roles:

1) Corporate Portfolio Office

This is not a reporting team but an empowered function that can

• move resources between categories

• apply consistent planning processes

• enforce transparency across business units

The office is the institutional memory of the portfolio and prevents the common industrial pattern of “starting over” every cycle.

2) Executive Committee / CFO

This level must:

• arbitrate major reallocations

• set the funding envelopes

• ensure adherence to strategy

In practice, the CFO is often the pivotal actor, because portfolio discipline ultimately requires willingness to stop funding initiatives that have political support but weak evidence.

3) Category leaders

These leaders carry P&L responsibility and must deliver results within the allocation. They own the outcomes.

Critically, decision rights must operate at three levels

• Corporate level: align to strategy, balance risk/return, ensure coherence

• Category level: own performance, KPIs, and category health

• Business case level: validate assumptions, challenge resource use, monitor delivery

This multi-level structure matters because industrial software businesses often fail not at the strategy level, but at the point where execution assumptions—pricing, sales productivity, adoption dynamics—turn out to be wrong and no governance mechanism exists to correct course.

The anchor tool: a proprietary 2x2 matrix

Industrial groups often drown in complexity: dozens of products, overlapping roadmaps, and competing internal narratives. The portfolio needs an anchor.

The most effective tool is a proprietary 2x2 matrix based on market attractiveness versus relative strength, institutionalized as the backbone of investment decisions .

This matrix does not create insight by itself. It creates forcing function clarity:

• Where should we invest aggressively?

• Where should we harvest?

• Where should we fix underlying capabilities?

• Where should we exit?

The key is to make the matrix proprietary—not because the idea is novel, but because each industrial group must define “attractiveness” and “strength” in a way that reflects its economic realities: installed base leverage, channel access, data advantage, ecosystem power, and regulatory constraints.

Stop the “portfolio vs. non-portfolio” split

A surprisingly common failure mode is treating portfolio discipline as optional—applied to “strategic initiatives,” while other R&D runs independently.

The playbook is explicit: no split between “portfolio-relevant” and “non-portfolio” R&D. Everything must run through the same governance lens .

This isn’t control for control’s sake. It prevents the quiet accumulation of unowned products, orphaned prototypes, and “pet projects” that create complexity without compounding advantage.

Speed becomes structural: Agile, DevOps, and enabling architecture

Portfolio governance is not enough. Execution speed must be engineered into the operating system.

The best-practice baseline includes embedding Agile and DevOps as default delivery models, and enabling speed through microservices, cloud, low-code platforms, and AI where appropriate .
The point is not to chase the latest buzzwords. It is to ensure that the portfolio can reallocate resources without being trapped by monoliths, fragile release processes, and dependency lock-in. A portfolio that cannot shift capacity rapidly is not a portfolio. It is a collection of sunk costs.

Make learning travel across businesses

Industrial enterprises often behave like federations of disconnected companies. Portfolio management creates economic logic across them—but learning still tends to stay local.

The playbook demands explicit learning transfer: practices proven in one category must cascade to others. This can be:

• agile practices from a software unit into hardware-adjacent teams

• predictive maintenance capabilities moving from one business line to another

• repeatable sales plays scaling across regions

Cross-business learning is one of the few genuine scale advantages industrial groups can have. It rarely happens organically.

What to measure: portfolio health KPIs

Without the right metrics, portfolio management devolves into narrative competition. The playbook therefore defines portfolio health through a small, decision-oriented KPI set :

• Strategic alignment: % of spend linked to top priorities

• Balance: allocation across protect / fuel / manage / incubate

• Capital efficiency: return on invested capital by category

• Speed and agility: cycle time for reallocating resources

• Innovation vitality: % of revenue from products <3 years old

• Transparency: quality of reporting and visibility across units

These KPIs have a single purpose: enabling executives to act. They are not dashboards for dashboards’ sake. They support reallocation, exit decisions, and focus.

The industrial reality: multi-BU software fragmentation is normal

In most multi-BU industrial technology companies, software is present everywhere—and rarely coherent. The majority of software activity and acquisitions often sit within a single BU, sales is executed regionally with overlays, and only a subset of companies attempt cross-BU platforms .

This is not a failure of intent. It is a predictable outcome of vertical accountability. Portfolio governance is the mechanism that turns this fragmentation into manageable structure.

Some companies have taken clearer strategic steps, for example by committing to standalone software businesses (such as Schneider Electric with AVEVA) or establishing dedicated digital units (as in GE Vernova’s digital BU heritage) . The common thread is not the brand name; it is the willingness to assign real operating autonomy and P&L logic to software.

A final question CEOs and CFOs cannot avoid

Portfolio playbooks are ultimately designed to force one unavoidable leadership choice:

Should software amplify the core business—or become a core business?

There is no universal answer. But there is a universal cost to avoidance. Companies that do not decide remain trapped in a hybrid model where software carries the expectations of growth but inherits the constraints of hardware governance.

In an era where AI is accelerating competitive cycles and compressing differentiation, this becomes existential. The next phase of industrial software will not be defined by platforms, clouds, or algorithms. It will be defined by governance: decision rights, capital allocation, accountability, and operating autonomy.

Software does not scale because it is strategically important.

It scales when it is structurally enabled to win.

Industrie 4.0 ist nicht an der Technologie gescheitert, sondern am Organisationrahmen

Seitdem es den Begriff Industrie 4.0 gibt verkünden Industriekonzerne ihre Absicht zu Softwareunternehmen zu werden. Digitalstrategien werden mit großer Überzeugung angekündigt, Milliarden investiert, Plattformen versprochen. Trotzdem sind die Fortschritte weitestgehend ausgeblieben. Viele Initiativen sind ins Stocken geraten, sind aufgesplittert worden oder stillschweigend umbenannt. Die üblichen Erklärungen machen die Technologie zum Schuldigen: nicht ausgereifte Plattformen, Legacy-IT, Kunden, die digitale Nachzügler sind, oder Künstliche Intelligenz, die den Erwartungen bislang nicht gerecht wird.

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.

Industrial Software Didn’t Fail. Industrial Governance Did.

For more than a decade, industrial groups have proclaimed their ambition to become software companies. Billions were invested, platforms were launched, and digital strategies announced with great conviction. Yet progress has been uneven. Many initiatives stalled, fractured, or quietly rebranded. The usual explanations point to technology: immature platforms, legacy IT, customers that were not ready, or AI that has yet to deliver. These explanations are comforting — and largely wrong.

The problem was never software. It was governance.

The first phase of industrial digitization was built around the idea of horizontal IIoT platforms. The vision was compelling: one universal layer to connect machines, data, applications, and customers across the enterprise. Large incumbents sought to replicate the scale economics of enterprise software in an industrial setting. What they underestimated was how deeply industrial organisations are structured around autonomous business units, each with its own architectures, incentives, pricing logic, and customer relationships. Integration was costly, adoption voluntary, and value creation diffuse. Platform teams optimised for architectural elegance while budgets and accountability remained resolutely vertical.

As economic and operational pressure mounted, this tension became impossible to ignore. Business units gravitated back to what they controlled and what customers were willing to pay for. They prioritised solutions tied to specific workflows, assets, and outcomes. The universal platform did not disappear, but it was re-scoped. In many cases it became an integration backbone or architectural framework — necessary infrastructure, but no longer the growth engine it was once imagined to be.

Value creation moved upward, closer to business ownership. Vertical software — manufacturing execution, asset performance management, simulation, digital twins, and optimisation — began to attract real budgets and executive attention. Not because it was more sophisticated, but because it aligned with how industrial customers buy, govern, and measure value. The IIoT platform vision did not fail. It collided with organisational realities it was never designed to overcome.

The industrial groups that made the most progress recognised this early and responded not with better technology, but with better structure. Instead of forcing software to mature inside hardware-dominated organisations, they separated governance while preserving domain depth. Software assets were consolidated, given independent operating models, and allowed to scale with their own P&Ls, talent strategies, and market narratives. Only once these capabilities had matured were they reintegrated — not as experimental add-ons, but as credible businesses. The transformation was not organic. It was deliberate.

Nowhere is the governance gap more visible than in sales. Industrial companies excel at selling hardware and embedded software through capex-driven, project-based models built on engineering credibility. SaaS inverts this logic. Budgets shift to opex, sales cycles shorten, and success is measured after the contract is signed through adoption, retention, and expansion. Value must be articulated in business outcomes, not specifications. The economic buyer often moves from the plant to central IT or digital leadership. Overlaying SaaS onto legacy sales organizations without changing incentives, ownership, and accountability creates friction that no amount of product quality can resolve. What looks like a technology problem is almost always a commercial one.

These tensions ultimately surface as an organisational question that no industrial leader can avoid: should software amplify the core hardware business, or should it become a core business in its own right? Some companies embed software tightly within divisions, preserving proximity to customers but limiting scale and speed. Others establish corporate software units with independent governance, enabling focus and valuation clarity at the risk of cultural distance. Still others keep software fully embedded, optimising execution while constraining growth. None of these choices is inherently right or wrong. But avoiding the choice altogether is costly.

This is why industrial leaders, despite similar rhetoric, occupy very different positions on the software transformation journey. The differentiator is not technological sophistication, but the degree to which software has been granted real autonomy: decision rights, capital allocation authority, and a distinct go-to-market model. Where these conditions exist, software scales. Where they do not, it remains constrained by hardware logic, regardless of ambition.

The current enthusiasm around artificial intelligence risks repeating the same mistake. AI will not rescue industrial digital strategies that lack coherent data models, clear ownership, and aligned incentives. AI amplifies what already exists. Without governance, it accelerates fragmentation rather than resolving it. Industrial companies do not have an AI problem. They have a data and decision-rights problem.

The next phase of industrial software will therefore not be defined by platforms, clouds, or algorithms. It will be defined by governance. Who owns software P&Ls. Who controls roadmaps and capital allocation. Who carries accountability beyond the initial sale. Companies that address these questions explicitly will build durable software businesses. Those that do not will continue to diagnose technological symptoms while leaving organizational causes untouched.

The future of industrial technology will not be built by connecting more machines. It will be built by connecting software strategy to organizational power.