Премортем стратегии — это разбор возможного провала до запуска плана. Команда представляет, что цель уже не достигнута, выясняет возможные причины и превращает их в проверки, ограничения и действия. Результат — не перечень страхов, а таблица рисков с ранними сигналами и ответственными.
Допустим, компания решила выйти в новый сегмент. В плане есть маркетинг, продажи и дата старта. Но пока неизвестно, сможет ли производство выполнить новые заказы без срыва текущих, кто будет принимать нестандартные запросы и при каком результате эксперимент остановят. Премортем помогает вынести эти вопросы в повестку до расходования ресурсов.
Ниже — редакционный рабочий шаблон AiPeople для собственника и руководителей. Примеры учебные; они не описывают результаты клиентов и не обещают устранить все риски.
Чем премортем отличается от SWOT и разбора ошибок
SWOT-анализ помогает собрать картину сильных и слабых сторон, возможностей и угроз. Премортем уже привязан к конкретному решению: «Мы запускаем это направление с такими ресурсами. Почему оно может не сработать?» Разбор ошибок после проекта, напротив, опирается на произошедшие события. У этих упражнений разные задачи.
Метод проектного премортема описал Гэри Кляйн в Harvard Business Review в 2007 году. Открытый пример группового упражнения есть в Atlassian Team Playbook. Предложенная ниже таблица добавляет к обсуждению управленческие поля: сигнал, порог пересмотра и человек с правом действовать.
Не стоит проводить упражнение вокруг всей жизни компании сразу. Формулировка «Почему наш бизнес когда-нибудь закроется?» даёт слишком широкий список. Лучше взять одну ставку из стратегии на год: новый сегмент, изменение модели продаж, запуск продукта или пересборку процесса.
Сначала зафиксируйте, что считается провалом
«Проект не взлетел» участники поймут по-разному. Для продаж провалом может быть отсутствие сделок, для операций — нарушение сроков, для собственника — результат, который держится на его постоянном вмешательстве. Если не согласовать критерий заранее, команда будет обсуждать разные проекты.
Заполните короткую карточку решения:
| Поле | Что записать |
|---|---|
| Решение | Что запускаем или меняем, в какой части бизнеса |
| Ожидаемый результат | Какое наблюдаемое изменение хотим получить |
| Горизонт проверки | Когда впервые сможем оценить результат |
| Ограничения | Какой ресурс доступен и чем нельзя пожертвовать |
| Неудачный исход | При каких признаках признаем, что план требует пересмотра |
Ограничение должно быть проверяемым. «Не ухудшать качество» трудно использовать. «Новые заказы не должны увеличивать число просроченных действующих заказов выше согласованного порога» уже задаёт предмет контроля. Сам порог устанавливают по исходным данным компании, а не берут из универсального шаблона.
Если команда не может назвать текущий уровень показателя, первым действием будет сбор исходных данных. Прогноз без точки отсчёта нельзя честно сравнить с результатом.
Как провести обсуждение с командой
Пригласите людей, которые видят разные части выбранного решения: клиента, продажи, выполнение, ресурсы и ограничения. Отдельно определите, кто вправе изменить план. Не каждый участник обязан принимать решение, но каждый должен понимать, какие факты от него нужны.
Начните с индивидуальных записей. Участники отвечают на вопрос: «Наступила дата проверки, и результат не получен. Какие конкретные причины могли к этому привести?» Только после этого сравните ответы. Такой порядок даёт каждому возможность сформулировать собственную версию до общего обсуждения.
Разделите записи на три группы:
- Подтверждённое ограничение. Например, нужный специалист уже занят другим проектом. Это факт, который требуется учесть сейчас.
- Гипотеза о риске. Например, новый сегмент может ожидать другой срок поставки. Нужна проверка спроса или условий.
- Неопределённая тревога. Например, «рынок нестабилен». Её нужно уточнить: какое изменение важно для решения и как его заметить?
Не обсуждайте личные качества сотрудников вместо причин. Запись «продажи опять всё сорвут» не помогает управлять. Запись «в обещания клиентам не включена проверка доступной мощности» указывает на процесс, который можно изменить.
Таблица рисков, из которой следуют действия
Для каждого существенного риска заполните строку. Не стремитесь оценить всё по точной числовой шкале: если оснований для вероятности нет, отметьте неопределённость. Полезнее договориться, какое наблюдение изменит решение.
| Риск | Что известно | Ранний сигнал | Действие до старта | Кто решает и когда проверяет |
|---|---|---|---|---|
| Не хватает ресурса на выполнение | Какие задачи уже назначены команде | Новые обязательства превышают доступную мощность | Ограничить объём запуска или снять другой проект | Владелец операций; до подтверждения обязательств |
| Предположение о клиенте ошибочно | На каких разговорах и сделках основана гипотеза | Клиенты называют другую задачу или причину отказа | Проверить предложение на ограниченной выборке | Руководитель продаж; на согласованной контрольной точке |
| Решения снова замыкаются на собственнике | Какие согласования нужны сегодня | Работа стоит в ожидании одного человека | Назначить полномочия и границы самостоятельного решения | Собственник; перед стартом |
| ИИ выдаёт убедительные, но неверные выводы | Какие источники данных доступны | Вывод нельзя связать с исходной записью | Ввести проверку ссылок на данные и ответственного за вывод | Владелец процесса; перед использованием результата |
Это заготовка для обсуждения. У конкретной компании вместо общих ролей должны появиться имена, реальные сроки и допустимые значения показателей. Иначе таблица останется памяткой, а не частью управления.
Для рисков, по которым решение всё ещё неясно, добавьте отдельное поле: «Какого факта не хватает?» Например, вместо нового совещания о возможности роста может потребоваться проверка мощности на уже согласованных заказах.
Учебный пример: новый сегмент без перегрузки действующих клиентов
Представим небольшую сервисную компанию. Она хочет начать обслуживать корпоративных клиентов, сохранив текущие проекты. Это вымышленная ситуация для проверки шаблона.
Первоначальный план: запустить продвижение и продавать новый пакет. Во время премортема обнаруживаются две зависимости. Новому клиенту нужен единый ответственный, но эту роль пока выполняет собственник. Для оценки нестандартных задач требуется ведущий специалист, у которого уже заполнен рабочий график.
Запись «найти больше клиентов» не решает ни одну из зависимостей. Команда меняет порядок действий: сначала описывает стандартный пакет, ограничивает число одновременных пилотных проектов и выделяет время специалиста на оценку. Решение о следующем расширении привязывает к фактической загрузке и качеству выполнения.
Премортем здесь не доказал, что направление выгодно. Он показал, какие условия нужно проверить, прежде чем увеличивать обязательства. Если эти условия не выполняются, компания может сузить предложение, отложить запуск или пересмотреть ресурсный план.
Как использовать ИИ для проверки стратегии
ИИ можно поручить проверку связности уже заполненной таблицы: где действие не связано с риском, где отсутствует ответственный, какие утверждения названы фактами без источника. Начните с обезличенной версии; клиентские сведения и внутренние документы передавайте только в разрешённой компанией среде.
Рабочая постановка задачи:
Проверь эту карточку решения и реестр рисков. Используй только предоставленные факты. Для каждой строки укажи: какое допущение не проверено, есть ли наблюдаемый ранний сигнал, связано ли действие с причиной и кто должен принять решение. Отдельно перечисли вопросы к команде. Не придумывай вероятности, финансовый эффект, факты о клиентах или вывод о том, что проект обязательно стоит запускать.
Результат нужно разобрать с владельцами данных. Если ИИ предлагает риск, которого не было в материалах, это новая гипотеза для проверки. Она не становится фактом от уверенной формулировки. Окончательный выбор — продолжать, ограничить или остановить проект — остаётся за уполномоченным человеком.
Что делать после встречи
Перенесите выбранные действия в рабочий план. У каждой проверки должны быть срок и ожидаемое свидетельство: расчёт загрузки, ответы клиентов, согласованные полномочия или проверенный образец результата. Назначьте дату возврата к решению сразу, пока контекст общий.
На контрольной точке сравните сигналы с согласованными условиями. Если риск не проявился, это не повод автоматически расширять проект: проверьте и ожидаемый результат. Если проявился — используйте заранее оговорённое действие и зафиксируйте, что изменилось в плане.
Так реестр рисков включается в первые 90 дней реализации стратегии. Разбирать каждую строку на всех встречах не нужно; внимание требуется там, где появились новые факты, нарушено ограничение или наступил срок решения.
Если для выбора нужно согласовать приоритеты собственника, продаж и операций, этот вопрос можно вынести на корпоративную стратегическую сессию AiPeople. При обращении опишите спорное решение и ограничения команды — это полезнее общего запроса «нужна стратегия».
Часто задаваемые вопросы
В1: Можно ли провести премортем без готовой стратегии?
Можно проверить конкретную гипотезу или проект. Но нужно хотя бы предварительное решение, ожидаемый результат и горизонт проверки. Если команда ещё выбирает направление, сначала полезнее прояснить варианты и критерии выбора.
В2: Премортем гарантирует, что проект не провалится?
Нет. Он помогает выявить допущения и подготовить реакцию на часть рисков. Внешние условия могут измениться, данные — оказаться неполными, а важный риск — остаться незамеченным. Поэтому проверки продолжаются после старта.
В3: Что делать, если собственник не согласен с названным риском?
Уточнить, какие факты подтверждают каждую позицию и какое наблюдение позволит пересмотреть решение. Разногласие можно записать вместе с проверкой. Требовать единодушия по всем предположениям необязательно.
В4: Нужен ли отдельный сервис для реестра рисков?
Для начала достаточно общей таблицы или документа с ответственными и датами. Важны доступ участников, единая актуальная версия и использование записей при принятии решений. Выбор инструмента сам по себе не создаёт этот процесс.
В5: Чем ранний сигнал отличается от уже случившейся проблемы?
Сигнал появляется, когда ещё есть возможность изменить действие: например, доступное время специалиста уже распределено, а новые сроки только обсуждаются. Просроченный клиентский заказ — уже результат проблемы. Для каждого риска стоит искать наблюдение, которое возникает раньше ущерба.