О системах и системном подходе

cryptoemcee · 14.Июль.2025 17:25:58

Данная заготовка содержит разные “вкусные” куски, которые во время чтения разных текстов А. Левенчука с 2016 года показались мне весьма ценными для понимания системного мышления (до начала освоения руководств летом 2025 года).

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

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

Системное мышление - это мышление в понятиях системного подхода.

Мир становится слишком сложным, чтобы жить в нём без системного мышления. Стремиться к простоте желательно. Но чтобы сделать просто для других, нужен кто-то, кто возьмёт на себя сложность.
Желание простоты - мышление масс и потребителей, а любовь к сложности - мышление деятеля. Интеллектуал формирует свою картину мира из лучших теорий человечества (sota) и создаёт успешные системы. Потребитель пользуется стандартизованными картинами мира, которые кто-то упростил и сделал доходчивыми, чтобы потребитель не тратил лишних усилий. Основная задача человека - загрузить в мозг хорошие теории (обучиться), которые можно применять в жизни.
Жизненное мастерство позволяет меньше зависеть от случая, открывает дверь к бесконечному развитию: мастер получает удовольствие от жизни, занимаясь своим делом и создавая успешные системы. Поэтому постоянно быть при деле - это важная составляющая интересной жизни.
Церенов

Для получения результатов в проектах любого сорта нужна не только системность, но и систематичность. Одновременно. Дисциплина мышления и дисциплина действия. Чекнуть предписанное системным мышлением (системность), чекнуть всё предписанное без пропусков (систематичность).

Выделять шаблоны хорошего мышления - это работа методолога. Оформление этих шаблонов в виде учебных курсов - работа методиста/instructional designer.

Критерии сильного мышления:

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

Системное мышление помогает мыслить тем, кто знает свою предметную область. А кто не знает свою предметную область, им уже ничего не поможет. Они будут описывать странное, реализовывать случайные изменения в физическом мире, или вообще не затрагивать физический мир своими фантазиями.

Системное мышление позволяет:

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

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

Праксиология изучает логические следствия из аксиоматически верного утверждения, что человек действует, используя средства для достижения целей. Экономическая теория вводит понятие “разделение труда”. Системное мышление - междисциплинарный подход, который изучает, как разделение труда устроено (как устроена любая деятельность вне зависимости от предметной области; для этого создаётся единая картина мира - мета-мета-модель, позволяющая рассуждать в единых понятиях о любой предметной области). Поэтому праксиология является одной из трансдисциплин системного подхода.

Системный подход вводит набор понятий и их отношений, позволяющих рассуждать о деятельности вне зависимости от её предметной области. Для этого нужно находить в реальном мире объекты, соответствующие этим понятиям, и проводить с ними рассуждения. Если не используются понятия системного подхода как объекты внимания в проекте - мышление не системно.

Системное мышление предполагает использование мысленного разбиения физических объектов на части. Мыслить системно - это:

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

Система отвечает на вопрос “что это делает”, а не “как устроено”.

Система сама себя не создаст. Это делают конкретные люди в соответствии с конкретным замыслом, который определяется замыслом других людей.

Жизнедеятельность деятеля можно представить как творческий конвейер, состоящий из стадий: потребление информации, размышление, действие, отдых.

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

Применительно к жизненному мастерству, это значит, что смотрим от себя как деятеля наружу - в проект, в сообщество, в общество и человечество, какое поведение туда “нужно вставить”, чтобы надсистема успешно работала. И потом смотрим внутрь себя как личности, чтобы понимать, какое мастерство надо развить, чтобы это поведение обеспечить.

Главное в системном мышлении - умение проводить на разных уровнях разные рассуждения, основанные на разных прикладных дисциплинах, занимающихся объектами разной крупности.

Система не создаётся, а развивается/evolve. Это не техноорганизм, а техновид в ходе эволюции (мемом хранится отдельно), конкурирующий с другими видами. Поэтому - непрерывный ввод в эксплуатацию (continious delivery).

Системное мышление:

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

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

