Print 9.35 pt 9.35 pt

Цикл "Шесть Сигм, с чем его едят". Статья №10. Алгоритм DMAIC. Шаг MEASURE. Часть 3..

Автор: Антон Анферов
13 февраля в 11:14

Допустим, вы прошли предыдущий шаг проверки измерительной системы.

Дальше у вас есть уникальная возможность доверять получаемым данным, и самое время заняться определением, а где вы есть, и, что более важно, а куда стоит идти и что улучшать.

кен1.jpgОбычно в проекте к этому моменту понятно принципиально, что нужно улучшать. Но не понятно, что нужно улучшать конкретно.

Приведем пример.

Возьмем пекарню из нашего списка примеров. Поставлена задача улучшить качество булочек, далее нашли полный перечень требований клиента, установили проектный показатель и задали для него границы спецификации. Уже немало на данный момент.

И тут вопрос. А это все вообще достижимо? И за что браться? Нужно ли на чем-то сфокусироваться или, наоборот, всем понемногу заняться?

Дальше перед нами Клондайк потенциальных возможностей для улучшений. Можно привлечь экспертов и пойти путем экспертной перебора вариантов, а дальше, куда кривая выведет. Если упрощать и слегка утрировать – это путь Лин. А можно с самого начала ответить на 

главные вопросы: 

  • а может ли наш процесс принципиально достичь этой цели?

  • в чем основное препятствие на пути достижения цели?

Сколько раз мы сталкивались с ситуациями, когда начинающие проектные лидеры ставили себе заведомо более простые цели, чтобы не дай бог не появилось риска их не достичь. Да что там молодые. У опытных тоже через раз проявляется неумение поставить адекватную достижимую цель. На практике ее обычно ставят или, исходя из лучших результатов за прошлые периоды, или по экспертным или иным ощущениям заказчика проекта. Реже, исходя из реальных требований клиентов (и это уже, к слову, очень неплохо). Только в этом случае исполнитель седеет, так как не может быть уверен в достижимости цели. Это же кошмар наяву. «А если я не дойду, если в пути пропаду… » 

Сколько раз мы сталкивались с ситуациями, когда начинающие проектные лидеры ставили себе заведомо более простые цели, чтобы не дай бог не появилось риска их не достичь. Да что там молодые. У опытных тоже через раз проявляется неумение поставить адекватную достижимую цель. На практике ее обычно ставят или, исходя из лучших результатов за прошлые периоды, или по экспертным или иным ощущениям заказчика проекта. Реже, исходя из реальных требований клиентов (и это уже, к слову, очень неплохо). Только в этом случае исполнитель седеет, так как не может быть уверен в достижимости цели. Это же кошмар наяву. «А если я не дойду, если в пути пропаду… »

Есть много всяких рекомендация по целеполаганию. Тут тебе и метод СМАРТ, и СМАРТ+ и методики теории ограничений… и еще всякого до кучи. Но очень мало способов дают четкий ответ про достижимость цели. Да, в СМАРТ указано, что цель должна быть Достижимой, а вот что под этим понимать остается за скобками. Я это до сих пор воспринимаю не иначе как некую издевку или тонкий троллинг. 

В сигме же есть возможность оценить достижимость цели еще до того, как ты ринулся ее достигать.

Представьте себе, что у вас есть такой график: 

qwe123.png

И вы, сделав первичные замеры, по нехитрой методике ставите точку. Куда эта точка попадет, такова и ситуация. Такое вот «свет мой зеркальце». Например, попав в зону В, можно с уверенностью сказать, что хоть что вы делайте с системой управления, как угодно кусайте ее организационными методиками, толку особо не будет. Потому как ваш процесс, даже в идеальных условиях и при идеальном управлении не достигнет цели. Надо технологию процесса пересматривать. Например, можно создать стрелку идеальные условия для стрельбы, исключить смену ветра, дать крутую оптику, целеуказатель повесить и т.д. А это чудо все одно мажет, ибо стрелять не умеет. Так и тут. 

rty123.jpg

Дружно лезем обратно на первые статьи, где я рассказывал об алгоритмах DMAIC и DMADV. Вот в этой ситуации скорее DMADV. И, что самое печальное, процентов 80 методик Бережливого производства резко тут перестают работать. Хотя бы потому, что эксперты обычно не готовы ни морально, ни квалификационно к смене методики. Им сам факт необходимости ее смены порой сложно принять. Второй забавный нюанс здесь в том, что именно в такой ситуации призывы «а давайте другое оборудование закупим», обычно не поощряемые в Лин, становятся вполне актуальными. 

И, наоборот, в зоне С совершенно спокойно можно применять любые организационные методики, в том числе и Линовские, и получать результат.

Тут есть еще две новости, хорошая и плохая.

Плохая заключается в том, что большинство (по моим субъективным оценкам процентов 60-70) процессов попадает в зону А. То есть там плохо все, и управление, и технология.

Хорошая новость заключается в том, что в этой ситуации, на чем бы ни сосредоточился при улучшении, все будет работать. (Чем пользуются, в частности, многие консультанты). И в зоне А Лин инструменты предпочтительнее, ибо они быстрее.

uio3.jpg

Дальше, поставив стартовую точку, и зряче понимая, что не так с вашим процессом, можно наметить направление улучшений и сосредоточить усилия именно на этом направлении.

