4. Воплощение и описание системы

Воплощение, описание и документация системы

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

Адекватность системного мышления обеспечивается тем, что когда мы говорим о системе, то имеем в виду воплощение системы (system realization — тот же корень, что real, реальный, буквально речь идёт о существовании в реальности, reality), причём обычно в момент эксплуатации, когда система работает/функционирует, взаимодействуя с окружающим миром.

Система понимается всегда как конкретное воплощение системы в физическом мире — индивидуальный, уникальный физический объект. Например, это фирма Apple (все её здания, сооружения и сотрудники фирмы в тот момент времени, когда они в ней работают), топливный насос с серийным номером #12345, установленный на авиадвигателе #5678, перформанс (работа танцоров) танца «Барыня» на сцене Усть-Урюпинского театра вечером 24 октября 2029 года (воплощение системы в будущем нас вполне устроит).

Как узнать, что конкретная воплощённая система существует в физическом мире? Мы будем считать, что в физическом мире присутствуют (в том числе в настоящем, прошлом и будущем — время тут не важно!) только те объекты, которые занимают какое-то место, объём какой-то причудливой формы в нашем пространстве-времени, принимая идею Эйнштейна про существование физического мира в четырёхмерном пространстве-времени. Есть какой-то кусок пространства-времени, который мы называем система/system и выделяем вниманием из его окружения/environment, при этом у системы есть граница/boundary, проходящая в пространстве-времени. Поскольку тут пространство-время, то неважно, где в пространстве (тут или в соседней галактике) и неважно, где во времени (например, система будет существовать пять минут, но через сто лет от «сейчас»).

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

А ещё эта система имеет изменяющиеся состояния/states. Системы меняются по мере взаимодействия с окружающими их системами, которые тоже находятся в физическом мире, а внутри них меняются взаимодействующие в них подсистемы. Например, «дверь::система открыта», «дверь::система закрыта», «дверь::система выломана» — это всё разные состояния двери. Состояния крайне важны, ибо работы по разным методам могут приводить к разным состояниям систем. Например, «открыть дверь номер четыре в 3 часа 15 минут 24 мартобря»::работа может перевести дверь номер четыре из состояния «дверь закрыта» или в состояние «дверь открыта» (например, «открыть ключом, повернуть ручку и нажать рукой»::«метод работы») , или «дверь выломана» (например, «как следует двинуть ногой в районе замка»::«метод работы»).

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

Тем самым мы чётко различаем (и это различие — предмет изучения трансдисциплины семантики):

• воплощение системы (system realization), занимающее объем в физическом пространстве-времени, как предмет физики.

• описание системы (system definition, часто называются ещё и определениями системы, не путайте со «словарными определениями»!) как идеальный/математический/ментальный/абстрактный/понятийный/концептуальный объект. Поведение описаний как идеальных объектов изучается математикой.

• документ с описанием системы, как выражение описания системы на физическом носителе. Способы выражения (паттерны на физическом носителе) изучаются семиотикой, «наукой о знаках».

В физическом мире есть какие-то ненулевого размера участки пространства, а в математике — математические точки, в семиотике — паттерны на носителе, знаки/символы. Конечно, есть и распределённые/distributed представления, которыми занимаются в методах познания представлений/representation learning (мы переводим learning в методах AI как познание). Но мы не будем заниматься тем, как устроено интуитивное быстрое мышление S1, которое и использует распределённые представления. Мы будем работать с локальными/символьными/symbolic/знаковыми представлениями, которыми занимается медленное мышление S2. В распределённых представлениях очень трудно найти ошибки, они не локализованы в буквальном смысле слова. А вот в символьных представлениях ошибки найти много легче. Поэтому инженерные задачи надёжней решаются в компактных локальных представлениях с немногими знаками, а не в распределённых представлениях (например, нейросетях — живых в мозгу людей или компьютерных в системах AI).

Поведения математических объектов и соответствующих им физических объектов всегда отличаются, поэтому физика в ходе своего развития заменяет одни математические представления другими, которые ведут себя более похоже на то, как ведут себя физические объекты. Скажем, сумма углов треугольника вблизи Земли чуть-чуть больше, чем 180° даже не из-за шарообразности земли, но из-за искривления пространства-времени массой Земли. Поэтому нельзя будет реализовать GPS навигацию, если полагаться на геометрию Эвклида в физических расчётах инженерного проекта. Поэтому физика заменила в теории относительности геометрию Эвклида на Риманову геометрию.

Традиционно соответствием описаний как идеальных/математических объектов/понятий, выраженных/presented какими-то паттернами/узорами/шаблонами/повторяемостями на одних физических объектах (документах) и представляемых/represented ими других (описываемых) физических объектов/систем занимается семантика. Впрочем, семантика может заниматься и описанием описаний (скажем, вы можете описать математический язык, на котором описываете физический объект). Но всегда эта цепочка описаний упирается в описание реальных физических объектов, иначе нельзя будет договориться о том, что все эти описания означают, без заземления/grounding с описаниями работать нельзя.

Семантику иногда считают разделом информатики/computer science наряду с алгоритмикой, подробней об этом можно узнать, например, из книги Дэвида Дойча «Начало бесконечности. Объяснения, которые меняют мир»³, где он рассматривает отношения между физикой, математикой и computer science. Больше наставлений по задействованию методов семантики в мышлении вы можете найти в руководстве по интеллект-стеку методов фундаментального мышления в программе исследовательского развития.

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

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

Сами описания как ментальные/идеальные/понятийные/математические/абстрактные объекты не имеют места в реальном мире. Нельзя сказать, что математический/ментальный объект «число 300», определяющее высоту в метрах (воплощения) системы «Эйфелева башня», находится где-то в реальном мире и имеет собственную длину-ширину-высоту. Если вы укажете на это «число 300» и скажете, что оно существует и имеет свой объём — то вы укажете не на само число, а на документ как носитель информации, который своими паттернами/узорами как формами материала (паттернами/узорами частиц краски, или прозрачности материала, или ещё как-то) кодирует это число. Тем самым место в физическом мире занимает не «300» как число, не часть описания Эйфелевой башни (число 300 описывает Эйфелеву башню), а материальный объект кусочка документации (system description в отличие от system definition) Эйфелевой башни, т.е. носитель/документ с записанной на нём информацией/описанием. Документ — это абстрактное/идеальное/математическое/понятийное описание системы, записанное на каком-то физическом носителе информации. Один или несколько документов обычно называют документацией системы.

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

В системном мышлении вам потребуется владение семантикой. Горе вам, если вы плохо понимаете этот материал и будете путать автомобиль как целевую систему и фотографию автомобиля как документ-носитель описания этого автомобиля. Фотография материальна, но материальность её важна только как возможность нести на себе описание физического объекта-автомобиля, материальность носителей информации не должна нас путать — это не материальность воплощения изображённой/описанной/документированной системы!

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

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

Абсолютно такое же действие — выключить экран с фотографией, или стереть файл с фотографией (это не так символично, как порвать бумажную фотографию, но по сути — то же самое. Абстрактные/математические/понятийные/концептуальные объекты не горят, представление их на носителях обычно легко копировать, и уничтожение документа, а хоть и электронного — это не уничтожение описываемого документом объекта, а часто это и не исчезновение документированного описания, доступного на многих копиях документа). Концепт/понятие/математический объект «число 1» по большому счёту даже не зависит от шрифта и прочих особенностей отображения, он абстрактен, может быть выражен множеством способов, множеством начертаний знаков. И помним, что концептов в физическом мире нет, они абстрактны/математичны. Информационные модели систем (когда-то в прошлом веке их называли чертежами) абстрактны/идеальны/понятийны, документированы они во множестве копий, а описывают они воплощение системы, то есть физический мир. Информационная инженерная модель космодрома, отправляющего людей на ракетах на Марс — это описание возможного/possible (ибо речь идёт о возможном будущем) физического мира.

Описания системы легко отличить от воплощений системы и документов системы — они не занимают места в физическом мире, у них нет объёма и координат в этом мире, они абстрактны/«идеальны»/нематериальны/математичны/понятийны как противоположность материальному/физическому/воплощённому. Системы и системные документы (документы о системах) материальны, они занимают место в физическом мире, но мы при этом не путаем системы и документы с описаниями систем.

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

• Документация — это внешняя память, «экзокортекс». Биологическому мозгу не верим, верим записанному на какой-то более стабильный носитель. Документация всегда в экзокортексе, а не неокортексе (коре головного мозга). Для AI-агентов документация может быть и с весами нейросети, но она вполне копируема и стабильна во времени.

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

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

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

