Это всё политика, это не системный менеджмент, не проектное управление, не системная инженерия технической системы, не медицина или образование.
Строить государство и организовывать госпроекты вы будете не из своего бездушного материала, а всегда из чужого с собственными их мозгами: из других людей. Люди — это не железо, и не компьютеры. Не считайте, что именно вы из них что-то построите успешное/удачное/хорошее для вас или этих других людей. Не считайте, что вы как системный мыслитель (системный менеджер, или инженер, или даже просто программист, или сапожник, или деятель культуры) квалифицированы что-то строить из людей, реализуя какие-то идеи госстроительства. Эти люди как самопринадлежные системы, из которых вы будете пытаться строить системы систем, они не ваши материалы для строительства, и они не материалы ваших заказчиков-чиновников, заказчиков-политиков. Они самопринадлежны, они все свои собственные. И они так же точно могут хотеть что-то построить из вас — в том числе и то, что вам не понравится. Золотое правило работает и тут: не делайте с людьми того, чего не хотели бы, чтобы люди делали с вами.
Люди, занимающиеся работой с государством, должны помнить, что им придётся играть роли, которые будут уменьшать свободы граждан — государство не даёт свободы, оно их главным образом ограничивает. Это этический выбор людей, помогающих государству.
Краткий тут совет — если уж нужно заняться госстроительством, то используйте знания по этике, политологии, конфликтологии, праву, экономике, социологии и системное мышление в его «мягких» (soft systems) вариантах, но не используйте системное мышление в вариантах системной инженерии киберфизических систем, системного менеджмента как инженерии предприятия, как вы привыкли его использовать для мышления о системах на уровнях инертного вещества, существа, личности, организации/фирмы. Эти проекты обычно даже не уровня небольшого сообщества, а уровня общества, когда вы лично не знаете людей, которых это затрагивает (включая тех людей, у кого на это дело отняли налоги и предложили потом спать спокойно).
Совесть задействует метод/способ/культуру рассуждений по той этике, мастерство выполнения которой известно агенту.
Человек, равно как и AI-робот в составе систем учитывается сложно, ибо он одновременно может быть
• и целевой системой («продуктом»)
• и надсистемой, где чаще удобней рассматривать даже не всего человека, а его часть — часть тела::hardware или мастерство как часть личности::software,
• и материальным «оборудованием» типа станка в составе создателя (если он делает что-то руками/манипуляторами, а всякие молотки и стамески и даже моделеры тут просто продолжение его рук или мозга/вычислителя),
• и быть конструктивом/«материальным телом» с его весом и инерцией, влажностью и твёрдостью (как, например, в учёте инерционного движения в телесных практиках или робототехнике или в примере с наручными часами),
• проектной ролью, или даже целым набором проектных ролей: мы можем не учитывать мнений и интересов животных (хотя и это плохо), но мы принципиально не можем не учитывать мнений людей-в-ролях, вынуждены считаться с решениями AI и даже просто компьютерных программ (помним про «я бы помог, но компьютер не даёт»), и ещё решения организаций как «юридических лиц».
В ISO/IEC/IEEE 21841:2019 выделено четыре типа систем систем, отличающихся степенью их автономности:
• управляемые (directed), в которых есть назначенный архитектор (агент в роли архитектора, то есть отвечающего за деление системы на конструктивы и способы организации связи между конструктивами), который может выдавать свои архитектурные решения командам проектов составляющих систем и менеджер (агент в роли менеджера), который распоряжается общими ресурсами.
• подтвержденные (acknowledged), в которых признаваемый архитектор есть, но он может только уговаривать владельцев составляющих SoS систем изменить свои системы согласно разработанной им архитектуре (то есть у архитектора нет отношения надзора/governance, только менторинг по поводу принимаемых им архитектурных решений).
• сотрудничающие (collaborative), в которых владельцы всех составляющих систем договариваются друг с другом «по каждому чиху», но нет оргзвеньев (агенты, выполняющие роли) архитектора, менеджера проекта или аналогичных выделенных оргзвеньев, занятых созданием и развитием SoS на уровне целой системы.
• виртуальные (virtual), в которых владельцы систем, составляющих SoS, вообще не знают друг о друге ничего, и тем самым команды проектов создания и развития составляющих систем не влияют друг на друга явно.
Иногда систему, которая состоит из других систем, называют «системой систем». Это неправильно, это просто система, а другие системы в ней — это подсистемы. Вроде как не нужно специально подчёркивать тот факт, что любая система состоит из систем. Тем не менее, термин система систем (system of systems, SoS) есть, он закреплён за особым случаем выделения систем по социальным характеристикам систем их создания и особенностям времени создания, а не по чисто техническим особенностям вложенности систем друг в друга в окружении и работы в ходе использования.
Тем самым разница между «просто системой» и «системой систем» определяется не через особую структуру или конструкцию системы (определяемую во время её использования), а через наличие независимых друг от друга систем создания (определяемых в момент создания), описывающих и воплощающих входящие в систему систем отдельные составляющие/constituent системы, а затем имеющие возможность независимо их использовать. Поэтому метафорически систему систем мы представим диаграммой, где показано, что система систем состоит из трёх подсистем («составляющие системы» системы систем), каждая из которых автономна и в свою очередь состоит из своих подсистем, показано два системных уровня), но главное — фигурки с портфелями указывают на агентов-собственников, которые должны договориться о том, чтобы из автономных систем получилась целая система.
Рассказ о целевой системе всегда начинается с её описания как чёрного ящика, при этом по факту приходится рассказывать не столько о самой целевой системе, сколько о надсистеме. И это не случайно: системный подход начинается с того, что система определяется по её роли в окружении (ролевой/функциональный объект среди систем окружения), по её ролевому поведению/функции (изменениям состояний систем в окружении, которые проводит описываемая система как «чёрный ящик»).
От границы целевой системы по системным уровням наверх, к окружению, к надсистеме — это первый мыслительный ход в системном мышлении, это главный императив. Никакого «деления на части», никакого «состоит из», пока не выяснили, для чего используется целое, в котором мы интересуемся частями — сначала само это целое «является частью в» и «входит в» и понимание, что там делает это целое в своём «надцелом»!
концепция использования привязана к границам целевой системы и надсистемы соответственно, они не должны быть упущены вашим вниманием, они обязательно должны присутствовать в проекте! И ещё в концепции использования должны быть помянуты архитектурные характеристики (о них позаботятся не разработчики::«внутренняя/командная роль», которые готовят концепцию использования, а архитекторы::«внутренняя командная роль»). Все эти модели::описания системы как чёрного ящика документируют. Конечно, без разработки концепции использования систему можно сделать (строители египетских пирамид их построили, но вряд ли там была разработана и документирована концепция использования), но успешной она может стать только случайно (например, не надо спрашивать, сколько лет строились пирамиды, сколько они при этом стоили, и сколько недовольных проектом погибло. В государственных проектах до сих пор крайне не любят прописывать концепции использования, это не случайно).