PDCA — это способ проверить изменение процесса на фактах. Команда планирует один эксперимент, проводит его в ограниченном масштабе, сравнивает результат с исходной точкой и принимает решение: закрепить изменение, скорректировать гипотезу или отказаться от неё.
Аббревиатура описывает четыре повторяющихся шага: Plan — спланировать, Do — выполнить, Check — проверить, Act — скорректировать и закрепить. В поиске и практике PDCA нередко называют циклом Деминга, но Институт Деминга различает PDCA и PDSA: Деминг подчёркивал Study — изучение результата и нового знания, а не только Check. В статье используем привычное название PDCA, а эксперимент строим как проверку гипотезы на данных.
Для первого ограниченного эксперимента не нужна отдельная система качества. Достаточно выбрать один наблюдаемый сбой, заранее определить показатель и сохранить ход проверки. Разберём это на примере команды закупки, которая хочет сократить задержки при согласовании заявок.
В рабочей схеме этой статьи каждый этап заканчивается конкретным результатом. После Plan остаётся карточка с гипотезой и способом измерения, после Do — записи о проведённом пилоте, после Check — сопоставимый факт, после Act — принятое решение. Если одного из этих результатов нет, команда ещё не завершила соответствующий этап, даже когда все запланированные действия выполнены.
Что считать одним улучшением
Одно улучшение меняет конкретный фрагмент повторяемого процесса. В закупке таким фрагментом может быть передача заявки от инициатора согласующему. Формулировка «ускорить закупки» слишком широка: она объединяет подготовку требований, поиск поставщика, согласование бюджета и подписание документов. Для первого цикла команда выбирает один участок, который можно наблюдать отдельно.
У цикла должна быть исходная точка. Команда берёт фактические записи из журнала заявок за сопоставимый период и определяет, где возникает ожидание. Если данных нет, первым результатом станет настройка наблюдения. Без исходного факта завершённая задача покажет лишь выполнение действия, но не изменение процесса.
Как отделить проблему от решения
Проблема описывает наблюдаемый разрыв. Например: «часть заявок возвращается инициатору после передачи согласующему». Предположение «заявки возвращаются из-за нехватки обязательных данных» относится к гипотезе. Фраза «нужно добавить новый шаблон» уже задаёт решение и закрывает обсуждение причин.
Полезно разложить запись на три части:
Причину тоже не стоит объявлять доказанной заранее. Если команда предполагает, что задержку создаёт неполное описание, это пока гипотеза. Журнал возвратов, комментарии согласующих и повторный замер покажут, насколько предположение соответствует реальности.
Как выбрать показатель до запуска
Показатель связан с проблемой и доступен в одном и том же источнике до и после эксперимента. Для возвратов подойдёт доля заявок, которые согласующий отправил на уточнение. Для задержки — срок от передачи заявки до решения по ней. Количество закрытых карточек описывает объём работы команды, но не отвечает на вопрос об эффекте изменения.
До запуска записывают источник, период, способ расчёта и защитное условие. Если команда сокращает срок согласования, она одновременно проверяет, не выросло ли число ошибочных решений. Целевой ориентир нужен для решения, но его нельзя подгонять после получения результата. Общую формулировку цели поможет задать критерий результата.
Как собрать цикл в одной карточке
Одна карточка эксперимента хранит договорённость о проверке. Она не заменяет журнал процесса или аналитический отчёт: в карточке остаются ссылки на источники, описание изменения, ответственные и вывод. Команде не приходится восстанавливать логику решения по разрозненным сообщениям.
Карточку создают до изменения процесса. Если заполнить её после пилота, исходная гипотеза смешается с тем, что команда уже увидела. Отрицательный результат тоже сохраняют: он помогает не повторять проверку под новым названием.
Что записать до изменения
Минимальный набор полей выглядит так:
- наблюдаемый сбой и участок процесса;
- гипотеза об одной причине;
- изменение, которое будет проверяться;
- исходный показатель и ссылка на источник;
- ожидаемый результат и защитное условие;
- границы пилота;
- владелец результата, исполнители и дата сравнения;
- решение после проверки.
В Канбано эти сведения можно разместить в описании задачи. Метки помогают обозначить тип эксперимента или участок процесса, чек-лист — сохранить шаги пилота, вложения — приложить исходный отчёт. Показатель рассчитывает человек по рабочему источнику: доска сохраняет контекст и ход работы, но не вычисляет эффект автоматически.
Кто отвечает за срок
Владелец результата принимает решение после проверки. Исполнители проводят пилот и фиксируют отклонения. В небольшой команде владелец результата и исполнитель могут совпасть, однако ответственность всё равно лучше назвать прямо: иначе карточка дойдёт до «Готово», а сравнение останется без владельца.
Дата сравнения задаёт момент, когда команда вернётся к источнику. Она не обещает, что улучшение проявится за выбранный срок. Правило остановки записывают до запуска: например, собрать не менее 20 заявок одной категории за период с 1 по 30 сентября, исключив отменённые и дублирующие заявки. Если за этот срок набралось меньше 20 подходящих случаев, пилот продлевают, не меняя критерий после просмотра результата.
Как провести небольшой эксперимент
На этапе Do команда меняет одно правило в заранее выбранных границах. В примере закупки чек-лист обязательных данных вводят для одной категории заявок или одного подразделения. Остальные заявки идут по прежнему процессу, если такое разделение допустимо и не создаёт риск.
Пилот нужен, чтобы снизить цену ошибки и понять механизм изменения. Массовый запуск усложняет разбор: участники адаптируются по-разному, причины смешиваются, а вернуть прежний порядок становится труднее. Перед пилотом стоит проверить шаги процесса по чек-листу.
Как ограничить масштаб проверки
Границы определяют до старта:
Экстренную проблему сначала локализуют. PDCA подходит для последующего разбора и улучшения повторяемого процесса, когда у команды есть возможность собрать данные и провести ограниченную проверку.
Как сохранять факты по ходу работы
Исполнители отмечают реальные действия, отклонения и условия, которые могли повлиять на результат. Если один согласующий отсутствовал, изменилась категория заявок или часть участников обошла новое правило, это записывают в карточке. Факт не исправляют задним числом ради аккуратного отчёта.
Обсуждение лучше вести рядом с задачей эксперимента. В комментариях фиксируют решения, а в чек-листе — выполнение шагов. Исходные значения и итоговый расчёт остаются в журнале или отчёте, где их можно перепроверить.
Как сравнить ожидание с фактом
На этапе Check команда возвращается к показателю, выбранному в Plan. Источник, способ расчёта и границы должны совпадать. Если пилот проходил на одной категории заявок, нельзя сравнивать её с общим потоком компании и называть разницу эффектом изменения.
Для сроков полезно смотреть не только среднее значение. Один очень долгий случай способен заметно сдвинуть среднее, поэтому команда может дополнительно проверить медиану и диапазон. Подробный ручной протокол помогает измерить срок процесса.
Какие данные брать в расчёт
Сравнение строится вокруг одного вопроса: изменился ли выбранный показатель при сохранении защитных условий.
В примере закупки команда подставляет реальные значения из журнала. Статья не задаёт готовый процент улучшения: результат зависит от исходного процесса, потока заявок и того, насколько гипотеза объясняет возвраты.
Как отличить эффект от случайности
Одного удачного случая недостаточно для вывода. Команда проверяет число наблюдений, состав потока и внешние изменения. Если в пилоте было мало заявок, период продлевают или повторяют эксперимент. Если одновременно сменился согласующий или изменились требования, влияние нового чек-листа отделить сложнее.
Для небольшого рабочего эксперимента не всегда нужен сложный статистический тест. В примере статьи правило принятия решения задают заранее: после первого периода из 20 подходящих заявок доля возвратов должна снизиться относительно исходной точки, защитный показатель — не ухудшиться, а эффект — повториться во втором периоде из 20 заявок. Одновременное изменение согласующего, требований или состава потока делает вывод неоднозначным.
Как перенести выводы в следующий цикл
Этап Act превращает наблюдение в решение. Подтверждённое изменение закрепляют в рабочем порядке, назначают владельца и дату повторной проверки. Неподтверждённую гипотезу не прячут: команда сохраняет данные, уточняет одну часть предположения и запускает следующий Plan.
PDCA остаётся циклом только при возвращении к планированию. Если команда один раз ввела правило и больше не проверяет его действие, получается разовое изменение без механизма обучения. Если нужна общая логика малых улучшений, стоит разобрать канбан-метод.
Что закрепить в рабочем порядке
Закреплять стоит механизм, который выполнил заранее записанное правило в двух последовательных периодах и не ухудшил защитный показатель. В закупке это может быть утверждённый перечень обязательных данных перед передачей заявки. Команда обновляет инструкцию, шаблон или правило приёмки и сообщает участникам, с какого момента оно действует.
В карточке остаются ссылка на новую версию правила, основание решения и дата следующей проверки. Завершение эксперимента не означает, что процесс больше не изменится: новый поток заявок или требования могут сделать прежнее решение слабее.
Когда изменить гипотезу
Если результат не подтвердился, команда возвращается к проблеме. Возможно, чек-лист не влияет на возвраты, причина находится на другом этапе или выбранный показатель не отражает сбой. В следующем цикле меняют один элемент: причину, изменение, границу пилота или способ измерения.
Несколько правок одновременно снова скроют механизм результата. Отрицательный вывод с сохранёнными данными полезнее уверенного рассказа без проверяемого основания.
Как показать этапы на канбан-доске
Для учебной схемы подойдут колонки «Наблюдение», «План», «Пилот», «Проверка» и «Решение». Одна карточка эксперимента перемещается по ним по мере работы. Последовательность колонок показывает состояние проверки, но не является универсальным шаблоном: команда может собрать канбан-доску под свой процесс.
На доске не нужно создавать отдельную карточку для каждого слова PDCA. Целостная карточка лучше сохраняет связь между проблемой, гипотезой, фактом и выводом. Отдельные рабочие задачи допустимы, если они связаны с экспериментом и не превращают его описание во второй реестр.
Какие колонки нужны учебной схеме
«Наблюдение» хранит подтверждённый сбой и источник. В «Плане» команда фиксирует гипотезу, показатель и границы. «Пилот» показывает, что изменение применяется на выбранном участке. В «Проверке» собирают итоговые данные. «Решение» содержит один из четырёх исходов: закрепить, скорректировать, отменить или повторить.
Колонки показывают этап работы, а не качество результата. Карточка в «Решении» может содержать отрицательный вывод, и это нормальное завершение цикла.
Что хранить в карточке эксперимента
В описании остаются проблема, гипотеза, исходный факт, ожидаемый результат, источник и защитное условие. Исполнителей и сроки задают средствами задачи. Метки обозначают участок процесса, чек-лист сохраняет шаги пилота, вложения — исходные материалы. Фильтры позволяют отбирать карточки по исполнителю, создателю, статусу, дате и меткам. Для поиска экспериментов одного типа заранее задают отдельную метку.
Канбано вручную отражает ход PDCA. Сервис не рассчитывает эффект, статистическую значимость и новый стандарт автоматически. Решение принимает владелец результата после проверки рабочего источника.
Какие ошибки ломают цикл
Сбой цикла может возникнуть ещё до пилота. Команда начинает с любимого решения, выбирает несколько изменений сразу или вспоминает о показателе после запуска. В результате карточка закрывается, но связь между действием и результатом остаётся недоказанной.
Почему нельзя начинать с готового решения
Готовое решение сужает поиск причин. Если команда сразу решила внедрить чек-лист, она будет собирать аргументы в его пользу и может пропустить другой источник возвратов. Сначала записывают наблюдаемый разрыв и данные, затем формулируют проверяемую гипотезу.
Первый цикл не обязан дать окончательный ответ. Его задача — уменьшить неопределённость и подготовить следующее решение на фактах.
Почему отметка «сделано» не заменяет проверку
Статус «Готово» подтверждает, что исполнители провели запланированное действие. Он не показывает, сократились ли возвраты, изменился ли срок и сохранилось ли качество решений. Для эффекта нужен повторный замер из того же источника.
Перед завершением первого цикла проверьте семь пунктов:
- проблема описана наблюдаемым фактом;
- выбраны один показатель и защитное условие;
- гипотеза меняет один элемент процесса;
- пилот ограничен по участникам, типу работы и периоду;
- отклонения сохранены без исправления задним числом;
- итог сравнен с исходной точкой;
- владелец принял и записал решение для следующего цикла.
Рабочий PDCA заканчивается ясным выводом и новой точкой Plan. Доска делает путь эксперимента видимым, а данные защищают команду от ложного успеха. Когда проблема, показатель и границы пилота согласованы, можно создать доску эксперимента и оформить первую карточку.