Следующие три блока этапа Измерение (Measure) можно не разделять, так как по факту они обычно происходят плюс-минус одновременно.
1. Как только мы прошли предыдущий этап Установки стартовой точки, уже есть понимание достижимости цели. А значит и понимание, надо ли первоначальную цель дробить, изменять, уточнять. Итоговые согласованные цели по Проектному Y и заносятся в Устав.
После проверки Измерительной системы тоже могут появиться выводы, которые недурно бы в этот Устав вписать.
На практике, кстати, частенько Устав не делают, ограничиваясь кучей протоколов и кучей подписей. Но это уж как кому больше нравится. Эффективнее и безопаснее для Лидера проекта работать через устав, потому как:
Протоколов много, и не все подписываются. Да и присутствовать могут не все, соответственно подписи не все. (А Устав один и подписи там все)
В протоколе могут быть ошибки.
Разные протоколы могут противоречить друг другу. Казалось бы как так-то? А вот запросто в проектах длиннее месяца. Что вы там на первых встречах решали… это же вспоминать надо. А привычка перечитывать протоколы встреч далеко не у всех даже лидеров проектных встречается.
Разные встречи могли вести разные люди. Вот вел встречу ваш зам и внес в протокол что-то интересненькое. А дальше на это будут ссылаться. Устав такое не дает сделать.
Ну а дальше, как говорится, думайте сами, решайте сами…
2. Определение списка возможных факторов и Сбор данных для анализа идут в целом рука об руку. Сбор данных так и вообще будет главным спутником, начиная с этого момента.
Опять же, за что часто критикуют Сигму, называя это бюрократизацией и формализацией? Главные раздражители как раз:
Уже разобранная нами проверка системы измерения
Это напоминает анекдот (он в разных вариациях есть, пусть будет эта):
Экспериментатор подвесил к потолку банан и впустил в комнату обезьяну. Та прыгала, прыгала, а достать не могла. Тогда экспериментатор говорит ей: «Думай, Чичи!». Обезьяна посмотрела вокруг. Видит несколько предметов и среди них табуретку. Быстро подтащила табурет и сняла банан. Потом ученый подвесил к потолку бутылку водки и пригласил Васю. Вася прыгает, прыгает, но достать не может. Экспериментатор и ему говорит: «Думай, Вася, думай!» — а Вася отвечает: «Что тут думать? Прыгать надо!».
Печальный факт в том, что не раз и не два встречал ситуацию, когда лидер группы принимает решение: «давайте соберем все, что можно, а там, глядишь, чего и поймем». Или наоборот, «а ну его нафиг с этими данными, у нас экспертов что ли нет?».
А какие нужны данные, сколько их надо, как они друг с другом соотносятся? Это их не заботит.
А, впрочем, я об этом уже писал.
Итого, почему нельзя собирать данные всем скопом?
Данные часто собирают по времени, делая единый срез, забывая при этом о географии процесса (см. пример с pH стоков в статье №8)
Тратятся избыточные ресурсы на сбор ненужных данных. Вам достаточно 30 замеров, а замеряем все 300 раз.
Наоборот, не собрали нужные данные. А досбор уже потребует сбора всего массива заново.
Просто пропустили важность тех или иных факторов и либо не собрали по ним данных, либо не нашли сходу возможности их собирать.
Ну и так далее. В конечном счете, в Сигме на этапе Анализ все эти ошибки-сорняки дадут вам отличные всходы.
Про Рациональную группировку данных (Rational Subgrouping) надо бы рассказать подробнее… Но это прямо лекция получится. Если вкратце на пальцах, у вас есть собственные колебания/вариации процесса и привнесенные извне. Рациональная группировка данных позволяет их разделить и анализировать раздельно.
Думаю, не нужно пояснять, почему это важно.
Но вот мы и добрались до факторов. Что ж это за зверь такой, и зачем на них целый этап. Начнем немного издалека.
Возьмем типичную ситуацию перед началом анализа.
Проект Лин:
- Итак, коллеги, теперь проанализируем, какие факты по проблеме мы знаем? Отсюда, поймем, из-за чего она может возникать, найдем первопричины и устраним их.
Команда сказала хмуро «угу» и начали строить Исикаву, 5 почему, CEDAC (если продвинутые) на тему, а какие причины проблемы.
Проект 6 Сигм:
- Итак, коллеги, а какие ФАКТОРЫ могут влиять на наш ключевой показатель? Принципиально. Давайте рассмотрим, потом соберем по ним данные и проанализируем.
Команда сказала хмуро «угу» и начали строить Исикаву, Логическое дерево или когнитивную схему (5 почему и CEDAC тут уже не сработают) на тему, а какие ФАКТОРЫ потенциально влияют на наш проектный Y.
Вроде бы похожие процессы. Но есть нюансы. Лин сразу пошел к причинам, к сути. Они рассматривают те факты, что они знают, что произошли. То есть идут от фактологии проблемы, вынеся за скобки те причины, которые не проявились к данному моменту.
Тут есть плюсы и минусы. Вот не хочу их расписывать, сами пишите в комментариях. А то чего я за вас все разжевываю?
Сигма делает промежуточную остановку (даже не одну) и решает, а что вообще может влиять (читай послужить причиной) проблемы. Это уже не фактология, это исследовательская задача.
Нет интереса агитировать «за Советскую власть». Тут тоже свои плюсы и минусы.
Важно то, что, если все сделано правильно, то на выходе проекта вы не просто решите проблему, а узнаете как управлять процессом. На какие рычаги он откликается.
Всего у вас появится в ходе проекта три списка факторов:
И вот наша с вами задача на этапе Измерение, построить 2-й список и собрать по нему данные.1. Список потенциальных факторов – это те, которые в принципе могут повлиять на ключевой проектный показатель. Тут может быть все, что угодно, включая магнитные бури на солнце, температуру на улице и индекс Доу-Джонса (не к ночи будь помянутый). Ограничений особых нет. Тут, пожалуй, основной момент, где вам нужны эксперты.
2. Список возможных факторов – это фильтр предыдущего списка. Отсеиваются те факторы, которые мы не можем
Я это называю правилом двух Измов. Если хотя бы один из Измов не выполняется – откладываем фактор в запас.
- Измерить
- Изменять
3. Список, так называемых Vital Few. Переводы разные, где-то Критичное подмножество, где-то просто Список влияющих факторов, есть и другие вариации. Но суть одна: это следующий фильтр, который из предыдущего списка уже определяет тот минимум факторов, который гарантированно влияет на наш ключевой показатель.
Те, кто занимался лепкой из пластилина, знают, что сколько бы ни было на старте цветов в наборе, в конце концов все закончится одним серым куском.
И собирая данные сразу этим куском, потом нереально сложно на этапе Анализ разделять обратно на цвета. Работа с факторами и Рациональной группировкой данных, позволяет «не смешивать цвета» в процессе сбора данных.
На этом с Измерением все. Дальше Анализ.
Понятно, что в ходе этих статей я лишь слегка погрузил вас в «дебри» Измерения и сбора данных. Те, кому это чуждо, глубже и не полезут. А с те, кому это интересно, пишите, будем общаться лично.
Ссылки на предыдущие статьи цикла "Шесть Сигм, с чем его едят":
Статья №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.
Статья №10. Алгоритм DMAIC. Шаг MEASURE. Часть 3.