«Методы оценки зрелости процессов часто превращаются в бюрократические ритуалы, которые не дают реальной картины. Есть способ получить честный срез за пару часов, задав правильные вопросы не в анкетах, а в разговорах.»
Почему стандартные оценки зрелости не работают
Большинство методик оценки зрелости — CMMI, COBIT, ISO-серии — предлагают долгие аудиты, анкетирование и формальные интервью. Результатом становится толстый отчёт с баллами и диаграммами, который ложится на полку. Проблема в том, что эти методы оценивают не реальную работу, а документальное отражение процессов. Команда может идеально заполнять чек-листы, но при этом регулярно тушить пожары и работать в авральном режиме. Формальная зрелость не равна операционной устойчивости.
Быстрая диагностика строится на другом принципе: она выявляет не соответствие эталону, а разрыв между декларируемыми правилами и реальной практикой. Её цель — не поставить оценку, а найти точки, где процессы дают сбой или создают избыточную нагрузку.
Подготовка: что нужно перед стартом
Диагностика не требует специального ПО или сложных форм. Достаточно блокнота, календаря и чёткого фокуса. Ключевой элемент подготовки — определение «единицы диагностики». Это не вся компания, а конкретный сквозной процесс или сервис, например: обработка инцидента информационной безопасности, вывод нового сервиса в промышленную эксплуатацию, управление изменениями в контуре АСУ ТП.
Выберите процесс, который критичен для бизнеса и в котором задействовано несколько отделов. Затем составьте список из 3-5 ключевых участников этого процесса с разных уровней: исполнитель, координатор, руководитель смежного подразделения, конечный потребитель результата. Именно их вам нужно будет опросить.
Этап 1: Карта процесса «как есть»
Начните с исполнителя — того, кто выполняет основную работу. Ваша задача — восстановить реальную последовательность действий, а не ту, что описана в регламенте. Задавайте вопросы не о правилах, а о последнем конкретном случае.
- «Расскажите, как в прошлый раз вы получали задачу на изменение в системе?»
- «Куда вы пошли или кому написали, когда столкнулись с непонятным требованием?»
- «Что вы делали, когда поняли, что не укладываетесь в срок?»
Фиксируйте не только шаги, но и используемые инструменты (мессенджеры, почта, тикеты), точки ожидания и принятия решений. Часто выясняется, что официальный маршрут документооборота дублируется неформальным чатом, где решаются все реальные вопросы.
Этап 2: Поиск разрывов и узких мест
Сравните рассказ исполнителя с официальной процедурой, если она есть. Основные разрывы обычно лежат в областях:
- Коммуникации: Согласования уходят в личные сообщения, статусы задач не обновляются.
- Ответственности: Непонятно, кто принимает итоговое решение на стыке отделов.
- Инструментов: Данные дублируются в Excel, Trello и Jira одновременно.
Спросите у исполнителя: «Какой один шаг вы бы исключили из процесса, если бы могли?» Ответ почти всегда указывает на бюрократическую или бессмысленную операцию.
Этап 3: Взгляд координатора и потребителя
Поговорите с тем, кто управляет процессом (координатор, руководитель проекта). Его картина часто отличается. Спросите: «По каким метрикам вы понимаете, что процесс идёт нормально?» и «Что является самым частым сбоем?». Отсутствие простых метрик или reliance на устные отчёты — признак низкой управляемости.
Затем найдите потребителя результата процесса (например, сотрудник бизнес-подразделения, для которого внедряется функция). Его ключевой вопрос: «Вы получаете то, что вам нужно, в оговоренный срок? Если нет, где возникает задержка?» Это выявляет, насколько процесс закрывает реальные потребности, а просто существует сам для себя.
Ключевые индикаторы зрелости, которые можно оценить за час
На основе этих бесед вы можете оценить несколько практических индикаторов, более показательных, чем абстрактные уровни зрелости.
| Индикатор | Признак низкой зрелости | Признак высокой зрелости |
|---|---|---|
| Определённость входа | Задача приходит разными каналами (звонок, чат, письмо), формулировка размыта. | Есть единая точка входа (тикет-система), запрос имеет чёткий шаблон. |
| Прозрачность статуса | Чтобы узнать статус, нужно писать или звонить исполнителю. | Статус виден в общей системе, обновляется по мере движения. |
| Принятие решений | Решение «зависает», требует поиска конкретного человека. | Есть понятное лицо или коллегиальный орган, сроки принятия решений известны. |
| Накопление знаний | Каждый новый сотрудник обучается «из уст в уста», решения прошлых проблем теряются. | Есть база типовых решений, ошибок, FAQ по процессу. |
Что делать с результатами
Цель быстрой диагностики — не отчёт, а список точечных гипотез для улучшений. Сформулируйте 3-5 конкретных предложений, например:
- Зафиксировать единый канал поступления заявок на изменения (например, только Jira) и отключить приём через почту.
- Ввести еженедельное 15-минутное совещание ключевых представителей отделов для снятия блокировок.
- Создать шаблон чек-листа для передачи задачи между отделами.
Эти гипотезы обсудите с участниками процесса. Если они находят отклик, можно запускать пилот по их внедрению. Сама диагностика становится не концом, а началом изменений.
Ограничения и риски метода
Двухчасовая диагностика не заменит глубокого аудита для сертификации. Она субъективна и зависит от откровенности собеседников. Риск в том, что можно принять частную проблему за системную. Чтобы снизить его, всегда проверяйте найденную «болевую точку» у нескольких участников. Если три разных человека из одного процесса указывают на сложности с согласованием у одного и того же руководителя, это системная проблема. Если жалоба единична — возможно, это частный случай.
Этот метод — инструмент для внутреннего использования, для быстрого понимания, куда двигаться. Он даёт не абсолютную оценку, а вектор для развития, который гораздо ценнее для реального повышения зрелости, чем абстрактный балл в отчёте.