BPMM (Business Process Maturity Model, OMG)

BPMM (Business Process Maturity Model, модель зрелости бизнес-процессов) — стандарт консорциума OMG, который описывает, как организация проходит путь от хаотичных, зависящих от героизма отдельных людей процессов до процессов, которые управляются статистически и непрерывно улучшаются. Модель отвечает на вопрос, который часто задают руководители: «Насколько наши процессы зрелы и что нужно сделать, чтобы стать лучше — и в каком порядке?» Особенность BPMM в том, что она не даёт списка «модных практик», а описывает ступени: каждая ступень закладывает фундамент для следующей, и пропустить её нельзя. В этой статье модель разобрана по первоисточнику — самой спецификации OMG (версия 1.0, 2008 год): история, пять уровней, 30 областей процесса, принципы, критика и работа с фреймом в OrgDevTools.

Что такое BPMM и зачем нужна модель зрелости процессов

В описании самой спецификации мотивация BPMM сформулирована практично: многие провалы корпоративных приложений стоили миллионов и объясняются не только технологиями, но и состоянием организации, в которую систему внедряют, — слабыми бизнес-процессами, на которые система нацелена. Улучшение готовности организации к внедрению технологий — исходная причина создания модели. Кроме того, спецификация называет ещё две задачи: помочь оценить способность поставщика, выполняющего аутсорсинговые ИТ- и бизнес-услуги, и дать руководству ориентиры по построению процессных основ, необходимых для гибкости и снижения операционных затрат.

Практический смысл модели — общий язык и «дорожная карта». Руководитель может сказать: «Мы на втором уровне — работа стабилизирована в подразделениях, но единого стандарта нет; следующий шаг — стандартизация», а не «нам нужно улучшить процессы вообще». Смежные подходы: процессный подход, процессная структура организации и офис бизнес-процессов.

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

Спецификация сама излагает родословную модели. Современное управление качеством обычно связывают с Уолтером Шухартом (Western Electric и Bell Laboratories, 1920–1930-е годы), развитым затем Эдвардсом Демингом и Джозефом Джураном. В 1970-х Филип Кросби предложил «решётку зрелости» управления качеством, чтобы улучшать качество ступенчато («Quality is Free», 1979). В 1980-х Уоттс Хамфри, работавший в IBM, а затем в Институте программной инженерии (SEI), разработал ступенчатую схему внедрения практик — Process Maturity Framework, ставшую основой первой модели зрелости CMM для программного обеспечения (версия 1.0 вышла в августе 1991 года), позднее развитой в CMMI. Подробнее о связи с CMMI — в статье «От цикла PDCA к модели CMMI».

Сама история BPMM началась в 2002 году. Руководитель технологий и операций южноафриканского банка Nedbank Барри Хор и его комитет увидели, что выгоды, полученные от CMM для программного обеспечения, можно получить и в остальных операциях банка: свыше 80% его бизнеса составляли операции, поэтому пропорционально выгода могла оказаться больше. Банк обратился к компании TeraQuest Metrics, разработка модели началась в апреле 2002 года — вначале как Service Operations CMM. Nedbank выделил финансирование и ресурсы и сразу решил, что модель будет доступна международному сообществу, а не станет внутренней разработкой. Применение в нескольких компаниях разных отраслей показало, что практики операционных услуг близки к практикам разработки, подготовки, развёртывания, эксплуатации и поддержки продуктов и услуг в любой отрасли, и Service Operations CMM развили в BPMM. В 2005 году TeraQuest Metrics приобрела Borland. Руководитель проекта BPMM — Чарльз Вебер; в авторский коллектив входили Вебер и Билл Кертис (Borland) и Тони Гардинер (Nedbank); в OMG версия 1.0 опубликована в июне 2008 года, авторы — Дж. Олден и Б. Кертис.

BPMM — не ИТ-стандарт «про программистов», а перенос идеи ступенчатой зрелости CMM на любые бизнес-процессы; исходным заказчиком выступил банк, а не разработчик ПО.

Академическая теория: принципы, пять уровней и 30 областей процесса

