Разделение труда между создателями. Наша система. Граф создания. ​

Особенность системного рассмотрения в том, что объекты всех системных уровней существуют и взаимодействуют в момент работы нашей (кто ---«мы» в этом «нашей»? Это оказывается важно! Разные «мы» ---разные ответы!) целевой системы. У нас в примере социальных танцев из предыдущих разделов целевая система неявно была задана как выполнение конкретной работы по методу создания перформанса сальсы, который выполняет пара артистов::роли, задействуя свою подроль сальсеро и танцевальные подроли лидера и фолловера. Артисты реализуются парой людей-агентов (один агент в роли лидера/ведущего, другой в роли фолловера/ведомого/следующего) в одном из клубов в Москве.

Но это не факт, что автор курса прописывал именно «пару артистов» как целевую систему в каком-то проекте! И вряд ли автор писал этот текст как амбассадор субкультуры, называя целевой системой сообщество сальсы (чаще говорят «сообщество танцоров сальсы», хотя мы помним, что там кроме сальсерос довольно много и других ролей --- орги мероприятий, диджеи, фотографы) как часть сообщества социальных танцев!

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

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

Производитель кирпичей (завод! Но мы назвали его просто по роли) берёт глину, изготавливает кирпичи. Каменщик (человек! Но мы назвали его просто по роли) изготавливает из кирпичей стену. Прораб (человек в роли менеджера, тут помянута должность) из стен изготавливает здание, координируя («назначения работ»::метод менеджером::роль, при этом помним, что в бытовой речи типы мета-мета-модели не произносим) подчиняющихся ему в силу должности каменщиков. Застройщик (компания) из зданий, строительство/изготовление которых координируется прорабами, создаёт целый квартал. Строительный девелопер (компания) из кварталов создаёт какую-то зону застройки, городской архитектор (подразделение мэрии как учреждения) из этих зон застройки создаёт город (или с нуля, или модернизацией уже имеющегося).

Это всё было описанием проектов, происходящих с системами разных системных уровней. Разные агенты (люди, AI и их организованные коллективы), помянутые в предыдущем абзаце, работают с городом в разных ролях на разных системных уровнях: кто с городом как целым, кто со зданиями города, кто с глиной кирпичей города. Хотя фраза «глина кирпичей города» уже «не звучит», по системным уровням кирпичи и тем более глина кирпичей уже далеко от города. Обычно осмыслены фразы, где связываются системы смежных системных уровней, а не далёкие друг от друга по иерархии отношений композиции системы. «Глина кирпичей» (тут отношение композиции/«часть-целое»!) или «здания квартала» (тут тоже отношение композиции/«часть-целое»!) тут много осмысленней, это как раз системы смежных системных уровней.

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

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

Роберт Хайнлайн писал: «Любой человек должен уметь менять пеленки, планировать вторжения, резать свиней, конструировать здания, управлять кораблями, писать сонеты, вести бухгалтерию, возводить стены, вправлять кости, облегчать смерть, исполнять приказы, отдавать приказы, сотрудничать, действовать самостоятельно, решать уравнения, анализировать новые проблемы, вносить навоз, программировать компьютеры, вкусно готовить, хорошо сражаться, достойно умирать. Специализация --- удел насекомых»^[1].

Этот афоризм можно понимать как гимн человеческому интеллекту: потенциально да, любой человек может освоить все эти методы, даже «вносить навоз» (в том числе в промышленных масштабах^[2], а не в масштабах любительского огородничества^[3]). Но увы, за время человеческой жизни нельзя научиться работать по всем этим методам профессионально, а также нельзя успевать отслеживать все изменения в непрерывно улучшающихся методах работы, чтобы удерживать своё мастерство современным. Решение тут --- разделение труда, обычный путь цивилизации. Один «неразбиваемый на частные методы» метод/дело/практика/деятельность/занятие, который выполнялся одним человеком в прошлом, сегодня начинает выполняться хорошо если дюжиной разных ролей (часто больше), в которых специализируются разные агенты (люди и AI, и даже целые организации), да ещё и включая в свой состав разные всё более специализированные для выполнения этих стремительно расходящихся ролей инструменты. В этих более и более узких методах/«видах труда/деятельности/инженерии» индивидуальные и коллективные агенты достигают высоких уровней мастерства, ибо они имеют достаточно времени на достижение этого мастерства, они фокусируются на выполнении одного узкого метода работы, у них есть время для:

