Аналитик — не «переводчик» с языка бизнеса на язык разработки. Его задача — мыслить системами: видеть целое за набором требований и функций, а не только локальные изменения. Эта статья закрывает базовый вопрос: что считать системой, какие у неё свойства и как системный подход проявляется в вашей работе. Граница с ролями BA и SA и со стандартами — в 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).

IIBA выделяет системное мышление (systems thinking) в отдельную базовую компетенцию (Underlying Competency). Для системного аналитика параллельный ориентир — SEBoK и INCOSE Systems Engineering Handbook: та же идея «целого в контексте», но с акцентом на жизненный цикл и границы технического решения. Системный взгляд на границы и цели нужен на всех фазах жизненного цикла ПО — здесь только базовая рамка, без разбора фаз.

1. Суть темы

Что такое система

INCOSE в пятом издании Handbook (2023) уточняет: система — мета-концепция, а не только физический объект. Её используют, чтобы организовать знания о сложном явлении и согласовать описания между ролями.

Классическое определение (INCOSE SE Handbook, 5th ed., 2023):

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

Для аналитика мета-концепция означает три практических следствия:

  • Границы и цели задаются, а не «даны природой» — одна и та же CRM может быть системой продаж, подсистемой маркетинга или элементом процесса онбординга; от выбора границы зависит scope требований.
  • Одна система допускает несколько корректных описаний (бизнес-, функциональное, техническое) — они должны быть согласованы, а не конкурировать.
  • Цель формулируется явно — без неё нельзя отделить элемент системы от части среды.

Три базовые характеристики любой системы:

  • Элементы (компоненты, подсистемы) — из чего система состоит.
  • Связи (взаимодействия, интерфейсы) — как элементы влияют друг на друга.
  • Цель (назначение) — ради чего система существует.

Открытые и закрытые системы, граница и среда

Закрытая система — абстракция, где обмен с внешним миром не моделируется (редко в ИТ-проектах). Открытая система обменивается с средой (окружением): люди, смежные ИС, регуляторы, рынок. Граница системы — договорённость, что внутри scope анализа, а что снаружи.

На стороне бизнес-анализа границы решения задают через моделирование scope; на стороне системного анализа — через контекстную диаграмму. Без явной границы нельзя перечислить акторов, входы/выходы и критерии «система работает / не работает».

Типы систем в ИТ-анализе

  • Социотехнические системы — люди + процессы + технологии (система обработки заказов).
  • Информационные системы (ИС) — подкласс, где ключевой ресурс — данные и их обработка; отличие от «продукта» и «предприятия» — в масштабе границы (см. виды описания архитектуры).
  • Программные системы — софт, взаимодействующий с окружением через API и интеграции.

Пример: CRM — не «просто база клиентов». Это элементы (контакты, сделки, интеграция с почтой), связи (API между модулями, роли пользователей, сквозные бизнес-процессы) и цель (например, рост конверсии воронки). Решение нельзя проектировать в изоляции: горизонтальные связи (между модулями) и вертикальные (CRM внутри цепочки «лид → оплата → поддержка») влияют на требования одинаково.

Система, процесс и функция — разные «проекции»: процесс — последовательность работ во времени (BPMN); функция — что система делает для пользователя (бизнес- и функциональные требования); система — целое с границей и целью. В спецификации не смешивайте уровни без явной пометки.

Системный подход

Системный подход — методология, при которой объект рассматривается как система и во взаимосвязи со средой. Это не то же самое, что перечисление свойств системы (§2): подход — как вы действуете, свойства — что вы наблюдаете. Каркас подхода сводится к четырём опорам: целостность, структурированность, учёт среды, согласованность нескольких описаний — их развёрнутое применение в §3.

На практике системный подход начинается с явной цели и границы и связывает декомпозицию с контекстом. Аналитический рез (термин Russell Ackoff) — разобрать объект на части без учёта цели и среды: декомпозиция полезна локально, но сама по себе не делает мышление системным. Конкретные паттерны проектирования решений — в соседней статье раздела 01.

2. Ключевые понятия

Эмерджентность

Целое обладает свойствами, которых нет у частей по отдельности.

