Граница системы
System Boundary Definition
01.1 System Boundary Definition
Граница системы — первое и самое рискованное решение в любом аналитическом цикле STAF. Всё, что будет найдено дальше — разрывы, петли, рекомендации — является следствием этого решения. Неправильно проведённая граница не исправляется на этапе диагностики: она просто делает диагноз диагнозом другой системы.
Что такое граница и почему она — решение, а не факт
В физическом мире границы часто очевидны: завод — это завод, офис — это офис. В организационных системах граница — аналитический выбор. Один и тот же процесс подачи грантовой заявки можно рассматривать как: (а) действия заявителя от заполнения до подачи, (б) взаимодействие заявителя с фондом до объявления итогов, (в) полный цикл от идеи проекта до закрытия гранта и отчётности. Это три разные системы с разными петлями, разными разрывами и разными точками рычага.
Никакая из этих границ не является "правильной" в абсолютном смысле. Правильная — та, которая соответствует вопросу, на который мы отвечаем, и полномочиям тех, кто будет действовать по результатам анализа.
Следствие для практики. Если у заказчика анализа нет полномочий менять то, что находится внутри предложенной границы — граница проведена неправильно, независимо от её аналитической точности.
Три составляющих границы
В STAF граница системы фиксируется тремя явными элементами, каждый из которых обязателен.
Базовый образ — одна и та же схема, к которой мы будем возвращаться при разборе ошибок:
╔══════════════════════════════════════════════════════╗
║ ║
║ IN SCOPE ║
║ ║
║ [Событие-начало] ──→ [шаг] ──→ [шаг] ──→ [шаг] ║
║ │ │ ║
║ │ СИСТЕМА │ ║
║ └──── петли внутри ────────────────→ [Событие-конец]
║ ║
╠══════ граница ══════════════════════════════════════╣
║ ║
║ EXCLUSIONS (осознанно вынесено) ║
║ · Финансовый аудит — не в полномочиях ║
║ · Онбординг после выхода — следующий процесс ║
║ ║
╠══════════════════════════════════════════════════════╣
║ ║
║ OPEN QUESTIONS (влияет, но неясно как) ║
║ · Участвует ли бухгалтерия в сверке? (неизвестно) ║
║ · Как решения внешнего регулятора меняют процесс? ║
║ ║
╚══════════════════════════════════════════════════════╝
[Внешние акторы] [Внешние факторы]
Донор, Регулятор Рынок, Законодательство
← влияют на систему, ← влияют, но не анализируются
не входят внутрьТри зоны на схеме — три обязательных элемента описания границы.
1. Что входит (in_scope)
Человекочитаемое описание того, что охватывает анализ. Формулируется как процесс, а не как организационная единица: "процесс найма от открытия вакансии до выхода сотрудника на работу", а не "HR-отдел". Процессная формулировка точнее определяет начальную и конечную точку, не создавая иллюзию, что за пределами "отдела" система не существует.
✓ ПРАВИЛЬНО: "от открытия вакансии до первого рабочего дня нового сотрудника"
→ начало и конец — события, граница однозначна
✗ НЕПРАВИЛЬНО: "HR-отдел"
→ это организационная единица, а не процесс;
неясно, где он начинается и заканчивается2. Что исключено осознанно (exclusions)
Список того, что упоминается в источниках, влияет на систему, но намеренно вынесено за границу анализа — с явным обоснованием.
╔══════════════════════════════════════════════════════╗ ║ IN SCOPE: процесс найма ║ ║ ║ ║ [Вакансия] → [Отбор] → [Оффер] → [Выход на работу] ║ ║ ║ ╠══════ граница ═══════════════════════════════════════╣ ║ ║ ║ EXCLUSIONS: ║ ║ · Испытательный срок ← в юрисдикции ║ ║ (влияет на retention, другой команды ║ ║ но не в полномочиях HR) ║ ║ · Финансовое согласование ← фиксируем как ║ ║ ставки (упоминается в внешний фактор, ║ ║ регламентах, влияет на не разрыв ║ ║ скорость оффера) ║ ║ ║ ╚══════════════════════════════════════════════════════╝
Этот список важен по двум причинам. Во-первых, он предотвращает ситуацию, когда аналитик молчаливо исключает что-то, не осознавая этого. Во-вторых, он защищает от ложных разрывов: если исключённый элемент не попал в карту, это не разрыв системы — это осознанное решение о границе.
3. Открытые вопросы о границе (open_questions)
Список подозрений: элементы, которые находятся за границей, но, возможно, влияют на систему существеннее, чем казалось при определении границы.
╔══════════════════════════════════════════════════════╗ ║ IN SCOPE: процесс найма ║ ║ ║ ║ [Вакансия] → [Отбор] → [Оффер] → [Выход на работу] ║ ║ │ ↑ ║ ╠══════ граница ═══│════════════════════════│══════════╣ ║ │ │ ║ ║ OPEN QUESTIONS: │ │ ║ ║ · Откуда идут ↓ Что влияет ─┘ ║ ║ лучшие кандидаты? на скорость выхода? ║ ║ (реферальная программа (IT-доступы, оборудо- ║ ║ находится за границей, вание — за границей, ║ ║ но может объяснять но задержки критичны) ║ ║ качество воронки) ║ ║ ║ ╚═══════════════════════════════════════════════════════╝ ↑ Эти вопросы не блокируют анализ — они становятся гипотезами для следующего цикла или уточняются при верификации с носителем системы.
Как проводить границу: четыре вопроса
Правильная граница отвечает "да" на все четыре вопроса.
Вопрос 1: Есть ли у заказчика полномочия изменить что-либо внутри? Если всё внутри границы находится вне зоны влияния тех, кто будет действовать по результатам — граница слишком широка или направлена не туда. Диагноз правильный, но бесполезный.
Вопрос 2: Включены ли все петли обратной связи, критические для понятия проблемы? Если ключевая петля пересекает предложенную границу — система будет выглядеть разомкнутой там, где она замкнута в реальности. Это создаёт ложные разрывы и упускает реальные точки рычага.
Вопрос 3: Можно ли описать начало и конец системы как конкретные события? "Процесс работы с клиентами" — слабая граница. "От первого контакта клиента до закрытия первой сделки" — сильная. Конкретное начало и конец позволяют однозначно решить, входит ли конкретный элемент внутрь или нет.
Вопрос 4: Является ли граница достаточно узкой, чтобы анализ был завершим? Слишком широкая граница ведёт к анализу, который никогда не заканчивается или заканчивается поверхностно. Лучше провести глубокий анализ узкой, но верно выбранной части системы, чем поверхностный — широкой.
Происхождение границы и его последствия
В STAF граница системы несёт атрибут происхождения — так же, как любой другой элемент модели.
user_guided: граница сформулирована на основе ответов носителя системы или
заказчика анализа на направляющие вопросы. Это предпочтительный статус: граница
отражает понимание людей, живущих внутри системы.
ai_inferred (или аналитически предположена): граница определена аналитиком
на основе изученных источников, без явного подтверждения от носителя. Это
допустимый, но рискованный статус: в точке верификации такая граница должна быть
показана носителю первой и получить явное подтверждение или корректировку.
Граница со статусом ai_inferred, перешедшая в диагноз без верификации,
аннулирует доказательную силу всего последующего анализа.
Типичные ошибки при определении границы
Каждая ошибка показана относительно одной и той же базовой схемы — чтобы было видно, что именно ломается в структуре.
Ошибка 1: Организационная граница вместо процессной
╔══════════════════════════════════════════════════════╗
║ IN SCOPE: "Отдел продаж" ← ОШИБКА ║
║ ║
║ [менеджер 1] [менеджер 2] [менеджер 3] ║
║ ║
╠══════ граница по краю отдела ════════════════════════╣
║ ║
║ За границей осталось: ║
║ · Лиды от маркетинга (откуда приходят клиенты?) ║
║ · Финансы (оплата как подтверждение сделки) ║
║ · Продукт (что именно продаётся) ║
║ ║
╚══════════════════════════════════════════════════════╝
↑ Граница отрезала именно те элементы, которые могут
быть корнем проблем, кажущихся "внутренними"Вместо этого: "процесс от получения лида до закрытия первой оплаты" — тогда все зависимости от маркетинга и финансов попадают на границу явно, а не исчезают.
Ошибка 2: Граница по видимому симптому
Симптом: "растёт время ответа на запросы клиентов"
↓
╔══════════════════════════════════════════════════════╗
║ IN SCOPE: "команда поддержки" ← ОШИБКА ║
║ ║
║ [тикет] → [назначить] → [решить] → [закрыть] ║
║ ║
╠══════ граница ═══════════════════════════════════════╣
║ ║
║ За границей осталось: ║
║ · Как продукт создаёт ожидания клиентов ──┐ ║
║ · Как UX генерирует тип запросов ─────────┤← здесь ║
║ · Как разработка создаёт баги ────────────┘ КОРЕНЬ ║
║ ║
╚══════════════════════════════════════════════════════╝
↑ Граница проведена по симптому — петля, ведущая
к причине, оказалась снаружиГраница по симптому систематически срезает петли, ведущие к его причине. Правильная граница здесь: "от формирования пользовательских ожиданий до закрытия запроса" — тогда UX и продуктовые решения попадают внутрь.
Ошибка 3: Граница шире полномочий
╔══════════════════════════════════════════════════════╗
║ IN SCOPE: весь процесс работы с клиентами ║
║ ║
║ [маркетинг] → [продажи] → [онбординг] → [саппорт] ║
║ ↑ ↑ ↑ ║
║ нет доступа ограничен другой отдел ║
║ у заказчика доступ ║
║ ║
╠══════ граница ═══════════════════════════════════════╣
║ ║
║ Заказчик анализа = менеджер по саппорту ║
║ Полномочия заказчика: только саппорт-команда ║
║ ║
╚══════════════════════════════════════════════════════╝
↑ Диагноз правильный, рекомендации невыполнимы:
"исправьте маркетинговые сообщения" —
у заказчика нет на это влиянияПравильная граница: только то, что заказчик реально может изменить. Всё остальное — внешние факторы или открытые вопросы для другого цикла.
Ошибка 4: Отсутствие exclusions
╔══════════════════════════════════════════════════════╗
║ IN SCOPE: "процесс подачи гранта" (описан) ║
║ ║
║ [заявка] → [проверка] → [экспертиза] → [итоги] ║
║ ║
╠══════ граница ═══════════════════════════════════════╣
║ ║
║ EXCLUSIONS: не заполнено ← ОШИБКА ║
║ ║
║ Что молчаливо не вошло: ║
║ · Финансовый аудит — аналитик "не думал о нём" ║
║ · Реализация проекта — "само собой не входит" ║
║ · Взаимодействие с СМИ — "не наш процесс" ║
║ ║
╚══════════════════════════════════════════════════════╝
↑ Если финансовый аудит влияет на процесс и
не войдёт в карту — будет диагностирован
как разрыв, которого нет.
Без явного exclusions — невозможно отличить
"не вошло случайно" от "исключено осознанно"Как думали до STAF, как стало: где провести границу
ДО STAF (привычный подход) В STAF
────────────────────────── ──────
граница = там, где граница = там, где
организационная единица замыкаются петли,
(«наш отдел», «наш процесс») влияющие на проблему,
И где есть полномочия
на изменения
проводится молча, проводится явно, с
по умолчанию тремя частями (входит/
исключено/открытые
вопросы) и проверкой
4 вопросами
следствие: следствие:
причина за границей → причина внутри границы
её не видно → → её видно →
лечат симптом можно вмешаться в кореньПривычный подход проводит границу там, где проходит организационная или процессная граница — «вот наш процесс, его и анализируем». STAF проводит границу там, где это нужно для понимания проблемы: достаточно широко, чтобы включить причину (а она часто за пределами «нашего» процесса), и достаточно узко, чтобы анализ был выполним и привязан к реальным полномочиям. Это превращает выбор границы из умолчания в осознанное решение с проверяемыми критериями.
Граница как живой артефакт
При верификации модели. Носитель системы часто указывает на элементы, которые аналитик не включил, считая их "за пределами". Это сигнал к расширению или смещению границы — до того, как диагностика проведена.
При диагностике. Если обнаруживаются разрывы, которые невозможно устранить без изменения того, что за границей — это сигнал, что граница проведена неверно. Инструмент без точки приложения — не инструмент.
При пересмотре цикла. Система меняется, полномочия изменяются, контекст обновляется. Граница, верная год назад, может перестать соответствовать текущей ситуации.
STAF 1.0 · SysMindLab · 2026