Проектируйте проверку до окончания сессии

Цель урока

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

Почему это важно

Энергия, посещаемость и удовлетворённость помогают оценить опыт, но не доказывают, что сессия изменила операционную систему.

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

Ключевая идея: три уровня проверки

1. Использование артефакта: применили ли решение, устав или план?
2. Поведение или механизм: изменились ли handoff, control или правило решения?
3. Результат: изменился ли клиентский, операционный или risk measure при приемлемых guardrails?

Baseline, владелец, источник данных и дата определяются до ухода участников. Первый обзор использует ранние process indicators; outcome indicators — только на горизонте, где изменение могло проявиться.

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

Визуальное объяснение

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

Пример NordForge

• 30 дней: governance пилота работает, владельцы площадок назначены, новое правило handoff используется в выборке заказов.
• 60 дней: age of exceptions, число эскалаций и expedited freight сравниваются с baseline и guardrails.
• 90 дней: OTIF, переносимость и capacity определяют продолжение, корректировку, остановку или расширение пилота.

Обзор спрашивает не только «Выполнены ли действия?», но и применялся ли механизм и поддерживают ли данные следующий выбор.

After Action Review как цикл обучения

Логика AAR U.S. Army движется от ожидания и факта к изменению следующей попытки. Исследовательские обзоры структурированных debriefs показывают положительную среднюю связь с результативностью, но эффект зависит от качества и контекста разбора.

Используйте шесть вопросов:

1. Что ожидалось?
2. Что произошло?
3. Чем объясняется разница?
4. Что сохранить?
5. Какое конкретное правило изменить?
6. Что проверить в следующей попытке?

Список абстрактных «уроков» ещё не является циклом обучения.

Типичная ошибка

Ошибка: измерять только финальный бизнес-показатель. Если outcome не изменился, нужно понять: использовали ли интервенцию, ошибочен ли механизм или горизонт был слишком коротким.

Быстрая проверка

OTIF не изменился через 30 дней, но пилот ещё не работал на обеих площадках. Какой вывод допустим?

A. Сессия провалилась.
B. Пилот работает.
C. Outcome пока нельзя интерпретировать без проверки внедрения и механизма.
D. Нужно немедленно масштабировать.

Ответ: C. Сначала проверяют использование артефакта и механизм.

Практическое задание

Используйте 30–60–90 Review: определите владельца, baseline, источник, дату и правило реакции на каждом горизонте. Назначьте After Action Review до завершения сессии.

Итог

• Отдельно оценивайте использование, механизм и результат.
• Заранее задавайте baseline и источник данных.
• Соотносите индикатор с реалистичным горизонтом.
• Меняйте конкретное правило, а не только формулировку урока.
• Передавайте данные проверки в новый мандат.

Источники

• U.S. Army, FM 7-0: Training (откроется в новой вкладке), After Action Review agenda.
• Scott Tannenbaum и Christopher Cerasoli, Do Team and Individual Debriefs Enhance Performance? (откроется в новой вкладке).

Завершение трека

Примените полную цепочку к практическому кейсу Decision Room: мандат → доказательства → участие → варианты → решение → артефакт → проверка.

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