Типовая история для отечественных реалий выглядит так:

yuio1.png

То есть начинают улучшать управление процессом, обучают людей, вводят стандарты, штрафы и премии, готовят менеджмент и делают прочие подобные, безусловно, важные действия. Доходят при этом в зону В… и успокаиваются. Улучшение-то есть. Экономический эффект тоже. Чего еще-то?

Вот только реальная эффективность и полное удовлетворение потребностей клиента лежит в зоне D. Оставляю вам возможность самим прикинуть, какой потенциал улучшений еще остается. 

Собственно, вся эта преамбула была  для того, чтобы на пальцах объяснить, зачем в методике Шесть Сигм есть такой блок как Установка стартовой точки и направления для улучшений. А то повадились, понимаешь, фыркать на него из разряда «ну мы же знаем текущую ситуацию, чего еще огороды городить?».  

1302.png

Добавить осталось немного. Шаг позволяет:

  • Рассчитать сколько же дефектов ваш процесс производит и будет производить далее, если ничего с этим не сделать. Полезно для всяких экономических расчетов, для понимания, в какой момент клиент даст по шее и сколько раз, ну и вообще бодрит по утрам.

  • Определить, какое среднее и сигма нужны именно в этом процессе, чтобы все было хорошо.

  • Обосновать все вышеперечисленное руководителям, так сказать, на пальцах и с аргументами, денежными затратами, если ничего не делать и т.д. Да, они вам будут говорить, что, мол, «вы данные плохо собрали»… Но мы-то с вами уже проверку измерительной системы прошли, и с данными у нас все в порядке. 

 И по инструментам. Их тут хватает разных. При этом большая часть из них – это методики расчета для разных ситуаций. Поэтому остановлюсь на одном плюс-минус визуальном.

Инструмент Capability Analysis (Анализ возможностей/способностей процесса). Наследие от статистического контроля качества, малость переработанное в Сигме.  

Задачи инструмента: определение текущего уровня дефектности процесса (если точнее – сигма уровня процесса, если это кому-то что-то говорит).

 Чего дает? Дает понимание, сколько дефектов производит процесс в идеальных и реальных условиях. Соответственно, разница между этими показателями и даст уровень управления процессом. Позволяет построить ту замечательную схему, которая изображена в начале статьи, и поставить на нее точку текущего состояния. В целом, никто не запрещает потом в конце проекта повторить упражнение и поставить итоговую точку, к чему пришли.  

Где не стоит использовать? Для систем с дискретным типом данных не подойдет. Для дискретных данных более распространен инструмент Yield Rate Analysis (но он сугубо расчетный и без визуализации, поэтому я не буду эту скукотищу описывать тут).

Инструмент обычно требует непрерывного распределения данных (или хотя бы известного типа распределения), что накладывает ограничения на его использования неподготовленными людьми.

Вам также потребуется специальное ПО (Minitab, SigmaXL, Статистика и т.д.) или понимание математического аппарата, поэтому инструмент плохо сочетается с такими людьми:

098.jpg

Где можно использовать? Для построения стартовых точек для данных непрерывного типа. 

Аналоги в ЛИН. Как и для проверки измерительной системы, прямых аналогов нет. В Бережливом производстве иногда применяют частичные расчеты, например показатели Ср и Срк.

Как выглядит? В Минитаб выглядит так:

13021.png

В этом примере анализ пробега автомобильных шин для транспорта. Целевых 90.5тыс. км. Не достигла ни одна из тестируемых шин. Более того, они не достигли даже минимального целевого пробега в 81,5 тыс. км.

Это, кстати, пример системы из блока С. Можно как угодно менять систему управления этим процессом. В действующих условиях это почти не приблизит нас к целевому значению. Нужна смена технологии. Поэтому идеи в духе «а давайте ездить медленнее» или тому подобное можно, в целом, отметать cразу.

В общем, думаю, вы уже начали понимать, что мир статистики лукав, жесток для новичков, но прекрасен и полезен для тех, кто смог с ним подружиться. И это я еще в статистические показатели не полез, вроде Zst, Zlt, Zbench, Zshift, Cp, Cpk, Pp, Ppk и полный набор Yield Rate-ов.

13023.jpg

Как я писал ранее, эра Сигмы в нашей стране еще только грядет. И сегодня, думаю, я объяснил почему:

13024.png

Ведь «Рыжая стрелочка» еще ждет своих героев.

13026.jpg    


Ссылки на предыдущие статьи цикла "Шесть Сигм, с чем его едят":

Статья №1 Основные положения Шесть Сигм

Статья №2. Принцип решения проблем в Шесть Сигм. Алгоритмы проектов.

Статья №3. Алгоритм DMAIC. Шаг DEFINE. Часть 1.

Статья №4. Алгоритм DMAIC. Шаг DEFINE. Часть 2.

Статья №5. Алгоритм DMAIC. Шаг DEFINE. Часть 3.

Статья №6. Алгоритм DMAIC. Шаг DEFINE. Часть 4.

Статья №7. Алгоритм DMAIC. Шаг DEFINE. Часть 5.

Статья №8. Алгоритм DMAIC. Шаг MEASURE. Часть 1.

Статья №9. Алгоритм DMAIC. Шаг MEASURE. Часть 2.