Системное мышление 2024. Том 2

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

Дальше вы активно ищете в жизни объекты этих типов, ибо уже имеете ожидания по поводу этих объектов. Активно – это расспрашиваете о состоянии этих объектов, придумываете и создаёте такие объекты, если убеждаетесь, что их нет, проверяете догадки рациональным рассуждением и даже экспериментами.

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

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

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

• Эта работа активна/деятельна: камеру сначала надо навести на какой-то кусок мира, который собираемся рассмотреть, затем её настроить на нужный зум. Это изменение состояния мира ещё перед замером: направить камеру на объект! Измерение надо готовить, только потом измерять! Чтобы описать то, что за углом, надо подойти к этому углу и заглянуть за угол, сделать активное действие. И там надо понимать, высматриваешь силуэт большой горы или песчинку на этой горе, настроить фокус: это задействование знаний, мета-мета-модели.

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

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

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

Вот пример рассмотрения системных уровней для мультимодальной транспортной системы51:

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

В одной из подсистем транспортной системы можно выбрать для обсуждения железнодорожную систему – поезда, энергетику железной дороги, управление движением поездов и т. п. Если взять одну из подсистем железной дороги – систему железнодорожной станции, то в ней можно дальше рассмотреть её собственные подсистемы – систему посадки пассажиров, информационную вокзальную систему, систему питания пассажиров (catering), систему продажи билетов. Часть этой системы продажи билетов – её подсистема автоматов по продаже билетов. Эти автоматы тоже каждый могут быть рассмотрены как отдельные системы. Винты, которые крепят печатную плату контроллера к корпусу этого автомата – это тоже системы. И даже в винтах можно найти разные части – головку с шлицами под отвёртки разной формы, резьбу.

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

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

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

Боинг 747—8 состоит из 6 миллионов независимых видов деталей (входят в состав целевой системы), которые производили полмиллиона человек на 5400 фабриках (системы создания), за один год заказывалось (последний самолёт выпущен в декабре 2022) 783 миллиона частей самолёта (входят в состав целевой системы)53:

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

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

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

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

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

Задания по системным уровням

Поставьте отметку о выполнении:

1. Написан пост с моделированием системных уровней мастерства вашего хобби (за основу поста взято описание из разделов с примером социальных танцев).

2. Написан пост с моделированием системных уровней вашего основного рабочего мастерства, (за основу поста взято описание из разделов с примером социальных танцев).

8. Графы создания

Отношения создания

Простейший граф создания метафорически (то есть весьма вольно) можно проиллюстрировать диаграммой:

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

Целевая система проявляет свои внешние свойства в надсистему «в ходе»/«во время» её работы/operations, это обозначено словами «феном55 тут». Слова run-time часто используются в программной инженерии, чтобы обозначать время функционирования/работы/эксплуатации готовой системы. Но мы обозначили на диаграмме его другим, не менее употребимым словом – Ops-time, время работы операторов системы, когда система в рабочем состоянии, функционирует.

Целевые системы создаются и развиваются не сами (они саморазвиваться обычно не умеют, ибо не совсем живые, а в классической инженерии чаще совсем неживые), а создателями, выполняющими методы визионерства, разработки, архитектуры, DevOps/«инженерии внутренней платформы создания» и т. д. Системы создания включают в себя агентов с их инструментами. Агенты в узком смысле (автономные интеллектуальные вменяемые агенты) изображены кружочками с «лицами», а их явно неживое оборудование (от отвёртки до датацентра) – кружочками без лиц, организации изображены состоящими (композиция) из умных агентов и их оборудования и инструментов. Обратите внимание, что и во время эксплуатации/operations какие-то агенты на нашей картинке входят в окружение (например, пользователь::внешняя-роль-из-надсистемы компьютера::система входит в его операционное окружение, в отличие от компьютерного завода, который будет создателем компьютера и будет рассмотрен во время создания/dev-time).

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

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