• Когда люди даже и не думают создавать систему, а пишут очередную «концепцию». Нужно проверить, описывает ли концепция что-то существующее в реальности, а не просто описывает создание документации и избегает описания воплощения системы. Скажем, «концепция развития региона»: это утопия? Какие есть инструменты реализации концепции? Ведь «регион» — это абсолютно материальный объект. Кто и что должен сделать (выполнить работы, имея для этого ресурсы и полномочия распоряжения ресурсами), чтобы перевести регион из состояния «было» в «стало» согласно концепции? Точно ли «концепция» описывает физический объект «регион», который будет существовать в будущем?

• Когда разработчики проектной документации считают, что их целевая система — документация. Инженеры из конструкторского бюро или проектного института часто путают воплощение системы в момент, когда она уже сдана в эксплуатацию с информационной моделью такой системы, которую они «нафантазировали» без шанса на её воплощение/реализацию/изготовление. Нет, целевая система — это всегда воплощение системы, без воплощения системы не стоит и заводиться с её описанием (результат мышления, ментальный объект), документированием этого описания (результат вывода описания на внешний стабильный носитель информации). Без намерения сделать систему речь идёт о «художественных описаниях», в них могут быть любые ошибки, и их даже не будет желания проверять. Надо спросить проектировщика, что будет результатом его работы. Если проектировщик, например, здания, ответит «здание», то всё ОК. Если такой проектировщик ответит «информационная модель здания» — то бить тревогу, ибо мысль проектировщика явно не дотягивается до воплощения системы, ограничивается описанием и документацией.

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

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

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

Результат работы проектировщика атомной электростанции — в конечном итоге воплощение работающей атомной электростанции, а не описание атомной станции, даже документированное в форме информационной модели атомной станции в полусотне компьютеров. Результат работы хореографа — это в конечном итоге перформанс танцора (исполняемый в конкретное время в конкретном физическом месте во вселенной), а не описание хореографии (последовательности движений) в виде идей в головах танцоров, или тем более не документ (бумажный или электронный) с описанием хореографии. И это несмотря на то, что проектировщик сам не строит атомные электростанции, а только их описывает, а «хореограф» в его изначальном значении тоже «описатель» танцевального перформанса (от др.-греч. χορεία — хороводная пляска, хоровод + γράφω — записывать, писать. Первоначальное значение хореографии — это отнюдь не сочинение и постановка танцевальных перформансов, а именно искусство записи танцевания как наблюдаемого поведения танцора⁴, грубо говоря, это был не «писатель», а «писарь»).

Карта — это не территория. Люди ходят не по карте, а по территории. Карта — это только описание территории, которое может быть представлено в разных документах (электронных или бумажных, или пластиковых), и это верно для всех описаний/документов, не только для географических карт. На географическую карту смотрят, по территории ходят.

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

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

Карта коктейлей в данном случае — не система, а только документация материальной системы «ассортимент ресторана» (system description/documentation), а информация на ней — описание системы (system definition).

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

Моделирование: воплощения, описания, документы с описаниями

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

Описания

Но зачем нам нужны описания, ментальные/идеальные объекты?! Нас будут интересовать изо всех видов описаний главным образом:

• Символьные/знаковые/языковые описания в отличие от коннекционистских/нейросетевых. Нам нужна коллективная разработка, то есть возможность доступа нескольких агентов к одному описанию как для исправлений, так и для ознакомления. Символьные описания легко отчуждать (документирование), копировать и пересылать в ходе коллективной разработки. Описание, находящееся в нейросети агента, отчуждается трудно — там вместо «копирования, пересылки» работает «обучение», совсем другой механизм передачи описаний.

• Описания в рамках теоретической теории понятий (theory theory, объекты и отношения, работа медленного мышления S2), а не прототипной теории понятий (prototype theory, работа с метафорами и аналогиями, concept blending, работа быстрого мышления S1). Формальность описания нужна для облегчения проверки.

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

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

Мышление в создании/construction каких-то новых систем, в познании/learn и последующем изменении каких-то уже существующих/brownfield систем обычно происходит не для отдельных экземпляров систем, а сразу для множеств систем, то есть для типов систем. Конечно, можно представить ситуацию, когда описывается конкретный экземпляр системы в конкретном экземпляре окружения в конкретное время (например, в записи базы данных поломок насосов на какой-то подстанции или записи в базе данных землетрясений, или записи в истории болезни какого-то пациента, или события в летописи какой-то страны), но это обычно записи времени эксплуатации системы, а не времени разработки. Разработка (замысливание, проектирование, планирование изготовления) всегда ведётся не для конкретных экземпляров систем, а «в общем случае», то есть для множества/типа/вида/класса подобных систем, даже если речь идёт о создании одной системы (скажем, Эйфелевой башни или новой страны).

Множество/класс/тип/вид/сорт — это математический/ментальный/понятийный объект. В математике множество из одного объекта не эквивалентно этому одному объекту: свойства множества отличаются от свойств самого объекта в этом множестве.

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

Информационные технологии работают с описаниями, так что если вы имеете дело с какими-то компьютерами и компьютерными сетями, то остерегайтесь перепутать документированное описание системы (информационную модель на каком-то материальном носителе) и воплощение системы. Вы легко сможете сообразить, что фотография человека — это не человек, на ней изображённый. Чуть трудней будет сообразить, что табличка с данными температуры ракетного двигателя на листочке бумаги — это описание ракетного двигателя, а сам листочек бумаги тут не важен. Но вот если речь идёт о небольшой базе данных, в которой описывается поведение ракетного двигателя в серии испытаний — вот тут наступает ступор, ибо сама база данных представляется её разработчику какой-то системой, которая будет казаться целью вашей работы, целевой системой, воплощением системы, материальным/физическим объектом, итогом работы. Нет, база данных тут — документированное описание ракетного двигателя, просто в менее привычной форме, документированное не на бумаге. Даже если с этой базой данных рассмотреть программу управления ракетного двигателя и назвать это цифровым двойником/digital twin⁵, то интересовать вас всё-таки будет поведение физического двойника, то есть сам ракетный двигатель. И при разработке такой базы данных и всех программ вокруг неё надо в первую очередь думать именно о двигателе::физический двойник::подсистема! Если не удерживать в голове разработчика этот двигатель, то база данных легко может оторваться своим содержимым от описания реального физического мира — и оказаться бесполезной, а то и вредной. Система тут будет состоять из двух подсистем — цифрового двойника::софт (всё-таки взятый с учётом аппаратуры, софт без вычислителя не бывает) как одна подсистема и физический двойник как другая подсистема. Если вы не понимаете, какую систему вы делаете и заняты только своей подсистемой цифрового двойника (впрочем, и физического двойника тоже), то у вас будут огромные проблемы в проекте. Когда две подсистемы физического и цифрового двойников начнут работать вместе, успешной работы системы в целом не получится — и денег поэтому у её разработчиков не будет (а если их успели выплатить, то деньги даже могут отобрать! Ничего же не работает, за что платить?!).

Умение понять, какая система описывается в физической реальности, если вам показали описание в виде каких-то структур данных, документированных в компьютере — это ключевое умение для всех, кто встречается с современными информационными технологиями. Если у вас CRM (customer relationship management⁶) система, то её базы данных подробно описывают клиентуру как целую систему в физическом мире, а части клиентуры — это отдельные клиенты (возможно, сгруппированные в какие-то сегменты, но это сейчас неважно, пока нам важно разобраться, что клиентура — это система в реальном/физическом мире, а компьютерная CRM-система по отношению к этой клиентуре — примерно то же, что фотография человека по отношению к человеку, документ с описанием с удобными средствами просмотра документа).

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

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

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

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

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

Для этого нужно обладать кругозором и прикладным мастерством. Если вы изготавливаете ERP-систему (enterprise resource planning, планирование ресурсов предприятия), то вы должны понимать: ERP-система документирует и позволяет удобно просматривать самые разные описания потока ресурсов (ресурсы — это сырьё, полуфабрикаты разной степени обработки и сборки, конечная продукция, «застрявшие» в предприятии, которое что-то выпускает — всё это физические объекты, вещи, занимающие место в пространстве-времени). ERP-система существует как информационная модель, современная «ручка-бумажка», внешняя память для мозгов сотрудников предприятия, она просто отражает состояние этого потока ресурсов, причём модуль планирования ещё отразит в своих выходных данных и будущее состояние потока ресурсов. Это ОК, мир четырёхмерный и будущая физичность нас тоже вполне устраивает.

Единственная цель ERP-системы — учёт ресурсов предприятия с целью планирования максимального прохода/throughput этих ресурсов по предприятию. Чем больше пройдёт через предприятие сырья (реального физического, а не описаний сырья!) и выйдет готовой продукции (реальной физической!), тем больше будет встречный денежный поток (реальные деньги, думайте о них как о кучках золота). Если не брать в расчёт решений по физическому изменению потока ресурсов (заказ новых партий сырья, загрузки того или иного оборудования, задействования тех или иных складов, отгрузки по тем или иным контрактам), то ERP-программу со всеми её базами данных можно бы не делать, физический мир не изменился бы.

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

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

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

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

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

