Системное мышление дает мощный инструмент для анализа реального мира и создания проектов, которые его изменяют. Казалось бы, такой инструмент полезен всем, кто работает со сложными системами, к которым, в том числе, относятся enterprise-проекты в ИТ. Однако, когда я несколько лет назад рассказывал про него на Analyst Days, то в обратной связи мне прилетел вопрос: «Это интересно, но зачем так сложно? Почему бы просто не взять c4-model и не создать модель на ее основе, это же гораздо проще?» В следующих выступлениях я учитывал такое мнение и старался показать, зачем системное мышление ИТ-шнику, как стреляет его отсутствие. Впрочем, я не уверен, что убедил сторонников простых решений.
Сейчас аналогичный вопрос появляется по поводу ИИ-помощников: нужно ли им мыслить в системном подходе, когда с ними ведут проектирование сложных проектов? И ответ столь же не очевиден. Вернее, для разработчиков ИИ-моделей ответ как раз был очевиден и он отрицателен: знающий системный подход ИИ будет разговаривать слишком умно, а исследования показывают, что люди этого не любят и отвернутся от ИИ. А надо, чтобы не отворачивались, а разговаривали. Поэтому ИИ подстраивается под уровень собеседника, по-умолчанию полагая его не слишком высоким в соответствии со статистикой.
Конечно, когда собеседник спрашивает о каких-нибудь специальных областях, то ИИ делает поправку на то, что говорит со специалистом. Но далеко не всегда специалисты, даже инженеры владеют системным подходом. Более того, практика показывает, что вполне можно разрабатывать программы не только без системного, но и без мышления объектами, то есть плохо выделять сущности, путать типы и экземпляры и вообще мыслить литературными нарративами вместо структурных схем. Но та же практика показывает, что нарративное мышление для решения сложных задач не эффективно, и не только в ИТ, но во многих гуманитарных областях, например, в маркетинге – для планирования исследований и компаний продвижения надо мыслить структурно, и системный подход тут полезен. И для адекватной коммуникации важно, чтобы им владел не только человек, но и его ИИ-помощник.
Однако, с указанием ИИ-помощнику на системный подход есть трудность, просто сказать «используй системный подход» – недостаточно. Дело в том, что за этими словами скрывается множество разных смыслов, начиная просто от умения применять хоть какую-нибудь последовательность вместо беспорядочного метания мысли. И среди этого множества описаний лишь малую часть составляют те, в которых говорят про мышление системами, с умением выделять их в окружающем мире, строить правильные отношения, различать эмерджентные свойства, присущие системе в целом от свойств отдельных частей, не путать функциональное и модульное деление системы. Поэтому просто по указанию «используй системный подход» ИИ легко может ошибиться. При этом даже в рамках мышления системами существует рад версий, связанных с историей развития: на первом этапе имели дело с физическими системами, затем расширили его на биологические системы, начали говорить про экосистемы, границы которых являются нечеткими и часто выделяются «по соглашению», что дальше распространили и на инженерные объекты, что знает любой, кто пробовал выделить в сложном софте «подсистему безопасности».
Таким образом, ИИ-помощнику надо достаточно подробно рассказать, какие именно методы и шаблоны мышления мы подразумеваем под словами «системный подход», а что им не является. И это представляется сложной задачей. Однако, у этой задачи есть доступное (и бесплатное решение). Чуть больше года назад Анатолий Левенчук, руководитель Школы системного менеджмента, которая примерно тогда переименовалась в Мастерскую инженеров-менеджеров, занялся задачей: объяснить ИИ, что такое – современный системный подход. Анатолию это нужно было для прикладных целей: чтобы разработать развитие системного подхода, применимое не только для проектирования инженерных систем и управления организациями, но и для работы с моделями личности и сообществ. Создание такого объяснения, которое Анатолий назвал First Principle Framework (FPF) стало самостоятельной задачей. Однако, в сентябре 2025 года вышел первый релиз, с тех пор фреймворк активно развивается. Фреймворк с самого начала создавался с помощью ИИ-моделей, а с февраля Анатолий делает это в Codex с помощью агентов.
Текущая версия FPF выложена на на github https://github.com/ailev/FPF. Это большой файл, который нужно подключить к вашему ИИ-помощнику, внутри которого – шаблоны (паттерны) системного мышления, сформулированные на языке стандартов – с именованием шаблонов, перекрестными ссылками и так далее, которые можно использовать для разных задач. В readme сейчас 14 разных путей применения FPF для разных целей: создание архитектуры, разработка рабочих регламентов, сравнение альтернатив и принятие обоснованных решений, восстановление онтологий и другие.
Последняя из них – создание аналогичных фреймворков для конкретной предметной области – Domain Principle Framework (DPF). Об этом 28.06 Анатолий проводил семинар, что и послужило для меня непосредственной причиной написать эту статью. Материалы семинара доступны на телеграм-канале https://t.me/mim_workdev/196 – презентация, запись, краткий конспект. Чуть выше на канале – пост со ссылкой на подключение и большим количеством комментариев, в нем можно посмотреть ход обсуждения, а так же несколько описаний предметных областей, созданных участниками прямо в ходе семинара, как конкретных, таких как доставка платежных документов потребителям, так и достаточно общих, таких как создание Agentic AI Planform. Это получается «из коробки», одной командой. Понятно, что это – черновик, и его потом надо дорабатывать, тоже с помощью ИИ, но это – хороший черновик, где уже учтено много проблем предметной области и типовых ошибок, которые совершают при реализации. Соответственно, когда вы будете обсуждать с ИИ конкретный проект, он все это будет учитывать.
Описано это все на языке шаблонов, структуру которых Анатолий раскрывал на семинаре, там довольно много составляющих: проблемы, решения, метрики, на которые надо опираться, примеры использования, антипаттерны и так далее, и это – вполне читаемо. И не обязательно читать самому, можно спрашивать ИИ, просить объяснить содержание.
С другой стороны, вовсе не всегда DPF и даже FPF вам помогут, это тоже видно из комментариев. Контекст проекта, если он хорошо сделан, важнее общих принципов. При этом может оказаться, что ваш контекст по терминологии конфликтует с FPF, и это надо отдельно разводить, а не просто подключить FPF. Впрочем, следует отметить, что в FPF ситуация в принципе предусмотрена, и ИИ в задании на работу можно сказать, наприме, так: «при составлении плана проекта опирайся на FPF, но изложи результат на языке, понятном для менеджеров таких-то проектов». А в целом тут все, как со сложными фреймворками в ИТ-разработке: они многое умеют, но требуют подготовки для грамотного использования. Потому что если ИИ заложил в DPF одни шаблоны, а вы мыслите иначе, то ничего хорошего из использования не получится.
В заключении я хочу отметить, что интерес представляет не только сам FPF, но и история его создания, включая организацию команды агентов, с помощью которой Анатолий их создает. Он это достаточно подробно описывает в своем блоге https://ailev.livejournal.com/, правда, там вперемежку идут самые разные материалы. В середине апреля я публиковал подборку ссылок, можно обратиться к ней – но с тех пор прошло уже больше двух месяцев, явно появилось много нового. Это работа, за которой полезно следить и пробовать применять в своей работе, собственно, в сообществе, сформировавшемся вокруг школы-мастерской Левенчука многие так и делают. А Анатолий планирует серию семинаров с подробным объяснением, как оно внутри устроено.
Комментарии (8)
Wild_Boar_Y
06.07.2026 16:53Проблема не научить АИ помощников "мыслить" системно, проблема у современных моделей - не галлюционировать, не изобретать ответы, не совершать ошибки в мелочах. Будете оперировать системами, не дообучив машину простейшей логике, честности и здравому смыслу, при системном подходе получите систему с кучкой мин замедленного действия в фундаменте
MaximTsepkov Автор
06.07.2026 16:53Способность ошибаться или фантазировать ответы присуща ИИ не больше, чем студенту, отвечающему на экзамене на вопрос, который он знает смутно. При этом на работе многие продолжают вести себя так же, как на экзамене - выполняя задачу "как поняли", домысливая и фантазируя. ИИ уже лучше студента, ее знаний гораздо больше, при чем по площади. И большинство кейсов. когда "ИИ нафантазировала" делятся на две категории: ей смутно поставили задачу, не сказав важного или ее намеренно ввели в заблуждение, а она приучена доверять человеку, какой бы бред он не нес, потому что у нее цель - продолжать разговор, а не воспитывать. При этом ИИ способен проверять свои результаты - только для этого надо задать критерии что такое хорошо (или качественно). НА семинаре об этом много говорили, и во фреймворке есть готовые шаблоны для проверки, в том числе сложных решений.
AVF_613
06.07.2026 16:53даже инженеры владеют системным подходом.
" -Это неправильные пчёлы и они делают неправильный мёд"...
знающий системный подход ИИ будет разговаривать слишком умно, а исследования показывают, что люди этого не любят и отвернутся от ИИ.
А зачем "недалеких людей" допускать до разработки сложных систем??? Может хирурги тоже не любят руки мыть.... и что?...
При этом может оказаться, что ваш контекст по терминологии конфликтует с FPF
Может быть с терминологии и нужно начинать?... на данный момент, я не видел AI, который бы
мог структурировать или описать, даже простой, проект в соответствии с терминологией стандартов по УП, СИ и СМ.
Даже простая работа со стандартной терминологией показывает разницу в интерпретации одного термины в разных системах/доменах.
ПС: Уже, когда то, писал АИЛев по вопросу применения стандартов (15288 втч),... но он не ответил,.. а удалился пританцовывая бачату...
MaximTsepkov Автор
06.07.2026 16:53ИИ-модели изначально делали не для разработки сложных систем, а для разговоров. И когда вы что-то от нее просите. то надо задавать роль. Когда вы ее явно используете для написания кода и других разработческих задач, такая роль задана из коробки, там проблем нет. А вот когда обсуждаете какие-то свои проекты или новую для вас предметную область, она по умолчанию не понимает, кто вы - специалист или праздноинтересующийся блогер.
Что касается множества противоречивых терминологии, то Эванс в свое время придумал гениальное решение: делаем ограниченные контексты и их сшиваем, а то непорядок: софт уже модульный, а модели предметной области - монолитные. И Левенчук тоже методологически разбирался с этим в своих курсах, это уже давно там есть. И в FPF для ИИ это тоже перенесено - понятие языков разных предметных областей. А при переносе описаний системного подхода в FPF он много раз вставал на грабли, когда одно слово имеет 3-5-7 значений, например, под "map" подразумевается процесс, результат процесса и еще что-то. и разводил терминологию, иначе ИИ ошибался так же, как человек. ИИ с правилами - умеет выдерживать заданную терминологию.
Проблема в том, что он не знает вашей терминологии, ее надо выложить в виде правил, а это - непросто. Человек же не говорит языком конкретного ГОСТа, у каждого из нас - смесь разных терминов из разных учебников и методологий, в командах и проектах это как-то синхронизируется, но обычно не выкладывается. И новички из других проектов на такие грабли регулярно наступают.
AVF_613
06.07.2026 16:53И когда вы что-то от нее просите. то надо задавать роль.
ИИ с правилами - умеет выдерживать заданную терминологию.
Пробовал. Давал ИИ свои словари, справочники итд. Но после 2 -3 вопроса, приходится напоминать о контексте вопроса и заставлять создавать чек лист источников в ответе... сиди потом, проверяй. Код, да, это умеет, но кто бы у нас вёл нормальную документацию по версиям систем для ИИ.
Хотелось бы, как библиотеки, подключать комплексы стандартов. Или наоборот, отключать методички и учебники (упрощённые модели)...
когда одно слово имеет 3-5-7 значений, например, под "map"
У термина, всегда должен быть идентификатор (ссылка на стандарт), а так и любой инженер спросит "-откуда брали?".
пример конкретизации формулировки терминов Я то от него не звёзды с неба просил, а что бы он структурировал стандарты (10303-239 и др) в соответствии с др. стандартом (iso 29148) и собрал json.
*коммерческой цели это не имело. так, для души..
*ГОСТ Р ИСО 10303-239-2008 Системы автоматизации производства и их интеграция. Прикладные протоколы. Поддержка жизненного цикла изделий
Человек же не говорит языком конкретного ГОСТа
Как сказать... и такое бывало) Письмо в ****надзор с КД, не отличается выразительностью.
Реестр стандартов
Словарь
Samid777
Если пытаться внедрить системный подход, то практически всегда будете встречать сопротивление. Причины просты.
Большинство людей (не менее 95 процентов) в данной сфере мыслят не системно, а алгоритмически. Это не столько эффективно, как системно, но позволяет решать задачи прилагая больше усилий, но выполняя более простый действия. Это как перетащить телегу разобрав ее с грузом на мелкие запчасти, а не укатить на колесах.
Даже те, кто мыслят системно, не всегда знают что такое системное мышление. Многие воспринимают данную фразу как вообще способность мыслить не стандартно. Если критическое мышление, или абстрактное еще выделяют в отдельную, определяемую категорию, то увидев упоминание о системном мышлении фразу просматривают вскользь, отсюда идет игнорирование основной мысли.
Разве что показав, как человек с хорошо развитым системным мышлением имеет преимущество над алгоритмическом, в технической сфере, получится обратить внимание на вопрос.
MaximTsepkov Автор
С этим согласен. Есть большая проблема даже с объектным подходом - взгляд на мир через объекты и методы работы с ними, хотя, казалось бы в чем проблема, большинство современных языков как раз объектные. А системный подход - это следующий такт. Проблема начинается со сложными задачами, которые требуют учитывать много аспектов. НО их в современном ИТ много, почти все задачи масштабирования под нагрузкой с обеспечением устойчивости работы носят такой характер. И архитектурные решения алгоритмически не сделать...
Samid777
Причина проблем с системным подходом понятна. Она не выработалась эволюционно. Даже больше, если применять системный подход к решению задач где системы нет, а просто алгоритмы и шаги, мы потерпим фиаско. У меня с годами он выработался решая задачи по связи, плюс работа совпала с моим хобби. Потому мог быстро решать проблемы, при получении вводных задавал два-три дополнительных вопроса, и в большой системе мы может отбросить сразу большую часть аппаратуры, понимая где искать неисправность. К примеру
КОР У меня проблема с направлением 1, проблемы с афу. Дует ветер, думаю что нужно затянуть фидер на антенне. (почти очевидное решение, появился ветер, расшатал антенну)
Я Стой. А что у тебя с направлением 5?
КОР с этим направлением все в порядке!!
Я Не трогай антенну. На направление 1 и 5 используется сдвоенная антенна, по сути одна, общая. На КСВ может повлиять только цепь от приемопередатчика до дуплексора.
Диалог не вымышленный, просто немного упрощен, найден был разъем криво затянутый при обслуживании. А демонтаж антенны в ветер был бы сопряжен с большим риском повреждения мачты… И это очень простой пример. Более сложные случаи могли экономить часы или дни работы одной проверкой в нужном месте.
Вот тут пример, что причина-следствие должно рассматриваться в системе, как контролируя одни элементы системы можно проверить другие. И что удивительно, но эффективно использующих системный подход, видя всю картину целиком а не только участок цепи за и перед искомым прибором я видел всего двух… за 20 лет.
Объекты, в моем понимании это конкретные устройства на младших уровнях абстракции системы. Но в программировании это может что другое. Например если я от корреспондента 1 до корреспондента 3, через корреспондента 2 организовал изернет, то все что вложено, я не рассматриваю, пока не сломается. Для меня больше нет антенн, приемопередающий устройств. Есть единая система, от 1 до 3, а уровни абстракции ниже не нужны, когда мы обеспечиваем организованным каналом имеющихся корреспондентом. Потому объекты и система друг друга не исключают…
Но опять же, я рассматриваю все со стороны инженера, который работает с железом, его запуском и конфигурированием. Программирование чуть другое, но что такое архитектура в программировании представляю, а архитектуру без системного подхода… почти немыслимо.