Системный мыслитель про весь мир думает как про наборы вложенных друг в друга и взаимодействующих на каждом уровне “матрёшек” системных уровней - да ещё и много “матрёшек” в каждой. Свойства этих “матрёшек” на каждом уровне вложенности не совпадают со свойствами той “матрёшки”, в которую они вложены. И каждый уровень такой “мировой матрёшки” обслуживается своим экспертным сообществом, разобравшимся, как этот уровень “матрёшки” устроен. (Верхний уровень - Вселенная с галактическими кластерами, нижний - квантовые “супер-струны”; большинство интересного происходит на небольшом числе средних уровней физических объектов). Вот если у тебя такой “матрёшечный” взгляд на мир, и ты натренирован/привык сначала смотреть на ту обычно находящуюся в чужих руках (внешние проектные роли) “матрёшку”, в которую вкладывается находящаяся у тебя в руках “матрёшка”, и только потом раскрывать свою “матрёшку”-в-руках (внутренние проектные роли), вот тогда ты - системный мыслитель. Всё остальное - мелкие уточнения. “Матрёшки” всегда у кого-то в руках, они нужны им для чего-то - и в конце 20 века появилось понятие “проектная роль” (философия прагматизма). В 21 веке ход на прагматизм и проектную роль был довершён: жизненный цикл системы стал восприниматься не как набор работ, а как набор практик - деятельностей людей над частями “матрёшек”, и сразу стало понятно с мультидисциплинарностью в проектах. А само системное мышление получило статус трансдисциплинарного (находящегося не в ряду других дисциплин, а “по ту сторону” дисциплин, “транс”, за скобками, использующегося в рассуждениях других дисциплин.

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

Говоря о “системе Х”, мы тем самым подразумеваем существование какого-то куска мира, называемого Х, и всего остального мира за пределами этого куска. “Система” - это такой способ указать на специальным образом выделенный вниманием кусок мира в его противопоставлению тому миру, который остался за границей системы. При определении границы системы нужно понимать, что система задаётся субъективно - само выделение системы из окружающего мира должно быть таким, чтобы было удобно рассуждать о системе и проводить с ней какие-то действия в рамках деятельности стейкхолдера (и лучше бы сразу договариваться о границах системы так, чтобы это было удобно сразу нескольким стейкхолдерам). Система определяется стейкхолдерами субъективно, и лучше им быть в договорённости по поводу её границ. Это означает именно “деятельностную субъективность” (помним, что деятельность повторяема, у неё есть сценарий, речь не идёт о единичном действии), пристрастность обусловленной сценарием роли, пристрастность действующего лица - ролевая пристрастность, окрашенная талантливостью или бесталанностью исполнителя-актёра. Поэтому сначала задать уточняющий вопрос: какой стейкхолдер определяет границы, и какова деятельность этого стейкхолдера, чтобы для него было осмысленно проводить границы именно таким способом - то есть каким образом целевая система важна для его деятельности?

Таким образом, “система - в глазах смотрящего”. Эта субъективность системы - деятельностная (то есть повторяемая, но повторение не делает эту субъективность объективностью). Любая объективизация - это результат договорённости разных стейкхолдеров, согласовывающих свои деятельности и картины мира. Разные люди видят в одной и той же системе разные объекты - ибо они смотрят на них согласно своей роли, своей позиции. Это суть системного подхода, холизм (полнота рассмотрения с разных позиций стейкхолдеров по отношению к деятельности) против редукционизма (когда всё-всё связанное с системой объясняется с позиции одного научного предмета).

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

Системное мышление - коллективное мышление, а не мышление одного человека. Оно предполагает договорённость о предмете деятельности, то есть о целевой системе. ЦС не ваша, не какой-то одной роли - она общая для коллектива проекта.

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

“Говорю система - подразумеваю стейкхолдеров, говорю стейкхолдер - подразумеваю систему”, “каждый стейкхолдер имеет деятельность, и в этой деятельности целевая система будет частью надсистемы стейкхолдера” - это проявление системного мышления, самые азы системного подхода. Один конкретный человек - не стейкхолдер. Деятельность мы описываем безлично, в культурно-обусловленных типах участвующих объектов, субъектов, действий/операций.

Системы имеют минимально три ипостаси/аспекта: компонент, модулей и размещений. Ипостасей этих всегда больше, в “чистом виде” они не встречаются и обычно тесно сплетены друг с другом (гибридны). Философски очень похоже, что компонента - это “действующее лицо” в системе, а модули назначаются на соответствующие роли в качестве “исполнителей”. Никакого “истинного” или “объективного”, как независимого от ролевых интересов, разбиения системы на части нет. Поэтому для одной и той же системы в проекте по её созданию обычно рассматривается несколько вариантов разбиения её на части: функциональные, конструктивные, места, затратные и др. Эти разные варианты разбиений на части люди, играющие разные роли в проекте, согласовывают между собой, добиваясь успешности системы. Весь проект тем самым сводится к сначала достижению договорённостей между ролями по поводу значений важных для них характеристик/concerns (проект должен дать успешную систему! все должны договориться!), а затем к воплощению этих договорённостей в физическом мире.

Системные уровни нужны для того, чтобы структурировать достижение этих договорённостей, лучше понимать происходящее: обсуждаются всегда объекты этих уровней, которые и проявляют свои характеристики, воспринимаемые разными ролями как важные предметы их интереса. Нужно убедиться, что обсуждение ведётся специалистами по объектам этого уровня. Системные уровни принципиальны, они отражают саму суть системного подхода - для снижения сложности обсуждения ведутся отдельно для отдельных системных уровней, это существенно упрощает обсуждение сложных систем. Системные уровни хороши как раз тем, что позволяют обсудить, кто что делает, что можно не делать и что нельзя не делать. Особенность системного рассмотрения в том, что объекты разных системных уровней существуют и взаимодействуют в момент работы нашей (кто “мы”? Это важно. Разные “мы” - разные ответы!) целевой системы. Системное мышление рекурсивно, оно применяется на каждом системном уровне, каждой командой. И каждая команда имеет свои “системные координаты” вокруг своей целевой системы и отдельно ещё и “их системы”, поэтому самое важное - это договориться, что же это за системы. Системный подход, вводя системные уровни, делает рассуждения осмысленными: все люди получают возможность договориться, обсуждая проблемы только каждый на “своём” системном уровне (на уровне, для которого у них есть интересы, предпочтения, намерение действовать, чтобы изменить ситуацию к лучшему с точки зрения ролевых предпочтений).

Системное мышление не даёт никаких “объективных ответов” на вопросы о системах. Эти ответы всегда зависят от того, какая роль спрашивает, и какая роль даёт ответ. В системном мышлении нет никакого алгоритма, приводящего к “правильному ответу”, нет последовательности шагов, гарантирующих какой-то приемлемый результат данного мышления, нет “типичных случаев” - всегда найдутся нюансы, которые типичное делают абсолютно нетипичным. Системное мышление сложно, его долго осваивать - этим оно напоминает какую-то “необъективную высшую математику”. Системное мышление даже не трудится давать точные определения своим понятиям: разные стейкхолдеры норовят приспособить эти понятия для своих самых разных потребностей. Но понятия системного мышления позволяют компактно и просто описывать сложный мир, чтобы управлять коллективным вниманием в проектных ситуациях. Альтернативные варианты (например, редукционизм, когда вы явно не используете системные уровни для организации внимания людей в проекте) оказываются много хуже.

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

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

Ещё раз: никаких алгоритмов, рецептов, лайфхаков по определению целевой системы нет; это предпринимательские гипотезы, а предпринимательство “по рецепту”, “по алгоритму”, “по лайфхаку”, “по процедуре” или ещё как-то “по правилам” невозможно. Наоборот: есть множество способов критики предлагаемого решения, и реализовывать нужно (понимая, что всё это только гипотеза) лучшую из выдержавших критику гипотез. Система должна быть физична, её нужно рассмотреть прежде всего в составе надсистемы в момент её эксплуатации, полная стоимость владения системой должна быть меньше пользы от её эксплуатации и так далее, используя все подсказки по критике и поиску ошибок из руководства по системному мышлению МИМ: если всё это оказалось соблюдено, то вы (вероятно! гарантировать ничего нельзя! это предпринимательство) нашли целевую систему.

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

Системное мышление определяет объекты управления вниманием, а не алгоритм. Чётких правил определения “правильной целевой системы” не существует - в отношении неё могут существовать только гипотезы, которые могут быть проверены на соответствие понятиям системного подхода. Гипотезы подлежат критике всеми членами команды. Наилучшая из прошедших критику гипотез должна быть принята командой.

Признаков целевой системы не так много, но всё равно люди делают ошибки: проблема в том, что системное мышление не подсказывает, что является правильным выбором целевой системы. Но его ценность в том, что оно заставляет выбрать, не даёт от этого выбора уйти! Целевая система всегда выделяется из мира кем-то и для чего-то, а не “объективно” и “правильно/истинно”.

В философской логике рекомендуют всегда начинать с воплощения системы, даже если это воплощение будет существовать только в будущем: нужно представить и описать возможный мир, в котором воплощение системы существует!

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

Все системы прежде всего называют по их первичному назначению/роли в окружении. Во всех системах подсистемы взаимодействуют, чтобы они проявили эмерджентность/системный эффект.

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

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

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

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

Функция - это взгляд на поведение целевой системы со стороны надсистемы, “зачем нужно”, ролевой. Сервис - это взгляд на поведение целевой системы в сторону надсистемы, “не знаю, зачем нужно, но меняю окружение”, конструктивный. Функция - поведение подсистемы в системе как функционального/ролевого объекта. Сервис - поведение целевой системы в надсистеме как конструктивного объекта.

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

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

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

Системный мыслитель обязательно выделяет не менее четырёх областей/зон/предметов ролевого интереса:

функциональную/ролевую/аналитическую;
модульную/конструктивную/синтетическую;
пространственную (совмещения функциональной и конструктивной в рамках 4D экстенсионализма, отношение реализации проявляется в том, что функциональные и конструктивные части занимают одно и то же пространство-время);
стоимостную/экономическую/ресурсную.

Сложность описания/обсуждения системы тем самым падает по двум направлениям:

деление полного обсуждения всей системы на обсуждение её отдельных частей по системным уровням. Каждая часть системы проще, чем система в целом, поэтому обсуждение проходит более-менее единообразно на каждом уровне, а каждая часть системы определяется её требованиями (requirements), описанием системы как “чёрного ящика”. В требованиях игнорируется внутренняя структура системы и её частей, поэтому обсуждение начинается всегда с целых систем в составе надсистемы, или целых подсистем в составе системы;
деление полного обсуждения каждой системы на обсуждение с помощью множественных описаний этой системы как “прозрачного ящика”: принципов организации взаимодействия и структуры частей системы. Важнейшие из этих описаний - это архитектура, включающая и функциональное, и конструктивное, и пространственно описание, равно как и множество других. Но используются при обсуждении системы и все остальные описания “прозрачного ящика”, сделанные с точностью, достаточной для изготовления - это “рабочка”/неархитектурная часть проекта/дизайна.

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

Привязка к физическому миру (эти понятия в основном взяты из семантики, теории понятий, онтологии):

физический объект, занимающий место в пространстве-времени;
воплощение (физические объекты) против их описаний и документов;
изменения (процессы, проекты, кейсы) как физические объекты;
события как физические объекты;
ролевой/функциональный объект (роль) и конструктивный/материальный объект (конструктив) как его аффорданс/“подходяшка”, их физичность;
софт как физический объект (исходный код как описание софта);
предприятие/оргзвено как физический объект и его части во времени;
методологическое время против времени жизни системы;
при совпадении места/объёма двух объектов в пространстве-времени - это один объект (экстенсионализм);
отношение состава (composition, “часть-целое”, разбиение) физических объектов.

Методологическая/функциональная/деятельностная субъективность описания системы (понятия взяты главным образом из методологии как учения о методах работы агентов, в том числе актёров, играющих “роли в методе работы”):

метод/способ работы, метафора “ролевой игры”;
функциональная/трудовая/проектная/деятельностная/культурная/оргроль (stakeholder role): внешняя, внутренняя/командная;
ролевые: предмет интереса/важная характеристика (concern), интерес/предпочтение (viewpoint, view);
агент, его намерение, отыгрывание метода работы роли как актёра;
успешная система.

Системное разбиение:

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

Описание и документация системы:

описание (definition) системы;
документация (description) системы (не равно definition);
ролевое/частное описание (view);
ролевой метод описания (viewpoint) - всегда есть, но невидим, как и метод работы;
модель, мета-модель, мета-мета-модель, мульти-модель, мега-модель;
прожекторный и синтетический подходы к описанию систем.

Функциональные и конструктивные части системы, размещения и ресурсы:

разбиения: функциональные, конструктивные/материальные/модульные/продуктовые, размещения/пространственные, стоимостные (кандидат: работы);
конфликты между системными уровнями и неустроенности;
функциональная часть (роль), её порты, потоки/связи;
конструктивная/материальная часть (конструктив), его интерфейс, платформа;
пространственная часть (размещение);
ресурсная часть (совокупная стоимость владения);
архитектура;
функциональный анализ и конструктивный/модульный синтез (изобретение).

Системно-инженерный (он же эволюционный) стек:

Вселенная;
все инопланетные цивилизации;
человечество (мы тут одни на маленьком глобусе);
общество - дальний порядок (не знаем контрагентов в лицо), но может быть достаточно организованным, чтобы выставлять границы на территории;
сообщество (можно посмотреть определения subculture, counterculture, community, community of practice, learned society, school of thought - все говорят об одном и том же, подчёркивая разные стороны). У нас субкультура, контркультура, сообщество практики, сообщество наученных (деятелей, не учёных!), “незримый колледж”. Но можно говорить и о племени (очень модно!), и о “муниципальном образовании” типа “деревня, где все друг друга знают”, землячестве бывших (или даже нынешних) членов одного общества в каком-то другом обществе. Ориентируемся на число Данбара, ещё относительно ближний порядок;
коллектив/организация, которая трудится - это проекты (организованные коллективы, то есть с понятными ролями и полномочиями каждого). Инженерия предприятия как раз тут;
личность, тут разные психотерапии, образование и практики личной продуктивности как “инженерия личности”. Включать ли сюда разные варианты xGI не на базе homo sapience - почему бы и нет;
существо - тут разведение живых существ от вирусов через растения, а дальше червей, рыб и до зверей (включая приматов и даже человека вне аспектов его разума). Медицина/ветеринария, фермерство, генная инженерия, искусственная жизнь (системная биология, включая её инженерные изводы);
киберфизические системы (физические системы, включающие софт на базе универсального компьютера). Классическая системная инженерия;
вещество (молекулы, простые физические детали): тут от органического синтеза до инженерии мыльниц и электролампочек, то есть инженерия простых систем без сложного управления с контроллерами-компьютерами в их составе.

Краткий чек-лист при работе с системами:

ЦС представлена в физическом мире, и не является документацией. Докажите;

ЦС является частью надсистемы. Назовите ЦС и ее надсистему, а также докажите вложенность;

ЦС имеет свойство эмерджентности. Назовите системный эффект целевой системы (как именно свойства целевой не равны сумме свойств подсистем) или функцию целевой системы;

ЦС кто-то проектирует, производит, эксплуатирует. Назовите системы создания, в том числе укажите команды этих систем создания;

В ЦС заинтересованы определенные проектные роли. Назовите внешние и внутренние проектные роли;

ЦС имеет воплощение (realization), описание (definition) и документацию (description). Расскажите об этом;

ЦС имеет подсистемы. Назовите их, выделите самые важные;

Какие проектные роли играете вы, по каким методам и в каких системах. Свяжите выполнение проектных ролей с развитием жизненного мастерства.

Необходимо добиться беглости в следующих системных навыках:

Находить сначала ЦС и ее надсистему, а уже потом разбираться с внутренним устройством ЦС. Ни в коем случае не наоборот!
Разделять систему как физический/конструктивный объект и как функциональный объект с определенной функцией.
Отделять ЦС от систем создания или цель от средств (потребительское благо от капитального, если ЦС сама не является капитальным).
Видеть за системой заинтересованных лиц (внешние и внутренние проектные роли).
Описывать деятельность по трем областям интересов:

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

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

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

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

Системное мышление учит видеть мир состоящим из холархий, практик, видеть в мире границы систем, видеть в людях стейкхолдеров.

“Системная мантра” - последовательность логических шагов в рассмотрении создания и развития систем: обсудить пользу системы в её окружении; описать устройство системы для получения именно такой пользы; обсудить, какими методами такую систему с таким устройством можно изготовить; обсудить, какие создатели имеют мастерство в выполнении этих методов. Системное мышление состоит из типовых рассуждений, условно разбиваемых на шаги и объединяемых системным промптом (подсказкой, удерживающей все остальные рассуждения). На первом шаге называем:

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

Терминология системного мышления в одной фразе: чтобы удовлетворить потребности внешних проектных ролей, нужно понять принципы функционирования и конструкцию надсистемы в окружении, и тем самым сформулировать функциональные и интерфейсные требования к целевой системе. Затем выполнить эти требования, для чего разработать архитектуру и затем воплотить целевую систему в физическом мире. А для этого в обеспечение её жизненного цикла нужно организовать компетентную команду, использующую все необходимые для работы методы. И это нужно делать рекурсивно, для всех подсистем целевой системы.

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

Система - это:

4D (вещь в физическом пространстве-времени, можно показать пальцем, постучать по ней). НЕ информация/описание, НЕ свойство, НЕ поведение.
“Чёрный ящик” в составе надсистемы (в окружении других систем), не в вакууме.
В момент эксплуатации в надсистеме/в системном окружении (run-time).
Обладает эмерджентностью (свойства системы не равны сумме свойств её частей).
Обладает целостностью (можно провести чёткую границу между системой и окружением), связи внутри системы сильнее, чем снаружи.
Обладает вложенностью (система входит в состав других систем и сама состоит из систем).
Выдаёт определённое поведение в окружении (играет роль/выполняет функцию), выражаемое отглагольным существительным, название системы определяется её поведением.
Наносит непоправимую пользу внешним проектным ролям, удовлетворяя их потребности (за что они платят).
Успешность её описывается как “надсистема с нашей целевой системой работает хорошо” (а не “наша целевая система работает хорошо, а на остальное нам наплевать”).
Выделяется из мира вниманием (за удержание внимания отвечает собранность).
Внимание это коллективное - о целевой системе договаривается команда проекта, создающая её набором практик на всех этапах её жизненного цикла.
Имеет множество разных описаний (отражающих ролевые интересы проектных ролей) одного и того же объекта.
Устройство системы - “прозрачный ящик” (из чего сделана, архитектура, подсистемы) и кем (цепочка систем создания) - интересно только после того, как понятна роль/функция системы в окружении как “чёрного ящика”.

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

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

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

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

Окружение - сначала. Практики создания (“как делаем”) - потом. Системы создания (кто эти практики будет выполнять) - ещё позже. Надсистема и окружение сначала, целевая система потом (когда будет понятно, кому и для чего она нужна, какая у неё роль в надсистеме).

Сначала понимаем, что делаем (целевую систему в её окружении), затем понимаем, какими способами её можно делать (практики жизненного цикла), затем предлагаем вариант систем создания, которые могут выполнять эти практики (могут быть варианты; поставщиков сервисов много, и они конкурируют), в том числе создаём эти системы создания, если их ещё нет (иногда создавать приходится длинную цепочку систем, которые создают друг друга).

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

“Я как стейкхолдер/проектная роль хочу, чтобы [целевая система] [формулировка требования], для того, чтобы [потребности для надсистемы]”.

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

внешние, которых волнует прежде всего работоспособность надсистемы (для них как раз надсистема - их целевая, она их и волнует). Работает ли надсистема с включением в её состав целевой системы как задумано, удовлетворяет ли потребностям? Работают ли часы, в которых внутри работает сделанная нами шестерёнка? Отстают ли, или спешат? Обращаем внимание, что “отстают или спешат часы” замеряют на часах, это эмерджентные свойства, у шестерёнки таких свойств нет;
внутренние, которых волнует работоспособность целевой системы - работает ли целевая система как задумано, удовлетворяет ли системным требованиям? Мы спроектировали шестерёнку: то ли мы получили, что описывали? Тот ли у неё диаметр, вес, число зубьев? Заметим: про часы и их способность показывать время тут речь вообще не идёт.

Заказчик может предоставить только свои нужды, а не требования к системе.

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

Терминологически в системном мышлении требования отличают от потребностей (stakeholder needs, stakeholder requirements). Это не синонимы, термины имеют разные значения. Потребности - это требования внешних проектных ролей к их целевой системе, то есть надсистеме целевой системы команды проекта. Для внешних проектных ролей то, что называет требованиями команда системы создания целевой системы, видится как требования к подсистеме (целевая система - подсистема надсистемы).

Требование, взятое вместе с именем системы и временем его выполнения (когда воплощение системы начинает соответствовать требованию), называют контрольными точками (milestone).

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

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

Целевой системой тут является system, требования к ней так и называются - system requirements. Требования к надсистеме (system operation) будут называться stakeholder requirement или потребности/нужды стейкхолдеров. Их не перепутать: они описывают разные системы на их границах (как “чёрный ящик”, без подробностей про внутреннее устройство каждой из систем), на картинке это чётко видно. При перемещении на уровень вверх “потребности” становятся требованиями, и появляются новые “потребности” для новой надсистемы. При перемещении на уровень вниз “требования” становятся “потребностями”, и появляются новые требования для новой “подсистемы”. Эти термины определяются относительно двух смежных системных уровней. Мы привели эту картинку для того, чтобы показать присутствие в проекте множества самых разных требований и потребностей. Нельзя считать, что в проекте есть только требования для целевой системы и потребности для надсистемы. Они, конечно, основные для рассмотрения, но обычно ситуация сложней, и выявлять приходится множество самых разных требований к самым разным учитываемым в проекте системам из системного разбиения целевой системы, её окружения, её систем в цепочке создания. Слишком много разных требований, легко запутаться? Документируйте, записывайте их - и вы не запутаетесь. Вы не гроссмейстер, в шахматы по памяти не сможете играть. В системном мышлении то же самое: “системное мышление по памяти” это просто цирковой трюк, так оно не работает, в том числе так не работает мышление о требованиях. Обязательно документируйте требования! Не надейтесь на память (что вы вспомните какое-то требование, когда будет нужно) и телепатию (что кто-то из вашей команды или внешних проектных ролей узнает о требовании каким-то способом, если это требование не было записано). Пишите!

Инженерия предприятий тоже относится к менеджменту (но не операционному, а организационному - речь идёт не об управлении работами предприятия, а об управлении работами по созданию предприятия; run-time для предприятия противопоставляется его design-time), и она похожа на традиционную инженерную работу, хотя и с особенностями, в том числе терминологическими: инженерия архитектурных требований в ней - это стратегирование; инженерия системной архитектуры - это инженерия архитектуры предприятия; управление конфигурацией в run-time - это операционный учёт; основная практика в изготовлении предприятия - лидерство как “катализирование сотрудничества”, ибо предприятие невозможно “собрать из частей” так, как это делается с традиционными инженерными системами типа часов или ракет.

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

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

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

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

Системное мышление нужно для того, чтобы управлять вниманием в сложной коллективной деятельности людей, ведущих жизненный цикл самых разных систем. Для каждой отдельной части системы системный мыслитель будет понимать её место в целой системе, для каждой отдельной практики системный мыслитель будет понимать её место в жизненном цикле системы, для всех своих умений системный мыслитель будет понимать ситуации, в которых возникает потребность в этих умениях. Системный подход трансдисциплинарен, он нужен, чтобы упростить разбирательство со сложными мультидисциплинарными ситуациями, сложными системами, не терять леса за деревьями отдельных специализированных практик. Системное мышление поможет специалисту ориентироваться в окружающей жизни, не теряться внутри своей частной работы, вписывать свой труд и свои знания в общий труд и знания для проекта, а также **планировать своё личное развитие - возможность участвовать во всё новых и новых проектах по изменению Жизни на планете к лучшему.