Системная инженерия. Часть 1

Роли в системной инженерии

Вторая тема курса по бизнес-аналитике и науке о данных посвящена системной инженерии. Сначала мы рассматриваем формальную сторону — как устроена деятельность компании и какова роль бизнес-аналитика внутри неё. Это поможет очертить круг его ответственности и фронт работ, после чего мы перейдём к науке о данных.

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

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

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

Важно понимать, что речь идёт о ролях, за которыми могут стоять целые команды сотрудников разного профиля. После реализации система предъявляется заказчику, в ходе диалога выявляются недостатки и потребность в дополнительном функционале. Цикл «уточнение — доработка — демонстрация» повторяется до достижения компромисса, устраивающего заказчика. Формально это фиксируется в договоре и пунктах технического задания, хотя начальное ТЗ редко полностью совпадает с итоговой промышленной версией.

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

Системный аналитик и бизнес-аналитик не являются системными инженерами, но им крайне необходимы навыки системного мышления — понимание зоны ответственности и методов работы системного инженера.

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

Слово «система» происходит от греческого σύστημα, означающего «целое, составленное из частей». Мы встречаем этот термин повсюду: нервная система, система железных дорог и т.д. В общем смысле система — это целое, возникающее в результате взаимодействия элементов, сгруппированных определённым образом и имеющих цель функционирования.

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

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

Классификации систем

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

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

Открытость системы означает наличие внешнего интерфейса, связывающего её с элементом внешней среды. Этот элемент может быть частью другой системы. Среда, в которой работает система, становится операционной средой. Для успешного выполнения операций необходимы связи с внешними элементами через эти интерфейсы. Внешние элементы, в свою очередь, взаимодействуют с другими внешними сущностями, но для нашей системы это уже системы второго уровня, которые мы можем не учитывать.

Система как продукт

На ИТ-рынке (в широком смысле, включая кассовые терминалы и любые устройства со встроенным ПО) система часто выступает как продукт. Программная система может существовать в двух основных формах.

Функционирующий продукт (autonomous product)

Функционирующий продукт (или «коробочный», out-of-the-box) — это полностью самостоятельная программная система, готовая к использованию сразу после установки. Примеры: операционная система Windows, офисные пакеты, Adobe Acrobat Reader. Покупатель не взаимодействует с разработчиком для уточнения технических требований — он просто скачивает и пользуется готовым решением.

Обеспечивающий продукт (enabling product)

Если систему необходимо адаптировать под конкретного заказчика, она становится обеспечивающим продуктом (enabling product). Тогда возникает целый набор процессов: изменение программного кода, тестирование, развёртывание на серверах (продакшн-серверы, production servers), внедрение на промышленный контур, обучение персонала, сопровождение. Без обеспечения всех этих процессов невозможно продать продукт и извлечь прибыль.

Пример с самолётом

Самолёт — типовое изделие, например Boeing определённой модели. Но конкретная авиакомпания заказывает его со специфическими модификациями: разное количество мест, соотношение бизнес- и эконом-класса, расстояние между сиденьями (лоукостеры уменьшают его для размещения большего числа рядов), материал обивки, состав бортового оборудования. Формально продаётся типовая модель, но для совершения сделки требуется реализовать огромную цепочку кастомизации. Это и есть пример обеспечивающего продукта.

Логическое и физическое описание системы

Описание системы разделяется на два уровня.

Логическое описание отвечает на вопрос «что?». Система разбивается на элементы, цели — на подфункции. Задача — скомпоновать элементы и правила их взаимодействия так, чтобы совокупность функций приводила к достижению цели. Например, «передать сигнал» — задача логического проектирования.

Физическое описание отвечает на вопрос «как?» и описывает конкретную реализацию: система, подсистема, агрегаты, компоненты. Описание конкретного оборудования, передающего сигнал, — это уже физический уровень.

Система систем (System of Systems, SoS)

Сложные продукты могут представлять собой «систему систем» (System of Systems, SoS). Это иерархия, где каждый узел — самостоятельная система со своей целью. Как и в обычной системе, SoS разбивается на дерево систем.

Каждая из них оптимизирована под свои собственные цели, поэтому глобальная схема SoS в целом может быть не оптимизирована. Возникает дублирование: разные системы частично решают одни и те же задачи, расходясь лишь на определённых этапах логического исполнения. Теоретически хотелось бы объединить дублирующие функции, но этому могут препятствовать территориальная разнесённость элементов (например, оборудование в разных частях самолёта) или другие ограничения. Так появляется множество задач, требующих оптимизации и компромиссных решений.

Краткие итоги

Понимание структуры системной инженерии критически важно для бизнес-аналитика, чья работа лежит на стыке бизнес-целей и технической реализации. Ключевой разделяющей гранью выступает ролевая модель «заказчик — системный инженер — разработчик». Через неё становится ясным, каким образом неструктурированные потребности бизнеса проходят путь до детализированного технического задания и воплощаются в коде. На практике аналитик регулярно участвует в итерационном цикле уточнений, не позволяя проекту бесконечно дрейфовать и помогая сторонам зафиксировать компромиссный, но измеримый результат.

Центральное понятие — система как целенаправленный набор взаимодействующих элементов — служит единицей анализа на всех уровнях: от отдельного программного модуля до комплексного социотехнического продукта. Принципиально, что цель системы всегда задаётся бизнесом и стейкхолдерами, а не выводится из технических возможностей. Отсюда возникает необходимость в системных KPI, которые позволяют объективно судить о достижении цели. Классификационный фильтр (открытые, искусственные, конкретные, прецедентные системы) помогает аналитику определить, попадает ли рассматриваемый объект в поле применимости инженерных методов, и корректно подобрать инструментарий.

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

Разделение описания системы на логический («что») и физический («как») уровни выступает защитой от преждевременной фиксации реализации. На стадии сбора требований аналитик концентрируется на функциональности, не привязывая её к конкретным техническим артефактам. Это снижает риск переделок, когда под давлением подрядчика заказчик необдуманно согласует архитектурные решения.

Наконец, концепция «системы систем» высвечивает природу интеграционных проблем в крупных организациях. Каждое подразделение могло создавать свою систему, оптимальную локально, но при попытке заставить их работать вместе возникает дублирование, конфликты целей и неоправданная сложность. Аналитик, видящий эту слоистую архитектуру, способен выявлять зоны избыточности, ставить вопрос о консолидации или, напротив, обоснованно сохранять независимость систем из-за физических либо операционных ограничений. Таким образом, системное мышление даёт не только понятийный каркас, но и инструмент для повышения совокупной эффективности бизнеса.