В рамках конкурса на кубок им. А.К. Гастева проводится и «конкурс проектов улучшений в рамках совершенствования производственной системы».
Я уже несколько лет выступаю членом жюри этого конкурса, а это означает, что раз в год мне приходится оценивать отчёты по проектам, представленным на конкурс. В работах, представленных на последнем конкурсе я заметил одну характерную ошибку, на которую и хотел бы указать как тем, кто планирует участвовать в будущих конкурсах, так и тем, кто работает над регламентом конкурса, так тем, кто просто когда-либо собирается делать отчеты по проектам.
Не знаю, почему так получается, но участники конкурса регулярно путали стадии анализа и решения проблем.
Примеры ошибок
Например, на слайде одного из участников можно было прочитать следующее:
Анализ текущего состояния.
Механизмы подачи ИДЕЙ в команде:
Мозговой штурм
Совещания
Посещение гембы
Кайдзен-предложения
Для выявления ПРИЧИН несоответствий целевому состоянию использовались:
VSM
Диаграммы Исикавы
Диаграммы Спагетти
5 почему?
Вообще, строго говоря, подача идей не относится к этапу анализа. Ведь что такое анализ? Это выяснение ситуации, попытка ответить на вопрос «что происходит?»
Набрасывать идеи, не разобравшись в ситуации, — это наша, я бы сказал, национальная традиция. Мы обычно думаем так: «а что тут разбираться, и так всё ясно: Пупкина наказать, дыру заткнуть, работать вдвое внимательнее»…
Другой конкурсант сделал обратную ошибку. Вот содержание его слайда:
4.2. Выработка решения
Решение проблем (фото диаграммы Исикавы)
Фотография рабочего времени (круговая диаграмма с разбивкой: полезное время, переналадка, дефекты, ожидания, транспортировка)
И диаграмма Исикавы и структура рабочего времени — это инструменты анализа исходной ситуации. Конечно же я знаю, что в ряде случаев диаграмму Исикавы используют для визуализации решений (так называемый CEDAC — Cause and Effect Diagram with Additional Cards), но это — не тот случай, на фото представлен только разбор ситуации.
Точно могу сказать, что проекты, выполненные в соответствии с методологией Шесть Сигм не страдают такими проблемами, т.к. в самой методологии чётко расписано — где что применяется и когда какой инструмент использовать.
Один из лишних корней проблемы
Я специально покопался в регламенте Кубка Гастева, чтобы понять, не скрываются ли причины таких ошибок в нем самом и обнаружил, что так и есть — авторы невольно подталкивают участников к совершению таких простых ошибок, ведь в одном из пунктов сказано, что информация в презентации проекта должна соответствовать критериям оценки проектов, и дальше, например, можно прочитать такой раздел:
3. Анализ текущего состояния
Каким приемом или методом пользовалась команда для определения причин несоответствий целевому состоянию?
Каким образом члены команды подавали идеи решения проблем и ликвидации и причин, например, мозговой штурм и т. д.?
Вот она, причина ошибки первой команды — еще в регламенте процесс подачи идей решений проблем почему-то поместили в раздел анализа текущего состояния. И «исполнительные отличники» в строгом соответствии с буквой регламента выполнили это требование.
Дальше можно увидеть следующий пассаж:
4. Выработка решения
Какие были приняты решения для устранения причин несоответствий?
Каким образом подготовлен план мероприятий?
Каким образом планировались ресурсы для реализации проекта?
Какие инструменты или методы использовались для достижения целевого состояния (VSM, ТРМ, SMED и др.)?
Какие процедуры или рабочие инструкции были изменены, как это повлияло на внутренних и/или внешних заказчиков?
Предпоследний вопрос, конечно, интересен, но правильнее было бы указать, с моей точки зрения, «Как выполнялся выбор инструментов и методов для достижения целевого состояния?» вместо перечисления самих инструментов и методов.
А последний вопрос снова относится не к тому разделу. Описание измененных процедур и рабочих инструкций, а так же описание воздействия этих изменений на закказчиков — это ли не описание результатов проекта, следующего по порядку раздела презентации?
Почему я назвал это «одним из лишних корней проблемы»? Да потому что и без путаницы в регламенте мы часто спешим и начинаем предлагать решения еще до завершения анализа. И даже лучшие в своей отрасли компании страдают этим. Поэтому стоит исправить регламент и сократить количество корней.
Анализ и выработка решения — это два разных процесса
Недавно Джим Вумек опубликовал статью о том, что профессионалы часто превращаются в «человека-ответ»: они пытаются придумать решение любой проблеме, даже раньше, чем проблема была сформулирована. В российской практике, среди менеджеров, большинство из которых имеют техническое образование, эта болезнь, мне кажется, еще более распространена, чем на западе. И излечиться от неё очень сложно.
Тем не менее я должен сказать это еще раз: нельзя предлагать решения (и я напоминаю об этом и себе тоже) до того, как стала ясна полная картина происходящего. И пока эта полнота не проявилась, изложение любых версий — преступно, т.к. это сбивает с толку: люди перестают собирать факты и переключаются на обсуждение правдоподобности предлагаемых версий, высказывают свои, и это окончательно хоронит анализ.
А что такое хороший анализ? Если мы имеем проблему в бизнесе, нам нужно раскрыть все составляющие этой проблемы. Для простоты можно взять 4М и прокопать каждый корешок на пять уровней вглубь, задавая и задвая вопросы «почему», проверяя и перепроверяя ответы на адекватность. Пять почему — это очень сложный метод, и сложен он именно потому, что «человеку-ответу» кажется, что уже и так всё ясно, что уже нет никаких «более глубоких смыслов», и что все проблемы лежат на поверхности… Однако это не так, я пытался показать это в подборке статей про пять почему.
