В июне 2001 года на военной базе Эндрюс прошла симуляция «Dark Winter» — учение, разыгравшее скрытую биотеррористическую атаку оспой на Оклахома-Сити. Бывшие высокопоставленные чиновники играли роли членов Совета национальной безопасности на трёх заседаниях за смоделированные 14 дней кризиса. Симуляция вскрыла ровно то, что не видно на бумаге: острую нехватку вакцины, парализовавшую реакцию, и неясность, кто именно — федеральные или региональные власти — уполномочен принимать решения в конкретный момент эскалации. По сценарию за две недели заражёнными оказались 16 000 человек, из них 6 000 умерли или умирали — цифры внутри учения, но выявленные организационные пробелы были абсолютно реальными.
План, который никогда не тестировался в условиях, приближенных к реальным, — это гипотеза, а не проверенная процедура.
Происхождение и исследовательская база
Настольные военные игры (tabletop exercises) восходят к прусскому Kriegsspiel, принятому прусской армией в 1812 году — фигуры на карте представляли свои и вражеские силы, а офицеры разыгрывали развитие боя. Систематическую современную методологию разработала RAND Corporation в начале 1950-х годов, создав первые политико-военные симуляции («Cold War Games»); в 1959 году Милтон Вайнер (Milton G. Weiner) в исследовательской работе RAND «War Gaming Methodology» формализовал структуру подобных учений на примере Project SIERRA. Из военного и государственного антикризисного планирования практика перешла в управление непрерывностью бизнеса (business continuity management) — участники разыгрывают смоделированный кризисный сценарий в реальном времени, принимая решения так, как если бы кризис происходил на самом деле.
Ключевые идеи и принципы
Принцип: Реалистичный сценарий с нарастающей неопределённостью
Эффективная симуляция строится вокруг правдоподобного сценария, развивающегося во времени с элементами неопределённости и неполной информации, — участники должны принимать решения не располагая всеми фактами сразу, как это происходит в реальном кризисе.
Реальный пример намеренно правдоподобного, но не предсказуемого сценария — «Event 201», проведённая 18 октября 2019 года в Нью-Йорке Центром биобезопасности Университета Джонса Хопкинса совместно с Всемирным экономическим форумом и Фондом Билла и Мелинды Гейтс: 15 руководителей из бизнеса, госсектора и здравоохранения в течение 3,5 часов разыгрывали реакцию на вымышленный, но научно правдоподобный пандемический коронавирус. Организаторы намеренно построили сценарий на реалистичной, а не шаблонной эпидемиологической модели — именно поэтому учение вскрыло реальные пробелы в координации между государством и частным сектором при нехватке медицинских средств защиты и экономических потрясениях, а не просто подтвердило уже известный план. Ирония истории: сценарий Event 201 разошёлся с реальностью в деталях, но верно предсказал сам характер организационных провалов, вскрывшихся при пандемии COVID-19 несколькими месяцами спустя.
Принцип: Проверка распределения ролей и полномочий на практике
Симуляция явно проверяет, действительно ли каждый участник понимает свою роль и полномочия в кризисной ситуации, и выявляет случаи, когда формально назначенный ответственный на практике недоступен или неясен вопрос о том, кто уполномочен принимать конкретные решения.
Принцип: Разбор полётов после симуляции важнее самой симуляции
Ценность симуляции реализуется не в момент её проведения, а в структурированном разборе после — что сработало, что не сработало, какие пробелы в плане обнаружены, — за которым должна следовать реальная доработка плана, а не просто фиксация выявленных проблем.
Ограничения, слепые зоны и критика
Симуляция никогда не воспроизводит реальный уровень стресса и хаоса настоящего кризиса — участники знают, что это учение, и это меняет их поведение по сравнению с реальной ситуацией. Слишком редкое проведение симуляций (раз в несколько лет) снижает их ценность, поскольку команда и обстоятельства успевают существенно измениться; слишком частое проведение по одному и тому же сценарию создаёт эффект привыкания, когда участники запоминают "правильные" ответы вместо реального анализа ситуации.
Важное структурное ограничение самого термина: по официальной методологии HSEEP (Homeland Security Exercise and Evaluation Program, FEMA), настольная симуляция (tabletop exercise) относится к «discussion-based» типу упражнений — устное обсуждение сценария в комнате, без физических действий, — и намеренно менее реалистична, чем «operations-based» упражнения (функциональные и полномасштабные учения с реальным перемещением людей и техники). Тестирование словом «как бы вы поступили» и тестирование реальным действием — это два разных по силе метода проверки готовности, и настольная симуляция закономерно уступает полномасштабному учению в реализме, оставаясь при этом на порядок дешевле и быстрее в проведении.
Типовые ошибки
Ошибка 1: симуляция проводится без структурированного разбора после.
Учение завершается, но никто формально не анализирует, что сработало плохо, и не вносит изменения в план на основе выявленных пробелов.
Как избежать
Всегда проводить структурированный разбор сразу после симуляции и фиксировать конкретные изменения в план.
Ошибка 2: сценарий слишком предсказуем и не создаёт реального напряжения.
Участники заранее знают детали сценария или проходят его слишком гладко, потому что сценарий не включает реалистичных элементов неопределённости и осложнений.
Как избежать
Вводить в сценарий неожиданные осложнения и неполноту информации, приближая условия к реальному кризису.
Ошибка 3: проверка ролей проводится формально, без реального давления и неопределённости.
Участники заранее знают, кто и что должен делать, и просто зачитывают инструкцию из плана — вместо того чтобы реально принимать решения в условиях неполной информации, как это будет в настоящем кризисе. Именно так «Dark Winter» обнаружила, что вопрос «кто именно — федеральные или региональные власти — уполномочен санкционировать конкретное решение в конкретный момент» не был прояснён формальным планом заранее и потребовал живого выяснения прямо во время учения.
Как избежать
Вводить моменты, когда участнику нужно принять решение без полной информации или в отсутствие формально назначенного руководителя.
Ошибка 4: выявленные пробелы фиксируются, но план действий не дорабатывается.
Разбор после симуляции проходит содержательно, проблемы называются вслух, но конкретные изменения в план действий на случай ЧС так и не вносятся — та же ошибка повторится на следующей реальной проверке.
Как избежать
Для каждого выявленного пробела фиксировать конкретное изменение плана и ответственного за его внесение, а не только протокол обсуждения.
Ошибка 5: симуляции проводятся один раз и не повторяются регулярно.
Учение прошло один раз при внедрении плана, но с тех пор команда, процессы и внешние риски изменились, а актуальность готовности никто заново не проверял. Международный стандарт ISO 22301 (менеджмент непрерывности бизнеса) прямо требует регулярного тестирования и учений по плану continuity — это не разовая проверка при внедрении, а постоянная часть цикла управления, а не факультативное дополнение.
Как избежать
Закладывать регулярный цикл симуляций — например, раз в год или при значимых изменениях состава команды и внешних рисков.
Ошибка 6: решения и реакции участников во время симуляции никем не фиксируются в реальном времени.
Симуляция проходит живо и содержательно, но без независимого наблюдателя, который бы фиксировал, кто и когда принял какое решение, — на разборе участники полагаются на память и субъективные впечатления, а не на объективную хронологию событий. И «Dark Winter», и «Event 201» намеренно включали в структуру отдельных наблюдателей и модераторов, фиксирующих ход учения, — это не декоративная деталь, а условие содержательного разбора после.
Как избежать
назначать отдельного человека (не участвующего в принятии решений) фиксировать хронологию решений и реакций по ходу симуляции — именно эта запись, а не общие впечатления, становится основой разбора. Такая роль не требует специальной подготовки — достаточно человека, физически не занятого в принятии решений и способного кратко записывать, кто, когда и что предложил или решил.
План внедрения
Неделя 1: разработка сценария
разработать реалистичный кризисный сценарий с элементами неопределённости — по образцу структуры «Dark Winter» и «Event 201», удобно строить сценарий как несколько последовательных эпизодов, разделённых смоделированным течением времени (например, «день 1», «день 7», «день 14»), а не одну статичную картину.
Неделя 2: проведение симуляции
собрать ключевую команду и провести симуляцию в реальном времени, назначив отдельного наблюдателя-фасилитатора, который не участвует в принятии решений, но фиксирует хронологию — без этой роли последующий разбор будет строиться на памяти участников, а не на фактах (защита от Ошибки 6).
Неделя 3: разбор и пробелы
провести структурированный разбор и зафиксировать выявленные пробелы.
Неделя 4: доработка плана
внести конкретные изменения в план действий на основе разбора.
Далее: регулярное повторение
Далее: регулярно повторять симуляции с обновлёнными сценариями — по требованию ISO 22301 это постоянный, а не разовый цикл; со временем можно усложнять формат, переходя от чисто дискуссионной настольной симуляции к элементам операционных учений (частичное физическое разворачивание отдельных процедур), если ставки достаточно высоки, чтобы оправдать более дорогой и реалистичный формат.
Как реализовать этот план с помощью фрейма «Симуляции кризисных ситуаций» в OrgDevTools
Фрейм ведёт учение от сценария до доработанного плана и сам ищет слабые места: слишком гладкий сценарий, медленные или неверные решения по ролям, открытые пробелы, которые так и не попали в план. Это бесплатный тренажёр. Все поля изначально пустые, готовых примеров нет.
Вкладка «1. Сценарий» — Неделя 1: разработка сценария
Слева находится список «Сценарий»: по строке на каждый эпизод или вводную (что случилось, что известно сначала, какие будут осложнения). Сюда удобно записать «день 1», «день 7», «день 14». Справа четыре флажка реалистичности: неполные и противоречивые сведения в начале; осложнения, которые подбрасываются по ходу; решения на таймере; несколько функций, которые нужно согласовывать. Под флажками счётчик «Реалистичность: N из 4». От трёх признаков он зелёный, ниже красный. Порог в три признака — рабочая настройка фрейма.
Вкладка «2. Проверка ролей» — Неделя 2: проведение симуляции
Сначала задаётся цель в минутах. По умолчанию 15, минимум 1; это рабочая настройка фрейма. Дальше идёт таблица ролей, строки добавляются кнопкой «+ добавить роль». В каждой строке есть название, минуты до первого верного действия и переключатель «верное решение» (?/да/нет). Фрейм сам ставит статус по времени: «в цели» зелёным, «позже на N» красным или прочерк, если минуты не указаны. Верность решения на этот статус не влияет. Ниже список «Заметки по ролям»: кто реально готов, а кто назначен только формально.
Вкладка «3. Пробелы и доработка» — Недели 3–4: разбор и доработка плана
Таблица пробелов заполняется кнопкой «+ добавить пробел». Для каждого пробела указываются название, тяжесть от 1 до 5 и два переключателя: «в план внесено» и «закрыт» (?/да/нет). Под таблицей два списка. В «Разбор пробелов» пишут, что не сработало и почему. В «Доработку плана» — конкретные изменения в формате «изменение — владелец — срок».
Вкладка «Визуализация» — Неделя 3: опора для разбора
Полосы показывают время каждой роли, у которой заполнены и минуты, и верность. Пунктиром отмечена цель. Красная полоса со значком ✗ означает неверное решение, жёлтая — верное, но позже цели, зелёная — верное и вовремя. Ниже три счётчика пробелов: «Найдено», «Внесено в план», «Закрыто». Пустые строки без названия фрейм не учитывает.
Вкладка «Итоги» — Далее: регулярное повторение
Вердикт выдаёт первое сработавшее условие в таком порядке:
Сценарий пуст — просьба описать сценарий.
Признаков реалистичности меньше трёх.
Роли не внесены, или у части ролей нет минут или оценки решения.
Есть неверные решения, и доля верных ниже 80% (рабочая настройка). Это красный вердикт, неудачные роли перечисляются.
Хотя бы одна роль начала действовать позже цели.
Не найдено ни одного пробела. Фрейм считает это признаком лёгкой симуляции или формального разбора.
Есть открытый пробел тяжестью 4 или 5 (рабочая настройка). Это красный вердикт, называется самый тяжёлый.
Пробел отмечен закрытым, но изменение в план не внесено.
Есть пробелы, не внесённые в план, а список «Доработка плана» пуст.
Остались открытые пробелы. Фрейм показывает долю закрытых и советует назначить владельцев и запланировать повторное учение.
Иначе зелёный итог с предложением провести следующее учение по другому сценарию.
Под вердиктом выводится сводка: реалистичность, доля верных решений, сколько пробелов всего и сколько открытых, сколько открытых критичных. Кнопка «Создать задачу» видна, если документ сохранён. Задача называется «Закрыть критичный пробел: …», если такой пробел есть, иначе «Внести в план изменения по итогам симуляции». В описание попадает список открытых пробелов.
Чего фрейм не делает
Не ведёт таймер. Минуты вносятся вручную по записям наблюдателя, а отдельного поля для наблюдателя и хронологии нет.
Не проверяет регулярность учений: дат и истории симуляций во фрейме нет. Долю пробелов, закрытых к следующему учению, нужно считать самостоятельно.
Не связывает пробел со строкой в «Доработке плана». Противоречие «закрыт, но не внесён» фрейм только подсвечивает.
Не оценивает смысл текста в списках.
Не учитывает в вердикте пробел без указанной тяжести как критичный.
Не замечает неверные решения, если доля верных не ниже 80%.
Не различает настольный и операционный формат учения.
Заполнили фрейм? Сохраните, чтобы не потерять
Книги по теме
Fink S. — «Crisis Management: Planning for the Inevitable» (AMACOM, 1986). Первая книга, применившая термин «crisis management» к бизнесу — четырёхфазная модель кризиса (продромальная, острая, хроническая, разрешение) на реальных кейсах Ohio Savings and Loan, Union Carbide/Bhopal, Johnson & Johnson/Tylenol.
Митрофф И., Анагнос Г. (Ian I. Mitroff, Gus Anagnos) — «Managing Crises Before They Happen» (2001). Принципы заблаговременной проверки готовности к кризису через реалистичные учения, а не только документарное планирование.