Каркас метрик

04.1 Metrics Framework

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

Этот документ задаёт общую логику. Конкретные типы метрик раскрыты в 04.2 Опережающие vs итоговые–04.4 Шаблоны метрик.

Главный принцип: метрика следует из структуры

   Обычный подход                STAF
   ──────────────                ────
   "какие KPI важны              "что в структуре системы
    для бизнеса?"                 нужно видеть, чтобы
        │                         управлять ей?"
        ▼                              │
   список метрик                       ▼
   сверху вниз                   метрики выводятся из
   (часто оторван                карты: из петель, задержек,
    от реальной                  разрывов
    динамики)

Практическое следствие: прежде чем спрашивать «какие метрики ввести», STAF спрашивает «что показала карта». Три источника метрик в структуре:

Из разрывов. Каждый диагностированный разрыв порождает метрику: то, что позволит увидеть, закрывается ли он. Разрыв визуализируемости (решение без данных) → метрика «доля решений, принятых на основе данных».

Из задержек. Каждая длинная задержка в петле порождает опережающий индикатор: промежуточный запас перед задержкой (детально: 02.4 Задержки, 04.2 Опережающие vs итоговые).

Из прогнозов бездействия. Каждый прогноз содержал прокси-индикатор — это готовая метрика для мониторинга соответствующего разрыва (детально: 03.5 S3 · Дизайн вмешательства).

Как думали до STAF, как стало: метрики процесса подачи заявок

Чтобы увидеть ценность, сравним два подхода к одному процессу — приём и рассмотрение заявок — на конкретном примере.

Как это делает процессный анализ (например, BPMN). BPMN-нотация описывает процесс как последовательность шагов, шлюзов и событий: заявка подана → проверка → шлюз «полная?» → да/нет → рассмотрение → решение. Метрики назначаются к шагам и обычно отвечают на вопрос «насколько быстро и эффективно исполняется каждый шаг»:

   BPMN-метрики (привязаны к шагам):
   · среднее время проверки заявки
   · пропускная способность (заявок в день)
   · процент заявок, прошедших с первого раза
   · загрузка исполнителей на каждом шаге

Все эти метрики — про исполнение шагов. Они отвечают на вопрос «работает ли конвейер быстро и без простоев». И на этот вопрос они отвечают хорошо.

Чего эти метрики не показывают. Вернёмся к находке из реального кейса (05.4 Кейсы, кейс 1): заявители не улучшают качество заявок от цикла к циклу, потому что не получают содержательной обратной связи — контур обучения разомкнут. BPMN-метрики этого не видят в принципе:

   BPMN видит шаги:              STAF видит структуру:
   [проверка] → [решение]       [решение] → [итоги]
        ↑ метрика:                    │
        время, пропускная            ╳ ← отсутствующая
        способность                  │   связь к заявителю
                                [заявитель] не учится

   метрика «время проверки»     метрика «доля повторных
   = 2 дня, отлично             заявок с теми же ошибками»
                                = растёт каждый цикл
   ВСЁ В НОРМЕ по BPMN          РАЗРЫВ виден по STAF

Процесс может иметь идеальные показатели исполнения (быстрая проверка, высокая пропускная способность) — и при этом содержать структурный разрыв, который BPMN-метрики не способны обнаружить, потому что разрыв находится в отсутствующей связи, а не в шаге. Шага, который «работает плохо», нет — есть связь, которой нет вовсе.

В чём ценность подхода STAF.

   ПРОЦЕССНЫЙ ВЗГЛЯД (BPMN)        СТРУКТУРНЫЙ ВЗГЛЯД (STAF)
   ───────────────────────        ─────────────────────────
   метрика отвечает:              метрика отвечает:
   «быстро ли исполняется         «учится ли система,
    каждый шаг?»                   замкнуты ли контуры
                                   обратной связи?»

   находит: медленные шаги,       находит: разомкнутые
   простои, перегрузки            контуры, решения без
                                  данных, отсутствующие
                                  обратные связи

   метрика НАЗНАЧАЕТСЯ            метрика ВЫВОДИТСЯ из
   к шагу                         структуры (петли,
                                  задержки, разрывы)

   слепое пятно:                  видит то, чего нет в
   то, чего нет в процессе        тексте процесса —
   (отсутствующие связи)          отсутствующие связи

