Цикл управления процессом (Process Management Cycle)

Цикл управления процессом (Process Management Cycle) — операционный цикл управления конкретным бизнес-процессом: проектирование (или пересмотр), выполнение, измерение результативности, анализ отклонений и улучшение, после чего цикл начинается заново уже с обновлённой версией процесса. Он превращает процессный подход (Process Approach) из схемы в повторяющуюся управленческую практику: у процесса есть проект, владелец, показатели и регулярный разбор того, что показывают данные.

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

Материал разбирает: откуда взята логика цикла и как она соотносится с PDCA, жизненным циклом BPM и моделью зрелости процессов; методику Джона Джестона и Йохана Нелиса; каждый этап цикла с критериями «готово»; два документированных случая (пример радикального пересмотра процесса Ford, показывающий границу цикла; PEMM Хаммера как способ оценки зрелости управления процессами); метрики; критику; типовые ошибки; и что делает и чего не делает фрейм OrgDevTools. Смежные материалы: процессный подход, владельцы процессов, показатели эффективности процессов (PPI), реинжиниринг бизнес-процессов, модель зрелости процессов PEMM, цикл PDCA, Six Sigma DMAIC, сравнение AS-IS и TO-BE.

Происхождение и исследовательская база

Логика цикла развивалась в дисциплине управления бизнес-процессами (Business Process Management, BPM) как применение общего принципа непрерывного улучшения к отдельному процессу. Её корни — цикл Шухарта–Деминга (см. PDCA) и статистический контроль процессов (SPC): процесс нужно описать, измерять и улучшать на основе данных. В BPM-литературе этап за этапом это выражается «жизненным циклом» процесса; у разных авторов число и названия этапов различаются, поэтому «пять этапов» не следует считать единственным каноном.

Джестон и Нелис. Джон Джестон и Йохан Нелис — практики BPM и авторы книги «Business Process Management: Practical Guidelines to Successful Implementations» (первое издание — 2006; последующие издания — 2008, 2014 и позднее). Книга предлагает практический подход к внедрению BPM в организации: понимание процессов, проектирование, внедрение, встраивание непрерывного вовлечения в процессную культуру и инструменты для проектов. Цикл управления процессом в этом материале — практическая формулировка операционного контура из этой литературы: проектирование, выполнение, измерение, анализ, улучшение. Оговорка: точные названия и число этапов в конкретном издании книги могут отличаться; источник цитируется по описаниям, а не по дословному тексту.

Другие описания жизненного цикла. Дюма, Ла Роза, Мендлинг и Рейерс в учебнике «Fundamentals of Business Process Management» (2013, 2-е издание 2018) описывают жизненный цикл BPM от идентификации процессов через обнаружение (моделирование), анализ, перепроектирование и внедрение к мониторингу и контролю. По сути это тот же контур, но с явным этапом идентификации процессов и более подробной работой над моделями. Для практики важно не название этапа, а замкнутость: результаты мониторинга возвращаются в перепроектирование.

Зрелость управления процессами. Майкл Хаммер в статье «The Process Audit» (Harvard Business Review, апрель 2007) предложил модель PEMM (Process and Enterprise Maturity Model), в которой зрелость процесса определяют пять факторов: проект процесса (Design), исполнители (Performers), владелец процесса (Owner), инфраструктура (Infrastructure) и показатели (Metrics); отдельно оценивается зрелость предприятия (лидерство, культура, экспертиза, управление). Практический вывод для цикла: он не заработает без владельца, показателей и людей, умеющих улучшать; см. PEMM и назначение владельцев процессов.

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

Документированные кейсы

Кейс 1. Ford: когда цикла улучшения недостаточно (Хаммер, 1990)