1. Принципы модели

   Спецификация формулирует четыре основополагающих принципа. Атрибуты процесса можно оценить, чтобы определить его способность вносить вклад в цели организации. Эффективные процессы не выживают, если организация недостаточно зрела, чтобы их поддерживать. Улучшение процессов лучше рассматривать как программу организационных изменений, поэтапно приводящую к всё более предсказуемым состояниям организационной способности. Каждая ступень (уровень зрелости) закладывает обязательный фундамент, на котором строятся дальнейшие улучшения. BPMM, как отмечено в документе, строго следует принципам Process Maturity Framework Хамфри и разработан соавторами CMM для программного обеспечения, CMMI и People CMM; его можно сопоставить с CMMI, но он написан для улучшения бизнес-процессов, которые чаще транзакционны и лучше описываются как потоки работ через организационные границы, а не как ограниченные проекты.

2. Пять уровней зрелости

   • Уровень 1 — Начальный (Initial). Бизнес-процессы выполняются непоследовательно, иногда стихийно, результаты трудно предсказать. Успех зависит от компетентности и «героизма» людей, а не от процесса.

   • Уровень 2 — Управляемый (Managed). Руководство стабилизирует работу в локальных рабочих единицах, чтобы она выполнялась повторяемо и удовлетворяла основным обязательствам группы. Но подразделения, делающие похожие задачи, могут работать по разным процедурам.

   • Уровень 3 — Стандартизированный (Standardized). Из лучших практик рабочих групп синтезируются общие стандартные процессы, а для разных бизнес-потребностей даются правила адаптации. Стандартные процессы дают эффект масштаба и основу для обучения на общих измерениях и опыте.

   • Уровень 4 — Предсказуемый (Predictable). Возможности, созданные стандартными процессами, используются и возвращаются в рабочие единицы. Результативность процессов управляется статистически по всему потоку работ, чтобы понимать и контролировать вариацию и предсказывать результаты по промежуточным состояниям.

   • Уровень 5 — Оптимизирующий (Innovating). Проактивные и оппортунистические улучшения ищут инновации, закрывающие разрыв между текущей способностью организации и тем, что нужно для достижения бизнес-целей.

3. Тридцать областей процесса (Process Areas)

   Уровни 2–5 состоят из областей процесса — наборов интегрированных лучших практик, которые говорят, что нужно делать, но не как: организации свободны выбирать методы достижения целей. Всего в BPMM 30 областей: 9 на втором уровне, 10 на третьем, 5 на четвёртом и 6 на пятом. Уровень определяется достижением целей, входящих в области процесса. Приведём по спецификации названия, чтобы показать глубину модели.

   • Уровень 2 (9 областей): лидерство в области процессов, управление бизнесом организации (governance), управление требованиями к рабочей единице, планирование и принятие обязательств, мониторинг и контроль, выполнение работы, управление конфигурацией рабочей единицы, управление закупками и подрядчиками (sourcing), обеспечение качества процесса и продукта.

   • Уровень 3 (10 областей): управление процессами организации, развитие компетенций, управление ресурсами, управление конфигурацией, управление бизнесом продуктов и услуг, управление работой, подготовка, развёртывание, эксплуатация и поддержка продуктов и услуг.

   • Уровень 4 (5 областей): управление общими активами организации, управление возможностями и результативностью, интеграция процессов продуктов и услуг, количественное управление продуктами и услугами, количественное управление процессами.

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

   Практический вывод: BPMM гораздо детальнее, чем простое «пять ступеней». На втором уровне модель уже требует управления требованиями, планирования, мониторинга, конфигураций, закупок и обеспечения качества — то есть базовой управленческой дисциплины в каждом подразделении. На третьем — единых стандартов и системы развития людей. Только затем имеет смысл говорить о статистическом управлении (уровень 4) и системных инновациях (уровень 5).