Как связаны понятия «объект в реальном мире» и «воплощение системы»? «Система» — это тип для объектов в реальном/физическом мире. Эти объекты характеризуются тем, что они как-то могут быть выделены из мира (граница системы, причём это граница в пространстве-времени — можно говорить о форме объекта в четырёхмерном мире). Всё, что снаружи от границы — среда/окружение/environment этой системы. Система и воплощение системы — это синонимы. Конечно, внутри системы можно выделить другие системы, они будут называться подсистемами. Конечно, можно выделить границей и какую-то систему, в котором внутри будет находиться система — она будет называться надсистема. Мы будем постепенно раскрывать понятие «система», добавляя и добавляя разные связи между ним и другими понятиями.

Если мы берём какой-то физический объект, то обычно у него уже есть тип из предметной области (тип из мета-модели/middle-ontology), который берётся из учебника предметной области/domain. Например, борт #45667 классифицируется в предметной области как «самолёт», записываем «борт #45667»::самолёт. Само понятие «борт #45667» — это будет понятие модели, соответствующее экземпляру «самолёта» в физическом мире ((вы же не путаете строчку символов ««борт #45667»::самолёт» с реальным физическим самолётом? Строчки не могут летать!). Мы можем записать «самолёт» как тип, а в системном мышлении дополнительно можем записать «самолёт::система», добавив к типу «самолёт» из мета-модели предметной области авиации тип «система» из системного мышления как мета-мета-модели. Значком :: мы будем показывать тип, который был использован в рассуждении (яблоко::фрукт), то есть показывать отношение классификации (принадлежности к множеству). В системном мышлении мы добавляем, что «система» и другие понятия системного мышления — это и есть типы, которые вы будете присваивать чаще всего. Мир вы будете видеть как набор не просто объектов, но объектов::система (объектов типа «система»).

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

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

• объект-из-жизни (иногда его ещё нужно найти!), то есть какую-то область пространства-времени в физическом мире, («яблоко в жизни»). Это модель, описание реального объекта.

• тип объекта из дисциплины/теории метода работы в этой предметной области («пища», или «счётный объект» — если яблоки используются вместо счётных палочек, например, в детском саду), это мета-модель, модель предметной области, которую узнаёте из материалов каких-то прикладных курсах и прикладного/профессионального развития.

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

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

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

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

Моделирование: присвоение типа системе по её описаниям

Восстановите, какие системы были описаны в приведённых документах/информационных моделях (впишите имена их типов в предметной области).

Как договориться: не обобщать, а конкретизировать

Если один человек упомянул президента США, а другой — Дональда Трампа, то они имели в виду одно и то же лицо? А если другие люди упомянули президента США и Джорджа Вашингтона — они имели в виду то же самое лицо, что и человек, упомянувший президента США в предыдущем предложении?

В инженерии нужна жёсткая логика для подобных рассуждений о том, относятся ли разные описания одному и тому же объекту. Описанный одним человеком насос P-101 на схеме трубопроводов, и описанный другим человеком насос модели ПДР-15-НШ-12 в монтажной спецификации — это один и тот же насос? А установленный в турбинном зале насос ПДР-15-НШ-12 с серийным номером RKS456/4 — как он соотносится с первыми двумя? Как описать это «в компьютере» так, чтобы и самому не запутаться, и других не запутать?

Ещё Декарт (1596-1650) задавался вопросом: а как вообще понять, что люди говорят об одном и том же объекте, если они видят в нём самые разные свойства (то есть относят его к самым разным классам)? Скажем, один инженер говорит о высокопроизводительной системе, другой — о взрывоопасной, менеджер — о прибыльной, а финансист — о дешёвой? Как тут понять, что речь идёт об одной системе? Ответ Декарта на такие вопросы используют до сих пор⁸: если места в физическом пространстве-времени/экстенты у двух объектов совпадают (совпадают формы объектов и их местоположение в пространстве-времени), то это один и тот же объект. Не важно, какие основные или вторичные характеристики, свойства и части увидели разные люди в объекте/системе, или для каких применений этот объект/система им нужна. Не важно, одинаковые или разные имена у тех мест в пространстве-времени, о которых говорят разные люди с разными предметами интереса в той или иной ситуации. Если речь идёт об одном и том же месте пространства-времени, значит речь идёт о том же самом воплощении системы. Если я говорю о пище, вы говорите о яблоке, она говорит о товаре, он говорит о зелёном физическом теле массой 150 грамм, и все мы показываем на одно и то же место/объем/форму/экстент в пространстве-времени/физическом мире, то речь идёт об одном и том же объекте. Если кто-то показывает в физическом мире/пространстве-времени на бабочку с крыльями и говорит «бабочка», а кто-то другой показывает на изменяющийся во времени и перемещающийся в пространстве объект яйцо-гусеницу-куколку-бабочку-с-крыльями и говорит «бабочка», то у этих двоих есть шанс понять друг друга, даже если они поначалу не могли договориться из-за путаницы в словах/терминах.

Важно, что «ход на понимание» тут на конкретику (воплощение системы, физический мир), а не на «определение» (то есть отнесение рода объектов к их виду — «определение по Аристотелю», «как в словарях», как в учебниках математики). Выдача определений, равно как и требование определений, обычно затуманивают понимание в сложных ситуациях. Проясняют понимание только примеры воплощений каких-то систем в физическом мире, «заземления»/grounding — все споры о терминах прекращают именно такие примеры.

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

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

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

Моделирование: заземление абстрактных текстов

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

Отношение состава

Главные отношения в системах (воплощениях систем, помним о физичности!) — это отношения «часть-целое» (part of), они же отношения состава/сборки (composition). Инженеры часто говорят об этом как о разбиении (breakdown) системы. В системах главное — это системные разбиения/breakdowns. Уровни этого разбиения — это и есть системные уровни. Разбиения делаются вниманием, ничего в физическом мире специально не разбивается! Если вы разбили бабочку на крылья, тушку, ножки и усики, то это не означает, что вы оторвали от тушки крылья, ножки и усики: нет, вы просто выделили в живой бабочке эти части своим вниманием! Более того, вы и саму бабочку выделили вниманием как часть её окружения!

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

Речь идёт об «истинных частях», то есть физических частях, а не бытовом разговоре про «часть описания системы», «часть характеристик системы» и прочих «частей информационных объектов». Мысли о том, как именно распространить системное мышление на такие «информационные части» сейчас появляются, мы немного этого коснёмся, но потом. Пока же говорим только о пространственно-временных частях, то есть частях физического мира, частях каких-то систем. Системы, напомним, физичны/реальны.

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

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

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

Удобно представлять воплощения системы эдакими «червяками» во времени, в которых их место в физическом мире проходит какую-то траекторию во времени/«развёртку во времени»:

При таком подходе простые/мгновенные события — это трёхмерные «срезы» системы на какой-то момент времени, эдакие трёхмерные «системы, какие они в моменты остановки их работы», «без времени». До события было одно состояние/роль системы, а после мгновенного события — другое состояние/роль. Кроме того, сама система появляется в какой-то момент времени, а в какой-то момент времени она исчезает, это события появления и исчезновения системы. Спортсменка на фотографии проходит разные события (отрыв от земли, приземление), определяемые её позами в эти моменты времени. Эти позы, как «трёхмерные фотографии» и есть события, разделяющие разные состояния «сальто», «подготовки к сальто», «выравнивание после приземления».

Например, в позном беге⁹событием является «поза бега» — всё тело бегуна в определённый момент времени. «Поза бега» является ключевой для правильного бега, весь бег оказывается основан на событии принятия правильной позы.

Описания очень сложных систем (от микропроцессоров с их диаграммами состояний до предприятий с их регламентами работы) часто опираются на связанную с ними событийную структуру. Проще всего выяснить что-то про незнакомую систему — это спросить, какие с ней связаны события, то есть какие объекты меняют свои состояния с каких на какие в какие моменты. В разработке информационных систем предприятия этот метод называется «событийный штурм»¹⁰ (event storming, по аналогии с «мозговым штурмом»). Очень удобно строить онтологию/мета-модель предметной области, задавая вопрос о том, что там меняется в ходе работы, «какие события у вас происходят, какие заметные моменты» — вот моменты изменений и будут тамошними событиями, а дальше вы интересуетесь объектами, которые поменяли одно состояние на другое, и тем самым находите эти объекты. Скажем, всех волнует момент, когда, наконец, прекращается сквозняк. ОК, что в этот момент происходит? Закрывают дверь! ОК, дверь меняет состояние с «дверь открыта» на «дверь закрыта», речь идёт о событии «закрытие двери».