Майкл Хаммер в статье «Reengineering Work: Don’t Automate, Obliterate» (Harvard Business Review, июль–август 1990) описывает отдел кредиторской задолженности Ford: он насчитывал порядка 500 человек, а сверка счёта, заказа на закупку и документа о приёмке товара была трудоёмкой. Руководство сначала предполагало сокращение штата на 20 % путём улучшения существующего процесса; сравнение с Mazda, где аналогичную работу, по описанию Хаммера, выполняла горстка сотрудников, показало разрыв на порядок. Ford пересмотрел логику процесса (платить при получении товара, а не при получении счёта, и сверять данные автоматически по немногим элементам), и штат в итоге сократился примерно на три четверти. Практический вывод: цикл управления процессом улучшает существующую логику постепенно; если сравнение показывает разрыв на порядок, нужен не очередной виток улучшения, а перепроектирование процесса (см. реинжиниринг бизнес-процессов). Оговорка: цифры (500, 20 %, порядка 125 человек) даны по статье Хаммера и вторичным пересказам, в которых приводятся разные значения; используйте их как порядок величины, а сам пример — как иллюстрацию границы метода.

Кейс 2. PEMM: компании оценивают зрелость управления процессами

В статье «The Process Audit» (2007) Хаммер сообщает, что модель PEMM использовали для оценки прогресса процессного преобразования такие компании, как Michelin, Shell, Tetra Pak, Clorox, Schneider National и CSAA; о каждом случае автор даёт краткое описание и рекомендации по модели. Практический вывод: до запуска цикла полезно оценить, есть ли у процесса владелец, проект, показатели, исполнители с нужными навыками и поддерживающая инфраструктура: иначе цикл будет формальным. Оговорка: это сообщения автора модели и участников; независимой оценки эффекта нет, а конкретные результаты по каждой компании в статье приведены не как измерения окупаемости.

Общий вывод из кейсов

Цикл управления процессом работает там, где есть владелец, показатели, регулярная привычка пересматривать процесс и понимание границы метода: небольшие отклонения и постепенные улучшения решаются циклом, радикальный разрыв с лучшими практиками — перепроектированием.

Ключевые идеи и принципы

1. Принцип: цикл управления процессом должен быть замкнутым, а не разомкнутой последовательностью.

   Этапы измерения и анализа результативности ценны только тогда, когда они реально приводят к конкретным изменениям в проектировании процесса. Разомкнутый цикл, где данные собираются и анализируются, но не приводят к улучшениям, теряет ключевое преимущество цикла. Признаки замкнутости: у каждого вывода анализа есть решение (внести изменение, отложить, отклонить с причиной), владелец и срок; изменения отражаются в новой версии процесса; результат изменения проверяется в следующем цикле измерения.

2. Принцип: цикл должен применяться регулярно и повторяемо, а не только при первоначальном проектировании процесса.

   Процесс, спроектированный однократно и никогда впоследствии не пересматриваемый на основе данных о фактической результативности, со временем перестаёт соответствовать реальным условиям (изменились клиенты, технологии, законодательство, состав людей). Периодичность выбирают по риску и скорости изменений: для критичных процессов — ежемесячный разбор показателей и квартальный пересмотр проекта; для стабильных — реже; для процессов, где изменения часты, — чаще. Календарь пересмотра фиксируют у владельца процесса.

3. Принцип: измеряемые показатели должны быть достаточно конкретными для выявления реальных узких мест процесса.

   Абстрактные, обобщённые показатели («качество», «эффективность») недостаточны для диагностики; измерение должно быть детализировано до этапов и типов отклонений, где возникают потери. Типовые показатели процесса: время цикла и время ожидания по этапам, доля работ с первого раза без переделок, доля заявок, выполненных в срок, стоимость выполнения единицы, число ошибок и их типы, загрузка ресурсов, удовлетворённость клиента процесса. См. показатели эффективности процессов и эффективность цикла процесса (PCE). Показатель без порога и владельца — не инструмент управления.

4. Принцип: у процесса есть владелец

   Владелец процесса отвечает за проект, показатели, регулярный разбор и решения об изменениях в сквозном процессе, а не в отдельном подразделении. Без владельца измерение превращается в отчёт, а улучшения — в конфликт функций (см. назначение владельцев процессов). В модели PEMM Хаммера владелец — один из пяти ключевых факторов зрелости.

5. Принцип: баланс частоты пересмотра и достаточности данных

   Слишком частый пересмотр без накопленных данных рискует реагировать на случайные колебания и делает процесс нестабильным; слишком редкий — упускает изменения. Практически: сначала определить, что считается нормальным разбросом показателя (контрольные карты), реагировать на устойчивые отклонения и тренды, а не на единичные выбросы; для быстрых экспериментов использовать малые циклы PDCA внутри более длинного цикла управления процессом.

6. Принцип: приоритизация процессов

   Организация не может вести полноценный цикл для всех процессов сразу. Выбирайте процессы по влиянию на клиента и результат, по величине потерь, по рискам и по готовности владельца; начните с одного-двух ключевых процессов (см. реестр процессов и сквозные процессы) и расширяйте по мере того, как цикл даёт результат.

7. Принцип: этапы цикла и критерии «готово»

   • Проектирование или пересмотр — процесс описан (шаги, роли, входы и выходы, правила, показатели, границы); для пересмотра — сравнение текущего (AS-IS) и целевого (TO-BE) состояний (см. AS-IS и TO-BE); версия процесса утверждена владельцем.

   • Выполнение — процесс выполняется по проекту; отклонения фиксируются, а не «исправляются молча».

   • Измерение — данные о показателях собираются по расписанию из систем или ручным учётом; определены источник, ответственный и периодичность.

   • Анализ — отклонения и узкие места объяснены причинами (диаграмма Парето, «пять почему», картирование), выводы записаны и связаны с решениями.

   • Улучшение — принято решение по каждому выводу, изменения внесены в новую версию процесса, обучены исполнители, назначено время проверки эффекта.

8. Принцип: метрики самого цикла

   Метрики: доля ключевых процессов с назначенным владельцем, актуальным проектом и показателями; доля показателей с порогом и источником данных; доля выводов анализа, по которым принято решение в срок; время от выявления отклонения до изменения процесса; доля изменений, эффект которых проверен; число пересмотров проекта процесса за период и доля просроченных пересмотров; динамика ключевых показателей процесса. Оговорка: нормативов нет; сравнивайте с собственной историей.

Ограничения, слепые зоны и критика

Типовые ошибки

1. Ошибка 1: собирают данные о результативности процесса и проводят анализ, но не вносят реальных изменений в процесс на их основе.

   Этапы измерения и анализа выполняются формально, цикл остаётся разомкнутым: изменения вносятся редко или со значительной задержкой, теряется ключевая ценность цикла.

   Как избежать

   у каждого вывода анализа фиксировать решение, владельца и срок; внесённые изменения отражать в новой версии процесса; проверять эффект в следующем измерении.

2. Ошибка 2: применяют цикл управления процессом только при первоначальном проектировании, не повторяя его регулярно.

   Процесс проектируется однократно и не пересматривается на основе данных эксплуатации, что приводит к его устареванию.

   Как избежать

   ввести регулярную периодичность полного цикла (календарь пересмотра у владельца процесса) и напоминания о просроченных пересмотрах.

3. Ошибка 3: измеряют результативность процесса слишком абстрактными показателями, не позволяющими выявить конкретные узкие места.

   Собираемые данные слишком обобщены для точной диагностики, что затрудняет целенаправленное улучшение.

   Как избежать

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

4. Ошибка 4: у процесса нет владельца.

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

   Как избежать

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

5. Ошибка 5: реагируют на каждое колебание показателя.

   Любой выброс считают сигналом и меняют процесс; процесс становится нестабильным, люди перестают верить изменениям.

   Как избежать

   определить нормальный разброс (контрольные карты), реагировать на устойчивые отклонения и тренды; накапливать данные до пересмотра.

6. Ошибка 6: применяют цикл улучшения там, где нужно перепроектирование.

   Процесс, который на порядок хуже лучших аналогов (как у Ford перед пересмотром), пытаются улучшить небольшими шагами; результат мал, время потеряно.

   Как избежать

   сравнить процесс с лучшими практиками и AS-IS с TO-BE; при разрыве на порядок рассматривать перепроектирование.

7. Ошибка 7: цикл ведут для всех процессов сразу.

   Ресурсы распыляются, качество измерения и анализа падает, цикл замирает.

   Как избежать

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

План внедрения

1. Неделя 1: определить или пересмотреть проектирование ключевого процесса

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

2. Неделя 2: настроить сбор конкретных, детализированных данных о результативности процесса

   Определить измеримые показатели по этапам и типам отклонений, для каждого — источник, ответственного, периодичность и порог; начать сбор.

3. Неделя 3: провести анализ собранных данных для выявления отклонений и возможностей улучшения

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

4. Неделя 4: внести конкретные изменения в проектирование процесса на основе результатов анализа

   Реализовать выявленные улучшения, выпустить новую версию процесса, обучить исполнителей и запланировать проверку эффекта в следующей итерации.

5. Далее: регулярная периодичность цикла

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

Как реализовать этот план с помощью фрейма «Цикл управления процессом (Process Management Cycle)» в OrgDevTools

Фрейм «Цикл управления процессом» в OrgDevTools — сетка из четырёх блоков-карточек в два столбца с тремя вкладками: «Карточки», «Визуализация» и «Итоги». Он построен на общем движке карточек: блоки не привязаны жёстко к неделям плана, порядок заполнения свободный, а в каждом блоке — список пунктов свободного текста (пункт добавляется кнопкой или клавишей Enter, пункты можно удалять).

• Вкладка «Карточки» — четыре блока. «Проектирование / пересмотр» (подсказка: «Последовательность шагов, роли и правила выполнения процесса» — неделя 1). «Измерение и анализ» («Достаточно детализированные показатели для выявления конкретных узких мест» — недели 2–3 и ошибка 3). «Замкнутость цикла» («Данные анализа реально приводят к изменениям процесса — не разомкнутая формальность» — неделя 4 и ошибка 1). «Частота пересмотра» («Баланс между своевременностью и достаточностью накопленных данных для устойчивых выводов» — ошибки 2 и 5 и календарь пересмотра).

• Вкладка «Визуализация» — столбчатая диаграмма: число заполненных пунктов в каждом из четырёх блоков.

• Вкладка «Итоги» — вердикт и кнопка «Создать задачу →» с заголовком по умолчанию «Продолжить проработку фрейма»; в описание задачи подставляются названия ещё не заполненных блоков (или «Все блоки заполнены — проверить и внедрить результат»).

• Вердикт считает только заполненные пункты: если пунктов нет ни в одном блоке — предлагает начать с любого блока; если какие-то блоки пусты — перечисляет их; если заполнены все четыре — сообщает общее число пунктов и самый насыщенный блок; зелёным он становится при одном пункте в каждом блоке.

• Чего фрейм не делает — он не проверяет, что цикл действительно замкнут (прежнее утверждение, что «Итоги» предупреждает о разомкнутом цикле, неверно: вердикт не анализирует содержание пунктов и не сопоставляет блоки), не имеет отдельных блоков для этапов «Выполнение» и «Улучшение» (о них пишите в блоках «Проектирование / пересмотр» и «Замкнутость цикла»), не считает показатели процесса, не хранит историю итераций и версий процесса, не напоминает о календаре пересмотра и не назначает владельца. Записывайте в блоки конкретно: шаги и роли процесса с версией и датой; показатели с порогом, источником и текущим значением; решения по выводам анализа с владельцем и сроком; периодичность цикла и дату следующего пересмотра.

Книги по теме

Джон Джестон, Йохан Нелис — «Business Process Management: Practical Guidelines to Successful Implementations» (первое издание 2006; последующие — 2008, 2014 и позднее). Практическое изложение внедрения BPM: понимание процессов, проектирование, встраивание непрерывной процессной практики, инструменты проектов.

Марлон Дюма, Марчелло Ла Роза, Ян Мендлинг, Хайо Рейерс — «Fundamentals of Business Process Management» (2013; 2-е изд. 2018). Жизненный цикл BPM от идентификации процессов до мониторинга; моделирование, анализ, перепроектирование.

Майкл Хаммер — «The Process Audit» (Harvard Business Review, 2007). Модель PEMM: как оценить зрелость процессов и предприятия.

Майкл Хаммер, Джеймс Чампи — «Reengineering the Corporation» (1993). Когда нужно не улучшать существующий процесс, а перепроектировать его; критика метода — в самой литературе о реинжиниринге.