• Развития --- смены мастерства в одном поколении метода на мастерство нового поколения метода, скажем, переход от метода «программирование на языке Fortran» в 80х годах 20 века к методу «программирование на Matlab» в начале века, а затем к методу «программирование на Julia» в 20х годах 21 века. Развитие --- это «научиться что-то делать новое», подразумевает два метода: старый (возможно, отсутствующий, если «никогда этим раньше не занимался») и новый.
• Совершенствования --- достижение высокого уровня мастерства, беглости в выполнении работ по какому-то методу текущего поколения, «набитие руки». Например, после перехода с одного языка программирования на другой как «развития», то есть изменения метода работы (и знаний/дисциплины, и инструментария), надо всё-таки потратить время на совершенствование/«беглость и безошибочность» в использовании этого языка, «тренировку» уже имеющегося мастерства, уменьшение процента ошибок и увеличение скорости того, что уже умеешь делать. Совершенствование --- это про один метод, который надо не просто освоить, но добиться в нём высокой степени мастерства.

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

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

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

Так, сверхсложный город можно обсуждать как состоящий из кварталов/зон застройки, кварталы как состоящие из зданий, здания как состоящие из стен, и никакого винегрета типа «кварталов из стен». С городом просто понимать идею системных уровней, с танцевальной вечеринкой --- сложней, с предприятием --- ещё сложней. Но разобраться с предприятием::создатель::система и выпускаемыми им системами::«целевая система» всё-таки можно, мышление о предприятии будет тем же самым: разные системные уровни выпускаемых предприятием систем и систем-создателей подсистем систем на этих уровнях (а внешние роли для предприятия ещё и занимаются созданием надсистем). Главное, что разобраться с тем, чем заняты самые разные агенты в предприятиях как коллективных агентах, можно: просто помним о разделении труда, поэтому выстраиваем размышление от целевой системы (обязательно в окружении!) в момент её работы к целевой системе из конструктов, затем методов создания целой системы из конструктов, затем роли для этих методов и дальше --- агенты с нужной степенью мастерства, а далее агенты, организующие агентов-сотрудников. Мы наблюдаем агентов при бытовом внимании к предприятию, а системное мышление говорит, какая должна быть траектория внимания по объектам, связанным с предприятием, если пользоваться системным моделированием. Поскольку объектов оказывается много, то предлагается документировать результаты системного моделирования, не ограничиваться «мышлением в уме», «мышлением проговариванием», и даже «мышлением письмом», но проводить «системное мышление моделированием».

В этом прелесть системного мышления: один раз понял, а затем используешь это мышление для всех самых разных систем, которые тебе встречаются. Окружающим агентам эти системы кажутся абсолютно разными, но системный мыслитель находит все эти системы довольно похожими друг на друга, мышление системного мыслителя про эти системы --- беглое, он разбирается только с прикладными нюансами проектной ситуации, а в общих чертах любая проектная ситуация для него выглядит одинаковой, он уже знает про там происходящее в объёме знаний мета-мета-модели, «в общих чертах». Это экономит очень, очень много времени! У системного мыслителя всегда есть чеклист: на что обратить внимание в незнакомой ситуации. Поэтому по-настоящему незнакомых ситуаций не случается, растерянности перед хаосом окружающего мира нет.

Совершенно неважно, какая система, если речь идёт о системном мышлении. Мышление будет устроено одинаково, внимание будет удерживаться системными уровнями, хотя содержание мышления будет абсолютно разным для разных видов систем, разных системных уровней. Типы мета-мета-модели одни и те же (мышление ведётся в типах! Мета-мета-модель --- это типы из нашего курса, типы понятий фундаментальных дисциплин/объяснений методов интеллект-стека), а вот типы мета-модели (предметной области, метаУ-модель из общего учебника какой-то дисциплины, метаС-модель ситуационная, как сложилась в какой-то организации и отражено, например, в регламентах и корпоративных стандартах) будут существенно отличаться.

