FAQ о методике решения проблем

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

Можно как-то классифицировать проблемы, поделить их на типы. Есть ли классификатор по проблемам?
Я классифицирую проблем следующим способом:
  • проблемы, которые можно решить в текущей операционной действительности (например, перегоревшая лампочка). Пошли и сделали, не нужно погружаться в проблему, собирать команду, выявлять первопричину с помощью различных инструментов;
  • проблемы, которые требуют решения на “Кружках качества”, т.е. в небольших командах (например, лампочка перегорает систематически, необходимо определить первопричину, проработать и выполнить действия по ее устранению и предупреждению появления);
  • проблемы, которые решаются на уровне проектных команд в рамках реализации проекта улучшения (например, низкая производительность производственной линии). В этом случае требуется кроссфункциональная команда, применение инструментов по поиску и решению проблем и другие ресурсы.

Как определить корневую причину?
Есть несколько способов, выбор которого будет зависеть от сложности проблемы:

  1. самые простые (линейные) проблемы: помогают последовательно заданные проблеме “5 Почему?” Причем количество “почему” может быть меньше и больше 5, но в среднем их – 5;
  2. более сложные проблемы: используется древовидная диаграмма. В процессе применения “5 Почему” возникает ситуация, когда при ответах на вопросы не выстраивается единая логическая цепочка - участники “перескакивают” в логическом пути. Тогда нужно вернуться к тому ответу, на котором произошел уход в сторону. Есть небольшой лайфхак для построения логической цепочки “без проскоков”: начинайте ответ на вопрос “Почему?” со слов “потому что…”;
  3. сложные проблемы (кросс-функциональный процесс): собирается команда профессионалов из представителей разных подразделений, чтобы четко разобрать проблему. Применяется комплекс инструментов: Паспорт решения проблемы (способ визуализации логических размышлений по поиску первопричины, мероприятия по ее устранению) + Диаграмма Исикавы / “5 Почему” / функциональный анализ и т.д.

Когда использовать диаграмму Исикавы, а когда “5 Почему”?
Если проблема решается на уровне линейных сотрудников, то начинаем задавать “5 Почему” проблеме. Далее раскручиваем цепочку и доходим до корневой причины. Если мы понимаем, что причина скрывается в совокупности факторов, то требуется диаграмма Исикавы, так как она помогает разобрать каждый фактор, совокупность отклонений в которых привела к появлению данной проблемы.

Кто должен быть в команде по решению проблем?
Универсального чек-листа нет, где были бы расписаны все возможные роли. Используется индивидуальный подход в зависимости от проблемы. Разберем на конкретном примере. Проблема: дефект продукции, которая изготавливается на станке ЧПУ. В этом случае включаем в команду:
  1. оператора, который работает на этом станке и который изготовил дефектную продукцию
  2. мастер / бригадир (непосредственный руководитель оператора)
  3. контролер, который выявил дефект
  4. технолог
  5. возможно потребуются слесарь, электрик и специалист, который разрабатывает ПО для станка.

Пример из практики: были длительные переналадки на одной из производственных линий. Когда стали разбираться, то выявили, что в производственном плане по изготовлению продукции не учтен наиболее оптимальный порядок перехода с одного вида продукции на другой. Это происходит из-за того, что есть неопределенность в конечном продукте, так как нет на 1 число месяца оплаченных заказов. Таким образом, отдел продаж не успевает сформировать портфель заказов. В этом случае в команду по решению проблемы включили сотрудников отдела продаж.

Что делать, чтобы сотрудники начали искать проблемы, а не говорили, что проблем нет?
Нужно вовлекать сотрудников в процесс решения проблем, а для начала – устранять информационные разрывы, доводить до персонала информацию. Люди должны понимать стоимость проблемы. Приведу пример из своего опыта: проводила аудит в одной из компаний. Вижу, что рядом с оператором стоит 2 коробки, одна с годной продукцией, другая с дефектной. На вопрос: “Почему так много дефектной продукции (примерно одинаковый объем с годной)?”, оператор говорит, что это не страшно, завтра переделает. То есть сотрудник не знает стоимость переделки дефекта и насколько это увеличивает себестоимость.
Сотрудники должны видеть, что проблемы, которые ими озвучиваются, решаются, а не откладываются в долгий ящик. Кроме того, нужно благодарить людей за то, что они выявляют проблемы, а не наказывать. Это связано с тем, что при передаче результата работы с одной операции на другую стоимость дефекта увеличивается. Важно оцифровывать проблемы, так как мы живем в условиях ограниченных ресурсов. Для расстановки приоритетов по решению проблем нужно использовать правило Парето, но для этого важно выразить проблему в натуральных единицах. Нужно устранять в первую очередьте проблемы, решение которых впоследствии даст максимальный результат.