Пример: кнопка, поле ввода и БД по отдельности не дают «записи к врачу»; вместе — дают. Эмерджентные свойства качества — функциональность сквозного сценария, надёжность, предсказуемость поведения при сбоях. Стоимость владения или разработки — скорее агрегат ограничений и решений команды, а не эмерджентность в строгом смысле.

Следствие: нельзя проектировать фичи изолированно — проверяйте, какие системные эффекты появляются на стыках.

Иерархичность

Любая система — подсистема для более крупной и надсистема для более мелких. Модуль оплаты — часть интернет-магазина и сам содержит подсистемы авторизации, чеков, возвратов. Декомпозиция — в отдельной статье.

Гомеостаз (устойчивость)

В теории систем гомеостаз — сохранение рабочего состояния через обратную связь. В ИТ-проектах это аналогия для эксплуатации: отказоустойчивость, деградация без полного падения (graceful degradation). Это не тождество классическому биологическому гомеостазу — скорее язык для обсуждения устойчивости и нефункциональных требований.

Эквифинальность

В открытых системах один результат достижим разными путями. Одно бизнес-требование можно реализовать множеством технических сценариев; выбор оптимального — часть системного анализа, а не единственный «правильный» вариант.

Следствие: несколько допустимых реализаций одного БТ — норма; зафиксируйте критерии выбора и отвергнутые альтернативы в scope или ADR, иначе команда будет спорить о «единственно верном» решении (подробнее — принципы проектирования решений).

Петли обратной связи

Поведение системы часто определяют не линейные цепочки «причина → следствие», а петли:

  • Усиливающая (R-loop) — изменение накапливается (рост → больше ресурсов → ещё рост).
  • Балансирующая (B-loop) — система стремится к цели или ограничению (рост нагрузки → throttling → стабилизация).

На CLD (Causal Loop Diagrams) с полярностью (+/-) и архетипами петель — в техниках анализа проблем и у Meadows (см. источники).

3. Как применяется в работе аналитика

Ниже — и BA-, и SA-точки зрения на одну систему: границы и KPI с бизнес-стороны, модели и декомпозиция с технической.

Принципы системного подхода

1. Целостность — анализируем систему как единое целое, а не сумму компонентов.

→ При сборе требований начинаем с контекста и границ (Context Diagram; scope с бизнес-стороны — Scope Modelling).

2. Структурированность — описываем элементы, связи, иерархию.

→ Структура данных — ER-модель; состав и декомпозиция — декомпозиция на подсистемы; нотации UML — поведенческие диаграммы.

3. Взаимозависимость системы и среды — система функционирует в окружении.

→ Внешние акторы — карта заинтересованных сторон; интерфейсы со смежными системами — интеграционные взаимодействия (без углубления в протоколы).

4. Множественность описаний — для сложной системы нужны несколько согласованных моделей.

→ Функциональная проекция — Use Case и Activity; информационная — ER; поведение во времени — Sequence. Это разные «срезы» одной системы, а не дублирование ради объёма документации.

Системный подход по этапам работы

Таблица опирается на свойства из §2 — что именно проверять на каждом этапе, а не повторяет четыре принципа выше.

