Many business leaders ask me if they need to send people to learn a whole new set of technical skills before using AI. My observation is that most companies actually don't lack this foundation. The management knowledge you have accumulated from managing people, processes, and quality can be translated into methods for managing AI. This article uses the manufacturing-oriented Toyota Production System (TPS) as an example to demonstrate how to translate a mature set of management knowledge into processes that AI can follow.
- Business leaders or managers evaluating whether to introduce AI, yet feeling that 'this is an engineer's job, I need to start from scratch'
- Already have experience managing people, processes, and quality, and want to know if this experience is still applicable when using AI
- Decision-makers who want to get their team to use AI, not just themselves
- A way of thinking that translates 'your existing management knowledge' into 'AI usable processes'
- A checklist you can follow to translate
- The first step to get started without needing to hire engineers or buy a bunch of systems
First, present the conclusion
You don't need to retrain yourself as an engineer to use AI. Managing AI is essentially an extension of organizational management. Your existing management knowledge is applicable, the difference being that in the past you managed people and machines, but now you also have to manage an additional object: AI.
First, condense the entire article's key points into a comparison table. On the left is the approach you are already familiar with in TPS and on the production line, and on the right is how the same thing can be implemented in an AI system. The rest of the article explains this table:
| TPS Approach | How to implement this in an AI system (in plain language) |
|---|---|
| Standardized operations include more than just a document. They also encompass step order, expected outputs, and rhythm. | A main rule file that both the team and AI follow, writing down the scope of work, steps, expected output, and unacceptable errors. I have a file called AGENTS, which all AI read from the same one |
| Automation, stopping when an anomaly occurs (the Andon cord is just one example of a on-site practice) | Set up an automatic checkpoint that intercepts errors, stopping AI immediately if it makes a mistake or performs a dangerous action, preventing errors from flowing to the next stage. I use a type of automatic script called Hook |
| Continuous improvement | Review after each task, writing down what was learned back into the main rule file, so that the same mistakes are made less and less |
| Standards are meant to be improved | The rule file is continuously overwritten by new experience, with old versions kept as a reference to see how the process has improved over time |
| Pass it on to others | Because all AI read the same rule file, once a change is made, all of them are updated at once, without having to explain it one by one |
What I have been doing in the past couple of years is essentially turning the judgments I have in my head, and the way I organize knowledge, into processes that AI can understand and run. This process has made me increasingly certain that training an AI employee is fundamentally similar to training a human employee
A hesitation many bosses have
I have met many operators, whose companies are running smoothly, but the first reaction when they hear about introducing AI is to step back. The reasons are usually similar: this sounds too technical, I don't know programming, do I need to send people to classes, hire someone who knows, or spend money on a system. Thinking about this, the matter is always postponed to 'talk about it later'
I can understand this hesitation. But I want to share my own experience: what often keeps people in place is the idea of treating AI as a completely unrelated new thing. Once you think this way, you feel like everything has to start from scratch. Technology becomes a secondary concern
In reality, if you have managed a team, led a production line, or monitored a quality process, the experience you have is exactly what is needed for introducing AI
I see it this way: managing AI relies on the foundation of organizational management
What do you do when you bring a new employee up to speed? Managing AI involves doing the same set of actions:
Tell them how to do it properly, where they can't make mistakes, what to do if they make a mistake, how to review and improve after completing the task, and then leave the good practices in place to teach the next person
Give the AI a clear standard, set where it cannot make mistakes, and when it does, it should stop. Let it run through one round, see the results, write down the issues back into the standard, and then let it run the next round.
The difference is that employees can absorb and judge on their own, and you only need to explain once for them to understand and apply it in different situations. AI needs you to explain it even more clearly and explicitly for it to understand. But this is exactly what managers are already good at: turning vague experience into standards that others can follow.
Therefore, I would say that introducing AI is really testing your organizational management foundation. This matter has less to do with whether you know how to write code than you might imagine.
Take Toyota TPS as an example
Toyota TPS stands for Toyota Production System, which is commonly translated as the Toyota Production System in Chinese. It has two main pillars: one is Just in Time (the right thing at the right time), and the other is Jidoka (letting machines and processes detect abnormalities themselves and stop immediately, incorporating quality into the process). This is the orthodox framework of TPS, and I will not cover it in one sentence.
In this article, I want to look at it from another perspective, that of knowledge management. From this perspective, TPS is not only about making production more efficient; it is more like a system that continuously discovers, verifies, standardizes, and passes on the experience at the site. Then it is improved again. I will say clearly that this is an interpretation, used to help you connect management knowledge to AI, and not to replace the original definition of TPS.
Generally, companies talk about knowledge management by asking: how to organize the things in employees' minds into a data repository. From the perspective of knowledge management, TPS asks another question: how to make every piece of work, every problem, and every improvement into knowledge that the whole company can reuse.
One is distilling employees, one is distilling one's own knowledge
After I have thought through the matter of TPS, it naturally corresponds to AI.
You take the master worker's feel, the best practices discovered on-site, and distill them into standard procedures, so that every employee can follow them, and the machine can run according to the settings. This is transforming employees' experience into organizational assets.
You distill your professional judgment and the way you organize things into a process that AI can understand, so that AI can follow it. This is transforming your own knowledge into organizational assets.
One is distilling employees, one is distilling one's own knowledge. One is letting the machines in the factory run automatically according to the standard, one is letting AI run according to the process you provide. The problems to be handled are actually very similar: how to turn good practices scattered in people's brains into a stable, repeatable, and ever-improving system.
Once you understand this, you will find that managing AI is not as unfamiliar as you might imagine. What you do is applying the management you already know to a new object.
How to translate a set of management knowledge into a process that AI can run
Speaking of this, let's look back at the initial comparison table: the TPS cycle, each cell corresponds to my own AI system. That table is trying to say that these mechanisms you already have on the production line and in management. You have standard procedures, quality inspection stop lines, continuous improvement, and handover. The difference is that these were previously for people and machines, now you need to make an additional one for AI.
Translation of the checklist: follow it step by step
If you want to try it yourself, I have compiled it into a table, which you can follow:
- First, choose a process you are most familiar with and that you will repeat frequently. Quoting, inspecting goods, writing weekly reports, and organizing meeting minutes can all be options.
- Write down the current best practices for this process and turn it into a standard. This step is distillation, and it is the most critical step. A sufficient standard should at least clearly explain several things: the scope of this work, where the inputs come from, how the steps proceed, what the expected output looks like, which errors are absolutely not allowed, and what situations require stopping and handing over to a person.
- Think clearly about where this process is most prone to errors, and set a checkpoint there, stopping if an error occurs.
- Let AI run through this standard and see the results it produces.
- Write down the issues found this time back into the standard, making the explanation clearer.
- Next time, or hand it over to the next colleague, and run it directly with the updated standard.
You will find that this logic is almost the same as the continuous improvement you do on the production line. You already know how to do it, just with a different target to practice on.
What this method guarantees and what it does not guarantee
I want to be honest and clear, so you won't have wrong expectations.
Not every management knowledge can be directly moved to AI. Those that can be directly moved are processes with clear steps, standards, and verifiable right or wrong, like quotation calculation, document organization, and data comparison. Those that require effort to adjust are highly dependent on interpersonal judgment, on-the-spot response, and unclarified tacit experience. These can also be done, but you need to first spend effort to explain them clearly, so that AI can take them in. This step cannot be faked. The clearer your judgment is, the clearer AI can help you achieve it.
The first step an enterprise can take
You don't need to introduce the entire system at the beginning, nor do you need to hire an AI team first. The first step can be small.
Pick a high-frequency, repetitive, and relatively clear process, and let one colleague try it first. Write out the standard for this process and let AI run through it once.
Find a colleague who is familiar with this process to verify: whether AI followed the standard and where it couldn't proceed. If you are confident enough to use the result directly, it's considered passed.
If you're still not ready to use it, it's usually because the standard hasn't been written clearly enough. Clarify it and run another round. Once this small cycle runs smoothly, you are already using the spirit of TPS to manage AI.
I want to emphasize one thing at the end. The few hours saved this month are an added benefit of this matter. What will truly stay in the company is the process, judgment, and standards you gradually turn into reusable knowledge assets. People will leave, machines will be replaced, but this knowledge, once organized and taken in by AI, will remain in the company and get thicker with use. This is what I think is most worth investing in.
Further Reading
If you want to look further at two things:
I designed the process of 'improving and updating standards repeatedly' as a workflow that can be run repeatedly. This article doesn't involve coding; it explains clearly what Loop Engineering is.
The action of 'distilling the best practices into standards' can eventually be made into a skill package that AI can repeat. This article explains how to do that.