Когда говорят о событиях, то рассматривают их в контексте таких больших отрезков времени, на которых длительностью события можно пренебречь. Если мгновенное/простое событие рассмотреть «в лупу», то мы найдём там сложное событие, которое занимает некоторое ненулевое время. Так, между двумя часами «дверь открыта» (и скозняк в комнате, состояние комнаты «комната проветривается») и сутками «дверь закрыта» (перед очередным проветриванием) происходит событие «закрытие двери». Временем этого события можно пренебречь. Но если не пренебрегать, то найдём 30 секунд, когда агент (человек или робот) подходит к двери и выполняет работу по какому-то методу закрытия двери (предложите три разных метода/способа/практики/стиля/культуры выполнения этой работы). Эта работа переводит дверь из состояния «дверь открыта» в состояние «дверь закрыта». Проект — это выполнение работ по каким-то методам, результатом работ будет перевод каких-то объектов из одного состояния в другое.

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

Вот диаграмма пространства-времени (space-time map) из книги Chris Partridge «Business Objects: Re-Engineering for Re-Use»¹¹, которая это иллюстрирует:

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

Событие «вторая мировая война» тоже длилось много лет, но при рассмотрении «предвоенного мира» и «послевоенного мира» это событие войны считается прошедшим «мгновенно», простым.

В упомянутой книге можно прочесть много любопытного про подобный 4D (4 dimensions, 4 измерения, три пространственных и одно времени) подход к описанию мира, в котором огромное множество самых разных отношений между объектами сводятся к ключевому для системного мышления отношению части-целого в физическом мире. «Состояние», «событие», «роль» — все они оказываются просто частями системы, что существенно облегчает мышление, делает его универсальным и компактным. Системное мышление — это прежде всего мышление про части и целое, отношение состава/композиции/разбиения/is_part_of. Самое тут важное, что при таком подходе резко упрощается рассмотрение самых разных других видов отношений: описание мира в таком подходе становится короче, рассуждения о самых разных явлениях унифицируются. И этот подход хорошо формализуется, что важно для инженерных применений¹².

Что тут можно спутать при рассмотрении истинного/физического отношения «часть-целое»? Удивительно, но естественный язык даёт богатый материал для путаницы.

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

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

Отдельный источник путаницы — это сначала перепутать воплощение системы и её описание, а потом говорить о частях описания как о части системы. Так, усы на моей фотографии можно признать моей частью. Но это не так: все молекулы краски, из которых состоят усы на моей фотографии не входят в число молекул, из которых составлен я в целом! Это путаница между усами и документацией усов, усами и описанием усов! Документация моста — это не часть железнодорожного моста! Молекулы документации (будь это информационные модели на серверах в датацентре, или по старинке пара грузовиков мёртвых деревьев с частицами краски) не входят в число молекул моста. Мост и его части (опоры, дорожное полотно и т.д.) — это одно, а документация на мост — это не часть моста, это просто документация на мост. Документация не входит в состав моста, не взаимодействует с другими частями моста как физический объект, не является истинной частью конструкции моста!

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

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

Даже граница системы становится из «мыслимой»/абстрактной/идеальной какой-то вполне материальной, тоже занимающей объём: мембраны клеток, корпуса кораблей, стены домов — они тоже в ходе усложнения организации жизни (и технологической жизни), по мере эволюции (и техно-эволюции) становятся полноценными системами! Подробней о том, что границы систем в физическом мире проходят не совсем случайным образом, а отражают фундаментальные законы природы, определяющие стабильность систем перед лицом разрушительного времени (физики тут упоминают неизбежный рост энтропии, преодолеть который может только жизнь, обучающаяся его преодолевать в ходе эволюции), можно почитать в работах Fields, Glazebrook, Levin и других авторов¹³.

Вопросы. Воплощение и описание систем

В какой момент появилась система «Ваза»?

--- В момент создания эскиза художника ### Нет, это появилось описание вазы. Ваза ещё не занимает какое-то физическое пространство-время в мире. Карта — это не территория, эскиз вазы — не ваза.

+++ По завершении формовки на гончарном круге ### Да, ваза заняла какое-то пространство-время в мире. Далее все технологические операции пойдут с этой вазой.

--- По завершении росписи ### Нет, в этот момент ваза уже есть — у неё уже есть какое-то место в физическом мире, и не говорится, что «ваза должна быть расписная и обожжённая, иначе это не ваза». Ваза вообще может быть стеклянной.

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

--- В момент установки в зале дворца ### Нет, к этому моменту ваза уже занимает какое-то пространство в мире, и речь идёт просто об изменении её положения в пространстве в момент установки, но не о её появлении.

Когда возникла система «Ваза с драконами»?

--- В момент создания эскиза художника ### Нет, это появилось описание вазы. Ваза ещё не занимает какое-то пространство-время в мире.

--- По завершении формовки на гончарном круге ### Нет, уже существует ваза, занимающая какое-то пространство-время в мире, но драконов на ней ещё нет.

+++ По завершении росписи ### Да, ваза с драконами появляется в этот момент — место в пространстве-времени теперь занято именно «вазой с драконами». До этого момента была просто «ваза».

--- По завершении обжига ### Нет, к этому моменту ваза с драконами уже существует (занимает какое-то место в пространстве-времени), просто меняются какие-то её свойства — она становится водонепроницаемой.

--- В момент установки в зале дворца ### Нет, к этому моменту ваза с драконами уже появилась, она просто поменяла своё местонахождение.

Когда закончилось существование системы «Ваза с драконами в парадном зале дворца»?

+++ Когда её украл дворецкий ### Да, с этого момента объект «ваза с драконами» существует, но объект «ваза с драконами в парадном зале дворца» исчез.

--- Когда украденную дворецким вазу разбила у себя дома жена дворецкого ### Нет, она разбила другой объект — «вазу с драконами», уже украденную из дворца, но не «вазу с драконами в парадном зале дворца».

--- Когда осколки разбитой вазы вместе с прочим мусором попали в подсыпку дорожной насыпи ### Нет, в этот момент исчез объект «разбитая ваза», а «ваза с драконами в парадном зале дворца» исчезла задолго до того.

Когда возникла система «стол семьи Ивановых»?

--- В момент изготовления последней детали комплекта стола на фабриках ИКЕЯ ### Нет, стол ещё не имеет формы стола, не занимает пространства-времени как «стол». Это только «набор деталей стола».

--- В момент сбора комплекта деталей в одну упаковку в упаковочном цехе фабрики ИКЕЯ ### Нет, в пространстве-времени ещё нет «стола», есть только «упаковка с деталями стола».

--- В момент снятия упаковки со стеллажа И.И.Ивановым в магазине ИКЕЯ ### Это до сих пор не стол, это только упаковка с деталями — в пространстве-времени нет объёма/места, занимаемого этим столом.

--- В момент оплаты стола И.И.Ивановым на кассе магазина ИКЕЯ ### Это до сих пор не стол, это только упаковка с деталями (хотя это уже будет упаковка семьи Ивановых, независимо от того, где она находится).

--- В момент вноса упаковки в квартиру Ивановых ### Это до сих пор не стол, это только упаковка с деталями (хотя это уже упаковка семьи Ивановых, независимо от того, где она находится).

+++ В момент окончания сбора в квартире Ивановых стола из деталей, находящихся в упаковке ### Да, в пространстве-времени появилось место, соответствующее объекту «стол» — и этот стол семьи Ивановых. Даже если бы этот стол собрали на улице, или прямо в магазине — момент появления стола семьи Ивановых именно этот.

--- В момент установки стола на место на кухне Ивановых ### Нет, к этому моменту стол уже существует и принадлежит семье Ивановых — он занимает какое-то место в пространстве-времени, и перемещение его в пространстве ничего тут не меняет.

Что из перечисленного является частью четырехмерного объекта «стол»?

--- Инструкция по сборке. ### Нет, это описание стола.

+++ Этикетка, приклеенная снизу. ### Да, это составная физическая часть стола.

--- Чертежи стола, находящиеся на заводе-изготовителе. ### Нет, это описания стола.

+++ Надпись шариковой ручкой на столешнице стоящего в гостиной стола. ### Да, частицы пасты шариковой ручки в надписи являются физической частью стола — они часть того места в пространстве-времени, которое занимает стол. Содержание надписи не имеет значения, имеют значение стол и краска как информационные носители, вопрос про носитель информации как часть стола.

--- Отклеившаяся от стола этикетка, которую выкинули в мусор. ### Нет, отклеившаяся от стола этикетка больше не является физической частью стола — она не будет частью того места в пространстве-времени, которое занимает стол.

Выберите из списка ниже названия физических объектов:

--- Атомный реактор ВВЭР (водо-водяной энергетический реактор) ### Нет, речь тут идёт о классе/типе объектов: он не занимает какого-то конкретного места в пространстве и времени, так что он не физичен — физичны только конкретные экземпляры атомных реакторов ВВЭР.

+++ Атомный реактор первого блока Калининской АЭС ### Да, мы можем указать на конкретное пространство и время, которое занимает в мире этот экземпляр реактора.