Пример космической ракеты легче понимать, чем танцевальный пример, ибо ракета не живая, и не учится, хотя AI в современной ракете уже не факт, что не учится примерно так же, как люди-агенты в танцевальном примере. Но мышление о космическом корабле устроено так же, как мышление про танцоров: если корпус корабля изготовлен из неправильного для успеха системы материала (например, из алюминия), то нужно опускаться на уровень рассмотрения материала, и решать проблему (например, брать сталь^[4], как это сделал SpaceX с ракетой Starship). Иначе из-за проблем с материалом нарушится работа всех остальных более высоких системных уровней ракеты, она не сможет летать, или будет летать не очень надёжно.

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

Ракета получает свою функцию летать с какими-то характеристиками с более высокого системного уровня. Например, можно рассмотреть космическую компанию вроде SpaceX, ставящую задачи для связки ракеты и космического корабля, или заказчика полётов корабля у такой компании, например, телекоммуникационную компанию, которая желает запустить спутник. Но вот для того, чтобы выполнить такое задание, нужно решить много-много проблем на низлежащих системных уровнях (их довольно много: скажем, из какого материала делать сопла двигателей? А чем охлаждать эти сопла? А как должны быть устроены насосы?), согласовать между собой взаимодействие всех частей ракеты, и частей этих частей, и так до уровня исходных материалов (из каких материалов делать насосы ракеты? А трубопроводы?). Чтобы сообразить, что много-много решаемых текущих проблем --- это совсем не те решаемые проблемы, которые нужно решать (они неважные, их решение ничего не даст!), нужно подниматься на много-много уровней вверх --- и затем спускаться опять вниз по системным уровням, чтобы выйти на действительно важные решения. Помним также, что конструкция системы должна отражать многоуровневую, а не одноуровневую оптимизацию. Глупо делать корпус ракеты из стали и иметь поэтому запас прочности корпуса при высоких температурах, а затем не использовать этот запас прочности! Все оптимизации конфигурации системы --- многоуровневые.

Полезное упражнение тут --- это представить авиалайнер как 6 млн индивидуальных деталей, летящих с одинаковой скоростью 890км/час в одном направлении на высоте 10 км. Это шутка, но это и чистая правда! Если не вводить тут рассмотрение на разных системных уровнях, оставаться редукционистом, то остаётся думать про самолёт именно так: 6 млн деталей, которые были собраны вместе и теперь согласованно летят на десятикилометровой высоте. Вспомните картику аккуратно выложенных рядом деталей разобранного автомобиля, работу автомобиля невозможно обсуждать, обсуждая его детали и их взаимодействие! Невозможно организовать производство автомобиля или самолёта, если рассматривать одноуровневое разбиение «автомобиль --- все его детали списком». Невозможно организовать предприятие, если его рассматривать, например, как «предприятие --- все его люди списком».

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

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

Окружение, включая надсистему, а также целевая система и её подсистемы, входят в одно системное разбиение, уровни которого определяются на момент, когда целевая система существует, готова и работает, внося свой вклад в появление нужных системных свойств у надсистемы. Никакая система не нужна сама по себе, она нужна только для того, чтобы стать частью надсистемы! Поэтому системное мышление начинается всегда с того, что целевая система определяется как «чёрный ящик» (непонятно, как устроенный объект), выполняющий какую-то свою работу в надсистеме: рассмотрение от границы целевой системы начинается вверх по уровням, а не вниз/внутрь целевой системы, в состав её частей. Рассмотрение частей системы, знание о подсистемах --- это рассмотрение «прозрачногоящика», у которого известен состав частей и как они взаимодействуют. Рассмотрение устройства/состава целевой системы, то есть проход от границы системы вниз по системным уровням --- это всегда второй шаг. Первый шаг --- «чёрный ящик» в системном окружении, второй шаг --- «прозрачный ящик». И так с системами каждого системного уровня --- на много уровней вверх и вниз.

