Портал №1 по управлению цифровыми
и информационными технологиями

Plan – Do – Check – What?

Э.Деминг В любой области существуют понятия, которые известны почти всем. Например, я уверен, что все посетители нашего портала слышали, хотя бы разок, про такую штуку, как цикл Деминга (он же  PDCA-цикл). Ничего сложного в PDCA в общем-то нет – четыре шага: Планируй, Выполняй, Проверяй, Корректируй. Однако недавно я задумался над вопросом, который раньше, почему-то, не приходил мне в голову: «А чем, собственно, отличаются шаги цикла Act и Plan?».

И ведь действительно: сначала мы планируем (Plan), затем выполняем (Do), далее проверяем (Check). А что дальше? Ищем причины расхождений? Нет, это Check. Изменяем наш план? Но это же Plan! Так в чем же смысл этого четвертого шага?

pdcaВот здесь написано, что сам Деминг при описании цикла (который он, кстати, называл циклом Шухарта) говорил, что шаг Act может заключаться либо в принятии изменений для исправления расхождений, выявленных на стадии Check, либо в игнорировании этих расхождений, либо в повторном запуске цикла. Насколько я понимаю, первые два варианта ведут к завершению цикла, а в последнем случае шага Act как такового не существует – он заменяется повторным выполнением P-D-C. Иными словами шаг Act заключается в ответе на вопрос: “Что же делать дальше?”. Чтобы сформировать более понятную картинку, попробуем разобрать пример.

Допустим, мы занимаемся совершенствованием процесса управления инцидентами, который функционирует в нашей компании и, проведя в очередной раз опрос пользователей, мы узнали, что большинство из них не довольны тем, что техническая поддержка очень долго исправляет возникающие сбои. Т.е. основная масса даже самых элементарных запросов выполняются очень долго. Тут-то мы и начинаем раскручивать PDCA-карусельку.

Планирование. Для того, чтобы решить возникшую задачу, мы вспоминаем про такой полезный инструмент, как Expanded Incident Lifecycle. Разбив время жизни инцидента на определенные этапы, и измерив среднюю продолжительность каждого из них, мы приходим к выводу, что довольно большую долю времени занимает нахождение инцидента в очереди. Чтобы с этим справиться мы просим всех специалистов при обнаружении “простых” инцидентов решать их сразу, откладывая решение “сложных” инцидентов. Для контроля же мы можем использовать метрику скорости реакции, например вот такую.

Выполнение. На протяжении некоторого периода времени мы работаем по придуманной схеме. Если наше предположение верно, то ситуация должна улучшиться.

Проверка. По истечении некоторого времени мы проверяем, улучшилась ли ситуация. Для этого мы опять проводим опрос пользователей, и выясняется, что хоть количество недовольных и сократилось, в ряде случаев (иногда очень серьезных) пользователи ждали решения сбоев чрезмерно долго. Причиной такой ситуации оказался тот факт, что из-за большого количества «простых» инцидентов, «сложные» порой откладывались в сторонку и ждали очень долго. 

Корректировка. Поскольку проведенное улучшение не устраивает нас в полной мере, мы принимаем решение запустить цикл заново и учесть все находки первого прогона цикла. В этом заключается шаг Act на данном этапе.

Планирование 2. Зная проблему «сложных» и «простых» инцидентов мы принимаем решение выделить подгруппу сотрудников, которая будет заниматься решением только «простых» инцидентов. Для них можно поставить в качестве KPI количество решенных инцидентов (в связке с количеством возвращенных).

Выполнение 2. Работаем еще некоторое время по новой схеме.

Проверка 2. Через некоторое время опять опрашиваем пользователей и видим, что неудовлетворенность скоростью устранения сбоев практически исчезла.

Корректировка 2. Поскольку результаты наших улучшений нас устраивают, шаг «корректировка» будет заключаться в завершении цикла без каких-либо дополнительных изменений.

Прошу не обращать внимания на некоторую надуманность примера. Жизнь, конечно же, немного более сложная и многогранная. Тем не менее этот пример неплохо демонстрирует мое текущее понимание того, что такое шаг Act.

А вы согласны с таким объяснением? Если нет, расскажите свою версию. 

UDPATE: Переосмыслил для себя понятие цикла Деминга. Теперь считаю верной вот такую картинку. Спасибо, коллеги!

