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

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

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

Боинг 747—8 состоит из 6 миллионов независимых видов деталей (входят в состав целевой системы), которые производили полмиллиона человек на 5400 фабриках (системы создания), за один год заказывалось (последний самолёт выпущен в декабре 2022) 783 миллиона частей самолёта (входят в состав целевой системы)[53 - http://787updates.newairplane.com/787-Suppliers/World-Class-Supplier-Quality (http://787updates.newairplane.com/787-Suppliers/World-Class-Supplier-Quality)]:

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

В современных системах число отдельных элементов, которые нужно согласовать между собой (в проектировании), а часто и создать с нуля (в конструировании) достигает десятков миллионов в «железных» системах, а если речь идёт об электронных системах, то и триллионов: на одном электронном чипе Cerebras число отдельных транзисторов – 2.6 триллиона штук, при этом каждый транзистор имеет своё уникальное назначение внутри чипа, выполняет свою уникальную функцию[54 - https://www.anandtech.com/show/16000/342-transistors-for-every-person-in-the-world-cerebras-2nd-gen-wafer-scale-engine-teased (https://www.anandtech.com/show/16000/342-transistors-for-every-person-in-the-world-cerebras-2nd-gen-wafer-scale-engine-teased)]. И ещё эти чипы – не самый высокий системный уровень, выше их уровень печатной платы, ещё выше – суперкомпьютера на основе этих плат.

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

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

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

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

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

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

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

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

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

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

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

Целевая система проявляет свои внешние свойства в надсистему «в ходе»/«во время» её работы/operations, это обозначено словами «феном[55 - https://ru.wikipedia.org/wiki/Феном (https://ru.wikipedia.org/wiki/%D0%A4%D0%B5%D0%BD%D0%BE%D0%BC)] тут». Слова 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, когда разработчики/создатели системы никак не связаны с операторами/пользователями и поэтому делают систему, которой невозможно пользоваться. Эта проблема решается прежде всего организационными мерами, но сегодня часто задействуют и технические меры: операторы и даже пользователи вообще исключаются как люди, заменяются роботами, так называемый подход NoOps[56 - https://ailev.livejournal.com/1367897.html (https://ailev.livejournal.com/1367897.html)]. В любом случае, в системном мышлении принято не столько считать всё происходящее в разработке и использовании принадлежащим к одному физическому времени, сколько различают «логические» времена создания (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 - https://en.wikipedia.org/wiki/Directed_acyclic_graph (https://en.wikipedia.org/wiki/Directed_acyclic_graph)].

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

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

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

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

Наша диаграмма графа создания (тип изображения, в котором квадратики или кружочки обозначений объектов соединены стрелками для обозначения отношений) в курсе используется исключительно в целях объяснения небольшого неизменяемого и никак не привязанного к проектам набора понятий. Она не будет модифицироваться в ходе проекта, она содержит очень мало деталей. Это иллюстрация в учебник, не рабочий инструмент системного моделирования. Мы не рекомендуем диаграммное моделирование в рабочих проектах, но мы требуем вести в проектах обязательное системное моделирование в виде текстов, аутлайнов, таблиц: форматы, которые удобно менять/редактировать, производить в них поиск, наращивать их объём без боязни запутаться в хитросплетении связей[58 - Подробней про системное моделирование на примере предприятий см. доклад А. Левенчука, 2022, «Как мы наладили обучение организационному моделированию», видео с 6:18:13, https://www.youtube.com/watch?v=lpgpnCoV14w&t=22693s (https://www.youtube.com/watch?v=lpgpnCoV14w&t=22693s), слайды https://disk.yandex.ru/i/ixpCGYY4kROrmA (https://disk.yandex.ru/i/ixpCGYY4kROrmA). Про вред от визуального моделирования см. книгу А. Левенчука «Визуальное мышление. Доклад о том, почему им нельзя обольщаться», 2018, https://ridero.ru/books/vizualnoe_myshlenie/ (https://ridero.ru/books/vizualnoe_myshlenie/)].

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

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

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

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

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

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

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

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

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

• Функционально: как роль (функциональный/ролевой объект) и его функцию во взаимодействии с окружением во время эксплуатации/работы/функционирования. Забивало – прикладывает усилие от руки к забиваемому острому предмету.

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

• Пространственно: как место в пространстве, которое занимает этот чёрный ящик в момент эксплуатации. Тот объект, который лежит в верхнем ящике шкафа у правой стенки, а в момент эксплуатации на рабочем месте номер пять в помещении номер четыре.

• Стоимостно: Как совокупная стоимость владения чёрным ящиком. Вот эта штука, стоит 1000 рублей купить и практически нисколько эксплуатировать.

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

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

• Граф создания: кроме рассмотрения системы как «чёрного ящика» в момент его работы, мы учитываем, что кто-то эту систему создаст и будет развивать.