Recently, while improving our factory systems, we ran into a simple problem.
The machine was still operating normally, but data that should have reached the computer suddenly stopped coming in.
Between the machine and the computer, the data passes through several points. The problem could have been a cable, a small device in between, or the computer itself.
But our original system told us only one thing:
That meant we did not know where to start checking.
After solving the problem, we kept four lessons from the experience.
1｜AI helps, but someone still needs to own the work
AI can help write code, look for problems, and organize information. It saves a lot of time.
But once you actually build and use a system, you still run into situations that only appear in real operation.
For example, we originally designed the system to open only after the data was received correctly. The idea sounded reasonable. But when something failed, the screen would not open, so we could not see which part had failed.
That kind of problem is difficult to predict until it actually happens.
If a company wants to keep improving its technology over time, someone needs clear responsibility for testing, making changes, and recording what has been learned. Otherwise every equipment problem, system change, and data issue ends up competing with other important work.
2｜Keep a spare when the part is cheap but important
During this problem, we bought a new replacement part and used it for testing.
At first, we did not know whether the original part was faulty or whether the problem was somewhere else. Having a known-good replacement immediately removed one possibility.
If you are not sure whether the bulb is bad, the fastest test is often to replace it with a bulb you know works.
For inexpensive parts that can affect an entire system, keeping one spare can be worthwhile.
A spare is not only for replacement. It can also help diagnose a problem.
3｜Do not just say “something is broken”
Our old system treated many different failures in the same way:
That message does not help much when you need to find the cause.
A warning that only says “car problem” is not enough. You need to know whether the issue is fuel, the battery, or something else.
We changed the system so the screen can still open when one part has a problem. It can then show which parts are working and where the data stopped.
The same idea applies outside technology.
If an order is late, simply showing “order delayed” is not very useful. It is much more useful to know whether material has not arrived, a machine has stopped, production is unfinished, or the company is waiting for customer confirmation.
Every important step should have its own clear warning.
4｜Do not investigate the same problem from zero every time
It is normal to spend time finding the cause the first time a new problem appears.
But once the cause is known, that lesson should be added back into the system.
In this case, we used to check only whether the equipment could be detected. We later learned something important:
So the next version should check those two conditions separately.
If the same issue happens again, the system can narrow down the problem before anyone starts checking everything from the beginning.
A useful report does not simply say “something is wrong.” Different results help narrow down where the problem may be.
The failure itself was small, but it changed how we think about technology improvement:
- Give someone clear ownership.
- Keep simple spare parts for critical points.
- Show errors separately instead of hiding them behind one failure message.
- Add lessons from real problems back into the system.
The goal is simple: the next time the same problem happens, we should not have to start from the first step again.
RUIJI keeps turning factory experience into repeatable methods
From equipment and workflow to management, we continue to document real problems so the next response can be faster and clearer.
Read more insightsAbout RUIJI