Слова для времени создания и развития из программной/software инженерии – dev-time (от «development»), часто design time. При рассмотрении создателей мы не рассматриваем работающую/эксплуатирующуюся в окружении целевую систему, а рассматриваем систему в момент её создания (замысливания/«стратегирования использования», проектирования, изготовления, ввода в эксплуатацию системы как MVP, а дальше поток инкрементального развития функциональности и конструкции). Остальные методы времени создания (инженерные обоснования, принятие архитектурных решений) тоже присутствуют, но они тоже опущены для краткости, главное, что понятно: речь идёт о ходе/времени создания, dev-time, а не ops-time. Системы создания и системы из системных уровней внутри и снаружи целевой системы рассматриваются в разные времена/realms, что отражено пунктирной вертикальной красной линией, которую пересекают стрелки отношения создания.

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

Конечно, есть проблемы и единства рассмотрения этого времени, так называемая проблема DevOps, когда разработчики/создатели системы никак не связаны с операторами/пользователями и поэтому делают систему, которой невозможно пользоваться. Эта проблема решается прежде всего организационными мерами, но сегодня часто задействуют и технические меры: операторы и даже пользователи вообще исключаются как люди, заменяются роботами, так называемый подход NoOps56. В любом случае, в системном мышлении принято не столько считать всё происходящее в разработке и использовании принадлежащим к одному физическому времени, сколько различают «логические» времена создания (development, design, construction, implementation, enabling – везде в центре методы работы создателей, а целевая система тут пассивна, ещё не готова к работе) и времени эксплуатации (run, operation, use – функции/методы самой целевой системы, а создатели тут уже не работают, пассивны).

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

Между системами в окружении (целевой, надсистемой, системами в составе надсистемы из ближнего окружения и т. д. – если встретилось слово окружение/среда/environment, надо всегда помнить, что это «операционное окружение»/«operations environment», то есть рассмотрение времени работы) и их создателями тоже отношение создания (development, design, construction, implementation, enabling), когда один создатель::система описывает и/или меняет другую систему. И таких систем можно рассмотреть целую цепочку по отношению создания, а если поглядеть на все такие цепочки, то это будет граф создания: узлы – это системы (целевая и создатели) а рёбра – отношения создания. Внутри одного времени – отношения часть-целое/композиции, через границы времён/realms – отношения создания (X::система создаёт/«изменяет состояние» Y::система).

На диаграмме показан вариант такого графа создания. Для каждого создателя тоже было его создание, и его эксплуатация/использование/работа/operations. Поэтому на диаграмме представлено несколько разных «времён» рассмотрения (realms), и что для создателя будет его ops-time, для целевой системы будет dev-time. А что для создателя его dev-time, то для создателя создателя – ops-time.

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

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

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

Отношения создания – это не отношения часть-целое! Enabling/construction это не composition/part_of! Кастрюля, в которой варится борщ – это не кастрюля в составе борща, или борщ в составе кастрюли! Это кастрюля для создания борща!

А теперь поставьте крестик на любом из кружков этой диаграммы, которым в составе большой команды проекта будет заниматься ваша маленькая команда (возможно, в ней будете только вы один) – это будет «наша система» (system-in-hand, engineered system, MySystem, OurSystem). И повторите все рассуждения про целевую систему для нашей системы – ни на секунду не забывая про целевую систему и отношения нашей системы и целевой системы!

Запутались? Запишите все эти системы в каком-нибудь редакторе текстов или другом моделере, как шахматист записывает шахматную партию. Думайте не «в уме», думайте над текстом, или аутлайном, или таблицей!

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

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

Документирование в системном мышлении важно. Внимание, которым управляют без записей, управляется ненадёжно. Люди забывчивы, поэтому документируйте/записывайте всё (всё-всё!).

Как моделировать изменения важных объектов в проекте, будет рассказано подробно в курсе «Методология».

Моделирование: цепочки создания

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

Концепция использования

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