Цикл PDCA (Plan-Do-Check-Act, «планируй-делай-проверяй-действуй») — итеративная модель непрерывного улучшения: сформулировать гипотезу, проверить её в ограниченном масштабе, честно сравнить факт с планом, принять решение — закрепить изменение или отказаться от него. Ключевая идея, которую упускает большинство пересказов: цикл не круг, а спираль — каждый следующий проход происходит на новом, чуть более высоком уровне зрелости процесса, а не просто повторяет предыдущий.
Происхождение и исследовательская база
Первым цикл описал Уолтер Шухарт в 1939 году, статистик компании Bell Labs, как трёхступенчатую модель управления качеством. Эдвардс Деминг развил идею Шухарта до четырёх этапов и распространил методологию в Японии в начале 1950-х годов, где она стала одной из основ послевоенного японского подхода к качеству.
Важная историческая деталь, которую не даёт ни один из массовых русскоязычных источников: аббревиатура именно PDCA (с этапом Check) — японская адаптация цикла Шухарта, возникшая ДО того, как сам Деминг предложил собственную версию названия. Деминг эту формулировку прямо не принимал — в книге «The New Economics» (1993) он называл название PDCA неверным и настаивал на PDSA (Plan-Do-Study-Act). Причину он сформулировал предельно ясно: «I don't use check. Check is too closely associated with inspection» — «Check» у него ассоциировался с инспекцией/контролем, тогда как цель цикла, по Демингу, — обучение (learning), а не оценка/наказание (judging). Слово «Study» точнее передаёт суть третьего этапа: не формальная сверка «выполнено/не выполнено», а содержательное изучение того, чему научил результат эксперимента. Оригинальное описание цикла Шухарта у Деминга приведено в книге «Out of the Crisis» (1986), страницы 88-94.
Ключевые идеи и принципы
Принцип: четыре этапа
Plan — сформулировать гипотезу и измеримую цель эксперимента. Плохая формулировка: «стать продуктивнее». Рабочая формулировка: «сократить время выполнения задачи на 20% за неделю» — с точным числом и сроком, иначе на этапе Check нечего будет сравнивать.
Do — реализовать план в ОГРАНИЧЕННОМ масштабе (пилот на части команды/процесса), не сразу на всю компанию — цена ошибки на пилоте кардинально ниже, чем при полном внедрении непроверенной гипотезы.
Check (или Study у Деминга) — сравнить фактический результат с гипотезой из Plan, разобраться, ПОЧЕМУ результат совпал или разошёлся с ожиданием — не просто зафиксировать «стало лучше/хуже».
Act — принять явное решение: закрепить изменение как новый стандарт, скорректировать гипотезу и повторить цикл, либо отказаться от идеи, если данные её не подтвердили.
Принцип: цикл как спираль, не круг
Возврат к Plan после Act происходит не на том же уровне, откуда цикл начался, — стандартизированное улучшение поднимает процесс на новую точку отсчёта, следующий цикл решает уже новую, более тонкую проблему. Визуально это лучше представлять восходящей спиралью, а не замкнутым кольцом, повторяющимся бесконечно на одном месте.
Принцип: SDCA как обязательное предусловие PDCA (по Масааки Имаи)
Японский теоретик кайдзен Масааки Имаи сформулировал важное методологическое уточнение: нельзя улучшать (PDCA) нестабилизированный процесс — сначала нужно закрепить процесс в цикле SDCA (Standardize-Do-Check-Act, «стандартизируй-делай-проверяй-действуй»), добиться его предсказуемой повторяемости, и только ПОСЛЕ этого запускать PDCA для улучшения уже стабильного процесса. Попытка улучшать хаотичный, непредсказуемый процесс через PDCA даёт зашумлённые, неинтерпретируемые результаты — непонятно, изменение это дало эффект или естественная нестабильность процесса.
Принцип: вложенные циклы на разных уровнях организации
PDCA работает не только как единая методика на весь процесс целиком — на практике эффективнее вложенные циклы: свой цикл PDCA на уровне отдельной операции, свой — на уровне всего процесса, свой — на уровне подразделения или компании, каждый со своим горизонтом и масштабом изменений, но одной и той же логикой.
Принцип: PDCA и родственные методологии — общий каркас под разными именами
Логика цикла проверки гипотезы через контролируемый эксперимент — не изобретение исключительно Деминга/Шухарта, она независимо повторно возникает в других системах: DMAIC (Six Sigma), метод 8D компании Ford, 6-шаговый метод решения проблем Xerox, управление по целям (MBO) Питера Друкера — все они, по сути, разные конкретизации одного и того же общего цикла «гипотеза → контролируемая проверка → анализ → решение», адаптированные под свой контекст применения.
Принцип: сравнение PDCA и DMAIC
PDCA — более общая, универсальная модель непрерывного улучшения любого масштаба; DMAIC (Define-Measure-Analyze-Improve-Control) — более структурированная, статистически строгая методология Six Sigma для проектов с явной количественной целью снижения дефектов/вариации. PDCA годится для быстрых итеративных улучшений практически любого процесса, DMAIC — для более формальных, ресурсоёмких проектов с обязательной статистической проверкой результата.
Ограничения, слепые зоны и критика
Метод плохо подходит для задач с жёсткими фиксированными дедлайнами, где нет времени на полноценный итеративный цикл проверки гипотезы, — это скорее методология постепенного, а не срочного улучшения.
PDCA линеен по своей базовой схеме и не даёт встроенного механизма приоритизации, КАКУЮ именно проблему улучшать в первую очередь среди множества возможных — сам цикл начинается уже после того, как проблема выбрана.
Попытка применить PDCA к нестабилизированному, непредсказуемому процессу (пропуская обязательный этап SDCA) даёт зашумлённые результаты — по сформулированному Имаи принципу, нельзя улучшать то, что ещё не работает предсказуемо.
Формальное, поверхностное прохождение цикла без реального анализа причин на этапе Check/Study (что Деминг прямо предупреждал словом «inspection vs learning») превращает методологию в ритуал отчётности, не дающий реального обучения организации.
Типовые ошибки
Ошибка 1: пропуск этапа Check/Study
После выполнения запланированных действий команда сразу переходит к следующим задачам, не сверяя фактический результат с изначальной гипотезой — цикл формально не завершён, никакого реального обучения не произошло.
Как избежать: явно закладывать время и ответственного за Check/Study как отдельный обязательный шаг, не полагаться, что «и так видно, сработало или нет».
Ошибка 2: отсутствие измеримых метрик на этапе Plan
Гипотеза формулируется в общих словах («улучшить процесс»), без конкретного числового ожидания — на этапе Check физически не с чем сравнивать факт.
Как избежать: формулировать Plan с конкретной цифрой и сроком с самого начала, а не постфактум придумывать критерий успеха.
Ошибка 3: массовое внедрение без пилота
Гипотеза сразу реализуется на весь процесс/всю компанию, минуя ограниченную пилотную проверку — цена ошибки при неподтвердившейся гипотезе многократно выше.
Как избежать: всегда проверять Do в ограниченном масштабе (часть команды, один отдел, короткий период) прежде чем масштабировать изменение.
Ошибка 4: попытка PDCA на нестабилизированном процессе
Цикл улучшения запускается на процессе, который сам по себе ещё не работает предсказуемо (нет базового стандарта, результаты сильно варьируются от раза к разу) — эффект изменения невозможно отличить от естественного шума процесса.
Как избежать: сначала стабилизировать процесс через SDCA (закрепить текущий стандарт и добиться его повторяемого исполнения), и только потом запускать PDCA для его улучшения.
Ошибка 5: сопротивление персонала и отсутствие поддержки руководства
Цикл внедряется формально сверху, без вовлечения людей, которые реально выполняют процесс, и без видимой поддержки руководства — команда воспринимает PDCA как очередную бюрократическую инициативу, а не рабочий инструмент.
Как избежать: вовлекать непосредственных исполнителей процесса в формулировку гипотезы на этапе Plan, обеспечивать видимую поддержку и интерес руководства к результатам цикла.
Ошибка 6: формализм — Check как инспекция, а не обучение
Этап проверки сводится к формальной галочке «выполнено/не выполнено» вместо содержательного разбора причин расхождения плана и факта — ровно то, против чего предостерегал сам Деминг, настаивая на замене «Check» на «Study».
Как избежать: на этапе проверки явно фокусироваться на вопросе «чему нас научил этот результат», а не только «уложились мы в план или нет».
Главное, что нужно знать
PDCA — 4 этапа (Plan-Do-Check-Act), но по замыслу Деминга правильнее PDSA: Check у него ассоциировался с инспекцией, тогда как цель цикла — обучение, а не формальная сверка.
Цикл — спираль, не круг: каждый следующий проход происходит на новом уровне зрелости процесса, не повторяет предыдущий на том же месте.
Do выполняется в ограниченном пилотном масштабе, не сразу на весь процесс/компанию — это резко снижает цену ошибки непроверенной гипотезы.
Нельзя улучшать нестабилизированный процесс (принцип Имаи): сначала SDCA — стабилизация текущего стандарта, и только потом PDCA — его улучшение.
DMAIC (Six Sigma), MBO, 8D Ford — родственные методологии с той же базовой логикой «гипотеза → проверка → анализ → решение» в разных конкретизациях.
План внедрения
Plan: формулировка гипотезы
Сформулировать гипотезу с конкретным измеримым ожиданием и сроком — не общее направление, а проверяемое утверждение.
Убедиться, что процесс, который собираетесь улучшать, уже стабилизирован (стандартизирован и предсказуемо повторяется) — если нет, сначала закрепить его через SDCA.
Do: пилотная проверка
Реализовать изменение в ограниченном масштабе — часть команды, один процесс, короткий период, не сразу везде.
Собирать данные по ходу пилота, не только в самом конце.
Check/Study: анализ результата
Сравнить фактический результат с гипотезой из Plan — не только «сработало/не сработало», а ПОЧЕМУ именно так вышло.
Зафиксировать реальное объяснение расхождения (или подтверждения), не формальную констатацию факта.
Act: решение и следующий виток
Явно решить: закрепить изменение как новый стандарт, скорректировать гипотезу для следующего цикла, или отказаться от идеи.
Если решение — закрепить, зафиксировать новый стандарт как отправную точку для следующего, более высокого витка спирали, не как конечную точку.
Как реализовать этот план с помощью фрейма «Цикл PDCA (Деминга)» в OrgDevTools
Фрейм PDCA в OrgDevTools — сетка из четырёх цветных карточек 2×2, каждая — один этап цикла со своей подсказкой: Plan («Что проверяем и какого результата ожидаем»), Do («Реальные действия по гипотезе»), Check («Подтвердилась ли гипотеза фактически»), Act («Стандартизация или новый цикл», визуально выделена градиентом). В каждой карточке — свободный список пунктов, добавляемых по одному кнопкой «+ добавить».
Вердикт фрейма построен строго по последовательности этапов, а не как простой счётчик: если не заполнено ничего — фрейм явно советует начать с Plan, «без чёткой гипотезы Check не с чем будет сравнивать результат» — прямая реализация принципа блока «Типовые ошибки» (Ошибка 2, метрики нужны с самого начала). Если Plan есть, а Do нет — предупреждение, что действия ещё не выполнены. Если Do есть, а Check нет — предупреждение, что данные ещё не проверены. Если Check заполнен, а Act — нет, вердикт явно говорит: «цикл PDCA не считается завершённым без Act» — прямая защита от Ошибки 1 (пропуск завершающего решения). Только при заполнении всех четырёх этапов цикл засчитывается завершённым.
Заполняя Check, пишите не «стало лучше/хуже», а конкретную причину — фрейм не проверяет содержательность текста автоматически, но именно в этом разница между формальной «инспекцией» и настоящим Study, о которой писал Деминг.
