Модель зрелости процессов (CMM): 5 уровней

Автор

Уоттс Хамфри и Институт программной инженерии (SEI) Университета Карнеги — Меллона; Марк Полк с коллегами (версия 1.1), 1986 (начало работы); 1991 (CMM); 1993 (версия 1.1)

Уровень

401 · Экспертный

Подходит

растущая компания, корпорация

Время на внедрение

одна рабочая сессия, чтобы оценить 3–5 процессов, затем квартал, чтобы поднять один из них на уровень

Что понадобится

список из 3–5 повторяющихся процессов, например запуск кампании, еженедельная отчётность и передача лида в продажи · 5–10 последних запусков каждого процесса с плановыми и фактическими датами и результатами · по одному человеку на процесс, который отвечает за него и может менять, как он устроен

Модель зрелости процессов (Capability Maturity Model, CMM) — пятиуровневая шкала, по которой оценивают, насколько предсказуемо и управляемо работают процессы организации. Институт программной инженерии (SEI) при Университете Карнеги — Меллона начал эту работу в ноябре 1986 года, чтобы правительство США могло оценивать подрядчиков, которые пишут ПО. Уоттс Хамфри описал рамку зрелости в 1988 году, а затем в книге 1989 года. SEI опубликовал модель в 1991-м, а стандартную версию 1.1 выпустил в 1993 году.

Сама идея появилась раньше модели для ПО. По отчёту SEI, рамку вдохновила сетка зрелости управления качеством Филипа Кросби из книги Quality Is Free. К ПО её приспособил Рон Радис (Ron Radice) с коллегами из IBM под руководством Хамфри, а в 1986 году Хамфри принёс её в SEI.

Какие пять уровней у модели зрелости процессов?

Уровни называются Initial, Repeatable, Defined, Managed и Optimizing (начальный, повторяемый, определённый, управляемый, оптимизируемый), и каждый описывает проблему, которая доминирует на этой ступени. Отчёт 1993 года называет шкалу порядковой: более высокий уровень значит большую зрелость, но расстояние между уровнями шкала не обещает.

Названия CMMI взяты у CMMI Institute, который к тому же выделяет уровень 0, Incomplete.

Как уровень меняет результаты?

Чем выше зрелость, тем меньше разрыв между планом и фактом. Отчёт SEI называет три эффекта: фактические результаты приближаются к целям, разброс вокруг цели сокращается, а сами цели становятся лучше, потому что переделок меньше. На уровне 1 команда, которая планирует десять похожих запусков на одну дату, получит их разбросанными по всему календарю.

Каждый уровень добавляет и конкретные практики. Модель собирает их в 18 ключевых областей процессов: шесть на уровне 2 (например, управление требованиями, планирование проекта и обеспечение качества), семь на уровне 3, две на уровне 4 и три на уровне 5. Чтобы получить уровень, организация должна выполнить все ключевые области этого уровня.

Почему нельзя перескакивать через уровни?

По мнению SEI, пропуск уровней контрпродуктивен: каждый служит основой для следующего. Организация первого уровня, которая пытается ввести стандартный процесс раньше, чем научится планировать и отслеживать проекты, обычно терпит неудачу: менеджеры тонут в давлении сроков и бюджета. Измерения на уровне 4 опираются на определённые процессы, потому что без них нет общей основы, по которой читать числа.

Отчёт добавляет оговорку. Команда первого уровня может применять практику более высокого уровня, например взаимные проверки (peer review), и получать от неё пользу. Просто полный эффект такая практика даёт только тогда, когда под ней есть фундамент.

Подтверждают ли это данные?

Отчасти. В исследовании SEI 1994 года по 13 организациям Хербслеб с коллегами нашли медианный рост производительности 35% в год, медианное снижение числа сообщений о дефектах после релиза на 39% в год и медианную отдачу 5,0 на каждый потраченный доллар. Авторы предупреждают: у всех участников опыт был хорошим, на результат влияли и другие факторы, а цифры показывают, что возможно в благоприятной среде. Опрос 1996 года Хербслеба и Голденсона связал зрелость с лучшими результатами, при этом усилия обычно занимали больше времени и стоили дороже, чем ожидалось.