--- Техническая документация атомного реактора первого блока Калининской АЭС ### Тут речь идёт обо всех комплектах документации (не конкретный комплект), то есть это класс таких комплектов — нельзя указать место в пространстве-времени, где находится «документация» (пространство-время может занимать только конкретный носитель информации, «медиа»: конкретные экземпляры листов бумаги, ячейки флеш-памяти, домены магнитного диска). Это класс описаний конкретного физического объекта-реактора как выделенного места в пространстве и времени, но это класс описаний — не физический объект.

+++ Первый комплект технической документации первого блока Калининской АЭС ### Да, речь идёт о конкретном пространстве и времени, где находится первый комплект (т.е. экземпляр, физический объект) документации. Тут речь идёт главным образом о носителе информации, а не о том, какая информация на этом носителе, не об описании первого блока Калининской АЭС.

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

--- Принципиальная электрическая схема платы ### Нет, это описание из какого-то документа. Описание — это не воплощение!

--- Схема разводки платы ### Нет, это описание из какого-то документа, описание не может быть воплощением.

--- Руководство по использованию платы ### Нет, это описание макетной платы (даже если оно документировано, оно не может быть воплощением).

--- Описание портов платы ### Нет, это описание каких-то важных характеристик макетной платы, описание не может быть воплощением (даже если описание документировать).

+++ Ничего из приведённых других вариантов ответа ### Да, воплощением системы является по факту именно макетная плата, в списке других ответов её нет.

Отверстия

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

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

Отверстие/дырка/полость занимает место в пространстве-времени, следовательно, присутствует в физическом мире. «Рабочая полость» в компрессоре — это тоже «дырка», рабочее пространство в трубопроводе — это тоже «дырка». Легко о них думать, представляя заполненным это пространство молекулами газа или жидкости, или даже вакуумом: физическое вещество тут не важно. Важно, как об этом думать, а думать нужно о местах физического мира, областях/объёмах пространства/времени.

Антракт — это часть (во времени) от концерта или спектакля, когда отсутствует представление. Рассуждать об антракте можно так же, как и об инженерных отверстиях, но это будет не пространственная часть, а часть во времени/темпоральная часть спектакля или концерта как материального объекта, воплощения системы. «Кульминация спектакля» тоже может быть представлена как вполне материальная часть: это темпоральная (во времени) часть спектакля, в которой достигается максимальный эмоциональный накал. С другой стороны, можно считать, что эта часть занимает незначительное время, и тогда «кульминация спектакля» будет событием — а темпоральные части будут важны до и после этого события.

Как же мыслить про антракт или кульминацию как темпоральные части спектакля? Это будут все предметы спектакля (все молекулы входящих в состав спектакля предметов — артистов, реквизита, зрителей) в какой-то отрезок времени.

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

Это в какой-то мере противоречит понятию «устойчивой к действию разрушительного времени конфигурации материи» как системы в физике. Так, если смотреть на пламя свечи, то исследователь Karl Friston замечает невозможность указать границу системы, ибо там идёт какой-то беспорядочный обмен молекулами с окружением. Но если взять инженера, то для него «пламя» вполне себе объект, состояние которого можно измерить (скажем, измерить температуру в центре пламени и на его условной границе). И это пламя инженер будет определять по его пространственной форме в окружении и необходимости выполнять какие-то операции с этой формой: у инженера будет тут всё то же самое рассуждение, что с «отверстием». И пламя для него будет вполне устойчивым, а уж сварной шов с его расплывчатой границей между собственно швом и материалом на молекулярном уровне — и подавно будет устойчив.

Можно и дальше разбираться с подобными сменами состояний и объектами, которые меняют состояние в ходе мгновенного/простого события или сложного события, занимающего некоторое время — в зависимости от рассмотрения. Так, в 3D-печати ракетных корпусов¹⁵ можно легко представить себе корпус ракеты, состоящий и сплошного «сварного шва» — по факту речь идёт о непрерывном наплавлении металла. Важно понимать, что масштаб времени рассмотрения/масштаб темпоральной части системы тоже имеет значение. В большом масштабе времени «вот корпуса не было — вот он есть», а в малом масштабе времени «мы добавили один виток наплавки на корпус, и так тысячи и тысячи раз». И важны не столько какие-то «объекты», воспринимаемые как «привычные твёрдые объекты», сколько занимаемое пространство-время в каких-то границах системы. Во времени такими границами системы (или состояний системы) являются события, в пространстве — форма/место. События и формы/места — это границы системы или состояний системы.

Поведение системы: процессы/изменения

Состояния системы меняются с ходом времени, и рассмотрение частей и целых материальных объектов даёт возможность говорить об изменениях — то есть обсуждать изменения/действия/процессы/поведения/процедуры/activities просто как наборы взаимодействующих систем/«воплощений_систем»/вещей-в-физическом-мире в качестве частей целого изменения/процесса. Процесс/поведение называется обычно глаголом или отглагольным существительным. Тут много нюансов, подробней об этом будет в руководстве по методологии, где нас будет волновать описание методов работы, то есть описание поведения систем-создателей (описание работ по каким-то методам) в сложных графах создателей и развития одних систем другими системами. Скажем, создание и развитие системы AI-агента командой инженеров компании-изготовителя, а эту команду инженеров создаёт какая-то команда менеджеров по развитию этой компании. В ходе эксплуатации как-то себя ведёт созданный инженерами AI-агент. Как-то себя ведёт в ходе своей эксплуатации (то есть в ходе создания AI-агента) команда инженеров. Как-то ведёт себя в ходе своей эксплуатации (то есть в ходе создания команды инженеров) команда менеджеров развития компании. И это явно не конец цепочки, ибо команду менеджеров тоже кто-то создавал, и это тоже система-создатель. Методы создания и развития систем и обсуждает методология, подробно создание::поведение и развитие::поведение разбираются в руководстве по методологии.

Тут же мы рассмотрим способ, каким можно думать о поведении системы в неразрывности системы и её поведения (ибо не бывает поведения в отрыве от того, что как-то себя ведёт, равно как чего-то, что ведёт себя «никак»). Думать о молотке легко, легко его представить, легко описать. Но вот как описать поведение молотка?

Поведение/behavior — это всегда изменения каких-то состояний систем (прохождение событий), а изменений бывает множество вариантов.

Наиболее значимыми для нас различимыми вариантами поведения (в случае систем-создателей говорят также о деятельности) являются:

• функции (для каких угодно систем, для создателей чаще говорят о методах/практиках/стилях/культурах и ещё много синонимов с нюансами). Это поведение системы как функционального объекта. Как думать о функциях/методах наставляет руководство по методологии.

• Работы. Это поведение систем-создателей как аффордансов/конструктивных объектов (ресурсы, которые могли бы выполнить работу) согласно их функциям, а систем-создателей как конструктивных объектов, выполняющих роль функционального объекта. Как думать о работах вы уже знаете из предыдущих руководств, а ещё про операционный менеджмент (как управлять работами) рассказывает руководство по системному менеджменту.

Самый общий тип изменений, относимый к какой-то одной системе, мы будем называть поведением этой системы по отношению к изменяемым системам. Поведение — это взаимодействие системы с её окружением, то есть «внешнее поведение». Мы тут не рассматриваем то, как взаимоменяются/взаимоизменяются подсистемы, которые тоже как-то себя ведут, совместно давая внешнее поведение системы, в состав которой они входят. Внешнее поведение электронных часов — показ времени, для этого там внутри работают батарейка, какие-то микросхемы и экран, защищаемые от внешних воздействий корпусом часов.

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

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

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

В текущем подразделе руководства мы не будем вводить разные типы изменений/поведения/процессов. Оставим различения сервисов, функций систем, и «методов работы»/деятельностей/«видов труда» систем-создателей на более позднее рассмотрение (разница там больше терминологическая, понятие же имеется в виду одно и то же — функция/сервис/метод работы, в его отличии от собственно работы). Заметим только, что слово «процесс» используется и как общее название для «всяких типов изменения систем» (в физике), и как синоним для методов (в process management, процессном управлении). И в этом плане использования в менеджменте «процессы»/«методы работы»::поведения отличаются от «работ»::поведения. Метод и работа — это разные виды поведения (два способа рассмотрения поведения, с акцентами на разные его аспекты):

• метод/способ как паттерн работы с (функциональными) предметами метода (инженерное содержательное рассмотрение),

• работа — задействование ресурсов-конструктивов для выполнения метода (экономическое рассмотрение).

Иногда пытаются подчеркнуть это различие процессов/методов и работ, добавляя к процессу эпитет «рабочий», и тогда «рабочий процесс» означает метод работы, а работа — это таки работа, не «рабочий процесс», другой тип. Подробней, как мы уже говорили, будет в руководстве по методологии. Просто внимательней к слову «процесс»: оно может означать разное, как, впрочем, и любые другие слова, которые люди используют для описания не только поведения, но и чего угодно. Уточняйте, что имеется в виду, заземляйте!

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

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