Этап анализаПроявление системного подхода
Выявление требованийЯвные граница и цель; карта среды и акторов; первые гипотезы о петлях — что усиливает или балансирует ключевые KPI.
Анализ и спецификацияДекомпозиция с учётом иерархии; несколько согласованных описаний; проверка эмерджентных эффектов на стыках модулей и интеграций.
Проектирование решенияЭквифинальность: несколько допустимых реализаций одного БТ — явные критерии выбора, фиксация альтернатив в scope или ADR.
ВалидацияПроверка, что система в целом достигает бизнес-цели ([[02.04.01 Верификация и валидация (V&V)

Практические приёмы

Теория становится инструментом, когда вы явно фиксируете:

  1. Контекст и границы — кто внутри, кто снаружи, какие потоки данных и событий пересекают границу.
  2. Модель «айсberg» — заимствованная рамка (не часть INCOSE/SE): видимые симптомы (инциденты, жалобы) отделены от структур и ментальных моделей; полезно на старте разбора «почему процесс не работает» (определение бизнес-проблем).
  3. Петли обратной связи — перед усилением контроля (дополнительные проверки, согласования) спросите: какая B-loop удерживает метрику и не сломает ли новое требование R-loop в смежном KPI. Локальная «оптимизация» одного показателя — тема теории ограничений.
  4. Упрощённая причинная схема (не полноценная CLD) — для обсуждения trade-off на воркшопе, с последующей проработкой полярности в техниках анализа проблем.

Пример (банковский KPI): ужесточение проверок в кредитном конвейере может одновременно снижать дефолты (балансирующая петля «качество портфеля») и увеличивать время обработки, снижая число одобренных заявок (усиливающая связь «нагрузка → пропускная способность»). Универсального вывода «100% валидация всегда вредна» нет: для высокорисковых сегментов и регуляторных требований жёсткий контроль может быть обязательным. Задача аналитика — явно назвать затронутые петли, риски, сегменты и критерии успеха (KPI и критерии успеха), а не продавать одну сторону trade-off как «системную истину».

graph TD
    A["Число проверок и согласований"] -->|+| B["Качество одобренных заявок"]
    A -->|+| C["Время обработки TAT"]
    C -->|-| D["Число одобренных заявок"]
    D -->|-| E["Объём выданного портфеля"]
    B -->|+| E
    E -->|+/−| F["Доход банка"]

    style A fill:#f9f,stroke:#333,stroke-width:2px
    style E fill:#bbf,stroke:#333,stroke-width:2px
    style F fill:#afa,stroke:#333,stroke-width:2px

Подписи +/- на рёбрах — направление влияния «в том же / противоположном направлении», как в CLD. Переменные и полярности — гипотезы для сессии, не модель конкретного банка: связь «качество → объём портфеля» упрощена для обсуждения trade-off. Замыкание «доход → число проверок» намеренно не показано — это спорная R-петля, которую команда должна явно согласовать или отвергнуть после обсуждения сегментов и KPI. Полноценная CLD с именованными R/B-петлями — следующий шаг после согласования переменных с заказчиком.

4. Типовые ошибки и ограничения

Классические антипаттерны несистемного мышления:

  • Фрагментация — детальная проработка одной фичи без влияния на сквозные процессы.
  • Локальная оптимизация — ускорили модуль A, система в целом замедлилась из-за узкого места в B.
  • Игнорирование обратных связи — «идеальный» процесс на бумаге, который пользователи обходят в обходных петлях.
  • Игнорирование среды — система стабильна внутри контура, но падает на интеграции с legacy.
  • Подмена границы удобством — scope «плывёт», потому что не зафиксированы акторы и цель.
  • Одна модель на всё — только User Story без контекста, данных или поведения во времени.
  • Аналитический рез вместо системного — глубокая декомпозиция без явной цели, границы и учёта среды; части описаны, целое не сходится.

Часть ловушек усиливается когнитивными искажениями (якорение на первом решении, confirmation bias) — см. когнитивные искажения и критическое мышление. Здесь — системный слой: что именно в модели мира команды упущено.

Связи с другими разделами базы

Ссылки, не упомянутые выше в тексте:

Источники и дополнительные материалы

Книги

  • Донелла Медоуз «Азбука системного мышления» (Thinking in Systems: A Primer). Петли обратной связи, запасы и потоки, точки воздействия.
    • Meadows, D. H., & Wright, D. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
    • Русский перевод: изд. «БИНОМ. Лаборатория знаний», 2013.

Стандарты и своды знаний

  • INCOSE Systems Engineering Handbook (v5, 2023) — концепция системы, системное мышление, жизненный цикл.
  • BABOK® Guide (v3) — гл. 9 Underlying Competencies, раздел «Systems Thinking».
    • IIBA. (2015). A Guide to the Business Analysis Body of Knowledge (BABOK Guide) (v3).
    • В BABOK системное мышление — способность понимать предприятие и контекст целостно; терминология пересекается с работами Russell Ackoff о системах управления и «системном» vs «аналитическом» подходе к организациям (не путать с отдельным глоссарием IIBA — это общая системная традиция).
  • SEBoK — свод знаний по системной инженерии; обзор в статье о стандартах; wiki: https://www.sebokwiki.org/
  • Профессиональные стандарты РФ:
    • «Системный аналитик» (Приказ Минтруда № 367н от 27.04.2023) — блок «Основные принципы системного анализа и управления требованиями».
    • «Бизнес-аналитик» (Приказ Минтруда № 821н от 22.11.2023).

Онлайн-ресурсы