Комментариев: 23

  • Юрий

    Попробуйте переставить буквы местами: apdc

    a-оценка рисков,оценка соответствия,оценка достижения целей,…

    P-планирование обработки рисков, приведения к соответствию, план работы подразделения, …

    D- реализация планов

    с- контроль и мониторинг рисков (kri), kpi,..

     

    Как считаете, в таком исполнении “а” нужен? 🙂

    • Интересный взгляд.

      Мне, правда, казалось, что оценка и определение целей относятся больше к Plan, нежели Act.

      Если же говорить про оценку расхождения план-факт, или оценку достижения целей, то это Check.

      Не так?

    • Здорово. Т.е. если совсем простыми словами объяснять (уж извините, что все упрощаю), то получается:

      • A – продумать и сравнить различные варианты реализации;
      • P – выбрать один из вариантов и продумать его детально;
      • D – реализовать;
      • С – оценить результат.

      Верно я понял?
      Да, так пожалуй можно разделить. Первый шаг более стратегический, второй более тактический. Более того это будет полезно, если за A и P будут отвечать разные люди.

  • Act – принятие решения, Plan – планирование реализации.

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

    Скажем, Act – решение о переводе call-центра из Москвы в Воронеж. Или о построении портала самообслуживания для пользователей. Или об изменении технологии мониторинга того или иного объекта. Тут без планирования, наверно, уже не обойтись – состав и порядок действий из решения сам собой не вытекает. Более того, в приведенных мной примерах вероятно Act сделают одни люди (или даже один человек), а Plan будут делать другие.

    • Act — принятие решения, Plan — планирование реализации.

      Перед этим утверждением не хватает вводной части, такой как: “Мне кажется, что…” или “Возможно, что…“, или “Есть мнение, что…“.

      Ведь тот же стандарт ISO 20000 не считает, что Act – это лишь принятие решения.

      Цитата:

      Act: taking actions to continually improve performance of the SMS and the services.

      Если же почитать раздел 4.5.5 того же стандарта, где Act расписан чуть более подробно, то выяснится, что по мнению авторов Act – это почти то же самое, что CSI, и на этом шаге предполагается выявлять, документировать, оценивать, утверждать, приоритизировать, управлять, измерять и отчитываться об улучшениях, являющихся следствиями предыдущего шага, Check.

      • Ведь тот же стандарт ISO 20000 не считает, что Act — это лишь принятие решения.

        Это да. Но ISO – не первоисточник. И, насколько мне известно (есть мнение, мне кажется, я думаю), стандарты ISO (что 9000, что 20000) описывают цикл Деминга весьма вольно, как некий философский принцип, а не как методику (в отличие от самого Деминга). А если посмотреть, например, на картинку в посте, то Act представляет собой именно фазу принятия решения по итогам проверки и изучения полученных результатов.

        Вообще, как я понимаю (есть мнение, мне кажется, я думаю), изначально методы Шухарта, а затем Деминга относились к более низкоуровневым, производственным процессам, где результат непосредственно следует за действием. И Act – было действие контролера на конвейере. На уровень универсальных систем управления качеством все это обобщалось сильно позже – в 90-х годах. Так, видимо (есть мнение, мне кажется, я думаю), и появились варианты и трактовки.

        • Но ISO — не первоисточник

          Безусловно.

          Можно посмотреть и на первоисточник. Вот что пишет тов. Шухарт в своей книге 1939 года:

          Broadly speaking, there are three steps in quality control process: the specification of what is wanted, the production of things to satisfy the specification, and the inspection of the things produced to see if they satisfy the specification.

          То есть в первоисточнике есть P, D и C, но пока нет A. Условная буква A появилась тогда, когда тов. Деминг в 1950 году заменил три слова Шухарта на другие три слова и добавил четвёртое:

          Step 1 – Design, Step 2 – Produce, Step 3 – Sell , Step 4 – Redesign through marketing research.

          А потом его поправили японцы, которым идея очень понравилась, и цикл стал называться Plan-Do-Check-Act.

          Если же посмотреть на более поздние работы Деминга (1993), когда он переименовал цикл в Plan-Do-Study-Act, то становится понятно, что Act – это не только не “принятие решения”, но иногда – выполнение запланированного, протестированного и скорректированного изменения:

          • Если же посмотреть на более поздние работы Деминга (1993)

            О чем я и писал – 90-е годы.

            становится понятно, что Act — это не только не «принятие решения», но иногда – выполнение … изменения

            Почему выполнение? Adopt – это разве выполнение? Я переводил это как принятие выполненного изменения. То есть три варианта решений на фазе Act я перевожу как “оставить изменение, его результаты удовлетоврительны” (Adopt), “отказаться от него, поскольку результаты неудовлетворительны” (Abandon) или “протестировать еще раз, поскольку результаты пока недостаточно ясны” (Run … again). Не так?

    • Очень интересно.
      Получается, что для простых задач вполне хватает PDC (или DCA). Если решать более сложные или глобальные проблемы, то следует добавить “стратегический шаг” и получится PDCA. А для совсем сложных задач можно еще более детальное разделение сделать (например, использовать DMAIC из SixSigma или 7-step improvement process из ITIL). Т.е. количество шагов зависит от масштаба и сложности задачи.

      • Интересно ещё и то, как меняется наше отношение к таким открытиям-изобретениям, вроде PDCA, с течением времени. То, что раньше считалось сильной мыслью, теперь стало само собой разумеющимся.

        Ведь, честно говоря, в идее PDCA нет больших откровений (что, конечно же, не делает идею слабой или не нужной).

        Хорошая русская пословица “семь раз отмерь, один – отреж”, в общем-то, про тоже.

        Или как нас учили в школе на уроках математики: решение задачи начинаем со слова “Дано”, затем переписываем что нам известно из условия, только затем начинаем решать.

        Тут то же самое: не нужно сразу бросаться что-то делать ( D ), нужно сначала подумать ( Р ).

        Сделав что-то ( D ) не следует без оснований полагать, что это что-то принесло пользу, а нужно проверить ( С ).

        Проверив ( С ), нужно устранить расхождения между тем, что хотели и тем, что получили ( А ). Ну или принять решение, что всё напрасно, и пойти спать. Или принять решение, что выбранные ранее P и D толку не дали, и “запустить цикл заново”. Если же на шаге D был только пилот, то с учётом С на шаге А можно и доделать всё дело.

        Вроде банальности, да?

  • Андрей

    “Есть у революции начало, нет у революции конца!” Из старой советской песни:)

    Тут важно определиться по поводу того, что есть триггер, запускающий цикл. Если в качестве триггера выступает событие – жалоба пользователя, нагоняй от руководства и т.д., то Act обязательно должен быть. Любой, чтобы как минимум отчитаться о принятых мерах. Если же ИТ подразделение достигло вершин совершенства, то тут уместнее говорить о непрервном циле, или, как это модно сейчас – CSI (Continual – непрерывное совершенствование). Тут действительно возможна ситуация, при которой плановый анализ не позволил выявить причин, требующих корректирующих действий и фазу Act можно пропустить до следующего раза. Правда, если выставить KPI по Act, то фаза будет присутствовать всегда, пусть бестолковая, но будет, чтобы достичь великих значений KPI.

  • Вспоминая, что Act иногда заменяют на Adjust, мне симпатичен такой взгляд на PDCA:

    Альтернативный PDCA

    Да, это не очень похоже на традиционный цикл с переходом от Act к Plan.

    Зато мне так понятнее 🙂

    • Очень хорошая картинка, как мне кажется. Т.е. мы оставляем цикл Do-Check-Act, а про Plan говорим, что это некий “инициализирующий шаг”. Вот как раз такой подход у меня никакого смущения не вызывал, а наличие перехода между Act и Plan показалось странным и привело к раздумьям на эту тему.

  • Альберт

    Это непрерывный цикл и он не должен останавливаться. Даже если изменение нас устроило полностью, нужно его проверить в других условиях или перейти к следующему изменению. Иначе система рано или поздно себя изживет. Act = Adjust по сути 3 варианта: отказаться от изменения->принять изменение в существующих условиях->проверить изменение в других условиях.

    • Альберт, спасибо огромное за ваш комментарий! Я посмотрел на него, посмотрел еще раз на картинку из поста и, кажется, понял свою ошибку – я думал, что изменение, которое выполняется на стадии Act направлено на устранение разрыва между фактом и целью, которую мы ставим перед собой на фазе Plan. А ведь получается, что все совсем не так.

      Получается следующая картинка:

      Непрерывное совершенствование – это череда полезных изменений.
      Чтобы изменения были полезными, бесполезные изменения нужно отсеивать или превращать в полезные.
      Для этого мы каждое изменение планируем (P), выполняем (D), измеряем (C), причем желательно на небольшом масштабе или в тестовой среде (т.е. нам нужно провести эксперимент).
      В зависимости от результатов эксперимента мы либо принимаем изменение, либо откатываем все назад (отклоняем изменение), либо запускаем P-D-C еще раз (при этом на шаге P мы немного меняем условия эксперимента). Этот выбор и есть шаг Act.

      Так ведь?

  • Альберт

    Верно. Как заметили выше этот цикл применим для простых изменений. Если интересует расширенная версия то можно почитат про кайдзен. 

    Такие циклы хорошо представлять в виде колеса которое движется вперед и вверх, указывая при этом направление вращения (как в комментарии Олега).  

  • Elena

    Добрый день! Дмитрий и Олег, ваша интеллектуальная борьба (или даже гонка) зажигает и восхищает существующей свободой, не перерастающей в анархию или авторитаризм мысли – две крайности одного явления. У меня эта статья и комментарии спровоцировали видение вашей трактовки в новой области! Попробую теперь воплотить идею. Спасибо за Вызов!

    • Да мы-то что, это Степану спасибо за интересную заметку.

    • У меня эта статья и комментарии спровоцировали видение вашей трактовки в новой области!

      Елена, намекнёте, о чём речь? Страшно любпытно 😉

      • Елена

        Это не связано с IT или ITSM, а сдругой стороны – вся жизнь, мир, кажущаяся реальность – это сплошной ITSM. В любом случае management. А информация, она во всем; процесс ее потребления – уже услуга; предоставление или управление качеством – искусство, мастерство, умение.

        В моем случае речь о Life Management. У Вас (Cleverics) хотелось бы учиться ясности мысли! Позволите?


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM