Мульти-модель. Мега-модель.
Само системное мышление с системным моделированием как обсуждением состава моделей в системной мульти-модели трансдисциплинарно/фундаментально, оно работает с монопредметными прикладными моделями, собирая эти модели вместе. Для этого задействуется интеллект-стек. Скажем, какая-нибудь электротехника::«метод инженерии систем, использующих электрические цепи» (электротехника ещё и задействует множество методов описания, заимствованных из физики) расскажет, как делать функциональные/принципиальные схемы электрических цепей в системах. Но системное мышление скажет, что функциональная модель в «системном описании»::мульти-модель обязана быть. Конечно, может существовать мульти-модель и без функциональной модели системы в её составе (в том числе без функциональной модели электрических цепей, если в системе они есть), но тогда это уже не будет системной моделью. И так со всеми основными видами описаний. В мульти-модели кроме основных может быть множество описаний, но в системной модели:
- Системные описания даются многомасштабные, то есть на каждом системном уровне (иерархия по отношению композиции), это принципиально. Описывается окружение, система, подсистемы (и это рассмотрение идёт на несколько уровней вверх и вниз от границы нашей/рассматриваемой системы, в том числе целевой системы)
- Обязательно включают описание функциональное, конструктивное, размещение, стоимостное (в том числе гибридные описания: концепция использования, концепция системы)
- Обязательно включают описание систем создателей в их графе (как минимум на одно отношение создания).
- Включают какое-то описание общего метода создания и развития (учитывают то, как происходит эволюционирование системы во множестве её «поколений», учёт «непрерывного всего»).
Не знакомые с системным подходом люди с трудом воспринимают идею множественности моделей, описывающих сложную систему. Обычно они требуют в мульти-модели указать «главную модель», которая является «правильной» по отношению к другим «вторичным» или «вспомогательным» моделям — но в системном мышлении нет «главной модели», для каждой проектной роли просто даётся её набор моделей для ответа на вопросы её ролевых предметов интереса. Нет «главной модели», нужны все модели, каждая в своей онтике/мета-модели/meta-model/framework. Хотя «главная модель» (определяющая набор всех этих моделей и то, что вообще должно моделироваться) таки есть, но это не модель и её мета-модель, но мета-мета-модель. При этом помним, что модели чаще всего задаются на формальном языке, мета-модель тоже обычно имеет формальное выражение (с определениями «как в математике»), а вот мета-мета-модель намеренно избегает определений, остаётся довольно общей (как говорит John Sowa, «намеренно недоспецифицированной»/underspecified, чтобы её типы классифицировали самые разные мета-модели). Понятия мета-мета-модели задаются их употреблением в самых разных контекстах, обычно в рамках изложения текстов на естественном языке — и ровно это и делаем мы в нашем руководстве по системному мышлению и других руководствах программы рабочего развития инженеров-менеджеров.
Если присмотреться, то и для формально определённых моделей в математике есть некоторое количество текста на естественном языке, задающего тип и примеры использования понятий мета-модели, и вот этот текст «пояснений и комментариев» обычно и задаёт фрагмент использованных для определения/definition мета-модели понятий мета-мета-модель/upper ontology (а в самых абстрактных случаях — мета-мета-мета-модель/foundational ontology).
Системное моделирование также должно быть «многомасштабным», обязательно выполнено на нескольких системных уровнях: модели нужны не только для целевой системы, но ещё и для надсистемы, и для подсистем. В системном мышлении обсуждается появление новых свойств на каждом уровне. Проявление синергии — это резкое изменение старых свойств, у которых резко меняются их значения — скажем, «мощность 100 Вт» вдруг станет «мощностью 1500 Вт», но это всё та же мощность, старое свойство. А проявление эмерджентности — это новые свойства. Скажем, принципиальной схемы резистора, конденсатора, транзистора обычно не делают, там нечего моделировать (но могут посчитать сопротивление и ёмкость, исходя из их материалов и выбранной конструкции), но если собрать их некоторое количество, то получится усилитель — и у него новые свойства, уже усилителя, и для их описания нужны новые характеристики (например, коэффициент усиления, коэффициент нелинейных искажений, к подсистемам усилителя их применить нельзя). В силу эмерджентности нужны будут разные модели::описания на каждом системном уровне, для усилителя уже уместна принципиальная схема и какие-то расчёты по оптимизации выбора его комплектующих. Это нужно, чтобы согласовать интересы пользователей усилителя, разработчиков усилителя, закупщиков комплектующих и самых разных других проектных ролей. Модели для разных системных уровней обычно сильно различаются, даже если это «функциональные модели», или «конструктивные модели», или какие-то гибриды. Модели кирпича, модели стены и модели здания — это совсем разные модели.
Модели специфичны для проектных ролей каждого системного уровня, и если выбрать неверный системный уровень, то можно скатиться к редукционизму или холизму, а это ошибка. Редукционизм — это пробовать объяснить сложную систему взаимодействием не её подсистем на ближайшем системном уровне, а каких-то частей системы на существенно более низких уровнях, даже если в этих неадекватно выбранных уровнях выделить что-то на этих уровнях важное и опустить при описании всё на этих уровнях неважное. Да, человек состоит из атомов, это правда — но это неправильный системный уровень для объяснения того, чем человек отличается от роботов и кошек, неправильно моделировать человека как набор атомов, если хочется, например, его научить арифметике. Если захочется отремонтировать поломанный экскаватор, то моделирование экскаватора из атомов, или даже молекул для ведения этих ремонтных работ будет крайне неверным решением. То же самое относится к холизму: объяснению того, что в системах всё зависит исключительно от их надсистем. Если это принять к сведению, то поломка унитаза будет быстро приводиться к зависимости от макроэкономической ситуации в стране.
Нет, модели должны быть удобны для деятельности на каждом системном уровне как уровне масштаба систем, они должны позволять проводить объяснения (обсуждать причины и следствия происходящего в предметной области интереса), а не абстрактно «научно правильными».
Повторимся: системное мышление — это не чистая математика, не чистая логика, его модели и рассуждения с их использованием определяются интересами в выполнении работ по каким-то методам, опора тут на методологию как дисциплину интеллект-стека. Если какие-то модели и рассуждения по ним формально правильны, но не помогают что-то сделать в физическом мире, то они бесполезны, их не нужно делать.
Для создателей и их работ, которые они ведут по каким-то методам, тоже нужны модели. Множественность описаний означает множественность моделирования. Удерживать внимание проектных ролей на главном (определяемом как типы мета-модели, в свою очередь определяемые как типы мета-мета-модели), и не привлекать внимание к неглавному (то есть не отображать в модели случайные объекты произвольно выбранных типов — скажем, цвет корпуса при прочностном его расчёте, причёску человека при проектировании метода его обучения какому-то мастерству) нужно сразу для многих методов работы в проекте. Для этого и служит культура моделирования (культура — метод, признаваемый многими): отражение главного, типы которого берутся из культуры (культура — все знания человечества). Культура, конечно, помогает, если кто-то с этим уже работал до вас. Но вы можете высказать догадки о мета-модели (или даже необходимой мета-мета-модели) в ходе исследований, если вы первый, кто разбирается в новой предметной области и пытается понять, на каких типах объектов в ней удаётся получить объяснения, как связаны в этой предметной области причины и следствия, какие методы работы могут быть в работе с этими предметами метода и требуемыми для этих предметов состояниями.
Как узнать, что должно в проекте быть важным? Мета-моделировать, двигаться от модели к мета-модели и затем мета-мета-модели (важное в построении мета-модели тоже не произвольно, а задаётся типами мета-мета-модели).
Один из критериев хорошей модели — это удобство обсуждения причинно-следственных связей в ситуации, а для этого удобство проведения контрфактических[1] рассуждений с объектами этой ситуации. Типы из мета-модели поэтому должны быть не любыми, а пригодными для таких рассуждений, этим вопросом пригодности занимается метод создания объяснений (входит в состав интеллект-стека). Нахождением таких типов занимается метод ведения исследований, это тоже один из методов мышления, входящих в интеллект-стек.
Получается, что системное мышление, которое занимается главным образом составлением системных описаний (системным моделированием)****, задействует довольно много методов из****состава интеллект-стека, и для хорошего владения системным мышлением нужно быть уже достаточно образованным человеком. Именно поэтому системное мышление у людей встречается не так часто: нужно учиться не только ему, но и всем методам мышления из состава интеллект-стека**.** Более того: системное мышление как карта местности, она не скажет «куда идти»****— она даст описание местности, в том числе укажет**,** где горы, а где болота, где плодородные долины, где города. Чтобы куда-то пойти по этой карте**,** нужно будет задействовать рациональность: предложить разные методы поведения в текущей ситуации, прокритиковать их, выбрать какой-то лучший (часто говорят «наименее плохой», ибо «лучший метод» недостижим в реальности), запланировать работы по этому методу, а потом перейти к действиям: найти ресурсы и выполнить работы. Подробней об этом в руководствах по интеллект стеку и инженерии личности, а наставления по моделированию даются в руководстве по рациональной работе. В нашем руководстве только рассказывается, как заниматься не любым моделированием, а моделированием «систем» как правильно выбранных важных объектов окружающего мира, то есть заниматься «системным описанием/моделированием»/«описанием/моделированием систем»/«systemsmodeling**»/«systemicmodeling****»**. Напомним, это такое мульти-моделирование, при котором:
- Отмоделировано несколько масштабов (системных уровней), на каждом уровне новые свойства (учтена эмерджентность).
- Отмоделированы обязательные аспекты: функциональный, конструктивный, размещения, стоимостный.
- Отмоделированы создатели.
- Отмоделирован процесс создания и развития целевой системы её создателями.
Системное моделирование нужно для коллективного мышления в проекте: все эти модели нужны для того, чтобы проектные роли договорились между собой по поводу целевой системы и всего того, что нужно для её создания и развития (включая, конечно, эксплуатацию всех версий системы).
Проектных ролей много, и что модель для одной роли — информационный шум и перегрузка «думалки» играющего эту роль агента (вычислителя с конечными ресурсами: будь то мозг, мозг с компьютером или даже просто компьютер) для другой роли, и наоборот. Возникает соблазн моделировать меньше, избавиться от лишней работы, но этого нельзя делать. Нужно моделировать (и документировать модели) для удовлетворения всех интересов всех причастных проектных ролей: ошибки в описании системы дорогостоящи, а эти ошибки обычно выявляются как расхождения**/коллизии/**collision между различными моделями системы. Вы узнаете о проблемах (проблема — когда никто не знает, что делать, то есть какой метод работы для каких объектов метода применить, чтобы перевести их в желаемые состояния), ибо проектные роли предъявят претензии к системе (в физическом мире), что наверняка отразится и как претензии к моделям, а иногда и претензии к мета-моделям, а изредка — и претензии к мета-мета-модели. Например, наставления нашего руководства вполне могут устареть, скажем, поменяться состав обязательных аспектов моделирования для системной модели.
Ошибки/коллизии****в системной модели (несоответствия между моделями в мульти-модели, несоответствие типов объектов модели типам мета-модели, несоответствие типов мета-модели необходимым типам мета-мета-модели, несоответствие ожидаемой степени формальности модели и предъявленной в модели, и т.д.)желательно выявлять и исправлять при описании и документировании системы перед изготовлением, а не после изготовления, и уж тем более не при эксплуатации системы. Семь раз опиши и покритикуй (и не только найди коллизии, но и обнаружь другие ошибки— **например, опечатки. Впрочем, они всё одно приведут к каким-то коллизиям)**, семь раз исправь после этого найденные ошибки в системной мульти-модели (в том числе коллизии между отдельными моделями в мульти-модели), затем один раз изготовь по системной мульти-модели как проекту/design и далее ещё и проверь, соответствует ли изготовленная система её системной мульти-модели! И продолжай это делать постоянно, со всеми версиями системы, в том числе не только во время создания, но и во время эксплуатации.
Захватывающая время эксплуатации мульти-модель обычно называется «цифровой двойник»/«digital twin». Цифровой двойник в том числе может включать и мульти-модель/design, используемую при проектировании и изготовлении версий системы, но главное — это мульти-модель времени эксплуатации, причём эта мульти-модель задействуется для автоматизированного принятия операторских решений по эксплуатации (настройки параметров работы, индикация желательности превентивного ремонта ввиду износа и т.д.).
Итого: в системном описании моделей должно быть много (системная модель— это мульти-модель), ибо с системами связано множество разных методов работы**, выполняемых самыми разными проектными ролями, реализующими самые разные намерения, проистекающие** из их предпочтений в самых разных предметах **интереса****.** А чтобы внимание к важным описаниям не уплывало в ходе согласования действий агентов, выполняющих разные проектные роли, мульти-модели нужно документировать в виде, позволяющем ими пользоваться всем заинтересованным ролям**.**
Это иногда называют «****управление информацией»: все модели, которые кому-то нужны, должны быть доступны и изменения в них должны доводиться до всех «заинтересованных сторон»/ролей/stakeholders.
Кроме моделей в составе системной мульти-модели надо в явном виде иметь ещё и мета-модели этих моделей (метафора тут — для набора карт нам нужно ещё иметь и набор легенд для этих карт). Для разных наборов данных, чтобы их прочесть, нужно иметь их модели данных. Например, для базы данных сведений о концертах в Париже осенью 2029 года нам нужна ещё и модель данных для таких сведений, а не только сами сведения: надо знать, что там будет в сведениях (скажем, только название концерта и его время, или ещё и вместимость зала, цена билета, адрес зала, чат для справок). Модель данных — это мета-модель для сведений о концертах, которые — модель самих концертов. Будем называть мульти-модель в сумме с определяющими её мета-моделями — мега-моделью.
Если вы встретили лист электронной таблицы, на которой нет заголовка и приведены две небольших таблички, для которых тоже нет заголовков ни самих табличек, ни их колонок — вот это и есть мульти-модель, каждая табличка там — модель. Если заголовки есть — то это мега-модель. Обычно мета-мета-модель в мега-модель не попадает (помним, что мета-модель обычно хорошо формализуется, а вот мета-мета-модель обычно выражается текстом), но формальная (например, в виде базы данных со строгой типизацией её данных) мега-модель может быть дополнена каким-то описанием того, откуда и как брали в неё типы мета-модели (как создавалась модель данных, каких типов там данные). Это описание мета-мета-модели тоже можно считать частью мега-модели.
Если наш ролевой предмет интереса географический, то он оформляется географическими описаниями — картами. Для географического описания/моделирования холма в соседней деревне нам потребуются самые разные модели (карты), составляющие целый атлас (мульти-модель), но кроме этого нам потребуется знание, какие виды моделей должны быть в атласе (например, физическая карта, политическая/административная карта, карта полезных ископаемых, карта плотности населения, карта флоры, карта фауны, карта почв и т.д.), задаваемые мета-моделями (легендами соответствующих видов карт, которые разрабатываются исследователями-географами и обычно доступны из культуры, их можно «нагуглить»).
Если нам потребуется отмоделировать холм около другой деревни, то у нас будет другая мульти-модель при сохранении всех тех же мета-моделей. Рассматривать же и обсуждать в целом можно будет только мега-модель: без обсуждения видов карт, соглашения об условных обозначениях на этих картах и прочего, относящегося к мета-моделированию, обсуждать карты нельзя.
Если вы не договорились, на каком языке пишете проектную документацию (китайском, суахили или румынском), то вам может понадобиться её переписывать — но перед перепиской всё равно придётся договориться о языке.
Если вы не договорились, в каком формате вы предоставляете отчёт о прибылях и убытках, то вам может понадобиться его переписывать, но перед перепиской всё равно нужно будет договориться о мета-модели из финансового метода описания — какой же формат отчёта о прибылях и убытках нужно предоставить. Нельзя моделировать без знания мета-модели и договорённости о том, что она сможет отразить предмет интереса какой-то проектной роли. Не знаете о существовании типов и присвоении типов (не имеете образования, например), не нашли нужный учебник и выдумали мета-модель «из головы», «на коленке», не документировали мета-модель — и дальше будут бесконечные провалы из-за невозможности объяснений по поводу значений важных характеристик, отражённых как объекты плохих или вообще неизвестных/непонятных типов. Повторим: «-- Петька, приборы! — Восемь! — А чего восемь?! — А чего приборы?!», — эта ситуация и есть работа с моделями без мета-моделирования, желательно многоуровневого. Вот так и выглядит мульти-модель (например, файл с данными, структура которого известна читающей программе, но в самом файле не описана — данные есть, а вот «модели данных»/мета-модели нет). Но даже если в этом файле будут прямо внутри приведены не только данные по описываемому объекту (модель, например, данные о сепульке, 8), но и данные про это описание (мета-модель, например, не просто 8, а что эта мощность в ваттах и дополнительно указано, что эта мощность относится к системе «сепулька»), то возникнет вопрос о том, откуда взялась сама эта модель данных — и надо будет вспомнить о мета-мета-модели, например, в варианте нашего руководства по системному мышлению. Мы уже неявно это сделали, когда кроме мощности в файле указали, что эта мощность относится к системе «сепулька», мощность тем самым не существует сама по себе, это характеристика системы, и хорошо бы указать, какой именно (про нюансы — вид/тип системы мы указываем, или экземпляр какого-то вида, мы тут не говорим, но и с этим придётся в моделировании разобраться).
При обучении моделированию учат не какой-то модели (модель будет каждый раз создаваться новая для каждой новой системы!), учат набору типов мета-модели, объекты для которых нужно будет уметь находить в предметной области какого-то интереса. Эта мета-модель (набор типов) будет одна и та же для самых разных моделей каких-то конкретных экземпляров объектов моделирования. Но для каждого экземпляра объекта моделирования надо будет выполнить моделирование (можно считать это вариантом «измерения» объекта). Не отмоделировали (не нашли мета-модели, например, про «сепульку» не узнали её мощность) — не договорились по поводу чьего-нибудь интереса, проморгали что-то важное в проекте.
Учат методам моделирования и мета-моделирования — они будут одни и те же для разных систем, они будут помогать учитывать интересы одних и тех же проектных ролей, хотя играть эти проектные роли будут разные агенты (люди и не только) в разных проектах — знание мета-моделей помогает переносить из проекта в проект опыт о том, что является в системе важным и что удовлетворяет интересам проектных ролей. Вы один раз учитесь 3D или даже 4D-моделированию инженерных систем, один раз учитесь моделированию мастерства, один раз учитесь моделированию чего угодно, а затем используете это мастерство моделирования во множестве самых разных проектов для самых разных экземпляров систем из той же предметной области.
Если вы даёте кому-то описание системы (документированное! Устно**—** это не «давать», оно легко может быть не «взято»)****, то вы обязаны также сообщить прямо в документе**, как вы получили это описание****, указать использованный метод** описания**,** в котором задать типы важных объектов, отражённых в модели (задать мета-модель, а то и дополнительно указать мета-мета-модель)****. Это можно делать в разных формах: предлагать модель данных, аннотировать типами (например, давая заголовки таблицам и колонкам таблиц или указывая типы мета-модели и даже мета-мета-модели прямо в тексте рядом с объектами модели). Вы должны понимать, что это передаваемое описание какого-то объекта**—** результат моделирования, то есть оно должно содержать только важные факты**,** при этом желательно**—** все важные факты для той проектной роли,которой вы даёте это описание, и не должно содержать ничего другого, что будет для это****й проектной роли информационным шумом. Если вы не можете сказать, каким методом вы описали систему, если вы не знаете, о****тражает ли этот метод предмет интересапроектной роли**, вы делаете ошибку****, эта ошибка вам дорого обойдётся****.**