У критиков тоже есть аргументы. Джеймс Бах (1994) утверждал, что модель преклоняется перед процессом и забывает о людях, а организации гонятся за рейтингами. В 1991 году Боллинджер и Макгоуэн опубликовали критический разбор оценок возможностей SEI, а в 1997-м Файяд и Лайтинен в Communications of the ACM спросили, не расточительна ли оценка процессов. Позже и сам SEI выпустил заметку о том, что CMMI и гибкие методы можно применять вместе.

Как применить модель в операционном маркетинге?

Воспринимайте пять уровней как очерёдность шагов, а не как сертификат. SEI писал версию 1.1 с расчётом на крупных правительственных подрядчиков и сам говорил, что остальным организациям её надо подстраивать. Таблица ниже — наше собственное прочтение, а не продукт SEI или CMMI.

Помните два ограничения. Первое: оценивайте процессы по отдельности, как это делает аудит процессов Хаммера для бизнес-процессов в целом. Второе: CMM не охватывает людей. Для найма, обучения и удержания SEI выпустил отдельную People CMM в 1995 году.

Отличается модель и от ступенчатых шкал для данных и цифрового маркетинга. Модель зрелости данных оценивает, как данные собирают и используют, а исследование зрелости цифрового маркетинга от BCG — технологии и команды. CMM оценивает, насколько предсказуема сама работа. Уровень 5 описывает непрерывное улучшение — идею, на которой стоят кайдзен и цикл PDCA; сам отчёт SEI ссылается для этой логики на работу Имаи о малых эволюционных шагах. Пёппельбус и Рёглингер насчитали сотни моделей зрелости после CMM, а Беккер с коллегами отмечают, что многие плохо документированы, поэтому проверяйте, что именно утверждает каждая ступень.

План Growth Lab начинается с оценки нескольких процессов, которые определяют скорость запуска и доверие к отчётам.

Как применять: Модель зрелости процессов (CMM): 5 уровней по шагам

1. Берите процессы, а не отделы. Уровень зрелости есть у процесса, а не у команды. Выпишите 3–5 повторяющихся процессов: запуск кампании, еженедельный отчёт по результатам, передача лида в продажи. Результат: короткий список процессов с названиями и владельцами.
2. Определите единицу работы. CMM сравнивает проекты с их целями. В маркетинге назовите единицу сами: одна кампания, один отчёт, одна партия лидов. Результат: для каждого процесса понятная вещь, которую можно посчитать и сравнить между запусками.
3. Оцените каждый процесс по фактам. Возьмите 5–10 последних запусков и сравните плановые даты и результаты с фактическими. Большие необъяснимые расхождения и результат, который зависит от исполнителя, указывают на уровень 1. Письменные планы, по которым велось отслеживание, — на уровень 2. Результат: один уровень на процесс, и за каждым стоит история запусков.
4. Сначала закройте пробелы уровня 2. В отчёте SEI сказано, что перескакивать через уровни непродуктивно: каждый служит основой для следующего. Прежде чем писать стандарт для всей компании, добейтесь, чтобы у каждого запуска были план, владелец и отслеживаемый результат. Результат: нет процесса, в котором не хватает плана или владельца.
5. Напишите стандарт один раз. На уровне 3 у организации есть один задокументированный способ работы, который каждый проект подстраивает под себя. Для кампаний это единый шаблон брифа, единые правила именования и единый путь согласования. Результат: один стандарт, на котором обучают новых сотрудников.
6. Измеряйте только там, где хватает объёма. Уровень 4 требует количественных границ, а для них нужно достаточно запусков. Следите за несколькими числами, например за днями от брифа до запуска или за ошибками разметки на запуск, и только в процессах, которые идут раз в неделю или чаще. Результат: диапазон контроля для одного-двух процессов или честное решение остаться на уровне 3.
7. Пересматривайте оценку раз в полгода. Каждый раз используйте те же правила учёта фактов и тех же людей. Результат: динамика по каждому процессу, из которой видно, растёт ли сама работа или только документация.