Создатели::система имеют дело/взаимодействуют с целевой системой по мере того, как она постепенно («разово» --- это так мыслили раньше, сейчас системы эволюционируют, а не «рождаются, живут, умирают») замышляется, проектируется, изготавливается, ликвидируется. Если речь идёт о времени создания и развития системы, то системы, изменяющие описания и материалы целевой системы, чтобы получить из них готовую работающую систему, называются создателями/«системами создания»^[5] (enabling systems по ISO 15288:2023, constructors в физике). Эти системы постепенно (в ходе «непрерывного всего» --- непрерывной разработки, непрерывного изготовления, непрерывного введения в эксплуатацию) создают и развивают целевую систему. Создатели проводят инкременты (части системы, содержащие новый функционал/фичи/features/возможности) целевой системы через разные состояния (инкремент «замыслен», «спроектирован», «в виде закупленного сырья», «изготовлен», «проверен», «принят в эксплуатацию») к готовности эксплуатации/использования, а потом выводят из эксплуатации/использования, в том числе и ликвидируют (это может быть непросто! Например, оставляют «зелёную площадку» после полной ликвидации атомной электростанции), или вместо ликвидации ремонтируют, или иногда модифицируют и возвращают в использование. Подробней это рассказывается в курсах «Методология» и «Системная инженерия».

Создатели не входят в окружение целевой системы (не являются частями каких-то надсистем целевой системы) и тем самым не входят в одно системное разбиение с целевой системой, но входят в самые разные иные системные разбиения. Почему так? Сама целевая система не живёт, себя не кормит, не выращивает --- для этого и требуются системы создания, сами работающие во время создания и развития системы. А окружение? Это все системы, которые окружают целевую в какой-то её конфигурации (помним, что система развивается/эволюционирует, поэтому конфигурация как состав системы меняется --- посмотрите ваш телефон, он расскажет, какая его версия и какая версия операционной системы, какая версия его приложений) во время её работы/эксплуатации, когда она уже создана, работает, ещё окончательно не ликвидирована. Конечно, живые системы являются и создателями/родителями целевых (бабочка-1 родитель/создатель другой бабочки-2), но там есть особенности --- геном (наследственный материал) находится в биологической системе и в создателе, и в целевой системе в ядре каждой клетки, а в техноэволюции мемом находится только в создателе (информационная модель системы), а то и распределён по многим создателям, а целевая система его не имеет.

В стандартах классической системной инженерии предпочитают о подобных системах говорить enabling system (например, в серии стандартов, основанных на ISO 15288:2023), но вот David Deutsch и Chiara Marletto предложили говорить о таких системах constructor^[6] (одно из словарных значений как раз «создатель»): основное тут то, что подобного сорта система поддерживает свою идентичность в ходе каких-то однородных изменений, производимых создателем в окружающей среде. Например, молекула катализатора производит множество актов катализа, оставаясь неизменной (enable chemical reaction, слово «enable» в английском языке тут хорошо подходит, поэтому enabling system в английском языке не вызывает вопросов). Или станок производит множество деталей. Или преподаватель обучает/«изготавливает» множество студентов. Или фирма рубит в лесу множество деревьев и изготавливает из них множество досок. Или кошка рожает множество котят, а самореплицирующийся робот производит/изготавливает множество себе подобных «роботят» (эти эксперименты уже идут^[7]).

У создателей, как и у любых других систем, есть свои надсистемы и свои подсистемы. Раньше системы создания называли системами ведения жизненного цикла (lifecycle enabling system). Иногда «lifecycle enabling system» переводят и как «системы обеспечения жизненного цикла», но слово «обеспечение» как перевод enabling часто путают с обеспечением/снабжением или с неглавными/вспомогательными «системами обеспечения», поэтому в текущей редакции курса мы не используем слово «обеспечение» для жизненного цикла, а также стараемся избавиться и от термина «жизненный цикл», который был одни из основных терминов прошлого поколения системного подхода: слишком много от этого ошибок.

Ещё раньше системы создания называли просто системами жизненного цикла, иногда даже сразу предприятиями (enterprise), ибо проектами создания чаще всего занимаются предприятия. Сейчас создатели упоминаются как системы, участвующие в проектах создания и развития систем в отличие от проектов, занимающихся эксплуатацией систем. «Создание» --- это по факту однократное (хотя там внутри может быть множество попыток с разными прототипами, просто эти прототипы не попадают в целевое окружение, они ещё могут не иметь минимальной нужной функциональности) выполнение работ по выпуску системы как MVP^[8] (минимальный жизнеспособный продукт, minimal viable product), а «развитие» --- это отсылка к длительному/многократному практикованию метода изменения конфигурации системы с целью улучшения её приспособленности/fit к «эволюционной нише», то есть использованию в каких-то надсистемах. Поэтому «создание» --- это чаще всего выпуск MVP, а «развитие» --- это выпуск множества версий системы после того, как она создана, то есть выпущена версия MVP.

