Зачем нам социогеномика

Зачем изучать социогеномику

Семинар по орг-импрувменту в Академгородке

Директорский форум в Академгородке

Блог для практиков управления изменениями

Анатолий Вассерман: Как

отличить правду от лжи

Как отличить правду от лжи

ТРИЗ Альтшуллера

ТРИЗ Альтшуллера

Джон Шук. Послание июня 2012: Visual Management – the Good, the Bad, and the Ugly
Статьи - Lean Production
Written by Джон Шук   
Thursday, 16 August 2012 12:59

Visualization is a good thing. We all know that. And many of us in the Lean Community practice it, to greater or lesser degrees of effectiveness. Among other benefits, making visible such things (see examples below) as pace or quality of work makes it easier to solve problems and sustain gains. To quote Dr. Thoralf Sundt of Mayo Clinic, "If I can see it, I can fix it."  The reverse must also be true – it's hard to fix what you can't see. This past month I ran across three examples of visualization – good, bad, and ugly – to share with you.

The Good

The first case involved a young woman doing a quality check at the end of an assembly line of electromechanical components. For two years she had been collecting the same quality information. Performing a series of checks, she would confirm that all connectors were firmly attached, components all assembled and in working order. As she found problems, she recorded them into a computer database, which was then compiled into a larger database. The database was reviewed, analyzed, and results fed back to the production group and others.

Like this:


There was no direct connection between the workers making the errors and the inspector finding the errors, and the information that was eventually shared followed a long and irregular time line. Management began looking at the situation because of a perceived "lack of motivation" in the workers and inspectors. As plant management explored various means of increasing worker engagement and motivation, a quality engineer noticed the disconnect between the workers and feedback on their performance. Problems that could have been fixed right away took days and weeks to even surface, and the time required for errors to be corrected could take much longer. The engineer wanted to fix his technical problem.

Материал доступен членам профессионального сообщества специалистов по развитию - Международной Гильдии Лидеров Перемен.

или познакомиться с документами Гильдии и  Зарегистрироваться