Примеры

Программное подразделение Hughes Aircraft, 1987–1990

Публичный случай из [исследования SEI о выгодах 1994 года](https://www.sei.cmu.edu/library/benefits-of-cmm-based-software-process-improvement-initial-results). В 1987 году первая оценка при участии SEI отнесла подразделение программной инженерии Hughes Aircraft, около 500 специалистов, ко второму уровню. Вторая оценка в 1990 году признала его уверенным третьим уровнем. По отчёту SEI, двухлетний переход обошёлся в 75 человеко-месяцев плюс $45 000 за саму оценку; среди перемен названы группа по процессам, обучение по ключевым темам и всесторонняя система технических проверок.

Передача лидов в сети стоматологических клиник

Иллюстративный пример, реальная клиника не подразумевается. В пяти клиниках заявки с сайта передают администраторам по-своему. За 10 недель время обратного звонка колеблется от 4 минут до 3 суток, а лучшие результаты показывает одна сотрудница регистратуры, которая весной увольняется. Это уровень 1: итог зависит от человека. Первый шаг — уровень 2, а не новая CRM. Каждая клиника записывает, кто перезванивает и за какое время, и ведёт журнал фактического времени. Только после этого имеет смысл вводить общий скрипт.

Проверка промо в платёжной компании

Иллюстративный пример, реальная компания не подразумевается. Каждое объявление и письмо о финансовом продукте проходит проверку комплаенса до выхода. У маркетинга есть чек-лист, но в 3 из последних 12 запусков проверку пропустили, когда срок поехал. Процесс записан, но под давлением не выполняется; в отчёте SEI это признак того, что процесс ещё не закрепился в организации. Исправление — владелец, жёсткий барьер в инструменте запуска и счётчик пропущенных проверок, и лишь потом разговоры об оптимизации.

Когда применять

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

Когда не применять

Не берите её, если команда небольшая и делает несколько разовых кампаний в год: стандартизировать нечего, измерять тоже. Не превращайте уровень в KPI или в цель сертификации, как у подрядчиков. Модель — диагностика работы, а не оценка людей.

Частые ошибки

• Гнаться за уровнем. Джеймс Бах в 1994 году назвал это завистью к уровню: организации целятся в следующий рейтинг вместо проблемы, которую рейтинг должен был показать.
• Ставить одну оценку на весь отдел. Передача лидов может быть на уровне 1, а еженедельная отчётность — на уровне 3, и среднее скрывает тот процесс, который болит.
• Писать стандарт для всей компании (уровень 3) до того, как появились планы и отслеживание (уровень 2). По отчёту SEI, такие попытки обычно проваливаются: менеджеры тонут в давлении сроков и бюджета.
• Применять статистику уровня 4 к процессу, который идёт шесть раз в год. На таком числе запусков диапазоны вокруг среднего ничего не говорят.
• Считать процесс единственным рычагом. Сама CMM оговаривает, что не отвечает на вопрос, как нанимать, мотивировать и удерживать сильных людей.

Вопросы и ответы

Какие пять уровней в модели зрелости процессов?

В версии SEI 1993 года это Initial, Repeatable, Defined, Managed и Optimizing: начальный, повторяемый, определённый, управляемый и оптимизируемый. SEI описывает их возможности как непредсказуемые, дисциплинированные, стандартные и последовательные, предсказуемые и постоянно улучшающиеся. В CMMI, преемнице модели, тоже пять уровней, но уровень 2 назван Managed, а уровень 4 — Quantitatively Managed.

Чем CMM отличается от CMMI?

CMM — исходная модель для разработки ПО, которую SEI опубликовал в 1991 году. По данным SEI, CMMI выросла из неё и сегодня охватывает области за пределами ПО. Её поддерживает CMMI Institute, который 1 марта 2016 года перешёл из Карнеги — Меллона в ISACA; в 2023 году к модели добавили домены Data Management, People Management и Virtual Work.

Можно ли использовать модель зрелости процессов вне разработки ПО?

Да, но с осторожностью. SEI писал CMM для крупных правительственных подрядчиков по ПО и оговаривал, что небольшим и другим организациям её нужно подстраивать. Другие авторы переносили логику на управление персоналом, данные и бизнес-процессы. Маркетинговой команде подойдёт пятиступенчатая логика, а не 18 областей процессов из мира ПО.

Улучшает ли результаты более высокий уровень CMM?

Данные скорее положительные, но ограниченные. В исследовании SEI 1994 года по 13 организациям медианный рост производительности составил 35% в год, а отдача — 5,0 на вложенный доллар, но у всех участников опыт был хорошим, и сами авторы называют цифры ориентиром возможного. Опрос Хербслеба и Голденсона 1996 года связал зрелость с лучшими результатами.

Источники

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024, Software Engineering Institute, 1993
2. Software Engineering Institute, Capability Maturity Model for Software, Version 1.1, library record
3. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, Capability Maturity Model, Version 1.1, IEEE Software 10(4), 1993
4. Watts S. Humphrey, Characterizing the Software Process: A Maturity Framework, IEEE Software 5(2), 1988
5. Watts S. Humphrey, Managing the Software Process, Addison-Wesley, 1989, Internet Archive record
6. Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain, McGraw-Hill, 1979, Internet Archive record
7. Software Engineering Institute, Transforming Software Quality Assessment (history of the Software CMM and CMMI)
8. James Herbsleb, Anita Carleton, James Rozum, Jane Siegel, David Zubrow, Benefits of CMM-Based Software Process Improvement: Initial Results, CMU/SEI-94-TR-013, 1994
9. James Herbsleb, Dennis Goldenson, A Systematic Survey of CMM Experience and Results, 18th International Conference on Software Engineering, 1996
10. James Bach, The Immaturity of the CMM, American Programmer 7(9), 1994, republished on Satisfice
11. Tom Bollinger, Clement McGowan, A Critical Look at Software Capability Evaluations, IEEE Software 8(4), 1991
12. Mohamed Fayad, Mauri Laitinen, Process Assessment Considered Wasteful, Communications of the ACM 40(11), 1997
13. Frederick P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer 20(4), 1987
14. Bill Curtis, William E. Hefley, Sally Miller, People Capability Maturity Model, CMU/SEI-95-MM-002, 1995
15. Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum, CMMI or Agile: Why Not Embrace Both!, CMU/SEI-2008-TN-003, 2008
16. CMMI Institute, Maturity levels
17. CMMI Institute and ISACA, FAQs on the acquisition, 3 March 2016
18. ISACA, ISACA updates CMMI model with three new domains, April 2023
19. CMMI Institute, CMMI performance solution
20. Michael Hammer, The Process Audit, Harvard Business Review, April 2007
21. BCG, Dominic Field, Shilpa Patel, Henry Leon, Dividends of digital marketing maturity, 2019
22. Jörg Becker, Ralf Knackstedt, Jens Pöppelbuß, Developing Maturity Models for IT Management, Business and Information Systems Engineering 1(3), 2009
23. Jens Pöppelbuß, Maximilian Röglinger, What Makes a Useful Maturity Model?, ECIS 2011

Обновлено 20 октября 2026

Илья ПушинОснователь PUSHERS & COO Fintech ServiceИлья строит операционные системы для растущих компаний в медицине и финтехе. С 2021 года руководит трансграничными платежами в ARBI Exchange, лицензированном обменнике в Таиланде, включая KYC, AML и выход в новые юрисдикции.Об автореLinkedIn