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

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

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

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

1. Переход от редукционистского к системному подходу.
Целое невозможно свести к сумме частей этого целого -- вот суть системного подхода. Само выделение целого как "фигуры из фона" не может быть произвольным, то же относится к элементам системы: важна цель системы, важно взаимодействие элементов для достижения этой цели, а не просто наличие произвольно выбранных частей. Любая система имеет надсистему и подсистемы, системы иерархичны. Границы системы с окружающими ее системами важны и требуют явного определения: все участники междисциплинарного обсуждения должны говорить об одной и той же системе в одних и тех же границах, чтобы не подменять системы в ходе их обсуждения.

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

Само выделение системы из окружащего мира происходит в форме описаний. Важным тут является вопрос, являются ли эти описания частью системы, а также как связаны между собой системы, выполненные по одним и тем же описаниям разного уровня абстракции (без этого трудно обсуждать systems family engineering, технологические платформы).

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

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

Например, в организационных системах сейчас повсеместно переходят от органиграммы как основного средства представления организации к процессным диаграммам, управление проектами -- это отражение того же тренда: сетевой график проекта много лучше отражает положение дел, нежели штатное расписание.

Сюда же обычно относят концепцию полного жизненного цикла, все варианты проектного подхода и связанные с ним методы управления жизненным циклом.

Изредка этот переход относят не к отдельному, а говорят о "втором поколении системного подхода", ибо само задание процессов требует выделения системы, в которой эти процессы идут.

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

Сюда же можно отнести необходимость перехода (как минимум, в информационном моделировании систем) к представлениям 4D-онтологии, в которых у объектов есть темпоральные части, и поэтому легче обсуждать изменения объектов во времени, чем в "бытовой" 3D-онтологии. Но дискуссия о необходимости такого перехода еще не закончилась.

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

3. Переход от одной группы описаний ко множественности групп описаний.
Никакой одной профессиональной точки зрения недостаточно, чтобы получить более или менее полное реализационное описание системы. Для системы должны быть получены различные группы взаимосвязанных описаний, часто получаемые междисциплинарно. В культурологии это "постмодерн", в СМД-методологии это "схема многих знаний", в системной инженерии ISO 42010, стандарт архитектурных описаний.

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

5. Переход от непосредственной реализации к моделецентричной реализации.
Вместо того, чтобы строить реальную систему, для начала создаются всевозможные модели системы -- как абстрактные архитектурные, так и имитационные, зависящие от реализации. Эти модели представляют более-менее адекватное реальности подробное описание системы, к которому возможно задавать вопросы "а что если" (т.е. речь идет прежде всего об имитационном моделировании, включая имитационные прогоны архитектурных моделей). Сначала система "строится" в идеальном мире моделирования, и только затем в реальном мире: все ошибки убираются на этапе моделирования, а не на этапе реального воплощения в мире.

Сюда же относится идея о том, что описания системы (включая архитектурные описания) должны быть представлены не на естественном языке, а на формальном языке, подразумевающем возможность какого-то отчужденного от чтения человеком "машинного исполнения".

6. Переход от документоцентризма к датацентризму.
Различные описания системы не должны готовиться в форме отдельных документов. Все эти описания должны храниться в виде взаимосвязанных отдельных информационных единиц-данных, готовых для объединения в той или иной форме -- речь идет о хранении информации в виде базы данных и доступе к этой информации с разнообразными запросами. Более того, работа с изменениями должна вестись в терминах отдельных данных, а не "документов". Думать об информации таким образом очень трудно, ибо базы данных (тем более -- распределенные базы данных) появились в истории человечества совсем недавно, а вся материальная культура и язык поддерживает работу с "документами-на-листах-бумаги".

7. Переход от работы "для одного хозяина" к работе со множеством заинтересованных сторон.
Для любой системы всегда есть множество заинтересованных сторон, мнение которых нужно учитывать. Это означает, что требования к системе всегда противоречивы, исходят из самых разных источников, и нужна специальная работа по их согласованию -- значительная часть этой работы сводится не к техническим решениям, а к проведению переговоров между заинтересованными лицами. Наличие множества заинтересованных в системе сторон существенно меняет содержание инженерной деятельности: эта деятельность по "инженерии требований" уже не проходит в мире исключительно технических решений, а должна учитывать противоречивые интересы самых разных людей.

8. Переход от "проверки" к раздельным верификации и валидации.
Идея верификации (проверка на соответствие формальным требованиям) всем привычна. Много более трудно воспринимается идея, что такой проверки явно недостаточно: важно не столько соответствие требованиям, сколько то, чтобы системой можно было пользоваться -- ибо при разработке системы ошибка могла закрасться в сами требования!

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

10. Переход от "технологического конвейера" к "заказам-поставкам".
Процесс управления жизненным циклом нельзя считать "конвейером", просто выполнением серии технологически предписанных работ (в теории управления организационными процессами это называют "оркестровка"). В жизни независимые акторы участвуют в процессе, выполняя контракт на оказание услуги по своей части участия в общем процессе (в теории управления организационными процессами это называют "хореография"). В системной ижненерии этот вопрос обсуждается как отдельная группа контрактных практик, причем самым трудным тут является понимание того факта, что контракты могут быть не только явные между различными юридическими лицами, но и неявные внутри акторов в рамках одной организации.

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

Понятно, что "проектирование сотрудника" или "проектирование организации" по методам существенно отличается от проектирования софта, а проектирование софта существенно отличается о проектирования оборудования. Но, например, переход от идеи рабочего проектирования к идее обязательной архитектурной (т.е. без реализационных деталей, сущностной "онтологической") проработки конструкции применим ко всем типам, хотя архитектуры оборудования, софта и организации выразимы в абсолютно разных типах описаний, взаимно непонятных для работающих над созданием оборудования, софта и организации специалистов.

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

Конечно, этот список можно критиковать. Например, можно обсуждать включение в него в явном виде работы с рисками. Или обязательность управления решениями. Можно выписать все практики системной инженерии, и потребовать научить этим практикам -- прямо по списку из какого-нибудь учебника или какого-нибудь стандарта. Легко заметить, что в предлагаемом мной списке довольно много того, что в явном виде не попадает ни в какие практики, а обычно пишется в "предисловиях", "введениях", "общих замечаниях" и дале считается само собой разумеющимся. Я при составлении этого списка ориентировался как раз на то, что все эти переходы от одних "бытовых" мыслительных парадигм к другим ("профессиональным") не являются само собой разумеющимися, такому мышлению нужно учить специально. И попробовал отобрать те подходы, которые являются ядром системной инженерии, отличающие ее от любых других способов продвижения рукотворных систем по их жизненным циклам -- от замысла до вывода из эксплуатации.