«Забивание гвоздя» легко представить просто как перечисление физических объектов/систем, участвующих/взаимодействующих/взаимоизменяющих свои характеристики в период времени, соответствующий этому забиванию — т.е. «забивание гвоздя включает участие в нём гвоздя, молотка, доски, плотника». Распишем типы: “забивание гвоздя”::процесс/изменение/поведение включает::“указание на множество” “участие”::отношение “гвоздя”::система, “молотка”::система, “доски”::система, “плотника”::система.

Отношение участия (participation) в изменениях/действиях/процессах/процедурах/activities — это просто специализация отношения состава (composition, part_of/whole_to — в зависимости от направления чтения, «состоит из»/«разбито на» — тоже в зависимости от направления чтения).

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

Ищите в мире не обозначаемые глаголами и отглагольными существительными действия, ищите обозначаемые существительными объекты физического мира (системы), которые как-то себя ведут во взаимодействии, проявляют в мир своё (внешнее) поведение.

.

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

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

• всех четырёхмерных танцоров, поведение которых — танцевание

• поддерживающий танцоров фрагмент четырёхмерного танцпола (паркет, на который опираются танцоры. Это важно, попробуйте прокрутиться на одной ноге два оборота на асфальте и на паркете — покрытие пола для танцев очень важно!), и ещё

• объем воздуха с колебаниями в нём, ибо в этих колебаниях — музыка для танцевания.

Мы тут сознательно отказываемся от термина «танец», поскольку он очень многозначен, имеет множество словарных значений, и поэтому путает:

• Танец в самом общем значении «поведение агента». Скажем, книжка Peter Senge называется «Танец перемен», и это просто указание на то, что всё в организациях взаимодействует-танцует и тем самым происходят перемены.

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

• Танец как работа, которая выполняется конкретным агентом в конкретное время, «перформанс»/«исполнение»/«выход». Танец Васи в детском саду №6, который он будет танцевать 4 мартобря 2029 года с 14:05 до 14:07.

• Танец как вариант танцевального стиля/культуры/практики/метода танцевания в отличии этих методов/культур/практик между разными вариантами танца. Танго или вальс отличаются, и это танцы («танец танго», «танец вальс»).

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

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

• Не путать системы и их поведения. Хотя мы тут и говорим, что в рамках 4D экстенсионализма поведение системы — это сама система в ходе её изменений, которые вызываются взаимодействиями как подсистем внутри системы (внутреннее поведение), так и системы с какими-то системами в её внешнем окружении (внешнее поведение), всё-таки трудно думать о четырёхмерных системах-процессах, легко запутаться, и мы крайне не рекомендуем это делать. Думать лучше о системах и их поведениях, считая поведение отдельным типом от типа «система» и различая типы поведения для одной и той же системы.

Поведение — это не система

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

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

Использование терминологии «над-» и «под-» для методов/практик может быть использовано двояко:

• Как темпоральная часть ситуации задействования какого-то метода работы (тут ровно такое — и мы использовали слова «более мелкий метод» вместо слова «подметод», когда описывали приёмы/шаги закрытия двери)

• Как альтернативные классы/типы методов::тип (например, прекращение сквозняка при проветривании путём закрытия двери, против прекращения сквозняка путём закрытия окна — и там перечисляться уже будут другие предметы, в том числе не дверь, а окно). В нашем руководстве мы предпочитаем тут говорить «вид» или «класс» (отсылка к родо-видовым отношениям), например, «вид труда», «вид деятельности», «вид культуры», чтобы показать разные типы/классы, классифицируемые типом метод/труд/культура::тип. Хотя в данном случае можно говорить и об отношении специализации (метод предотвращения сквозняка специализируется до прекращения сквозняка закрытием двери и прекращения сквозняка закрытием окна).

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

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

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

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

Заметим, что добавка зрителей к перформансу (буквально: зрители как подсистема::«физическая часть системы» перформанса::система) — неочевидный мыслительный ход. Например, если два танцора танцуют друг с другом, то этого достаточно для танца, они «зрители» друг для друга (зрители — это роли, а не какие-то отдельные объекты). Тем самым зрители и танцоры — участники (отношение participation, специализация отношения «часть-целое») танцевального перформанса, и тут возникает довольно богатый набор объектов для обсуждения ситуации перформанса. Мы можем рассуждать о танцевании артистов более точно, привязываясь к физическим объектам, физическому пространству-времени.

Танцевание танцора — это процесс/действие/activity, но когда мы добавляем к танцору другие объекты и это становится «танцевальным перформансом»::системой (набором подсистем, а не «процессом-танцеванием», ибо там много чего происходит в ходе перформанса, кроме собственно танцевания::поведения танцора::система), думать и о танцоре, и о перформансе с его участием можно уже примерно так же, как о «станке», «автомобиле», «отверстии». Уточнять, что такое «танцевание» (конкретизировать/заземлять/grounding) можно, давая примеры воплощений этого поведения/процесса у танцора в разных перформансах, а не обращаясь к словарным определениям термина «танцевание» или «художественный перформанс». Обращаться к определениям — это приводит к длительным и бесплодным «спорам о терминах», избегайте таких споров. Уточняйте значения через заземление.

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

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

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

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

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

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

Скажем, «танцевальный перформанс» (как и любое «мероприятие») мы легко назовём «системой», и ведущий там процесс/изменение будет — танцевание танцоров, а ещё провайдинг музыки (музицирование музыкантов, или игра колонок, к которым подключили плеер, причём через Bluetooth — важно всегда помнить, что есть альтернативы, которые можно рассматривать отдельно). Танцевание — нет, не назовём системой, оставим поведением танцора. Системой, осуществляющей какое-то поведение (работу, функцию, сервис, практику) танцевания останется танцор, а танцевание будет поведением (работой, сервисом, практикой, методом, способом, функцией — особенности использования разных терминов с отличающимися в системном мышлении их значениями обсудим позже) танцоров, а не перформанса. Перформанс не танцует! Он развлекает, радует, приносит деньги, что угодно, но танцуют в нём танцоры, они внутри перформанса, его часть. Части системы обладают одними свойствами/характеристиками и поведением, а целое — другими свойствами/характеристиками и поведением. Это появление новых свойств и нового поведения у системы по сравнению с частями называют эмерджентностью/emergence.

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

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

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

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

Мы часто будем приводить в качестве примера поведения системы танцевание танцора — танцор (как будет показано дальше в руководстве) не так тривиально разбирается на части, как насос или велосипед. Но танцевальные перформансы с танцеванием танцоров всё ещё много проще предприятия с его работой работников, поэтому думать о танцах проще, чем о предприятии. И совсем недаром одна из классических (год выпуска — 1999) книг Peter Senge по системному мышлению для предприятий называется «Танец перемен»¹⁷.

Ещё один пример — интеллект, как система, реализованная мозгом или аппаратурой компьютера. Его поведение — мышление. По мышлению не «постучишь», а вот по интеллекту (мы понимаем, что это часть материальной системы-вычислителя) — вполне, даже если мы не знаем точно, какие именно части (нейроны и иные клетки мозга — какие именно, транзисторы классического компьютера) выполняют мышление::поведение.

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

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

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

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

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

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

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

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

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

Вопросы. Процессы как физические объекты

Какие утверждения верны для объекта, являющегося в четырехмерном пространстве-времени процессом создания чертежа стола?

--- Этот объект обладает протяженностью только во времени, в пространстве он ничем не представлен; ### Нет, участвующие в создании чертежа физические объекты (люди, инструменты и т.д.) занимают место в пространстве.

--- Этот объект обладает протяженностью во времени и представлен в пространстве самим чертежом; ### Нет, кроме самого чертежа в процессе его создания участвуют и другие предметы — люди и инструменты, которые занимают место в пространстве.

+++ Этот объект обладает протяженностью во времени и совпадает в период рисования со всеми объектами, задействованными в рисовании (лист, карандаш, линейка, рисующий инженер). ### Да, все задействованные (участвующие) в рисовании чертежа стола объекты входят в этот процесс через отношение участия/participation (это подвид отношения состава/composition).

--- Этот объект обладает протяженностью во времени и представлен в пространстве рисующим инженером ### Нет, в процесс создания чертежа входят и другие объекты, занимающие место в пространстве.

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

--- этот объект — система ### Нет, это не система, это процесс. Создание стола ведётся системами-агентами (людьми), задействующими в ходе этого процесса и другие объекты.

Компьютерные программы как системы

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

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

Ещё раз подчеркнём: программу следует считать воплощением системы только в тот момент, когда она реально запущена на исполнение и работает, делает то, ради чего она была написана. Это довольно контринтуитивно, но исходный код программы — это не программа (алгоритм и его данные), но только описание программы; исходный код программы в системе управления версиями или просто в файле на носителе — это только документация программы. А ещё есть данные, программа их получит после начала работы и выдаст на выход после окончания работы. Не путайте «описание на носителе», фотографию человека с самим человеком. Программа — это то, что отражает состояние данных в момент её исполнения, это то, что меняет свои состояния во времени исполнения (а не в момент создания). Исходный код не меняет своих состояний в ходе исполнения, в нём нет изменяющихся данных, это просто описание алгоритма и структур данных.