Создатель --- это не только развитый интеллектуально агент (человек, робот) или даже коллективный агент (предприятие). Формально это может быть и просто какой-то станок, который вытачивает целевую деталь --- эта деталь потом станет подсистемой работающей целевой системы. Станок не участвует в эксплуатации целевой системы, он не входит в её эксплуатационное/операционное окружение, не рассматривается вообще во время эксплуатации. И даже метод работы станка для получения ожидаемых (а не абы каких) результатов работы обычно так не называется, чаще говорят «функция». Зато он участвует в создании системы --- так что этот станок будет создателем/constructor/enabling system/системой создания. И, конечно, станок будет входить в какое-то предприятие, но предприятие будет для этого станка далёкой над-над-над-надсистемой, через много системных уровней (например, системные уровни станок-сектор-отдел-служба-предприятие). А если рассмотреть станок-2, принимающий участие в создании станка-1, который принимает участие в создании целевой системы, то эта цепочка будет называться цепочкой создания, в которой основное отношение --- создания/enabling, а не часть-целое/композиции. В цепочках создания могут быть и люди, и предприятия, и AI. И из этих цепочек создаются сложные графы создания. Например,

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

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

Важно, что целевая система определяется для множества ролей, для большого коллектива. Об этом подробней будет говориться в следующих разделах. А как называется какая-то система, которая прямо сейчас находится в центре нашего внимания, но не целевая? Если мы эту нашу систему/system-in-hand назовём целевой, то нас никто не поймёт, будут считать (справедливо), что мы тянем одеяло на себя. Например, нам (в том числе вариант «мне и мне», или даже «нас тут пять ролей в команде из троих человек») поручили разработать винтик для большого и сложного станка. Да, целевой системой для всей команды является отгружаемый клиенту станок, который войдёт в остальное оборудование завода клиента как системное окружение, но мы-то в центре внимания вот прямо сейчас в разговоре держим этот винтик --- и до системного уровня окружения станка на заводе клиента нам как до Луны, слишком высоко! Что, нам считать станок над-над-надсистемой для этого винтика::система? Да, конечно. Считать винтик целевой системой? Нет, конечно. Целевая система уже есть, станок, это на каком-то среднем масштабе времени, жизненного цикла всего проекта станка, требующего кооперации и договаривания многих людей. Целевая система для этого и была введена как тип: это исходная точка для договаривания многих ролей, часто многих ролей, исполняемых командами агентов.

Для таких ситуаций рассмотрения отдельными агентами из больших систем создания, состоящих из множества цепочек создания и появляется вид системы, который называется термином наша система (engineered system в классической системной инженерии, managed system в системном менеджменте, MySystem, OurSystem, система в руках/system in hand). «Наша система» обозначает систему в частном/преходящем/вре́менном фокусе внимания в системном разбиении целевой системы или длинной цепочке создания. Скажем, «целевая система --- самолёт, наша система --- пятый винтик в топливном насосе двигателя целевого самолёта», или «целевая система --- самолёт, наша система --- уникальный станок::создатель для нарезки «высокочастотного кабеля авионики»::подсистема этого самолёта», или «целевая система --- процветающее трудолюбивое общество Остазии, но нашей системой сегодня является общество Евразии и Океании, которое мы всячески ослабляем и дестабилизируем».