Это не означает, что BPMN-метрики не нужны — они отвечают на свой вопрос (эффективность исполнения) и часто полезны. STAF добавляет второй слой: метрики, отвечающие на вопрос об обучаемости и замкнутости контуров, который процессная нотация задать не может, потому что не оперирует петлями обратной связи как объектами.

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

Четыре свойства хорошей метрики STAF

STAF наследует требования к показателям, проверенные практикой, и формулирует их как четыре свойства. Метрика, не обладающая всеми четырьмя, — кандидат на пересмотр.

   ┌─────────────────────────────────────────────────┐
   │  1. ИЗМЕРИМОСТЬ                                   │
   │     есть источник данных, значение получаемо      │
   │     (нет источника → метрика-декларация)          │
   ├─────────────────────────────────────────────────┤
   │  2. СВЯЗЬ С РЕШЕНИЕМ                              │
   │     метрика информирует конкретное решение         │
   │     (никто не использует → данные «в стол»)       │
   ├─────────────────────────────────────────────────┤
   │  3. ОПЕРЕЖЕНИЕ                                     │
   │     меняется раньше итогового результата          │
   │     (только итоговые → управление по зеркалу)      │
   ├─────────────────────────────────────────────────┤
   │  4. УСТОЙЧИВОСТЬ К МАНИПУЛЯЦИИ                    │
   │     не улучшается ложным образом                  │
   │     (без защиты → закон Гудхарта)                 │
   └─────────────────────────────────────────────────┘

Каждое свойство связано с диагностическим правилом STAF:

• Измеримость = цепочка «источник данных → метрика» (верифицируемость)
• Связь с решением = связь «метрика → решение» (визуализируемость)
• Опережение = учёт задержек (02.4 Задержки)
• Устойчивость = контр-метрики (04.3 Контр-метрики)

Полная цепочка измерения

Метрика не существует сама по себе — она является звеном цепочки от данных до решения. Полная цепочка верифицируемости:

   [▢ источник ▢] ┄feeds┄► [📊 метрика] ┄informs┄► [◇ решение]
        данных                измеряет              опирается
        реально                реальный             на метрику
        существуют             элемент

   Разрыв в ЛЮБОМ звене обесценивает всю цепочку:

   нет источника    → метрика-декларация (нечего измерять)
   нет измеряемого  → метрика измеряет не то
   нет решения      → данные собираются, но не используются

Это та же логика, что в диагностике (03.4 S2 · Точки рычага): метрика — не точка, а цепочка, и разрыв в любом звене диагностируем.

Что измерять: три уровня

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

   УРОВЕНЬ                ЧТО ИЗМЕРЯЕТ              ПРИМЕР
   ──────                 ────────────              ─────
   Результат              достигла ли система       выручка,
   (lagging)              цели?                      NPS, доля рынка

   Поведение системы      что происходит            длина очереди,
   (leading)              в структуре сейчас?        время в цикле,
                                                     загрузка

   Качество мышления      верна ли наша модель       сбылся ли
   (meta)                 системы?                    прогноз STAF
                                                     (см. S5)

Большинство организаций измеряют только первый уровень. STAF требует все три: результат — чтобы знать, достигли ли цели; поведение — чтобы управлять до наступления результата; качество мышления — чтобы знать, можно ли доверять собственной модели (это и есть этап S5).

Метрики и петли обратной связи

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

   [состояние системы] ──► [📊 метрика] ──► [◇ решение] ──┐
        ▲                                                 │
        └─────────────── влияние решения ──────────────────┘
                    замкнутый контур управления

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

Практический тест для любой метрики: какое конкретное решение изменится, если эта метрика изменится? Если ответа нет — метрика не замыкает контур, и её существование стоит пересмотреть.

Антипринцип: измерение ради измерения

Самая частая ошибка работы с метриками — собирать всё, что можно собрать, в надежде, что «данные пригодятся». STAF противостоит этому структурно: метрика оправдана только если замыкает контур (информирует решение) и обладает четырьмя свойствами.

   ✗  «давайте измерять всё, что можем»
      → дашборд-кладбище: много данных, ноль решений

   ✓  «что в структуре нужно видеть, чтобы принять
       конкретное решение?»
      → метрика на каждый реальный контур управления

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

STAF 1.0 · SysMindLab · 2026