S0 · Постановка проблемы

03.2 Problem Framing

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

Что производит этап S0

ВХОД:  запрос ("у нас проблема с X")
         │
         ▼
   ┌──────────────────────────────┐
   │  S0 — Постановка проблемы     │
   │                              │
   │  1. Вопрос-катализатор        │
   │  2. Граница системы           │
   │  3. Носитель системы          │
   └──────────────────────────────┘
         │
         ▼
ВЫХОД: зафиксированный контекст для картирования
       + критерий "правильно ли выбрана граница"

Три обязательных результата

1. Вопрос-катализатор

Вопрос-катализатор — это формулировка того, что именно не работает так, как должно. Он не является частью модели — он является компасом, по которому проверяется, верно ли выбрана граница и достаточно ли детально раскрыта нужная часть системы.

Хорошая формулировка катализатора:

• Описывает наблюдаемое расхождение между желаемым и фактическим
• Привязана к конкретному, по возможности измеримому, явлению
• Не содержит готового решения внутри себя

✓  "Время от заявки клиента до первого ответа выросло с 2 часов
    до 2 дней за последний квартал"
    → наблюдаемо, измеримо, без встроенного решения

✗  "Нам нужно нанять больше людей в поддержку"
    → это решение, замаскированное под проблему;
      встроенный ответ закрывает анализ до его начала

✗  "У нас проблемы с эффективностью"
    → слишком абстрактно, не привязано к наблюдаемому явлению

Почему важно убрать решение из формулировки. Если катализатор сформулирован как "нам нужно X", анализ превращается в обоснование X, а не в понимание проблемы. Это прямая дорога к архетипу "Fixes That Fail": решение выбрано до того, как понята причина.

2. Граница системы

Граница определяется по процедуре раздела 01.1 Граница системы. На этапе S0 фиксируются три составляющих: что входит (in_scope), что осознанно исключено (exclusions), открытые вопросы (open_questions). И граница проверяется по четырём вопросам — это ворота 0.

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

3. Носитель системы

Определяется, кто будет верифицировать карту на воротах 1. Это решение лучше принять в S0, а не в конце S1, потому что оно влияет на то, какие вопросы задавать при картировании и к каким источникам обращаться.

Носитель системы — это НЕ обязательно руководитель.
Часто это исполнитель, знающий детали, которые
не попадают в регламенты:

   руководитель          → знает, как ДОЛЖНО работать
   исполнитель процесса  → знает, как РАБОТАЕТ на самом деле
                            ↑
                  именно это нужно для верификации

Типичные ошибки этапа S0

Пропуск этапа целиком. "И так понятно, в чём проблема, давайте смотреть данные". Это самая частая и самая дорогая ошибка — она не ощущается как ошибка, потому что ускоряет начало "настоящей работы". Цена выясняется в конце, когда оказывается, что проанализирована не та система.

Катализатор-решение. Проблема сформулирована как недостающее решение ("не хватает автоматизации", "нужен новый процесс"). Анализ вырождается в обоснование заранее выбранного ответа.

Граница под катализатор-симптом. Граница проведена вокруг места, где проявляется симптом, а не где находится вероятная причина (см. ошибку 2 в разделе 01.1 Граница системы).

Носитель не определён. Картирование проводится, а в конце выясняется, что некому верифицировать карту — или верифицирует человек, не знающий реального процесса. Карта остаётся в статусе draft, и весь анализ повисает.

Ворота 0: критерии перехода к S1

Переход к картированию разрешён, когда:

• Вопрос-катализатор сформулирован как наблюдаемое расхождение, без встроенного решения
• Граница прошла 4 проверочных вопроса (01.1 Граница системы)
• in_scope, exclusions, open_questions зафиксированы явно
• Определён носитель системы для будущей верификации
• Граница достаточно широка, чтобы включить вероятную причину катализатора

Невыполнение любого критерия — сигнал остаться в S0, а не переходить дальше "с тем, что есть".

STAF 1.0 · SysMindLab · 2026