Непрерывное развитие бизнеса: от цикла PDCA к модели CMMI

1. Базовый цикл управления: PDCA

Любое целенаправленное улучшение в организации подчиняется циклу PDCA (Plan — Do — Check — Act), известному также как цикл Шухарта — Деминга. Это фундаментальная модель, на которой построены стандарты менеджмента качества (ISO 9001, Six Sigma, TQM):

Цикл PDCA не имеет конечной точки. Каждое завершение цикла — это выход на новый уровень. Трек в OrgDevTools использует оба подхода: PDCA как ритм движения, CMMI — как шкалу, по которой видно, насколько далеко компания продвинулась.

2. Три вида деятельности с разным ритмом

Развитие компании — это не линейный проект с концом, а замкнутый цикл из трёх разных по природе видов деятельности. Смешивать их — значит терять управляемость. Каждый вид имеет собственный ритм и функцию:

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

Результаты аудита возвращаются в следующий стратегический цикл — уже с поправкой на то, что реально сработало, а что нет. Именно поэтому у одноимённых тем в разных блоках, например «Клиенты» в Стратегии и «Аудит клиентского опыта» в Аудитах, разные, не дублирующие друг друга задачи: первая растит практику, вторая её объективно измеряет.

3. Уровни зрелости: почему необходим дифференцированный подход

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

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

• Незрелый процесс — даёт разный результат в зависимости от исполнителя и его настроения.

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

4. Модель CMMI: происхождение и назначение

В качестве шкалы оценки зрелости в OrgDevTools используется модель CMMI (Capability Maturity Model Integration):

• Разработана Software Engineering Institute (SEI) при Университете Карнеги-Меллон в конце 1980-х годов по заказу Министерства обороны США. Военным требовался объективный метод оценки подрядчиков, разрабатывающих программное обеспечение, — метод, который не полагался бы на репутацию или личное знакомство с исполнителями.

• Ключевая идея модели пережила расширение далеко за пределы разработки ПО и переход под управление ISACA (CMMI Institute).

• В OrgDevTools эта пятиуровневая шкала закреплена структурно, а не декларативно. У каждого документа библиотеки, методики или сценария есть собственная метка уместности по уровням, причём один метод может быть уместен сразу на нескольких уровнях одновременно.

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

Уровень 1. Начальный (Initial)

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

Пример для темы «Клиенты»: основатель лично разговаривает с несколькими клиентами время от времени, без системы и записей.

Уровень 2. Повторяемый (Managed)

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

Пример для темы «Клиенты»: обратная связь от клиентов собирается регулярно, появляется первый неформальный шаблон опроса.

Уровень 3. Определённый (Defined)

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

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

Уровень 4. Управляемый (Quantitatively Managed)

Характеристика: практика измеряется метриками, есть регулярный цикл сверки план/факт и корректировки на основе данных, а не интуиции.

Пример для темы «Клиенты»: качество клиентского опыта измеряется метриками — NPS, CSAT и другими, есть регулярный цикл разбора и корректировки.

Уровень 5. Оптимизирующий (Optimizing)

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

Пример для темы «Клиенты»: работа с клиентским опытом встроена в культуру компании и самонастраивается по объективным данным без внешнего напоминания.

Цикл не завершается на пятом уровне. «Оптимизирующий» означает, что система научилась сама находить, куда двигаться дальше, а не то, что двигаться больше некуда — именно поэтому Трек называется треком непрерывного, а не разового развития.

6. Архитектура Трека: вертикаль, горизонталь и три блока

Трек в OrgDevTools представляет собой координатную сетку:

• Вертикаль — общая пятиуровневая шкала CMMI.

• Горизонталь — 37 предметных областей бизнеса, сгруппированных в три блока, соответствующих трём видам деятельности:

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

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

7. Горизонталь: внешние шкалы для каждой области

Для каждой из 37 предметных областей отдельно подбирается реально существующий, признанный в отрасли инструмент измерения — не обязательно с словом «Maturity Model» в названии, но обязательно реально применяемый практиками в мире, а не придуманный внутри платформы для галочки.

Примеры внешних шкал:

Там, где строгой именной модели зрелости не нашлось, использовался любой другой распространённый, признанный в индустрии диагностический инструмент или индекс. Три темы — «Анализ», «Ресурсы», «Бизнес-модель» — не получили убедительной внешней шкалы даже после целенаправленного поиска. Для них Трек полагается на собственную логику уместности методик по уровням CMMI, без притворства, что общепризнанный внешний эталон существует там, где его на самом деле нет.

Позиция платформы: придумать шкалу самим, чтобы формально закрыть тему, — самый быстрый способ обесценить весь Трек. Честное «не найдено» полезнее фиктивной модели с солидным названием.

8. Соответствие между блоками

Соответствие между 26 неаудиторскими темами (Стратегия + Регулярный менеджмент) и 11 темами аудита не всегда один-к-одному:

• Иногда несколько рабочих тем ссылаются на одну и ту же тему измерения.

• Иногда пары нет вовсе — и это фиксируется явно, а не маскируется формальной привязкой ради красивой полноты.

9. Разделение развития и измерения

Модель «вертикаль CMMI × горизонталь — внешняя шкала» задаёт ещё одно разделение:

• Сценарии, которые растят практику, живут в своей «домашней» теме блока Стратегия или Регулярный менеджмент.

• Объективная проверка результата по той же самой признанной шкале — отдельно, в парной теме блока Аудиты.

Например: сценарии, поднимающие качество работы с клиентами, находятся в теме «Клиенты» блока Стратегия, а Customer Experience Maturity Model как инструмент измерения «было / стало» — в теме «Аудит клиентского опыта» блока Аудиты. Тот, кто растит практику, и механизм, который её измеряет, физически разведены по разным частям Трека — так же, как выше разведены сами эти два вида деятельности.

10. Структура сценария развития

У каждого сценария — две обязательные, независимые друг от друга части:

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

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

Без плана работ дорожная карта остаётся красивой витриной; без дорожной карты план работ не на чем строить.

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

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

11. Отдельное правило: не плодить дубли

Если методика, лежащая в основе шкалы, уже существует в библиотеке как самостоятельный документ, например OKR или ITIL, под неё не пишется второй документ «X Maturity Model» — сама методика уже описывает зрелую практику применения, а роль шкалы в Треке играет она же.

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

12. Принцип множественности треков

CMMI-трек — курируемый пример, собранный по конкретной, проверяемой логике, а не единственный узаконенный маршрут платформы. Архитектурно Трек в OrgDevTools — множественная сущность. Помимо основного трека cmmi-default, в системе уже подготовлены собственные, независимые треки под другие мировые шкалы зрелости:

• Technology Readiness Level (TRL)

• Market Readiness Level (MRL)

• Customer Readiness Level (CRL)

• И далее по мере того, как конкретным компаниям требуются собственные отраслевые маршруты.

Смысл: миссия платформы — не провести каждую компанию по одному заранее расписанному пути, а выдать в её распоряжение полную мировую библиотеку методик, фреймворков и признанных шкал измерения, из которой любая команда способна собрать собственный трек развития под свою отрасль и свою стадию.

13. Итоговые принципы

1. Непрерывность. Цикл не завершается на пятом уровне. «Оптимизирующий» означает, что система научилась сама находить, куда двигаться дальше, а не то, что двигаться больше некуда.

2. Гранулярность оценки. Компания вполне может быть на уровне 5 по Финансам и одновременно на уровне 1 по Корпоративной культуре — это нормальная, часто встречающаяся картина реального бизнеса. Единая усреднённая оценка «зрелость компании — 3 из 5» такую картину стирает и уводит приоритеты не туда. Разметка по 37 отдельным областям делает Трек инструментом приоритизации, а не просто красивым индексом.

3. Трек — не каталог. Свести развитие компании к списку хороших методик — самая частая ошибка систем управления знаниями. Список можно пополнять бесконечно, но он не отвечает на два главных вопроса руководителя: где именно моя компания находится сейчас и что конкретно нужно сделать, чтобы объективно, а не на глазок, продвинуться дальше. Трек отвечает на оба вопроса одновременно, потому что устроен не как каталог, а как координатная сетка.

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

5. Использование внешних эталонов. Там, где в мире уже существует признанный инструмент измерения, используется именно он.

6. Честность в отношении пробелов. Если убедительной шкалы не существует, это фиксируется открыто.