Описания
Но зачем нам нужны описания, ментальные/идеальные объекты?! Нас будут интересовать изо всех видов описаний главным образом:
- Символьные/знаковые/языковые описания в отличие от коннекционистских/нейросетевых. Нам нужна коллективная разработка, то есть возможность доступа нескольких агентов к одному описанию как для исправлений, так и для ознакомления. Символьные описания легко отчуждать (документирование), копировать и пересылать в ходе коллективной разработки. Описание, находящееся в нейросети агента, отчуждается трудно --- там вместо «копирования, пересылки» работает «обучение», совсем другой механизм передачи описаний.
- Описания в рамках теоретической теории понятий (theory theory, объекты и отношения, работа медленного мышления S2), а не прототипной теории понятий (prototype theory, работа с метафорами и аналогиями, concept blending, работа быстрого мышления S1). Формальность описания нужна для облегчения проверки.
Документировать описания нам нужно для (коллективно устроенного) мышления: они помогают удерживать внимание на важных объектах в физическом мире (документ/внешняя память удерживает внимание разных агентов-создателей систем на тех объектах, которые мы в нём описали). В том числе эти документированные описания можно использовать и для переноса опыта из одного проекта по созданию систем в другие проекты, если они описывают не экземпляры системы, а их тип (множество какого-то вида/сорта систем). Если вы сделали информационную модель табуретки, то это будет информационная модель не одной табуретки, вы можете изготовить десяток табуреток по этой информационной модели --- и использовать эти десять табуреток в десяти разных проектах.
Когда говорят «описание», то чаще всего имеют в виду «документированное описание» и даже «документ с описанием». Но остерегайтесь: иногда «описание» вовсе не означает того, что оно документировано, иногда описание есть (понятие, ментальный объект), а документа с этим описанием (физический объект) --- нет. Когда слышите «описание», определяйте по контексту, что имеется в виду: собственно описание, или документ с описанием. В нашем курсе мы тоже будем использовать «описание», когда речь будет идти о «документе с описанием». Но вы должны чётко различать описание (ментальный объект), документ с описанием (физический объект, обычно со знаковым описанием), описываемую систему (иногда через цепочку описаний описаний, но всё-таки в конечном итоге --- система, то есть выделенный из мирового пространства-времени какой-то границей четырёхмерный кусок).
Мышление в создании/construction каких-то новых систем, в познании/learn и последующем изменении каких-то уже существующих/brownfield систем обычно происходит не для отдельных экземпляров систем, а сразу для множеств систем, то есть для типов систем. Конечно, можно представить ситуацию, когда описывается конкретный экземпляр системы в конкретном экземпляре окружения в конкретное время (например, в записи базы данных поломок насосов на какой-то подстанции или записи в базе данных землетрясений, или записи в истории болезни какого-то пациента, или события в летописи какой-то страны), но это обычно записи времени эксплуатации системы, а не времени разработки. Разработка (замысливание, проектирование, планирование изготовления) всегда ведётся не для конкретных экземпляров систем, а «в общем случае»,то есть для множества/типа/вида/класса подобных систем, даже если речь идёт о создании одной системы (скажем, Эйфелевой башни или новой страны).
Множество/класс/тип/вид/сорт --- это математический/ментальный/понятийный объект. В математике множество из одного объекта не эквивалентно этому одному объекту: свойства множества отличаются от свойств самого объекта в этом множестве.
В системном мышлении то же самое: нас интересуют отдельные конкретные системы, воплощённые в нашем физическом мире, но моделируем их с задействованием присвоения типов/классов. Мышление ухватывает что-то общее во всех ситуациях, мышление происходит не для конкретных систем, о которых мы знаем разные факты. Мышление происходит чаще всего для классов/типов/множеств/видов/сортов систем/воплощений_систем/экземпляров_систем. И, конечно, ментальные объекты (множества, типы) легко изменять: для изменения абстрактных объектов не нужно тратить энергию на перетаскивание вещества воплощения системы, нужно тратить энергию только для изменения вещества для воплощения знаков, это неизмеримо меньшее количество.
Информационные технологии работают с описаниями, так что если вы имеете дело с какими-то компьютерами и компьютерными сетями, то остерегайтесь перепутать документированное описание системы (информационную модель на каком-то материальном носителе) и воплощение системы. Вы легко сможете сообразить, что фотография человека --- это не человек, на ней изображённый. Чуть трудней будет сообразить, что табличка с данными температуры ракетного двигателя на листочке бумаги --- это описание ракетного двигателя, а сам листочек бумаги тут не важен. Но вот если речь идёт о небольшой базе данных, в которой описывается поведение ракетного двигателя в серии испытаний --- вот тут наступает ступор, ибо сама база данных представляется её разработчику какой-то системой, которая будет казаться целью вашей работы, целевой системой, воплощением системы, материальным/физическим объектом, итогом работы. Нет, база данных тут --- документированное описание ракетного двигателя, просто в менее привычной форме, документированное не на бумаге. Даже если с этой базой данных рассмотреть программу управления ракетного двигателя и назвать это цифровым двойником/digitaltwin[1], то интересовать вас всё-таки будет поведение физического двойника, то есть сам ракетный двигатель. И при разработке такой базы данных и всех программ вокруг неё надо в первую очередь думать именно о двигателе::физический двойник::подсистема! Если не удерживать в голове разработчика этот двигатель, то база данных легко может оторваться своим содержимым от описания реального физического мира --- и оказаться бесполезной, а то и вредной. Система тут будет состоять из двух подсистем --- цифрового двойника::софт (всё-таки взятый с учётом аппаратуры, софт без вычислителя не бывает) как одна подсистема и физический двойник как другая подсистема. Если вы не понимаете, какую систему вы делаете и заняты только подсистемой, у вас будут огромные проблемы в проекте: когда две подсистемы начнут работать вместе, работы системы не получится --- и денег не будет (а если их успели выплатить, то деньги даже могут отобрать! Ничего же не работает, за что платить?!).
Умение понять, какая система описывается в физической реальности, если вам показали описание в виде каких-то структур данных, документированных в компьютере --- это ключевое умение для всех, кто встречается с современными информационными технологиями. Если у вас CRM (customer relationship management[2]) система, то её базы данных подробно описывают клиентуру как целую систему в физическом мире, а части клиентуры --- это отдельные клиенты (возможно, сгруппированные в какие-то сегменты, но это сейчас неважно, пока нам важно разобраться, что клиентура --- это система в реальном/физическом мире, а компьютерная 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»::самолёт» с реальным физическим самолётом? Строчки не могут летать!). Мы можем записать «самолёт» как тип, а в системном мышлении дополнительно можем записать «самолёт::система», добавив к типу «самолёт» из мета-модели предметной области авиации тип «система» из системного мышления как мета-мета-модели. Значком :: мы будем показывать тип, который был использован в рассуждении (яблоко::фрукт), то есть показывать отношение классификации (принадлежности к множеству). Это подробно проходилось в курсе «Моделирование и собранность», но в системном мышлении мы добавляем, что «система» и другие понятия системного мышления --- это и есть типы, которые вы будете присваивать чаще всего. Мир вы будете видеть как набор не просто объектов, но объектов::система (объектов типа «система»).
Можем записать или даже сказать просто «самолёт», без указания типа --- при этом чётко отдавать себе отчёт, что это мы просто опустили понятие типа «система» из мета-мета-модели. Так и происходит связь системного мышления и жизни, обеспечивается адекватность его приложения к объектам из рабочих проектов: мы удерживаем в голове (не обязательно даже явно указывать!) присваиваемые объектам предметной области (определяются типами мета-модели из учебника предметной области) типы из курсов фундаментальных трансдисциплин методов мышления интеллект-стека (физики, семантики, теории понятий, онтологии и т.д.) --- всё, что нужно для системного мышления, в данном случае понятие «воплощение системы» как присваиваемый тип. А сами объекты, которым присваиваются типы --- они будут в физическом мире, «в жизни».
Возьмём Китай. В системном мышлении это будет «Китай::система», в учебнике какой-то предметной области (например, геополитики) --- «Китай::страна». Мы можем записать «Китай::страна::воплощение системы», чтобы показать полную цепочку мета-моделирования. Но можем записать и просто «Китай», понимая, что это «страна» и понимая, что это «система» (удерживая эти типы в голове! Необязательно писать! Но обязательно понимать, какого типа был упомянут «Китай»!). Важно, что вы всегда«на автомате» должны удерживать во внимании три согласованных между собой объекта:
- объект-из-жизни (иногда его ещё нужно найти!), то есть какую-то область пространства-времени в физическом мире,(«яблоко в жизни»). Это модель, описание реального объекта.
- тип объекта из дисциплины/теории метода работы в этой предметной области («пища», или «счётный объект» --- если яблоки используются вместо счётных палочек, например, в детском саду), это мета-модель, модель предметной области. Даёт обучение на каких-то прикладных курсах.
- тип объекта из фундаментальных трансдисциплин(например, «система», «физическое тело») методов мышления интеллект-стека. Это мета-мета-модель, изучается образованием.
И на выходе у вас «яблоко из жизни», которое может быть или пищей, или счётным объектом (пищу едят, счётные объекты в детском саду считают), но ещё вы можете присвоить яблоку понятия типов «система» (и, например, обсудить, как выращивать яблоки) и «физическое тело» (если надо определить, по какой траектории полетит яблоко, если его бросить).
Эта работа с типами --- общий принцип для всего мышления, а не только системного. Вы смотрите на мир, и уже много об этом мире знаете --- это вам даёт интеллект, который снабжает вас набором типов из дисциплин методов мышления интеллект-стека. Эти типы сосредотачивают внимание на важном, даже если вы впервые попали в какую-то ситуацию. Вы не можете сказать «я понятия не имею, что я вижу». Вы, если знакомы с системным мышлением, можете сказать «я вижу системы» --- и из этого уже многое следует. Скажем, системы имеют свою функцию --- какое-то назначение во внешнем мире. И вы сразу уже можете интересоваться функцией тех объектов, которые вы видите, а не тратить время на определение того, чем же там надо было бы поинтересоваться по поводу полностью незнакомых объектов.
Ищите всегда воплощение системы первым делом, системное мышление --- прежде всего про физический мир и изменения в нём, хотя и имеет дело с описаниями. Но описания ничто, а вот описанное ими --- всё. Все описания делаются только ради того, чтобы менять описанное в физическом мире, их может быть много, но сами по себе они никому не нужны, нужны только в связи с тем, что они в конечном итоге описывают какую-то систему в физическом мире!