Right after the National Day holiday, a real-world test video took the automotive world by storm. Dongchedi took three brand-new Zunjie V800s to a closed test track for consecutive emergency braking tests at 100 km/h. As a result, the brake pedal brackets on all three cars broke one after another: the first broke during its third hard braking, the second during its fourth, and the third during only its second. Once the pedal broke, the foot brake failed completely, and the test driver had to bring the car to a stop using Park. Later, Zunjie issued a statement saying that the braking system itself had been validated to requirements higher than national and industry standards, but acknowledged that it would optimize the brake pedal bracket design and provide free upgrades for customers who had already taken delivery.
The boundaries of the test are open to discussion. But what is truly worth pondering in this matter is not whether a particular test was harsh, but what our eyes tend to be drawn to when we look at a car or a system. We are easily drawn to “visible features,” yet prone to overlook whether the “invisible structure” is sturdy enough.
A Car’s “Face” and “Inner Substance”
When people look at a million-yuan-class MPV, what do they look at? Zero-gravity seats, rear-seat entertainment screens, air suspension, Huawei intelligent driving. These features are listed on the spec sheet and can be felt as soon as you sit inside—that is the “face.” In contrast, the metal thickness of the brake pedal bracket, the welding process, and fatigue strength under extreme conditions belong to the “inner substance,” which you may not even be able to see even if you take the car apart.
The face determines whether you buy it; the inner substance determines whether you can survive when something goes wrong. This logic applies almost identically to the industrial software industry.
What Is the “Brake Pedal” of Industrial Software?
Over the years, Gongzhidao has worked with many IT heads at chemical companies and has noticed a very typical phenomenon: when selecting systems, what everyone cares about most is “Are the functions complete?” “Is there an XX module?” “Can it integrate with XX system?”—they take a long feature checklist and tick items off one by one, and whoever ticks the most boxes wins the bid.
But few people ask:
-
At what level of concurrency will the system crash?
-
When the network goes down, can on-site operations still follow the process normally?
-
When the data volume grows large, will queries become so slow they are unusable?
-
During upgrades and iterations, will historical data be lost?
-
Under abnormal scenarios, does the system “degrade gracefully” or “simply go down” ?
These questions are like a car’s brake pedal bracket. You normally do not feel its existence, but once it fails at a critical moment, the cost is an accident, a production shutdown, or liability.
What the Chemical Industry Demands of Software
If consumer-grade software crashes, you can just restart it, and the worst that happens is a couple of complaints from users. But systems in the chemical industry are different.
If a hot work permit approval system gets stuck during peak approval periods, on-site work permits cannot be issued, and maintenance progress has to be delayed. If an equipment inspection system cannot upload data because of an unstable network, hidden hazards may be missed. If a safety monitoring platform goes down under abnormal operating conditions, operators cannot even see reference information.
Features are for adding the icing on the cake; reliability is for providing the backstop. Especially in a high-safety-risk industry like chemicals, the “lower limit” of a system matters far more than its “upper limit.” No matter how rich the features are, if the system fails at a critical moment, all those features amount to zero.
This is also why, even after many companies have deployed MES and EHS systems, frontline workers still prefer pen and paper. It is not that the systems lack features, but that they are not stable enough, fast enough, or rugged enough, so frontline users do not trust them.
When Selecting a System, Ask a Few More Questions Beyond the Feature List
The Zunjie incident serves as a reminder for all digitalization projects: system selection cannot only look at “what it has,” but also at “whether it can hold up.”
Gongzhidao suggests that when evaluating industrial software, chemical companies should ask a few more “inner substance” questions beyond the feature list:
1.Ask about performance under extreme conditions.
Don’t ask “Can it run under normal conditions?” Ask “What happens when the network goes down?” “What happens when concurrency spikes?” “What happens when data volume grows large?” A vendor confident in its product will proactively tell you how its system is designed for edge scenarios.
2.Look at how long real customers have used it.
A demo is always perfect. Find a customer who has used the system for two or three years and ask them whether it is stable, what failures have occurred, and how quickly the vendor responds—this is more useful than ten slide decks.
3.Distinguish “feature-rich” from “reliable in critical functions.”
A system with 50 features, each half-baked, is worse than one with 20 core features done solidly. Chemical companies do not need “big and comprehensive”; they need “no breakdowns at critical points.”
4.Look at the history of iteration and maintenance.
Software is not finished just because it has been delivered. Look at how many bugs the vendor has fixed over the past few years, how many versions it has released, and whether it has been complained about by customers because of major failures—the ability to continuously refine is more important than the number of features delivered at once.
The Zunjie brake pedal incident is essentially not a question of whether standards are sufficient, but a question of whether awareness is sufficient. When all competition is focused on comparing configurations, features, and specs, few people turn back to examine whether the most basic bracket is sturdy enough.
The industrial software industry is the same. While “whose AI features are more numerous,” “whose modules are more complete,” and “whose concepts are newer” are tempting, what is more important to consider is: after group-wide deployment, as data volumes grow, can the system withstand the pressure? At plant sites with poor network signals, can processes still run through? During peak periods of batch operations, will approvals get stuck? Features determine whether a system is easy to use; reliability determines whether a system can be trusted.
And on the path of chemical industry digitalization, what ultimately matters is not a “beautiful-looking” feature list, but stable and reliable execution day after day, every time. Like a brake pedal: you do not notice it normally, but every time you press it, it must be there. In our years of doing chemical industry digitalization, we have become increasingly convinced: when choosing a system, do not just look at what it “can do,” but more importantly at whether it “can hold up.” If you are also selecting a system, we welcome you to talk with us about the questions beyond the feature list.
