When starting KAIZEN, it is essential to look at the current situation.
Even if you ask, "It's just as it is." "Let's make it visible as it is."
If you look at the finished product, you may already have Kaizen added.
Most people who challenge Kaizen for the first time will come in from countermeasures.
If you have kaizen sense, you may come up with a pretty good measure, so
I'm just saying, "What should I do ?!"
Please wait for a little.
I admit that what your unconscious quickly searched for your memories and came up with is doing a pretty good line.
But if you happen to take the measures you think of, will the problem be solved entirely?
Often, these proposals overlook something important.
It's safe to say that almost something is leaking.
Those who have mastered the standard of improvement and have solved many problems will work unconsciously to reach the correct answer.
The memory of solving many KAIZEN cases is accumulated in the brain, and I have a way of thinking to see those cases from a higher level of abstraction so that I can do that.
I'm not saying everyone, but there is something biased in the opinions of those who have little experience.
After all, I think that it is unavoidable that the countermeasure plan will be biased because the accumulation of cases based on experience is minor.
I remember having done a lot of development and design work from the manufacturing site, so even when working on a new improvement theme, I habitually look at the concept one level higher.
First, let's look at the significance of the work and the added value of the work.
Then, once you see the process of adding value to your work, try to eliminate other non-value-added processes as much as possible.
With that in mind, an improvement policy comes to mind.
Eliminate redo
Manufacturing eliminates processes that don't change things
Eliminate processes where information does not change even in development and design
The policy is decided almost instantly.
I haven't observed the target work in detail, so it is impossible to decide everything by itself. I may have something overlooked.
Therefore, even if you can confidently say, "I have a sense of KAIZEN," keep in mind the KAIZEN standard and proceed.
To that end, let's start steadily by "visualising the current state of affairs."
We use the word "take a table" to visualise the current situation from the TPS Kaizen method.
Table example
The word "table" is used because it means "to show the current state as it is".
In addition, we will standardise the end of Kaizen. Specifically, rewriting the standard document is to finish and stop KAIZEN.
If the end of KAIZEN is "standard", then the beginning is "table" after that.
When reading aloud, both "standard" and "table" become "leopards".
The table is read as "front leopard" to distinguish it from the standard "leopard".
I can say that it is as important as giving a name to the process of visualisation of the current situation.
The figure above is an example of the table.
It expresses the flow of time (horizontal axis) and related departments (vertical axis) from when a salesperson receives an order from a customer for a particular machine. Then, the design is customised, the parts are arranged, and the product is manufactured and delivered.
There are many other styles of the table.
Another way to visualise the conversation is to transcribe the recording.
It is also a table.
We often use a "Flowchart of Things and Information" tool in TPS.
I created the above figure for Kaizen before, and after the manufacturing process, so the manufacturing process is simplified, and the flow of information is visualised in detail.
There is a method called agile in software development, but I use a tool called "value stream mapping".
It started when the LEAN people developed the "flow chart of things and information" under "value stream mapping".
From LEAN PRODUCTION SYSTEM, through LEAN PRODUCT DEVELOPMENT, it is connected to agile.
Kanban and large rooms are connected to Agile by the same route.
You can visualise. The connection of processes without exception by following the flow of information.
上の図は、
「お子さんのいらっしゃる家族の喜ぶ姿」という情報を、開発者の脳にインプット
開発者の脳にある知見が、付け加えられて、新製品が完成するというイメージです。
実際は、多くの担当者の知見が集まって、製品図面が完成するわけです。
このプロセスの流れを、抽象度を上げて見ると、
インプット情報とアウトプット情報の差の部分が、開発者の頭にある情報だということがわかります。
このプロセスを、開発者本人に書いてもらうと、本人が当たり前にわかっている知見が、漏れてしまうことがあります。
製造でも、表どりをするときに、ストップウォッチを片手に、作業者の動作を観察して表準を作成します。
動作に付加価値があるかどうかを見る目を持っているか否かで、出来上がりも違ってきます。
一言で、「現状のありのままを見える化する」と言っても、なかなか難しいものです。
そのプロセスをパスして、思いつきの対策を先に考えてしまうのでは、本物のカイゼンにはたどり着くことはできません。😎