Кейсы

05.4 Case Studies

Этот раздел показывает STAF в работе на сквозных примерах. Кейсы обезличены: важна структура анализа, а не конкретные организации. Каждый кейс проходит по этапам цикла и демонстрирует конкретный методологический урок.

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

Кейс 1: Процесс с разомкнутым контуром обучения

Тип системы: регламентированный процесс приёма и оценки заявок с последующим циклом планирования.

S0 — Постановка

Вопрос-катализатор: участники процесса систематически не улучшают качество своих заявок от цикла к циклу, несмотря на накопленный опыт организации-оператора.

Граница: от подачи заявки до объявления результатов + годовой цикл планирования. Осознанно исключено: реализация уже одобренных проектов (другой процесс).

S1 — Картирование и находка

При картировании обнаружилось то, чего не было в регламентах — отсутствующая связь:

   [Заявки] → [Экспертиза] → [Решение] → [Итоги]
                                            │
                                            ╳  ← обратная связь
                                            │     к заявителю
                                       [Заявитель]   ОТСУТСТВУЕТ
                                       не узнаёт, почему
                                       заявка слабая

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

S2 — Диагностика

Разрыв: разомкнутый контур обучения (GAP-NOFEEDBACK в терминах диагностики). Оператор процесса учится на своём опыте (внутренняя усиливающая петля обучения работает), но заявители — нет, потому что их петля обучения разомкнута.

   Оператор:                    Заявитель:
   результаты → анализ →          результат (да/нет) → ???
   улучшение правил →                    │
   лучше работает                   петля разомкнута:
   (R-петля замкнута)               нет данных для улучшения

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

S3 — Вмешательство

Рекомендация: замкнуть контур — возвращать заявителям агрегированную оценку по критериям. Уровень рычага: 8 (информационные потоки). Прогноз бездействия: накопительный тренд, горизонт 1.5–2 цикла, прокси-индикатор — доля повторных заявок с теми же ошибками.

Урок кейса

Главные разрывы часто являются отсутствующими элементами, а не неправильно работающими. Их невозможно найти, читая описание процесса — они видны только на карте как недостающие связи. Это ключевое преимущество картирования над анализом документов.

Кейс 2: Балансирующая петля у жёсткого дедлайна

Тип системы: процесс с итеративной доработкой, ограниченный фиксированным сроком.

S0 — Постановка

Вопрос-катализатор: часть участников систематически не успевает довести заявки до приёмлемого состояния, хотя механизм доработки формально существует.

S1 — Картирование

Обнаружена балансирующая петля доработки: заявка проверяется, выявляются недочёты, заявитель исправляет, подаёт снова. Но у петли есть жёсткое временно́е ограничение — дедлайн, после которого доработка невозможна.

   [Подача] → [Проверка] → [Недочёты] → [Доработка] ──┐
       ▲                                              │
       └──────────────────────────────────────────────┘
              B-петля доработки
              │
              │ задержка проверки: до 5 дней
              ▼
   ════ ДЕДЛАЙН (жёсткое окно) ════
   после него петля физически обрывается

S2 — Диагностика

Разрыв: балансирующая петля с задержкой работает внутри закрывающегося окна. При поздней подаче петля не успевает завершить даже одну итерацию.

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

Любопытная деталь: оператор процесса уже знал о проблеме и закостылил её процедурной рекомендацией ("подавайте раньше"). Это вмешательство уровня 12 (параметр-рекомендация) на структурную проблему уровня 9–10 (задержка в петле) — сам по себе пример анти-паттерна AP-7 (глубина не по природе).

S3 — Вмешательство

Развилка вариантов:

   ┌──────────────┬──────────────┬──────────────┐
   │ БЕЗДЕЙСТВИЕ   │ БЫСТРОЕ      │ СТРУКТУРНОЕ   │
   │              │              │              │
   │ та же доля   │ предпросмотр │ мгновенная   │
   │ теряется     │ перед подачей│ автовалидация│
   │ каждый цикл  │ (ур. 12)     │ (ур. 9)      │
   │              │ эффект част. │ задержка → 0 │
   │ цена: 1 цикл │ цена: низкая │ цена: высокая│
   └──────────────┴──────────────┴──────────────┘

Структурное решение (уровень 9): автоматическая валидация в момент заполнения сжимает задержку петли с нескольких дней до нуля — дедлайн перестаёт обрывать доработку.

Урок кейса

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

Кейс 3: Выбор глубины рычага под природу проблемы

Этот кейс — не один процесс, а контраст трёх ситуаций из разных организаций, показывающий принцип 4 (глубина соответствует природе проблемы).

Ситуация А: структурная проблема → глубокий рычаг

Организация обнаружила дублирование управленческих функций после серии слияний. Это структурная, воспроизводящаяся проблема. Вмешательство: консолидация управленческой структуры (уровень рычага 11 — изменение структуры запасов/потоков) плюс упрощение правил (уровень 7).

   проблема: структурная, постоянная
        │
        ▼
   глубокий рычаг (11 + 7)
        │
        ▼
   результат: устойчивое улучшение
   (структура изменена, проблема не воспроизводится)

Ситуация Б: глубокое вмешательство → ожидаемый worse-before-better

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

   эффективность
   ▔▔▔╲                ╱▔▔▔  ← рост (долгосрочный)
      ╲              ╱
       ╲____________╱
            ↑
       ожидаемое снижение
       на старте — НЕ повод
       сворачивать

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

Ситуация В: преходящий шок → быстрый мелкий рычаг

Организация столкнулась с внезапным внешним шоком (резкое временное падение спроса на основной продукт из-за внешних обстоятельств). Реакция: быстрый запуск нового продукта, адресующего изменившийся контекст. Уровень рычага 12 (параметр — продуктовое предложение) — самый мелкий.

И это был правильный выбор: проблема преходящая, быстрый мелкий ход амортизировал шок, пока он не прошёл. Глубокая реорганизация под временный шок была бы ошибкой (AP-7).

   шок (временный)        быстрый мелкий рычаг (12)
        │                          │
        ▼                          ▼
   ▆▆▆▆▆___ падение           амортизация:
            спроса            компенсировать,
                              пока шок не пройдёт

Урок кейса (контраст трёх ситуаций)

   природа проблемы       правильный рычаг
   ────────────────       ────────────────
   А: структурная     →   глубокий (11, 7)
   Б: структурная     →   глубокий + терпеть worse-before-better
   В: преходящий шок  →   мелкий (12) — и это верно!

   "глубже = лучше" — НЕВЕРНО.
   "глубина под природу проблемы" — верно.

Как читать эти кейсы

Кейсы иллюстрируют не "правильные ответы", а правильный способ рассуждения. Одна и та же система, проанализированная разными аналитиками по STAF, должна дать один и тот же набор структурных находок (диагноз детерминирован относительно верифицированной карты) — но выбор приоритетов вмешательства остаётся управленческим решением, информированным анализом.

Общий метаурок всех трёх кейсов: структура определяет правильное вмешательство. Разомкнутый контур требует замыкания (информационный поток), петля у дедлайна требует сжатия задержки, природа проблемы определяет глубину рычага. Во всех случаях вмешательство выводится из структуры, обнаруженной на карте, — а не из интуиции о том, "что обычно помогает".

STAF 1.0 · SysMindLab · 2026