Поэтому программисты, которые считают, что их инженерная работа закончена в момент написания исходного кода (алгоритма и структур данных) — эти программисты глубоко неправы, и это типичная ошибка. Из признания этой ошибки появилось целые движения DevOps¹⁸, SRE¹⁹ и platform engineering²⁰ — программисты признали, что они должны быть озабочены не только разработкой кода программы как алгоритма и структур данных (время Development), но и быть операторами работающей на серверах программы (время Operations). Подробнее об этом в руководстве по системной инженерии.

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

• исходного кода::описания программы (алгоритма и структур данных),

• Файла::документ с описанием программы («информационный объект»),

• работающей программы::система.

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

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

Итак, первая ошибка — это считать, что исходный код программы и есть программа. Нет! Исходный код — описание программы!

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

Как только разработчик забывает, что его программа только цифровой двойник физического двойника, и что он разрабатывает целую систему из цифрового двойника и физического двойника, то проект будет провален. Это как если бы разработчика самолёта не интересовал самолёт в целом, но только его система управления. Нет, работоспособность ERP-системы проверяется не по тому, что она сама работает, а по тому, как она управляет потоком комплектующих через предприятие, важно поведение физического двойника. Работоспособность системы управления самолётом (цифровой двойник) определяется не сама по себе, но по работоспособности самолёта (физический двойник). Важно поведение физического двойника, и создание и развитие системы из подсистем цифрового и физического двойника. И даже в более слабых вариантах цифровой тени и цифровой модели это тоже выполняется: цифровой двойник — это автоматическая система управления, цифровая тень — автоматизированная система управления — она получает данные с датчиков физического двойника, но вот дальше просто показывает состояние оператору, и тот «руками» управляет системой. Цифровая модель и данные получает «вручную», и выдаёт параметры управления для «ручного» управления. Скажем, навигатор в автомобиле с автопилотом — цифровой двойник, навигатор со спутниковым датчиком и голосом говорящий, куда рулить — цифровая тень, а если навигатору надо говорить, где вы находитесь и он будет говорить, куда дальше ехать — а рулить надо вам, то это цифровая модель. Разговор о софте необходимо сегодня вести с учётом того, что этот софт или сам по себе агент, или цифровой двойник, или цифровая тень, или цифровая модель какой-то другой системы — физического двойника (ну, или софт — часть сети софтов, digital twin network, и всё равно нужно думать о физическом двойнике, который управляется этой сетью софтов).

Третья ошибка «программы как системы, которую мы разрабатываем» — считать саму программу разрабатываемой системой, а не какой-то подсистемой в ситуации, когда речь идёт о поддержке работы какого-то оргзвена с людьми или другими программами. Если ваша программа выдачи зарплаты чудесно работает, а вы забыли научить работников предприятия или AI-агентов (или даже другие программы в рамках автоматизации) мастерству работы с этой программой, то это означает, что программа не работает: зарплата-то не выдаётся! Если оплата ведётся только «за программу», то можно потом долго спорить, кто оплачивает обучение сотрудников или AI-агентов, или оплачивает перепрограммирование всех связанных программ (которое может быть много дороже разработки самой обсуждаемой программы выдачи зарплаты).

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

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

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

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

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

Например, ровно эта связь между объектами софта и физического мира обсуждается в подходе DDD (domain-driven design), где требуется, чтобы объекты программы напрямую отражали объекты физического мира в предметной области работы компании (впрочем, там требуют и отражения объектов ментального мира — мира описаний, но это для нас не так важно сейчас)²².

Целевая система в проектах разработки софта

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

Для начала надо просто пройтись по списку ошибок из предыдущего подраздела. Хотя этих ошибок может быть много больше, но и этот короткий список обычно сильно продвигает понимание. Скажем, предположить, что ваша программа — это цифровой двойник, и тогда вам надо найти физического двойника, а система будет состоять из цифрового и физического двойников. Соответственно изменить и проект: сдача программы будет не неубедительной для заказчика демонстрацией работы самой программы с её базой данных как цифрового двойника (но именно «демонстрацию работы только программы, и ничего сверх этого» хотели бы разработчики: «бумага всё стерпит», оторванная от жизни софтинка вольна фантазировать свои результаты, успешность фантазий показывать очень легко), но демонстрацией надлежащей работы физического двойника под управлением цифрового двойника. Продемонстрировать изменения физического двойника под управлением цифрового двойника много труднее, чем продемонстрировать оторванного от реальности цифрового двойника. Но только это и будет реальным успехом проекта, заплатят за это. Другое дело, что когда речь идёт о ракете или мосте, или даже о пациенте в больнице, то физический двойник очевиден. Но как его найти, если речь идёт о паутине объектов и их отношений в каком-нибудь предприятии? Что там может быть физическим двойником, работоспособность которого в паре с цифровым двойником надо продемонстрировать?

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

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

И тут надо не промахнуться, ибо «командировкой»/«деловой поездкой» называют разные процессы::поведения или мероприятия::система (и вам надо определиться ещё — вы это считаете процессами, или системами?):

• Посылающий в командировку (условно: «начальник») называет «командировкой» работу, которую надо выполнить где-то в другом городе. Часть этой работы — сначала агенту надо попасть в этот город, но это мало интересует.

• «Командированный» агент считает «командировкой» не столько результат работы (это для него просто «результат работы»), сколько «поездку»: полёт на самолёте, поездка на автобусе, проживание в гостинице, питание.

• «Бухгалтер» как агент считает «командировкой» не столько всю «поездку», сколько «подотчётную часть поездки»: не любой проезд, а только тот, который надо будет компенсировать. Скажем, до города проезд будет оплачен, а разъезды по городу — нет, а вот «командированный» считает это всё «командировкой».

Поскольку разные агенты считают командировку разными процессами или разными системами — надо просто дать им разные имена (скажем, «удалённая работа», «деловая поездка», «подотчётная часть деловой поездки», а от слова «командировка» отказаться, как от запутывающего) и научить разных агентов использовать эти имена, чтобы не путаться в разговоре. И вот дальше задаться вопросом: софт, который помогает «оформить командировку» — он помогает создать какую из этих трёх систем?! Конечно, это будут совершенно разные софты, или части одного софта, работающие как цифровые двойники (или тени, или модели) для разных целевых систем: одни помогают начальнику с «удалённой работой», другие — командированному с «деловой поездкой», третьи — бухгалтеру с «подотчётной частью деловой поездки». Есть подозрение, что для всех так называемых административных процессов есть не меньше трёх вот таких рассмотрений, поэтому-то и трудно разрабатывать софт для администрирования предприятий: все путаются из-за неразличения разных систем под одинаковыми именами! Если вы будете находить при этом разные объекты (пары: системы и их поведения) в физическом мире (4D экстенсионализм) и давать разные имена — путаница прекращается, и все участники проекта быстро договариваются между собой.

Если речь идёт о программе для станка с ЧПУ, то целевая система — это описываемая данными этой программы деталь. Программа же описывает работы станка, а станок нужен для получения детали. Цель — деталь, деньги от неё, а всё остальное только цепочка, приводящая к этой цели. Если программа работает хорошо, а деталь получается плохо — денег не будет. Так что с программами (включая мастерство как «программа для людей и AI-агентов» и тем более личность как совокупность всех видов мастерства одного агента) как целевыми системами нужно быть осторожными. Подробней про это в руководстве будет, когда будем обсуждать целевые системы проекта.

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

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

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

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

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

Все эти рассуждения легко переносятся из мира алгоритмов в мир данных. Ещё полвека назад не было даже персональных компьютеров (первый появился в 1980 году), а лет двадцать назад ещё считалось, что мир захватят сложные алгоритмы, которые будут хитро перерабатывать относительно простые данные в базах данных. Сегодня оказалось, что современное программное обеспечение сдвигается в сторону работы простыми алгоритмами над сложными данными. Даже в алгоритмах AI сработал этот принцип: самые простые нейросетевые алгоритмы над сложными данными весов нейросетей добиваются огромных успехов, разве что нужно очень много вычислительной мощности, которая позволяет выполнить эти простые алгоритмы (горький урок Sutton’а²³).

