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

Рассказывать истории успеха - всегда легко и приятно, но куда полезнее разбирать факапы, и этот пост про один из них.

В какой-то момент мы в компании пришли к необходимости внедрения методики 8D ("8 дисциплин") - де факто стандарта обработки несоответствий внутри нашей Группы. На уровне менеджмента сопротивления почти не было - этот шаг выглядел логичным.

Что такое 8D?

8D - это системный подход к решению проблем и постоянным улучшениям, состоящий из нескольких шагов:

🔷D0: Отреагировать на проблему - останавливаем работу и информируем заказчика 🔷D1: Собрать команду - собираем команду, привлекаем экспертов, назначаем руководителя, договариваемся о правилах 🔷D2: Описать проблему - что и когда случилось? в каком месте проекта? кого она затронула? как ее обнаружили? и пр. 🔷D3: Минимизировать ущерб - проверяем, нет ли аналогичной проблемы на других проектах, готовим быстрые решения для устранения последствий 🔷D4: Найти первопричину - ищем корневые причины проблемы (5 "почему", диаграмма Исикавы и пр.), не забывая про принцип Парето. 🔷D5: Придумать план действий - планируем действия по устранению самой проблемы и ее причин 🔷D6: Выполнить план - выполняем план корректирующих действий 🔷D7: Учесть опыт - в качестве превентивных действий улучшаем процессы, документацию и пр., чтобы проблема не повторилась в будущем 🔷D8: Поздравить команду - архивируем отчетность и благодарим команду за работу

Несмотря на некоторую тяжеловесность, логика подхода прозрачная, а цепочка действий - понятная.

Но что пошло не так?

🔴 Локальность и редкость применения. Освоение методики требовало ее практического применения, но серьёзные проблемы на проектах случались редко и в разных командах. Поэтому каждый кейс 8D для большинства участников был первым опытом - с обилием вопросов, ошибок и низким темпом. Этот фактор мы недооценили

🔴 Избыточная глубина. Не всякая проблема требует глубокого анализа. Устранять системные ошибки важно, но есть и обратная сторона - анализ становится самоцелью. Наше начальное решение применять 8D ко всем проблемам было ошибкой - через несколько месяцев накопилась масса зависших проектов без ощутимых результатов

🔴 Человеческий фактор. Наш директор по качеству был сильным методологом, но слабым практиком. Не умел он объяснять сложные вещи простым языком, увлекался формой и теорией, в ущерб практической пользе. В итоге ни обучение, ни коммуникация по теме не были эффективными

🔴 Конфликт приоритетов. Живые проекты для заказчиков - всегда важные, срочные и привязанные к системе бонусов. Проекты 8D - это внутренние улучшения, головная боль без быстрого эффекта. Не удивительно, что люди всеми силами старались уклоняться от последних

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

Когда стало понятно, что так дальше жить нельзя, перестроили процесс: 🟢 В роли фасилитаторов в проекты 8D привлекли экспертов, ранее уже накопивших достаточно опыта 🟢 Ввели четкие критерии, когда применяем 8D, а когда - нет 🟢 Привязали новые KPI по 8D к системе премирования 🟢 Полностью переделали все учебные материалы, упростив логику подачи и язык, заново провели обучение

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