Why is industrial software getting "smaller"?
Why is industrial software shifting from "big and comprehensive" to "small and specialized"? The 2026 Guidelines for "Small, Fast, Light, Precise" Digital Products signal that future software value lies not in feature count, but in solving one specific problem. Software can get smaller, yet industry know-how runs deeper. #IndustrialSoftware #DigitalTransformation #SmartManufacturing

In the past, selling industrial software meant telling everyone "I have everything"; now, some are starting to say: "I just solve this one problem."
This is not because industrial software has lost capability.
On the contrary, industrial software is becoming increasingly "specialised."
Why?
In the past, enterprises were used to buying a "big system."
MES, ERP, WMS, EAM…
They wanted production, quality, equipment, warehouse, and planning all bundled in.
But what SMEs truly lack is often not a system that "has everything."
Rather, it is a very specific problem that no one solves.
For example:
Equipment downtime is too high – why exactly?
Scheduling keeps changing – how to adjust quickly?
Quality data collection is too slow – can it be automated?
When exactly should tooling be replaced?
These are the problems enterprises are truly willing to pay to solve.
That is why in the recently released MIIT guideline – "Small, Fast, Light, Precise" Digital Products and Services Cultivation Guidelines (2026 Edition) – one direction is particularly worth attention:
Miniaturization.
It emphasises focusing on specific industry segments and core scenarios, avoiding the "big and comprehensive" accumulation of features.
Behind this is a shift in a very important logic of industrial software:
The value of software no longer depends on how many features it covers, but increasingly on how specific a problem it solves.
For example.
In the past, you might have sold:
"An MES covering production, quality, equipment, and warehouse."
In the future, you might sell:
"I specialise in solving tool management for machining companies."
Or even further:
"I don't sell tool management software – I help you reduce tool change costs."
At this point, you will notice that the software's boundary is becoming smaller, but the problem it solves is becoming deeper.
And why is this particularly worth attention now?
Because AI is further lowering the barrier to "small software."
Previously, building software for a niche scenario required a large team for development, configuration, implementation, and training.
Now AI can help with development, configuration, knowledge Q&A, and even enable users to operate the system directly through natural language.
This means:
"Industry small tools" that only big companies could afford to build in the past may become increasingly easy to productise in the future.
But there is a very critical question here.
If software becomes "small," does that mean simple functionality and low value?
On the contrary.
The truly valuable "small software" of the future may be:
small in function, deep in knowledge.
On the surface, it solves only one problem.
But behind it is the accumulated process knowledge, equipment knowledge, quality rules, management experience, and even AI models of the industry.
So a very interesting change may occur in industrial software:
the software's size is getting smaller, but the "industry knowledge" inside it is growing larger.
This is what makes "miniaturization" truly worth attention.
It is not simply cutting a few modules from a big system.
Rather, it is:
moving from "big and comprehensive software" to "deep and specialised industry capability."
And once software becomes smaller, the next question arises immediately:
If it still takes six months to implement, even the "smallest" software will feel too heavy for enterprises.
So the next keyword in "small, fast, light, precise" –
"fast" – may be even harder than "small."
To be continued in the next issue.