Метафорически, если «целевая система» в большом коллективном проекте --- это «начало координат»/«Северный Полюс», то «наша система» (engineered system) --- это конкретный какой-то географический пункт для нашей команды, чьи координаты определяются по отношению к этому началу координат. И мы:: «команда проекта нашей системы» должны чётко определить положение этого пункта по отношению к началу координат, определяя граф создания, иначе будет трудно договариваться с другими командами в проекте: мы для них будем не «сотрудниками, работающими на общую цель, успешность целевой системы», а «заботящимися о собственном благе, пришедшими откуда-то зачем-то», с чем бы ни пришли. Дальше об этом поговорим подробней, но пока несколько примеров (и небольшие нюансы могут приводить к большим изменениям в этих примерах! Помним, что при рассмотрении вымышленных учебных примеров не мышление прикручивается к ситуации, а ситуацию крутят так, чтобы она подошла к произвольно взятому мышлению, так что аккуратней с обсуждением примеров --- лучше берите реальные ситуации, которые не дадут вам изменять ситуацию вместо изменения мышления о ситуации):

• В парикмахерской целевой системой является причёска (платят деньги за причёски!), сама парикмахерская --- система создания для причёски, наша система --- это точильный станочек для заточки ножниц, который мы устанавливаем в углу парикмахерской. И горе нам, если заточенные на нашем станке ножницы плохо постригут клиента, и причёска будет из-за этого некачественной! Мы выявляем сценарии рационального использования станка, выбираем из разных вариантов видов станков, имеющихся на рынке, закупаем, настраиваем и т.д. --- занимаемся «нашей системой». Кто это «мы»? В данном случае «я, работающий на должности завхоза парикмахерской, мне поручили этот проект».
• У нас школа (частная!), мы усиливаем интеллект, тем самым занимаясь производством мастерства мышления в незнакомых ситуациях. Мы по факту изменяем свойства мозга наших выпускников так, чтобы в проблемных ситуациях включалось не бытовое мышление, а наше мастерство мышления по лучшим методам интеллект-стека. Моя система --- это та часть интеллекта, которая ответственная за системное мышление. Я как преподаватель системного мышления делаю этот кусочек мозга, который должен сработать в окружении кусочков мозга, вместе которые реализуют мастерство по всему набору методов мышления интеллект-стека. А если я буду в роли разработчика полной учебной программы, то у меня «наша система» --- это весь усиленный интеллект, включая системное мышление, но не ограничиваясь им. «Наша система» в этом случае будет совпадать с «целевой».
• Наш небольшой отдел IT-компании занят производством софта поддержания общей среды данных. Этот софт используется в проектных организациях, занятых проектированием объектов капитального строительства (мостов, эстакад, электростанций и т.д.). Конечно, сам софт как таковой никому не нужен, мы по факту сдаём работающий софт с людьми. Поэтому «нашей системой» («мы» для этого «наше» --- это наш небольшой отдел IT-компании) в этом проекте будет «служба управления инженерными данными проектной организации»::оргзвено, а целевой системой будет объект капитального строительства (например, мост). Нам придётся показать, как служба управления инженерными данными, которую мы помогаем сделать проектной организации, поможет мосту стать лучше, дешевле, быть построенным быстрее. А для этого мы показываем, как подсистема нашей системы (софт, который производит наш отдел) выполняет уникальные функции в службе управления инженерными данными, которая выполняет уникальные функции в проектной организации, которая проектирует стройку моста и проектирует сам мост. И показываем, как наша работа связана с мостом, демонстрируем для этого документированный граф создания. Тут важно, что наша система --- это служба, а софт --- лишь подсистема этой службы (обычно беда, если наша система --- это софт, ибо проектом службы тогда непонятно кто занимается, а софт не будет принят, ибо принимать будут работу службы, в жизни изменения от работы службы, нет изменений от работы софта, если им некому пользоваться).
• ... таких примеров множество. Речь может идти или о подсистеме целевой системы, или о какой-то системе в графе создания (иногда довольно далеко по путям в этом графе), или о подсистеме в какой-то системе в графе создания. Нюансы тут важны, и помним, что «объективного» выбора нашей системы тут нет, и нет «пошагового алгоритма выбора»/«волшебного рецепта». Просто нужно учитывать, что во внимании удерживаем целевую систему, её надсистему, её подсистемы, а также системы в графе создания. И ещё понимаем, где там наша система, за которую ответственны «мы» как «маленькая команда в большом проекте» (иногда это команда из одного человека, вас лично). И у нашей системы есть своя надсистема, свои подсистемы, свои системы создания: по отношению к ней мы тоже управляем вниманием в проекте её создания и развития.