Только ли по деньгам расставлять приоритеты?
Приоритеты в решении проблем нужно расставлять не только по деньгам, но иметь в виду и следующие факторы:
1. как проблема влияет на достижение целей: посмотреть на цели компании и цели подразделения
2. критичность проблемы, на что она влияет: и небольшой дефект может повлиять на конечный результат работы всей компании.
3. влияние проблемы на коллектив: некоторые проблемы негативно отражаются на состоянии команды, демотивируют сотрудников.

Должен ли быть в компании отдельный человек (отдел)-решатель проблем?
В промышленных компаниях мне нравится следующая фишка: на зеркале есть наклейка “в зеркале ты видишь ответственного за технику безопасности”. Важно воспитывать в людях культуру решения проблем. Вырастить решателя проблем, который будет всем помогать, – это здорово, но это не панацея. Культура работы с проблемами должна взращиваться в командах. Все сотрудники должны быть вовлечены в этот процесс. Один в поле не воин. С точки зрения обучения это оправдано: можно обучить одного-двух сотрудников методике решения проблем, а далее они обучают этому других. Надеяться на одного решателя – несбыточная мечта, так как проблем много, специфика разная, а линейные сотрудники лучше всего знают, как решить ту или иную проблему.

Сколько времени понадобится, чтобы превратить компанию из тех, кто прячет проблему в тех, кто ее решает? Сколько нужно, чтобы трансформировать культуру?
На этот вопрос нет однозначного ответа, все зависит от изначальной культуры внутри компании, от численности людей и других факторов. Например, если команда заходит на проект, то трансформация мышления у людей наступает на второй месяц проекта, если брать во внимание 6-месячный проект. Участники начинают осознавать: что такое проблема, как ее сформулировать, как детализировать, как применять инструменты. Тогда они понимают, что “5 Почему” элементарный инструмента, а диаграмма Исикавы не что-то ненужное и навязанное, а рабочий инструмент. После разбора топ-10 проблем в проекте, сотрудники уже сами могут выявлять первопричины проблем, более того, они инициируют решение следующих.

Чем ваша методика отличается от классической 8Д?
Ответ прост: классическая 8Д лежит в основе нашего метода, но мы на основе практики выделили следующий ключевой блок детализации проблемы. Если проблема не четко сформулирована, не детализирована, то очень много времени уходит зря, то есть команда собирается, тратит время и уходит “в космос” со своими решениями (находит причины из области: экономика такая, руководство виновато и прочее). Мы же на этапе формулирования проблемы применяем функциональный анализ (один из инструментов теории ТРИЗ). Он имеет низкий порог вхождения, то есть доступен каждому сотруднику. Это помогает сэкономить время и ресурсы

Бывают ли такие ситуации, когда график по решению проблемы настолько сбился, что наступает такой момент, что проблему и не стоит решать? Стоит ли добивать проблемы до конца всегда?
Нужно подходить гибко. Приведу конкретный пример: в проекте улучшения процесса был определен ТОП-10 проблем, и в результате работы сформирован график из 70 мероприятий по устранению их первопричин. В процессе работы 7 мероприятий были заморожены, потому что изменились рыночные условия и ситуация в компании. Дальнейшая реализация мероприятий была нецелесообразна. Но важно просчитать риски: насколько “заморозка” повлияет на финальный результат.

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

Как улучшить коммуникацию в команде в процессе решения проблем?
1. Четко подготовиться к командной работе. Сначала, до встречи команды, мы предлагаем проблему сформулировать и детализировать. Тогда становится понятно кто из специалистов нужен в команде, так как если собрать всех подряд, то половину участников мы потеряем в процессе. Это происходит из-за того, что сотрудники не понимают зачем они здесь.
2. Обязательно запускаем решение проблем через “Кружки качества”, причем должен быть ведущий кружка качества, который направляет команду, возвращает участников к обсуждению и доводит команду до результата.
3. Определяем одно информационное поле: где и как взаимодействуем, обмениваемся информацией. Это зависит от того, какие каналы коммуникаций используются в компании.
4. Четко прорабатываем время и график встреч, а также определяем кто отвечает за напоминание и прочие организационные моменты.

Какие ошибки допускаются при решении проблем? Есть ли перечень постоянных проблем?
Самые распространенные ошибки:

  • сбор для решения проблемы сотрудников на “всякий случай”. Это происходит из-за неправильно сформулированной и не детализированной проблемы. В итоге получается, что огромное количество времени тратится на то, чтобы понять: что это за проблема. В это время участники задают себе вопрос: а я здесь нужен?
  • сбор неполной команды. Собирается команда для решения проблемы, выявляется, что не хватает какого-то специалиста, за него начинают принимать решения. Когда этот сотрудник подключается к командной работе, то как правило отклоняет уже проработанные за него решения.
  • пробел реализации. Команда качественно проработала проблему, выявлены первопричины, разработан план-график мероприятий по их устранению, но он не выполняется. Могут быть разные причины невыполнения, но самая главная – отсутствие своевременного контроля реализации запланированных действий.
Остались вопросы?
Оставьте контактные данные и наш менеджер свяжется с вами