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

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

Вернее не так… назад дорога, конечно, есть, но вот желающих пойти этим путем маловато.

Впрочем, не спешите прощаться с этапом DEFINE, вы запросто к нему можете вернуться, если с первого раза наделали там ошибок. И такое встречается чаще, чем хотелось бы. Особенно у доморощенных экспертов без системного образования в Сигме. Как самолечение, пока везет, все нормально, но вечно вести не будет.

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

Но мы отвлеклись.

Следующим шагом в алгоритме DMAIC идет крайне недооцененный и недоиспользуемый на практике MEASURE или, по-нашему, Измерение.

При этом недоиспользуемость прямо вытекает из недооценки и недопонимания. Ситуации бывают разные.

Ситуация первая. Просто пропустим для экономии времени.

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

Так вот в Сигме не так. В методике Шесть Сигм на данном этапе единственное, что позволяется эксперту без подтверждающих данных – предложить список факторов, которые стоит рассмотреть и предложить порядок их рассмотрения. Все. При этом у эксперта никаких привилегий. Деминг еще более полувека назад говорил: «Верю только в Бога, остальные пусть несут данные».

Я могу понять, почему такое происходит. Иногда долго раскачиваются в проекте, иногда сроки поджимают по иным причинам. Этап Измерение выглядит как незначительный, которым можно при случае пожертвовать. Часто этим грешат лидеры с успешной Лин практикой, где многое как раз на экспертах основано. Тут и некоторая самоуверенность, и прошлый опыт работают не на методику.

Но давайте вспомним принцип работы Сигмы. Мы переводим реальную проблему в математическую, чтобы затем решать последнюю статистическими методами. А если вы не собрали данные… что будем решать?

Практика показывает (моя десятилетняя в том числе, если кому-то принципиально, чья именно), что сбор данных в серьезном проекте займет у вас от 40 до 60-70% всего времени в этом проекте.

И я не говорю сейчас о попытках решить Сигмой проекты из разряда «у нас тут потеря на перемещении, давайте ее устраним». Тут Сигма вообще не нужна. Я говорю о проблемах, которые никто не решил до вас, и никто не знает, как их решать. А решать надо.

Вон из недавнего. Варочный котел в целлюлозном производстве. Кто знает, что там происходит на самом деле. Да, есть учебники, да есть теория, да есть эксперты. Вот только котел за годы эксплуатации уже давно не соответствует тем документам, что на него были. Сырье в котел идет неоднородное и тоже не то, которое по инструкции. Ну нет такого у нас в стране, внезапно. Гадкий лес растет не так как нам надо.

И что? Эксперты в таких ситуациях куда-то пропадают или дают противоречивые показания. Или их вообще нет. Повторюсь, кто знает, что там в этом 8-метровом агрегате происходит на самом деле?

А лидер говорит «вы же эксперты», давайте анализировать…

Что сказать: слабоумие и отвага. Но точно не Сигма.

Ситуация вторая. Соберем быстренько данные, какие есть. 

Адепты такого подхода «И так сойдет» не особо задумываются о характере собранных данных, об их источниках и прочем. Данные есть и хорошо.

Часто этим ребяткам нужно лишь показать результат, а не добиться его.

В таких проектах быстро собираются «нужные» данные, по ним делаются «нужные» выводы, и все довольны. Кроме тех, кто в проекте реально заинтересован, так как проблема как была, так и остается. Забавно, что такое частенько встречается при подготовке Зеленых поясов, особенно дистанционно. «Ну чего там эти консультанты в наших процессах понимают?». А потом смотришь на графики, что они присылают, и тут же возникают вопросы по целостности данных, начинаешь задавать вопросы (внезапно, вот, гады, еще и вопросы задают), тут-то все и посыпалось.

Сколько раз было… и сколько еще будет.

Так вот аксиома Сигмы (если не говорил раньше, скажу тут): Люди Врут.

Кто-то больше, кто-то меньше. Будет это и при сборе данных.

А дальше, напомню, вам определять по этим данным, чего делать, и принимать управленческие решения. При этом вы не можете быть уверены в достоверности исходных данных?

Наверное, не я один вижу здесь нарушение логики? 

Так вот в Сигме у вас должно быть железобетонное аргументирование достоверности данных для анализа. Без этого дальше по шагам идти ЗАПРЕЩЕНО. Иногда это требует отдельных подпроектов.

Опять же из недавнего. Чтобы запустить систему работы по ТРМ на предприятии, пришлось сначала почти месяц ставить там систему сбора данных и выводить ее хоть на какую-то вменяемую достоверность. А иначе можно было любой ОЕЕ рисовать, какой нужен. Хоть 146%. 

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

Ситуация третья. У нас супер-пупер-мега-макси-шмякси автоматическая система сбора данных.

Она нам сейчас все соберет/ у нас есть данные за N лет/ Что может пойти не так…

Действительно, в эру всеобщей цифровизации мы привыкли полагаться на автоматику, стремимся все системы оцифровывать, включая и системы сбора данных.

Зло, как водится, в деталях.

В автоматических системах бывают две пагубные тенденции.

1. Их не резервируют. Нет проверки руками или чем-то еще. Максимум периодически калибруют и проводят поверку. Отсюда о возможном накоплении погрешности в работе узнаем с задержкой.

2. Систему настраивают люди. Люди же проверяют. И у тех, и у других иногда ручки бывают кривыми. В результате датчик классный. Но стоит неверно. Или в ходе ремонтных или обслуживающих работ его задели, и он какое-то время собирал не пойми что.  А проектный лидер потом берет этот массив данных и говорит… да, есть проблема. Да и общая ситуация искажается.

Приведу пример. Вот пишу это все, за окном «суровый» Московский январь. Включаю на часах датчик температуры окружающей среды. Он мне показывает 29.8 градусов по Цельсию.

И вообще, если верить этим часам, я живу где-то в тропиках. Еще ни разу температура ниже 27 не опускалась. При этом датчик у этих японцев поверен, имеет сертификат качества и т.д. Просто при разработке этих часов один косорукий дизайнер влепил точку расположения этого датчика очень близко к коже пользователя. И все. Датчик стал бесполезен, он ни мою температуру, ни температуру окружающей среды без специфических действий не замеряет. 

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

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

В этом примере система была настроена не под нужды проекта. И никто не гарантирует, что действующая система подойдет в вашем проекте. Но система же есть! Зачем еще что-то. 

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

Но давайте внесем немного системности в наше повествование.

Основные цели и задачи шага Измерение.

Главной целью шага Измерение, разумеется, является сбор данных для последующего анализа.

Вот только не все так банально просто, и эта задача распадается на целый список подзадач:

И именно тут начинает в полную силу проявляться специфика подхода Шесть Сигм. В Бережливом производстве и других методиках не уделяют так много внимания процессу подготовки к сбору данных, самому сбору данных и т.д.

Вот посмотрите еще раз на рисунок и задайте себе вопрос. А как часто в проектах вы делали полный перечень этих действий? И что это были за проекты по сложности?

Именно из-за этого шага методику Шесть сигм часто и критикуют. Мол, тяжеловесная и неповоротливая. Но во многом благодаря именно такому въедливому и последовательному подходу к сбору данных, Шесть Сигм способна перемалывать практически любую проблему с неотвратимостью промышленного шредера (правда и с его скоростью).

Про инструменты сегодня не буду рассказывать. О них далее отдельно. 

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

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

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

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

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

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

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

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

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