2602
3
×
Цикл "Шесть Сигм, с чем его едят". Статья №16. Алгоритм DMAIC. Шаг ANALYSIS. Часть 5.
Сообщество Lean+6Sigma в России
Цикл "Шесть Сигм, с чем его едят". Статья №16. Алгоритм DMAIC. Шаг ANALYSIS. Часть 5.
Антон Анферов, Руководитель направления Шесть Сигм, Топ-Менеджмент Консалт
09 апреля 2020 в 10:00

Постановка Эксперимента и Моделирование

На сегодняшний день нам с вами осталось разобрать лишь моделирование и методику постановки экспериментов.

090420.jpg

Начну с Моделирования. И особо много тут говорить не стану.

Моделирование в состоянии достичь всех озвученных результатов анализа:

  • Составить список реально влияющих факторов.

  • Определить характер влияния факторов на Ключевой показатель проекта.

  • Найти точную зависимость Y=f(xi).

  • Найти диапазоны допустимых значений влияющих факторов.

Причем сделать это надежно и для самых разных задач.


Есть только несколько НО в этой методике: 

1. Специальное ПО. Да, можно, разумеется, делать моделирования в Excel. Но сколько вы убьете на это времени и сил, вопрос. Был у меня такой опыт. Во время обучения на Зеленый пояс по Шесть Сигм наши преподаватели корейцы задали нам задачку: сбросить со второго этажа на асфальтовую площадку обычное куриное яйцо так, чтобы последнее осталось целым и невредимым. Разбили нас на команды, дали нам ограничение по времени и некий набор материалов + то, что сами в помещении найти сможем. А дальше мы веселились, как могли. Вот тогда я и попробовал впервые моделировать соприкосновение яйца с асфальтом в Excel =) Удовольствие то еще, но позволило нам понять направления сил и минимальную толщину и упругость «спускаемого модуля». Попытка-то была всего одна. Да, рассчитать-то рассчитал, но времени убил прилично.

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

Больше с реальным полным моделированием в Excel я старался дел не иметь. Максимум мозги модели в нем построить. А дальше все равно потом в автоматику переводить.

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

На рынке сейчас приличное количество вменяемых инструментов моделирования, от старичка MATLAB, до относительно свежих AnyLogic и других САПР систем. Так что выбор есть.

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

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

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

Отсюда вывод: ПО еще не панацея. У вас запросто может не быть того, кто с этим ПО договорится.

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

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

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

0904202.jpg

Это, кстати, еще и накладывает ограничения на само ПО. Мало есть совсем универсального. Очень вероятно, что для разных задач придется целый набор программ искать или делать.

3. Модель всегда не соответствует действительности. Всегда чем-то в ней придется пожертвовать при создании, а, значит, есть риск того, что пожертвовали больше, чем нужно, и в результате погибнет точность моделирования.

Кроме того, модель очень уязвима к подгонкам и подтасовкам.

4. И главное НО, почему моделирование так мало применяется в проектах DMAIC – ресурсоемкость моделирования. Это, в большинстве ситуаций, самый затратный вариант поиска решения, как по деньгам, так и по времени.

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

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

  • Проекты, где сбор данных – целая головная боль. Например, процессы создания чего-нибудь редкого или очень дорогого. Тогда любые изменения в реальном процессе могут вызвать такие затраты и объем брака, что лучше даже не начинать. В таких случаях может быть действительно проще и дешевле работать с моделью процесса, пусть и приближенной, а не с ним самим.

  • Организационные проекты в сфере услуг. Там выделить людей и смоделировать ситуацию не так сложно, зато сразу становятся видны нюансы.  
В общем, моделирование чаще применяют при системных изменениях в компании или в проектах по разработке новых процессов/продуктов. Там затраты на подобную деятельность более оправданы. 

Теперь о Постановке эксперимента или DOE (Design of Experiment)

Эта методика является чем-то средним между Моделированием, Проверкой Гипотез и Регрессионным анализом.

Не случайно разработчик этой методики Фишер был последователем Пирсона, создателя Регрессионного анализа.

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

В чем прелесть методики?

1. Вам потребуется минимум 4 измерения для ее реализации. Обычно этот минимум, разумеется, никто не использует, но ограничиться 10-20 замерами на весь анализ вполне реально.

Это делает методику просто незаменимой в ситуациях дороговизны сбора данных. 

Например, в моем самом первом проекте, который я еще на обучении делал, мне нужно было собирать данные по компрессорам для холодильников, у которых была проблема с входной мощностью. Беда в том, что к моменту, когда ты можешь измерять входную мощность, компрессор уже, в общем-то, готов и герметично запаян. А, значит, чтобы собрать данные, его придется сломать. И тут уже не до жиру с сотнями замеров для регрессии или 30-40 для анализа гипотез. Эксперимент тогда мне здорово помог, потому что он, как и Gage R&R в анализе измерительной системы, позволяет делать замеры заранее и очень ограниченное их количество.

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

Вся история позволила найти тот злосчастный шпынек внутри компрессора, поправить пресс-форму у поставщика и решить проблему.

2. Методика, в отличие от регрессионного анализа, приведет к результату. Внутри DOE используется принцип последовательного приближения к решению. Это не значит, что решение вы точно найдете во всем многообразии случаев (есть такие, при которых будет сложно даже DOE), но процентов 60-70 проблем вы так допинаете до результата.

Да, непросто, да, итерационно. Но случится.

3. Ну и наконец, это одна из наиболее эффективных методик приведения нашего проектного Y в заданные границы (экстремумы верхний и нижний, граничные условия).

Где ее можно использовать:  

  • В проектах с дорогим сбором данных

  • На втором витке анализа после Анализа Гипотез для проверки решения и поиска оптимальных значений факторов.

  • В проектах с минимально допустимым уровнем изменений в производственном процессе за время анализа. 


В общем, рекомендую. Штука относительно простая и надежная. 

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

Статья №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.

Cтатья №11. Алгоритм DMAIC. Шаг MEASURE. Часть 4.

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

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

Статья 14. Алгоритм DMAIC. Шаг ANALYSIS. Часть 3.

Статья 15. Алгоритм DMAIC. Шаг ANALYSIS. Часть 4. Корреляционный и Регрессионный анализ.


Полная версия доступна только пользователям сайта
Войдите, чтобы прочитать всю статью и оставить комментарий
E-Mail
Dmitry Isaichuk
Про Программное обеспечение хорошо сказано.
Но, не смотря, на что некоторые модели могут быть "зашиты" внутри ПО, всё-таки нужно понимать суть происходящего.
Иначе, с выходными данными можно будет промахнуться, если вдруг что-то пойдет не так.
10 апреля
Суть надо понимать однозначно. Не часто, но встречали модели противоречащие теории. Ошибки возникали из-за некорректно собранных данных на входе. Тот самый measure во всей красе, который может отправить проект не на одну петлю. Но были и случаи, когда изменение системы приводило к таким последствиям, что возникало то самое противоречие.
10 апреля
Про Программное обеспечение хорошо сказано.
Но, не смотря, на что некоторые модели могут быть "зашиты" внутри ПО, всё-таки нужно понимать суть происходящего.
Иначе, с выходными данными можно будет промахнуться, если вдруг что-то пойдет не так.
10 апреля
Задать вопрос автору статьи
Автор статьи ответит вам по email в течении 1-2 дней.

* - обязательные поля

Авторские статьи
Популярное | Последнее
Рекомендовано
Реклама
Поделиться