Описания
Но зачем нам нужны описания, ментальные/идеальные объекты?! Нас будут интересовать изо всех видов описаний главным образом:
- Символьные/знаковые/языковые описания в отличие от коннекционистских/нейросетевых. Нам нужна коллективная разработка, то есть возможность доступа нескольких агентов к одному описанию как для исправлений, так и для ознакомления. С****имвольные описания легко отчуждать (документирование)****, копировать и пересылать в ходе коллективной разработки. Описание, находящееся в нейросети агента, отчуждается трудно — там вместо «копирования, пересылки» работает «обучение», совсем другой механизм передачи описаний.
- Описания в рамках теоретической теории понятий (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-агенты), если они не кусаются, тоже будут всегда накормлены, независимо от результата их работы, даже если результаты работы оторваны от реальности, ничего в мире не меняют, просто кому-то поднимут настроение. Но иногда такие утопические работы приносят вред, даже если сами эти работы хорошо оплачиваются. Вред будет хотя бы от того, что будут потрачены впустую ресурсы, которые могли бы быть потрачены на что-то более полезное: не просто поднять кому-то настроение, но вылечить, накормить, согреть. В конечном итоге, если люди сидят голодные, холодные, больные и только и делают, что поднимают друг другу настроение, всё будет плохо. Так что избегайте отрыва от жизни, отрыва от физического мира, отрыва от реальности!
Это не означает, конечно, что в богатом мире довольно много людей не может перейти на предоставление «персональных сервисов» в так называемой «маникюрной экономике»[3]. В руководстве по методологии это будет подробней рассказано в разделе теории стратегирования. Но богатый мир — это когда какие-то люди с их инструментами достаточно произвели жилья, еды, медицинского оборудования и лекарств, средств связи и ещё много чего другого. Голодные люди потратят деньги на еду, на связь, а не на маникюр или коучинг. Голодные люди будут работать, а не говорить «я выгорел». Поэтому в конечном итоге смотрите, что в мире вы собираетесь менять своим проектом, какие ваши амбиции по сравнению с котёнком и его амбициями.
Как связаны понятия «объект в реальном мире» и «воплощение системы»? «Система» — это тип для объектов в реальном/физическом мире. Эти объекты характеризуются тем, что они как-то могут быть выделены из мира (граница системы, причём это граница в пространстве-времени — можно говорить о форме объекта в четырёхмерном мире). Всё, что снаружи от границы — среда/окружение/environment этой системы. Система и воплощение системы — это синонимы. Конечно, внутри системы можно выделить другие системы, они будут называться подсистемами. Конечно, можно выделить границей и какую-то систему, в котором внутри будет находиться система — она будет называться надсистема. Мы будем постепенно раскрывать понятие «система», добавляя и добавляя разные связи между ним и другими понятиями.
Если мы берём какой-то физический объект, то обычно у него уже есть тип из предметной области (тип из мета-модели/middle-ontology), который берётся из учебника предметной области/domain. Например, борт #45667 классифицируется в предметной области как «самолёт», записываем «борт #45667»::самолёт. Само понятие «борт #45667» — это будет понятие модели, соответствующее экземпляру «самолёта» в физическом мире ((вы же не путаете строчку символов ««борт #45667»::самолёт» с реальным физическим самолётом? Строчки не могут летать!). Мы можем записать «самолёт» как тип, а в системном мышлении дополнительно можем записать «самолёт::система», добавив к типу «самолёт» из мета-модели предметной области авиации тип «система» из системного мышления как мета-мета-модели. Значком :: мы будем показывать тип, который был использован в рассуждении (яблоко::фрукт), то есть показывать отношение классификации (принадлежности к множеству). Как это делать, разъясняется в руководстве по рациональной работе, но в системном мышлении мы добавляем, что «система» и другие понятия системного мышления — это и есть типы, которые вы будете присваивать чаще всего. Мир вы будете видеть как набор не просто объектов, но объектов::система (объектов типа «система»).
Можем записать или даже сказать просто «самолёт», без указания типа — при этом чётко отдавать себе отчёт, что это мы просто опустили понятие типа «система» из мета-мета-модели. Так и происходит связь системного мышления и жизни, обеспечивается адекватность его приложения к объектам из рабочих проектов: мы удерживаем в голове (не обязательно даже явно указывать!) присваиваемые объектам предметной области (определяются типами мета-модели из учебника предметной области) типы трансдисциплин интеллект-стека фундаментальных методов мышления (физики, семантики, теории понятий, онтологии и т.д.) — всё, что нужно для системного мышления, в данном случае понятие «воплощение системы» как присваиваемый тип. А сами объекты, которым присваиваются типы — они будут в физическом мире, «в жизни».
Возьмём Китай. В системном мышлении это будет «Китай::система», в учебнике какой-то предметной области (например, геополитики) — «Китай::страна». Мы можем записать «Китай::страна::воплощение системы», чтобы показать полную цепочку мета-моделирования. Но можем записать и просто «Китай», понимая, что это «страна» и понимая, что это «система» (удерживая эти типы в голове! Необязательно писать! Но обязательно понимать, какого типа был упомянут «Китай»!). Важно, что вы всегда «на автомате» должны удерживать во внимании три согласованных между собой объекта:
- объект-из-жизни (иногда его ещё нужно найти!), то есть какую-то область пространства-времени в физическом мире, («яблоко в жизни»)****. Это модель, описание реального объекта.
- тип объекта из дисциплины**/теорииметода работы в** этой предметной области **(«пища», или «счётный объект»—** если яблоки используются вместо счётных палочек, например, в детском саду**),** это мета-модель, модель предметной области, которую узнаёте из материалов каких-то** прикладных курсах и прикладного/профессионального развития.**
- тип объекта из фундаментальных транс****дисциплин (например, «система», «физическое тело») методов мышления интеллект-стека**.** Это мета-мета-модель, изучается при получении образования, в ходе рабочего развития (в том числе освоения наставлений наших руководств).
И на выходе у вас «яблоко из жизни», которое может быть или пищей, или счётным объектом (пищу едят, счётные объекты в детском саду считают), но ещё вы можете присвоить яблоку понятия типов «система» (и, например, обсудить, как выращивать яблоки) и «физическое тело» (если надо определить, по какой траектории полетит яблоко, если его бросить).
Эта работа с типами — общий принцип для всего мышления, а не только системного. Вы смотрите на мир, и уже много об этом мире знаете — это вам даёт интеллект, который снабжает вас набором типов из дисциплин методов мышления интеллект-стека. Эти типы сосредотачивают внимание на важном**, даже если вы впервые попали в какую-то ситуацию. Вы не можете сказать «я понятия не имею, что я вижу». Вы, если знакомы с системным мышлением, можете сказать «я вижу системы»**—** и из этого уже многое следует. Скажем, системы имеют свою функцию—** какое-то назначение во внешнем мире. И вы сразу уже можете интересоваться функцией тех объектов, которые вы видите, а не тратить время на определение того, чем же там надо было бы поинтересоваться по поводу полностью незнакомых объектов.
Ищите всегда воплощение системы первым делом, системное мышление — прежде всего про физический мир и изменения в нём, хотя и имеет дело с описаниями. Но описания ничто, а вот описанное ими — всё. Все описания делаются только ради того, чтобы менять описанное в физическом мире**,** их может быть много, но сами по себе они никому не нужны**, нужны только в связи с тем,** что они в конечном итоге описывают какую-то систему в физическом мире**!**