4. Что известно об эффективности моделей зрелости

   Из общих обзоров литературы по моделям зрелости процессов известны две вещи. Во-первых, после успеха CMMI появилось множество моделей зрелости (оценки называют до двухсот), но большинство лишь описывает, как организация выглядит на разных стадиях, и мало говорит о конкретных шагах перехода между уровнями. Во-вторых, доказательств, что рост уровня зрелости напрямую обеспечивает бизнес-результат, меньше, чем описаний: спецификация BPMM сама выделяет раздел «уровни зрелости и бизнес-результаты», но эмпирическая база лучше изучена для программной инженерии (CMM/CMMI), чем для бизнес-процессов в целом. Для практика это означает: используйте модель как диагностическую и коммуникационную рамку, а эффект проверяйте на собственных показателях.

   Зрелость нельзя купить и нельзя объявить: уровень существует, пока люди действительно работают так, как описано, и не исчезает при смене руководителя.

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

1. Принцип: уровни нельзя перепрыгнуть

   Каждый уровень закладывает фундамент следующего. Компания не может «включить» статистическое управление процессами, если нет стандартных процессов, а стандартные процессы бессмысленны, если работа в подразделениях нестабильна. Это защищает от типичного перекоса: показные продвинутые практики при отсутствии базовой дисциплины.

2. Принцип: зрелость — свойство организации, а не отдельного процесса

   Эффективные процессы не выживают без зрелой организации: важны лидерство, управление, компетенции, ресурсы и культура. Поэтому уже на втором уровне присутствуют области лидерства в процессах и управления бизнесом организации — не только «процедуры».

3. Принцип: модель говорит «что», а не «как»

   Области процесса описывают цели и практики, но не предписывают методы: организация сама выбирает способы их достижения. Поэтому BPMM сочетается с любыми инструментами — Lean Six Sigma, BPMN-моделированием, CBOK BPM — и не заменяет их.

4. Принцип: улучшение — программа организационных изменений

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

5. Принцип: оценка отделена от улучшения

   Оценка уровня (аппрейзал) — измерение, а не цель: уровень «засчитывается» только при достижении целей во всех областях уровня, а не по большинству. Формальное объявление высокого уровня без реального изменения практик — главный риск моделей зрелости.

Кейс: Nedbank — как модель зрелости пришла в банковские операции

Исторический кейс происхождения модели — сам Nedbank. По описанию в спецификации, в 2002 году руководство технологий и операций банка, уже получившее выгоды от CMM для программного обеспечения, решило применить те же принципы в остальных операциях; поскольку свыше 80% бизнеса составляли операции, ожидаемый эффект был пропорционально больше. Банк заказал модель у TeraQuest Metrics, выделил финансирование и ресурсы и договорился, что результат будет открытым для международного сообщества. Практический урок кейса — организационный, а не технический: сначала решение руководства и ресурсы, затем модель; и заинтересованность в том, чтобы модель стала стандартом, а не внутренней методикой одной компании. Количественных результатов внедрения в банке спецификация не приводит, поэтому мы их не приводим тоже; фиксируйте собственные показатели «до» и «после».

Как применять BPMM в организации

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

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

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

Типовые ошибки при работе с BPMM

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

   Компания объявляет третий уровень, потому что выполнила большинство практик; при этом часть обязательных областей второго уровня не закрыта — уровень не засчитывается.

   Как избежать

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

2. Ошибка 2: перепрыгивают через уровни.

   Внедряют статистическое управление или инновации, не стабилизировав работу и не стандартизировав процессы; данные ненадёжны, улучшения не закрепляются.

   Как избежать

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

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

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

   Как избежать

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

4. Ошибка 4: рассматривают модель как ИТ-проект.

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

   Как избежать

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

5. Ошибка 5: считают, что нужен максимальный уровень.

   Стремятся к пятому уровню, тратя ресурсы на практики, не нужные бизнесу.

   Как избежать

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

6. Ошибка 6: самооценка без независимой проверки.

   Подразделения оценивают себя сами и завышают результат.

   Как избежать

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

7. Ошибка 7: не связывают уровни с бизнес-результатами.

   Измеряют только «уровень», а не влияние на сроки, качество, стоимость и удовлетворённость.

   Как избежать

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

Метрики: как измерять прогресс по BPMM