Поскольку сложность из алгоритмов перемещается в данные, то системным подходом начинают интересоваться не только инженеры-программисты, но и инженеры данных. Никогда не нужно забывать, что данные — это в конечном итоге описания каких-то систем. Даже в больших языковых моделях их данные — это описание/представление/presentation нашего материального мира как системы, только в сжатом виде модели мира — результат процесса познания/learning. Но в момент их обработки какой-то программой они сами становятся частью системы этой программы, они меняют своё состояние, они могут пропасть, они ведут себя как «вещь». То есть данные для обработки их программой тоже нужно «изготовить» из первичных описаний. И когда мы интересуемся, как получить из данных полезный результат, то как и в случае программ, мы должны научиться их изготавливать из исходных данных — и мы по аналогии с DevOps будем говорить о DataOps²⁴.

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

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

Мастерство как система

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

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

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

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

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

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

• Человек::агент = организм + личность (личность как совокупность самых разных видов мастерства, «весь софт, все программы для мозга»)

• AI-агент = аппаратура + личность (личность как совокупность самых разных видов мастерства)

• Мастерство::система = обычная или нейросетевая программа::система, которая работает на базе какой-то аппаратуры AI-агента или организма человека, реализует алгоритм/теорию какого-то метода/способа работы.

• Метод::поведение — обобщённый алгоритм/теория, по которому работает мастерство, а также инструменты, которые нужны для того, чтобы метод мог быть выполненным (скажем, для метода рытья траншей землекопу кроме мастерства рытья траншей нужно иметь или лопату, или экскаватор — инструменты, делающие возможным применение мастерства).

В проекте разработки корпоративного софта обязательно будут:

• учёт аппаратуры для этого софта («железо» или «виртуальная машина» — контейнеризация софта, учёт того, что часть софта исполняется на сервере в датацентре, а часть может быть и на телефоне с крошечным экраном, и т.д. — везде своё, но аппаратура должна быть!). Программа работает в составе программно-аппаратного комплекса, а не сама по себе!

• собственно разработка целевого софта, её все видят и признают.

• «изготовление мастерства в мозгах людей» (обучение работе с программой: нужно «изготовить» те части самых разных людей в самых разных ролях, которые смогут делать что-то полезное с программой — изготовить мастерство работы с программой). Заметим, что надо будет как-то учесть и организмы этих людей, те самые «мозги людей» — если людей вам не дали, то и мастерство вы в них не изготовите, всё то же, что с аппаратурой для «программно-аппаратных комплексов».

• Изготовление мастерства в AI-агентах (это только-только появляется, но тут будут свои особенности: нынешних AI-агентов и не запрограммируешь как софт, и не обучишь как людей, а мастерство работы с вашей программой от них потребуется)

• Изготовление исходных данных (data engineering) и разноска их по разным носителям, с которыми будет работать программа. А уж сама программа будет формировать выходные данные, и их тоже надо знать, куда и как положить.

Не пропускайте эти части! Они физичны, их тоже нужно «проектировать», а затем «изготавливать»:

• сам софт «разрабатывают» в ходе программной инженерии/software engineering,

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

• дополнительный классический софт настраивать в части использования его интерфейсов (и проверять, всё ли настроилось).

А что же с людьми, которые работают с программами? Очень часто воплощением целевой системы проекта будет какая-нибудь часть организации, которая должна выполнить какое-то дело — выдать кредит, начислить зарплату, изготовить деталь. И если окажется, что программа работает «правильно» с точки зрения её разработчиков, но люди в организации не могут с ней работать даже неважно по каким причинам, то не будет засчитана за правильную и работа программы. Что толку в работе программы по начислению зарплаты, если люди с ней не смогут сработать? Если программисты хотят получить деньги за свою часть работы, они должны быть уверены, что кто-то работает и с людьми, а сдаваться заказчику будет совместная система из обученных людей и настроенных программ (а также данных к этой программе, что может быть отдельной проблемой и может требовать отдельных исполнителей). Сдаваться будет начисленная зарплата, изготовленная качественная деталь — и дальше по цепочке работа оргзвена, ведущая к этим важным целевым результатам, а внутри этой работы оргзвена (подразделения, проектной группы) будет сдаваться софт.

Для обучения людей проводите примерно такие же рассуждения, что и про компьютерные программы. Учебные книги, видео, компьютерные курсы, а также руководства/регламенты/стандарты/«описания рабочих процессов» (например, наше руководство по системной инженерии) — это только документированные описания того поведения, которое хотелось бы получить после обучения. Поэтому целью обучения (в том числе обучения работать по методам, описанным в руководстве/регламенте/стандарте) будет мастерство выполнять работу согласно методу.

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

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

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

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

Что является целевой системой проекта строительства моста? Мост, конечно! Но для строительства моста нужно создать организацию проекта, которая проведёт его создание, потом провести работу этой организации сначала в части проектирования (обычно в городе, в проектном институте), затем в части стройки (несколько тысяч человек в чистом поле!), и только потом получить удовольствие от моста. Это всё цепочка создателей: создать создателя, потом создатель создаёт целевую систему. В общем случае речь идёт о разветвлённых графах создателей, где создатели — это узлы графа, а рёбра — направленные отношения создания и развития (изменение состояния) создателями других систем этого графа. Часто ли нам нужно думать о создателе создателя создателя? Да, часто. Легко представить какой-то проект создания софта в проекте строительства моста. Зачем существует этот проект, зачем нужна команда разработчиков софта? Чтобы создать и развивать софт. Зачем нужен весь этот софт? Чтобы создать и развивать (как минимум — поддерживать) мост. Зачем нужен весь этот мост? Чтобы поддерживать (менять состояние) транспортного потока. Если нам нужен транспортный поток через реку, то мы создадим мост, для чего создадим софт, для чего создадим команду программистов, и так далее (чтобы создать команду программистов тоже нужно, чтобы кто-то был этим озабочен, провёл все нужные работы).

Системное мышление требует отследить всю цепочку от транспортного потока через мост до используемого софта. Если не отследить, то софт оказывается не нужен — хотя разработчики очень хотят за него получить деньги, особенно за ненужные никому «фичи»/возможности этого софта. Если возможности софта не будут использованы, то они могут и не работать как надо, но деньги за них заплатят, если удастся утаить связь этих возможностей софта с реализацией целевого моста. И если окажется, что целевому мосту от этого софта с его возможностями ни холодно, ни жарко (это никак не ускорит его строительство или никак не повлияет на транспортный поток), то это будет означать, что софт можно этот и не писать, проектом этого софта не заморачиваться, деньги за него не платить. Системное мышление быстро проверит, не занимаетесь ли вы никому не нужной работой.

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

Вопросы на физичность отношения состава

Джон написал несколько примеров для руководства по системному мышлению, вы должны проверить их и отметить правильные.

+++ Пример отношения состава: «Документация состоит из трёх томов, каждый том состоит из трёх тетрадей». ### Да, всё в порядке: все молекулы тетрадей входят в число молекул томов, а все молекулы томов входят в число молекул документации. Осмысленные операции возможны и с документацией, и с томами, и с тетрадями, сшитыми в тома.

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

+++ В спектакле есть три акта, каждый из которых состоит из трёх явлений. ### Да, всё в порядке: спектакль — это 4D объект (из актёров, декораций, зрителей, развёрнутый в некотором промежутке времени, аналогичный разобранному в руководстве «танцевальному перформансу»), и три акта — это крупное деление спектакля на темпоральные (то есть во времени) части, отделяемые друг от друга антрактами (когда спектакль вообще не идёт, и все зрители в буфете, антракты не считаем входящими в спектакль), а явления — это тоже истинные физические части четырёхмерного акта, которые отличаются приходом («явление») или уходом какого-то персонажа пьесы. То есть это всё истинные части четырёхмерного физического объекта. То, что спектакля нет во время антрактов, ничего не означает. Между молекулами воды тоже есть расстояние, но это не мешает каплю воды считать одним объектом, воспринимать её как целый физический объект, хоть и состоящий из (взаимодействующих! Как-то связанных друг с другом!) разделённых некоторым пространством более мелких физических частей. Разбирать на части ни воду, ни спектакль не надо, их части выделяем вниманием!

+++ Крепление состоит из трёх отверстий с резьбой М3, разнесённых по треугольнику на 6 см друг от друга. ### Да, это «крепление» имеет чёткие координаты в пространстве, понятны операции как его делать, понятно, что с ним будут делать после изготовления. «Состоит из» тут отношение композиции, части «крепления» — отдельные отверстия с резьбой М3.

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

--- Люди клана Среднезубых состояли из воинов, торговцев и юристов, а воины в свою очередь состояли из лучников, кавалеристов и артиллеристов. ### Нет, тут описывается не деление клана Среднезубых как какого-то целого объекта на физические его части. Тут приводится классификация входящих в множество Среднезубых объектов-людей (типа классификации Линнея для животных), это не отношение состава (например, нельзя сказать, что «воины» — это какой-то целый объект с его особыми свойствами и поведением, как нельзя сказать, что «мыши»  — это какой-то целый объект среди «млекопитающих». Если говорить о таксоне/классификаторе, то это ментальный объект, а не физический).

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

Задания: системы в физическом мире

Выполните задания:

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