PDCA: цикл улучшения, который не должен быть кругом имитации
PDCA выглядит настолько просто, что его часто перестают воспринимать серьёзно. Plan, Do, Check, Act: запланируй, сделай, проверь, закрепи. Что тут сложного?
Сложность в том, что компании обычно любят первые два шага. Запланировали и сделали. Иногда даже быстро. А потом переходят к следующей задаче, не проверив результат и не изменив стандарт работы.
Так PDCA превращается в бесконечный круг действий без обучения.
Plan: не просто придумать действие
Планирование в PDCA начинается не с решения, а с проблемы.
Плохой план: «сделать новую форму заявки».
Хороший план: «уменьшить долю заявок, возвращаемых из-за неполных данных, с 28% до 10% за месяц, проверив обязательные поля и ответственность за вход».
Во втором случае понятно, что меняем, зачем меняем и как узнаем, что стало лучше.
План должен содержать гипотезу. Не «мы уверены», а «мы предполагаем, что причина в этом, поэтому проверим такое изменение».
Do: сделать в ограниченном масштабе
PDCA плохо работает, когда любое изменение сразу раскатывают на всю компанию.
Если гипотеза ошибочна, масштабирование только увеличит ущерб. Поэтому разумнее проверять изменение на ограниченном участке: один процесс, одна команда, один тип заявки, один период.
Do — это не внедрение навсегда. Это управляемая проверка.
Check: самый неприятный этап
Проверка часто показывает, что идея была неполной.
Форма стала удобнее, но люди всё равно пропускают данные. Согласование убрали, но появилась новая ошибка. Время сократилось в одном месте, но выросло ожидание дальше по потоку.
Это не провал. Это нормальная работа с системой. Плохо, когда проверку заменяют отчётом «мероприятие выполнено».
Проверять нужно не факт действия, а изменение результата:
- стало ли меньше ошибок;
- сократилось ли ожидание;
- уменьшилась ли повторная работа;
- стало ли понятнее, кто за что отвечает;
- не появилась ли новая проблема.
Для этого до запуска нужно договориться о метрике. Иначе после изменения начнут спорить ощущениями: одним кажется, что стало быстрее, другим — что сложнее, третьи вообще не заметили разницы.
Метрика не обязана быть сложной. Достаточно количества возвратов, времени ожидания, доли ошибок, числа ручных исправлений или повторных обращений. Главное, чтобы она была связана с исходной проблемой.
Act: закрепить или пересмотреть
Если изменение сработало, его нужно закрепить: обновить стандарт, объяснить людям, убрать старый способ работы, назначить контроль.
Если не сработало, нужно не искать виновного, а пересмотреть гипотезу. Возможно, причина была не там. Возможно, решение затронуло симптом. Возможно, метрика была выбрана плохо.
Act — это момент управленческой честности. Компания либо учится, либо делает вид, что всё прошло успешно.
После закрепления важно убрать старый способ работы. Если новая инструкция появилась, но старая таблица, старый чат и старое согласование остались, люди будут выбирать привычный путь. Тогда улучшение формально внедрено, но процесс фактически раздваивается.
Вывод
PDCA — это не круг ради презентации. Это способ проверять изменения без самообмана.
Он полезен, когда нужно улучшать процесс постепенно, на фактах, с возможностью остановиться, уточнить причину и закрепить рабочее решение.
Если изменения запускаются, но не удерживаются
2П помогает разложить улучшение на проверяемый цикл: сформулировать проблему, выбрать метрику, провести ограниченную проверку и закрепить то, что действительно сработало.