Универсальных нормативов нет; фиксируйте динамику относительно собственной точки:

• Прогресс по областям процесса: доля выполненных областей процесса по уровням (по самооценке и независимой проверке).

• Стабильность работы: доля процессов с повторяемым результатом и выполнением обязательств; доля работ, выполняемых «в авральном режиме».

• Стандартизация: доля подразделений, работающих по единому стандартному процессу; число вариантов одного и того же процесса.

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

• Бизнес-результат: сроки, стоимость, дефекты, удовлетворённость клиентов до и после.

• Устойчивость: сколько уровней зрелости сохраняется при смене руководителей и команд.

Пять уровней — это не рейтинг, а последовательность фундаментов: сначала стабильность, потом стандарт, потом измерение, и только потом инновации.

План внедрения BPMM по месяцам

1. Месяц 1: область и самооценка

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

2. Месяц 2: приоритетные разрывы

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

3. Месяц 3: стабилизация

   Внедрите практики второго уровня в пилоте: требования к работе, планирование, мониторинг, управление конфигурацией, управление поставщиками, обеспечение качества. Оцените результат независимо.

4. Месяц 4: стандартизация и масштабирование

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

   Далее: раз в полгода повторяйте оценку, сравнивайте показатели с базовыми и обновляйте план перехода; для четвёртого и пятого уровней оцените наличие данных и потребность бизнеса.

Как реализовать план BPMM с помощью фрейма «BPMM» в OrgDevTools

Фрейм состоит из двух вкладок — «Уровни» и «Итоги». На вкладке «Уровни» перечислены уровни со второго по пятый (Управляемый, Стандартизированный, Предсказуемый, Оптимизирующий), у каждого — список областей процесса с флажками. Всего во фрейме 14 областей: 4 на втором уровне (управление требованиями к процессу, планирование и отслеживание работ, управление поставщиками процесса, обеспечение качества процесса), 4 на третьем, 3 на четвёртом и 3 на пятом. Формулировки — упрощённые: они передают смысл, но не совпадают с 30 областями процесса спецификации OMG.

• Месяц 1–2 — самооценка и разрывы: отметьте выполненные области второго уровня; фрейм показывает, сколько областей не хватает до следующего уровня.

• Месяц 3 — стабилизация: по мере внедрения практик отмечайте области второго уровня.

• Месяц 4 — стандартизация: отмечайте области третьего уровня.

Уровень считается достигнутым, если отмечены все области этого уровня и всех предыдущих: расчёт идёт последовательно от второго уровня, и при первой незавершённой области останавливается. Вердикт на вкладке «Итоги» показывает достигнутый уровень и число недостающих областей следующего; пока ничего не отмечено, он предлагает отметить выполненные области; на пятом уровне сообщает о максимуме. Уровни после незавершённого визуально приглушены и подписаны «заблокирован — завершите предыдущий уровень». Кнопка задачи создаёт задачу «Закрыть область процесса для следующего уровня BPMM».

Чего фрейм не делает. Он не содержит 30 официальных областей процесса и не проверяет достижение целей в каждой области — вы отмечаете флажки сами. «Блокировка» последующих уровней — визуальная подсказка (флажки остаются доступными), а вердикт не учитывает отмеченные области более высоких уровней, пока не закрыты предыдущие. Фрейм не фиксирует доказательства, не сравнивает подразделения и не оценивает бизнес-результат — для формального аппрейзала используйте спецификацию OMG.

Книги и материалы по теме BPMM

Object Management Group — «Business Process Maturity Model (BPMM), Version 1.0» (2008; авторы Дж. Олден и Б. Кертис). Первоисточник: принципы, пять уровней, 30 областей процесса.

Уоттс Хамфри — Process Maturity Framework (SEI, 1989). Основа всех моделей зрелости CMM/CMMI.

Марк Полк и соавторы — «Capability Maturity Model for Software» (SEI, 1993–1995). Модель зрелости, из которой выросла BPMM.

Филип Кросби — «Quality is Free» (1979). Решётка зрелости управления качеством.