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

Сегодня мы подходим к довольно неоднозначному блоку в Шесть Сигм – Определение ключевого показателя Big Y и проектного Project Y.

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

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

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

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

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

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

Пару слов о том, кто такой Big Y, кто такой Project Y.

Big Y – это показатель, который важен для клиента или бизнеса, отражающий тот или иной симптом/проблему для устранения. Обычно есть два источника для его получения: Голос клиента и Голос Бизнеса. Обычно Big Y берут либо из списка CTQ по процессу или из стратегических задач компании/подразделения (например, из X-Матрицы компании или подразделения). А дальше Big Y передают лидеру проекта для работы. Как правило, те, кто дают задачу, не делают дальнейшее уточнение цели. 

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

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

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

Сколько раз сталкивался с ситуациями, когда лидер проекта брал или Big Y, или какой-нибудь интегральный показатель вроде средней выработки за неделю/месяц или % качества за день, а потом, в лучших традициях бразильских сериалов, мучился по 2-3 месяца со сбором и обработкой данных. 

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

Обычно Project Y – это некий показатель, который характеризует наиболее значимую часть проекта. При этом у команды есть все шансы его измерять, когда надо, и воздействовать на него.

Примерно это выглядит, как на схеме:

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

Грамотнее в этой ситуации собрать первичные данные по ОЕЕ, определить, какие участки сильнее всего проседают, и заняться 1-2 самыми худшими. Но лучше пойти еще дальше и разложить худший участок по категориям потери ОЕЕ.

Правило Парето тут работает как нельзя лучше, если мы выберем 20% подзадач, которые дают нам 80% всей проблемы, то решив только эти 20%, мы уже дадим хороший эффект и на Big Y.

Тем самым мы с ходу отсекаем «нерентабельные» направления и берем уточненные показатели, которые лучше помогут нам решать именно эти 20% задач. Эти показатели и есть Project Y.

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

Вы можете сказать, что как-то это все сложно. Зачем так мучиться, дали ведь показатель уже.

Да, иногда в качестве Project Y можно взять и исходный Big Y без проблем. Но в ряде случаев, как я уже указал раньше, это может сыграть в Сигме плохую службу. Если вы можете измерять показатель только раз в день, то для сбора выборки в 30 значений понадобится месяц. Примерно столько же для проверки каждого фактора… Вы готовы годами этот проект делать? Ведь алгоритмы Сигмы просто так проскочить этапы вам не дадут.

 

Немного об инструментах.

В принципе тут их немного. Распространенными инструментами для выбора Project Y являются Логическое дерево и Диаграмма Парето. Первый мы уже рассматривали в статье про определение потребностей клиента (если что, вот тут).

Поэтому сегодня разберем Диаграмму Парето

Диаграмма Парето

Задачи инструмента: Определение доли каждой составляющей результата на общий результат.

 Чего дает? Инструмент позволяет определить, какой из симптомов или частей проблемы проявляется чаще всего и дает больший процент дефектов. Соответственно, это лучший инструмент для реализации принципа Парето: 20% причин дают 80% дефектов.

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

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

Для определения Project Y и уточнения целей проекта.

Для работы с голосом клиента в части ранжирования требований.

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

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

Аналоги в ЛИН. Как таковых нет. Бережливое производство не стесняется использовать этот инструмент, так как он, в этом плане, универсален. Можно еще использовать обычные процентные графики, вроде Pie Chart (секторных «пирогов»)

Как выглядит?

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

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

В данной ситуации одна проблема дает около 80% влияния, поэтому в качестве Project Y имеет смысл взять показатель по простоям.

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

 

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

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

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

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

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

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

• Онлайн обучение по внедрению Бережливого производства и Шесть Сигма с международной сертификацией. Все этапы обучения - Белый, Желтый, Зеленый и Черный пояса.