Элементы и связи
Elements & Connections
01.2 Elements & Connections
Карта системы в STAF строится из конечного словаря элементов и связей. Это не произвольная классификация — каждый тип несёт конкретный аналитический смысл и участвует в конкретных диагностических правилах. Знание типологии — это умение видеть систему через правильные очки, а не просто рисовать блок-схемы.
Часть 1: Элементы (узлы)
В STAF десять типов элементов. Каждый описан через: что это, как распознать, типичные ошибки при классификации.
Визуальная нотация элементов
Каждый тип элемента имеет свой глиф. Эта нотация используется при сборке схем (как в 01.1 Граница системы) — форма рамки сразу сообщает тип элемента, до чтения подписи.
// показать ASCII
ЗАПАС ПОТОК ПЕРЕМЕННАЯ ┌──────────────┐ ═══╪═══► ( опыт ) │ Очередь │ (кран на потоке) (без рамки, │ заявок ▓▓ │ в скобках) └──────────────┘ расходует/пополняет прямоугольник, запас накапливает ПРЕОБРАЗОВАНИЕ РЕШЕНИЕ АКТОР ┌──────────────┐ ◇──────────◇ ┌╴╴╴╴╴╴╴╴┐ │⚙ Проверка │ ◇ Выбор ◇ ╎ Коорди-╎ │ заявки │ ◇ приоритета◇ ╎ натор ╎ └──────────────┘ ◇────────◇ └╴╴╴╴╴╴╴╴┘ шестерёнка = ромб = точка пунктир = шаг процесса выбора кто действует МЕТРИКА ИСТОЧНИК ДАННЫХ ЦЕЛЬ ┌─ ─ ─ ─ ─ ─ ┐ ▢ CRM ▢ ◎ Прозрач- ◎ │ 📊 Время │ ▢ система ▢ ◎ ность ◎ │ обработки │ цилиндр/ ◎ ◎ └─ ─ ─ ─ ─ ─ ┘ хранилище мишень = к чему штрих = измерение стремится система ВНЕШНИЙ ФАКТОР ╔══════════════╗ ║ Регулятор ║ двойная рамка = за границей системы, ╚══════════════╝ влияет, но не анализируется
Глифы — мнемонические, не строгие: в рисованных от руки схемах достаточно подписать тип. Важна различимость на схеме (запас ≠ преобразование ≠ решение), а не точное воспроизведение символов.
Запас (Stock)
Что это. Элемент, который накапливается или расходуется со временем. Запасы инертны: их нельзя изменить мгновенно, только через входящие и исходящие потоки. Именно запасы создают задержки и инерцию системы.
Диагностический смысл. Запас — это то, что "есть прямо сейчас" в системе: очередь заявок на обработке, накопленный технический долг, репутация организации в глазах клиентов, уровень компетенций команды. Многие проблемы формулируются как нежелательное состояние запаса (очередь слишком длинная, репутация падает), а их решение — как изменение потоков.
Примеры. Очередь необработанных заявок. Бюджетный остаток. Уровень удовлетворённости клиентов. Задолженность по функциям продукта. Количество обученных сотрудников.
Типичная ошибка. Путать запас с событием. "Падение продаж" — это не запас, это изменение потока. "Уровень продаж за период" — запас. "Число активных клиентов" — запас. Если элемент не может "копиться" — это не запас.
Поток (Flow)
Что это. Темп изменения запаса за единицу времени. Потоки — единственное, через что запасы могут меняться. Нет потока — запас не изменится никогда.
Диагностический смысл. Воздействовать на систему можно через потоки: ускорить поступление ресурсов, замедлить отток клиентов, увеличить темп обработки заявок. Но потоки часто сами определяются другими элементами — переменными и решениями.
Примеры. Скорость поступления новых заявок (пополняет запас "очередь"). Темп оттока клиентов (расходует запас "активные клиенты"). Скорость обработки (расходует запас "необработанные заявки", пополняет "обработанные").
Типичная ошибка. Рисовать поток там, где нет изменения запаса. Если элемент не изменяет ничего накапливаемого — это не поток, это переменная или связь.
Переменная (Variable)
Что это. Вспомогательная величина, которая влияет на потоки или решения, но сама не является запасом. Переменные — это промежуточные звенья причинных цепочек.
Примеры. Загрузка команды (влияет на скорость обработки). Опыт руководителя (влияет на качество решений). Сезонность (влияет на поток входящих запросов).
Типичная ошибка. Пытаться разграничить запас и переменную "на глаз". Правило: переменная не имеет истории — она определяется текущими значениями других элементов. Запас имеет историю — его нельзя изменить мгновенно, даже если все потоки изменились.
Преобразование (Transformation)
Что это. Шаг процесса, принимающий входы и производящий выходы. Преобразования — это то, что делается в системе: проверяется, согласовывается, разрабатывается, доставляется.
Диагностический смысл. Каждое преобразование должно иметь: явного ответственного, измеримые входы и выходы, и в идеале — метрику своей работы. Отсутствие любого из трёх — кандидат на диагностический разрыв.
Примеры. Проверка заявки на соответствие требованиям. Сборка квартального отчёта. Онбординг нового клиента. Code review перед релизом.
Уровень автоматизации. Каждое преобразование может быть охарактеризовано по степени автоматизации: от полностью ручного (человек делает всё) до полностью автоматического (система делает без участия человека). Ручные преобразования на критическом пути — типичный кандидат на диагностику (не потому что автоматизация всегда правильна, а потому что стоит осознанно решить).
Решение (Decision)
Что это. Точка в системе, где совершается выбор, влияющий на последующие действия. Решения — это места, где система может "свернуть" в разных направлениях.
Диагностический смысл. Каждое решение должно иметь: информационные входы (что именно лежит в основе выбора) и ответственного актора. Решение без информационного входа — классический диагностический разрыв: выбор делается "вслепую" или на основе интуиции вместо данных.
Примеры. Решение о приоритете задачи в спринте. Решение о выдаче гранта. Решение о запуске нового продукта. Решение о найме кандидата.
Типичная ошибка. Путать решение с преобразованием. Решение — это выбор между альтернативами. Преобразование — это преобразование входа в выход без альтернатив. Если шаг можно описать как "берём X, делаем с ним Y, получаем Z" — это преобразование. Если "смотрим на X и Y, выбираем Z или W" — это решение.
Актор (Actor)
Что это. Участник системы, несущий ответственность за преобразования или решения. В STAF акторы — полноправные элементы карты, а не подписи к стрелкам. Это позволяет диагностировать отсутствие ответственного как структурный факт.
Диагностический смысл. Наличие актора для каждого преобразования и решения — это проверяемое условие (принцип подотчётности). Преобразование или решение без явного ответственного актора — диагностируемый разрыв.
Примеры. Координатор проектов. Комитет по инвестициям. Алгоритм автоматической модерации. Внешний аудитор. (Актором может быть человек, группа людей или автоматизированная система — важна ответственность, а не природа актора.)
Метрика (Metric)
Что это. Измерение состояния другого элемента системы. Метрики — информационный слой: они делают состояние системы видимым для принятия решений.
Диагностический смысл. Метрика без связи к решению — это данные, которые никто не использует (нарушение принципа визуализируемости). Решение без входящей метрики — выбор вслепую. Оба состояния диагностируемы.
Примеры. Среднее время обработки заявки. NPS после первого использования. Доля заявок, вернувшихся на доработку. Процент задач, завершённых в срок.
Источник данных (Data Source)
Что это. Место, откуда метрика получает свои значения. Метрика может существовать как концепция ("нам важно время обработки"), но если нет источника данных — метрика является пустой декларацией.
Диагностический смысл. Полная цепочка верифицируемости: источник данных → метрика → решение. Разрыв в любом звене диагностируем.
Примеры. CRM-система. Форма обратной связи. Ручная выгрузка из Excel. Данные ЕГРЮЛ. Система мониторинга производительности.
Цель (Goal)
Что это. Желаемое состояние системы или конкретного актора. Цели определяют направление балансирующих петель: система стремится закрыть разрыв между текущим состоянием и целью.
Диагностический смысл. Конфликт целей между акторами — источник архетипа "Accidental Adversaries" (союзники, работающие против друг друга). Цель, не связанная ни с одним решением и ни с одной метрикой — декларативная, а не системная.
Внешний фактор (External)
Что это. Элемент, находящийся за границей системы, но влияющий на неё. Внешние факторы включаются в карту для фиксации зависимостей — чтобы видеть, откуда приходят входы и куда уходят выходы, которые система не контролирует.
Примеры. Донор в процессе грантовой отчётности. Регулятор, устанавливающий требования. Клиенты, формирующие поток входящих запросов.
Типичная ошибка. Не включать внешние факторы в карту вообще, создавая иллюзию, что система полностью автономна. Другая ошибка — включать и потом пытаться диагностировать проблемы во внешних факторах, что означало бы выход за границу анализа.
Часть 2: Связи (рёбра)
Связи — это то, что превращает список элементов в систему. В STAF восемь типов связей, каждая с конкретным аналитическим значением.
Визуальная нотация связей
Тип связи кодируется стилем стрелки. Это позволяет на одной схеме различать причинность, поток ресурсов и информационные связи, не подписывая каждую стрелку.
// показать ASCII
ПРИЧИННАЯ ──(+)──► рост причины → рост следствия
(causal) ──(-)──► рост причины → спад следствия
──(+)═► двойная черта = задержка
ВХОДЯЩИЙ РЕСУРС ───────► ресурс на вход преобразования
(input) [запас] ──► [⚙ преобразование]
ИСХОДЯЩИЙ РЕЗУЛЬТАТ ───────► результат преобразования
(output) [⚙ преобразование] ──► [запас]
ОТВЕТСТВЕННОСТЬ ╴╴╴╴╴╴► актор отвечает за шаг/решение
(responsible for) [актор] ╴╴► [⚙] или [◇]
ИЗМЕРЕНИЕ ┄┄┄┄┄► метрика измеряет элемент
(measures) [📊 метрика] ┄┄► [⚙ процесс]
ПИТАЕТ ┄┄┄┄┄► источник данных → метрика
(feeds) [▢ CRM] ┄┄► [📊 метрика]
ИНФОРМИРУЕТ ┄┄┄┄┄► данные доходят до решения
(informs) [📊 метрика] ┄┄► [◇ решение]
ПРЕСЛЕДУЕТ ╴╴╴╴╴► актор стремится к цели
(pursues) [актор] ╴╴► [◎ цель]Три семейства стилей кодируют смысл: сплошная стрелка ───► — материальный
поток или причинность; пунктир ╴╴╴► — отношение (ответственность, цель);
точечная ┄┄┄► — информационная связь (измерение, данные, информирование).
Это деление помогает с первого взгляда отличить «что течёт» от «кто отвечает»
и «что кого информирует».
Причинная связь (Causal)
Что это. Утверждение: изменение одного элемента систематически ведёт к изменению другого. Самый аналитически насыщенный тип связи.
Обязательные атрибуты:
- Знак (+/-) — направление влияния (см. глоссарий)
- Задержка — насколько быстро следствие проявляется после причины
Именно причинные связи образуют петли обратной связи. Все остальные типы связей строят структуру; причинные — создают динамику.
Доказательность. Причинная связь — наиболее рискованный элемент для выдумывания. Аналитик видит корреляцию или логическую смежность и рисует стрелку. В STAF каждая причинная связь требует либо прямой цитаты из источника, либо явной маркировки как "предположена" с обоснованием. Без этого — это не факт о системе, а гипотеза аналитика.
Входящий ресурс (Input)
Что это. Ресурс (материальный или информационный), поступающий на вход преобразования. Описывает, из чего сделан процесс, не то, как один элемент влияет на другой.
Примеры. Заявка на входе процесса проверки. Данные пользователя на входе аналитического шага. Исходные материалы на входе производственного процесса.
Исходящий результат (Output)
Что это. Результат преобразования, поступающий в следующий элемент системы. Вместе с входящими ресурсами задаёт "что производит" данный шаг процесса.
Ответственность (Responsible For)
Что это. Связь "актор несёт ответственность за преобразование или решение". Делает подотчётность явным структурным фактом, а не подразумеваемым.
Диагностическое правило. Для каждого преобразования и решения в верифицированной модели должна существовать хотя бы одна связь этого типа. Отсутствие — диагностируемый разрыв подотчётности.
Измерение (Measures)
Что это. Связь "метрика измеряет состояние элемента". Делает явным, что именно и как именно отслеживается в системе.
Диагностическое правило. Каждый критически важный процесс и его выходы должны иметь хотя бы одну входящую связь этого типа. Отсутствие — диагностируемый разрыв верифицируемости.
Питает (Feeds)
Что это. Связь "источник данных питает метрику". Замыкает цепочку верифицируемости: данные реально откуда-то берутся.
Диагностическое правило. Метрика без источника данных — декларация, не инструмент.
Информирует (Informs)
Что это. Связь "метрика или источник данных информирует решение". Делает явным, что данные доходят до точки принятия решения.
Диагностическое правило. Каждое решение должно иметь хотя бы одну входящую связь этого типа. Отсутствие — диагностируемый разрыв визуализируемости.
Замечание о качестве. Наличие связи "информирует" не гарантирует качества информирования. Решение может быть связано с источником данных, который является самоотчётным или неверифицированным — это отдельный, более глубокий разрыв (нарушение верифицируемости источника, а не отсутствие связи).
Преследует (Pursues)
Что это. Связь "актор преследует цель". Делает явными стимулы и направление усилий каждого участника системы.
Диагностический смысл. Два актора, преследующие конфликтующие цели при зависимости друг от друга — структурная предпосылка архетипа "Accidental Adversaries".
Сборка: как нотация складывается в схему
Глифы элементов и стили связей собираются в единую карту. Пример — фрагмент процесса обработки заявок со всеми типами нотации:
// показать ASCII
┌╴╴╴╴╴╴╴╴┐ ◎ Пропускная ◎
╎ Коорди-╎╴╴ответственность╴╴┐ ◎ способность ◎
╎ натор ╎ ╎ ▲
└╴╴╴╴╴╴╴╴┘ ▼ ╎ преследует
╎ преследует ┌──────────────┐ ╎
▼ │⚙ Обработка │ ┌╴╴╴╴╴╴╴╴┐
◎ Скорость ◎ │ заявки │ ╎ Команда╎
◎ ответа ◎ └──────────────┘ └╴╴╴╴╴╴╴╴┘
▲ │
┌──────────────┐ │ input │ output
│ Очередь ▓▓ │───────┘ ▼
│ заявок │ ┌──────────────┐
└──────────────┘ │ Обработанные │
▲ │ заявки ▓ │
│ output └──────────────┘
═══╪═══► ┊ measures
поток входящих ┌─ ─ ─ ─ ─ ─ ┐
заявок │ 📊 Время │
(из облака ☁) │ обработки │
└─ ─ ─ ─ ─ ─ ┘
▲ feeds
▢ Тикет- ▢
▢ система ▢Читается так: команда и координатор отвечают за обработку заявки (пунктир ответственности); поток заявок пополняет очередь, очередь подаётся на вход обработки (input), результат уходит в запас обработанных (output); время обработки измеряется (measures) на основе данных тикет-системы (feeds); координатор и пропускная способность связаны с целями (преследует).
Эта же схема при диагностике сразу показывает потенциальный разрыв: измеряется
время обработки, но связь информирует (от метрики к какому-либо решению)
отсутствует — данные собираются, но ни одно решение на них не опирается. Глиф
есть, стрелки informs нет — визуальный сигнал разрыва визуализируемости.
Принципы построения карты
Каждый элемент — один раз. Одна и та же сущность не дублируется как несколько узлов. "Координатор проектов" — один узел, даже если он участвует в десяти преобразованиях.
Связи — не стрелки "для красоты". Каждая связь несёт тип. Нетипизированная стрелка между двумя элементами не является элементом карты STAF.
Гранулярность определяется вопросом. Преобразование "работа с заявкой" может быть одним узлом или разворачиваться в цепочку из десяти шагов — зависит от того, на каком уровне находится вопрос и потенциальная точка вмешательства. Лишняя детализация засоряет карту; недостаточная — прячет разрывы.
Провенанс обязателен. Каждый элемент и каждая связь несут атрибут происхождения. Это не бюрократия — это механизм, позволяющий верифицировать карту с носителем системы без пересмотра всего подряд (сначала проверяются предположенные элементы, потом — при желании — извлечённые).
STAF 1.0 · SysMindLab · 2026