Хочу поделиться историей познания сложного мира производства и логистики, методологий и алгоритмов, а также большого количества обеспечивающих их инструментов - ИТ-систем и продуктов. История планируется из 2-х частей, возможно трех. При этом не претендуя на высокую точность и академичность, при этом логичность и правильность тех или иных утверждений - дополнительно была уточнена и проверена.

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

Глава 1. Игровые симуляторы, стратегии и начало большой любви

Эта история берет начало со времен повального увлечения людей разных возрастов такими играми как например серии Diablo, C&C, HoMM и его величества - Counter-Strike преимущественно в игровых салонах. Однако меня больше всего привлекали экономические стратегии и симуляторы, а именно такие серии как Civilization, Caeser, Pharaon, Zeus, SimCity, ну и различные Tycoons. Сколько часов было потрачено на каждую из них - не поддается счету. Тогда индустрия развлечений еще не была настолько огромной, а алгоритмы привлечения внимания не были такими умными, чтобы была возможность всецело посвятить себя предмету увлечения. И вот однажды я встретил "её" - представительницу той самой серии "X". Начав правда не прародительниц вроде Elite или X-Beyond, а уже, наверно, с их внучкой - X-Tension.

"Positive. Please dock as soon as you get green position lights"

Неизвестный оператор станции

X-Tension отличалась от других сыгранных мною игр, тем, что мир жил как бы без игрока. Фракции воевали и торговали, экономика менялась, пираты грабили, ксеноны периодически просыпались и устраивали вылазки к соседям. И все это происходило, пока вы например - обедали, спали или делали домашнюю работу. Это было какое-то новое ощущение — понимать что ты прежде всего наблюдатель мира игры, а не её центр. «Это не игра крутится вокруг тебя, а ты пытаешься доказать ей, что достоин в ней находиться».

Это была какая-то смесь из необязательного сюжета, производства товаров с реальным спросом и предложением и цепочками поставок между ними, со следующими особенностями:

1. Живая экономика: В отличие от многих игр, где ресурсы возникают «из воздуха», в серии X всё взаимосвязано. Если пираты собьют транспорт с батарейками, встанет завод по производству щитов, что поднимет цены на снаряжение во всём секторе.

2. Масштабируемость: Ты начинаешь на простеньком корабле, а заканчиваешь владельцем сотен торговых кораблей, большого количества космических станций и целых флотов, которые защищают твои торговые пути.

3. Свобода: Можно быть честным торговцем, строителем заводов, наемником или пиратом, который живет за счет грабежа тех самых экономических цепочек.

Отдельное эстетическое удовольствие вызывал взгляд на общую карту галактики:

Это потом где-то в будущем, я узнаю про существование Nodes & Edges, а тогда в двухтысячные это было чем-то фантастическим. Система секторов, связанных прыжковыми вратами.

В игре, наиболее интересными были темы производства и доставки (логистики). Шаг за шагом приходилось разбираться ЧТО, КОМУ и самое главное КОГДА доставить. Где лучше всего построить свою первую, а где последующие станции? Как правильно выстраивать логистику: вокруг своих станций или встраиваться в мировую цепочку товарооборота? Все это я анализировал, используя для расчетов настоящий калькулятор, блокнот и карандаш, чтобы заработать как можно больше "кредитов" (местное название валюты) на единицу времени. При этом зачитывая до дыр FAQ по игре, а вдруг можно найти еще что-то полезное? - https://www.elite-games.ru/x-tension/faq2.shtml

И чем больше было сыграно игр экономической направленности, тем больше у меня появлялось желания - понять, а как это это все устроенно в реальной жизни? Есть ли сходства? Полезен ли игровой опыт - в реальных проблемах и задачах? Какова степень упрощения реальных проблем в играх?

Глава 2. Настоящий завод, системы и теория имитационного моделирования

История эта началась на проходной завода

Четверо молодых людей после ПТУ пришли устраиваться на работу

Завод встретил их покосившимся цехом и серьезного вида мастером...

Группа Ленинград

Встреча с настоящим производством была одновременно восхищающей и пугающей. Восхищала прежде всего реальная сложность, количество людей, функций, систем. Ну а пугало то, как это все порой сложно связано, где-то через "костыли" и через мат, а где-то просто "заглушки" и не особо нужно. Мне удалось поработать и в производстве, и в складской и немножко внутризаводской логистике. Тогда же я узнал про первые умные слова-сокращения, ERP (Система, где создаются заказы и происходит управление ресурсами), WMS (управление складом, в котором ведется прием продукции, перемещение и отгрузка). И что в них вложены другие умные сокращения и термины - например BOM Bill of materials (спецификации материалов) и адресное хранение. Также интересно было узнать, что ERP зачастую работает не точно, и что сроки изготовления заказа зачастую сдвигаются, и что перепланирование нужно начинать делать в тот самый момент, когда был выпущен новый план. При этом глядя на работу рабочих, которые по заданиям что-то изготавливают, транспортируют и отгружают клиенту - возникал невольный вопрос. Что мешает планировать точнее?

Ища ответы на эти и другие вопросы, я с головой ушел в изучение теории. 

Виды производств

Производства принято классифицировать по нескольким признакам. По объёму и повторяемости выпуска различают единичное (уникальные изделия — корабли, турбины), серийное (партии однотипной продукции — станки, бытовая техника) и массовое (непрерывный поток — автомобили, продукты питания). По характеру технологического процесса выделяют дискретное производство, где изделие собирается из деталей, и непрерывное (процессное), где сырьё преобразуется в продукт без явных границ между единицами — нефтепереработка, металлургия, химия. Отдельно стоят бизнес-модели по способу запуска: «на склад» (MTS), «под заказ» (MTO), и не очень популярные - «сборка под заказ» (ATO) и «инжиниринг под заказ» (ETO).

Производство - это еще и логистика

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

ИТ-системы и продукты для производства

Для управления этим хозяйством сложилась устойчивый комплекс информационных систем. ERP (Enterprise Resource Planning) объединяет планирование, финансы, закупки, производство и сбыт в единый контур. MES (Manufacturing Execution System) отвечает за исполнение производственных заданий на уровне цеха. WMS (Warehouse Management System) автоматизирует склад — от приёмки до отгрузки. TMS (Transportation Management System) управляет перевозками. Эти системы дополняют друг друга и обычно работают в связке. С действующими MES и TMS - мне встретиться увы не удалось.

Имитационное моделирование

Когда же нужно заглянуть «внутрь» процесса — оценить пропускную способность будущего цеха, найти узкое место в существующей линии, проверить гипотезу о новой раскладке оборудования, — применяют имитационное моделирование.

Существуют три ключевых подхода:

1. дискретно-событийное моделирование (DES) для потоков заявок и операций (наиболее распространено в логистике и производстве);

2. системная динамика для стратегических процессов с обратными связями и накоплениями;

3. агентное моделирование, где поведение системы складывается из решений множества независимых «агентов».

Современные платформы — AnyLogic, Simio, FlexSim, Plant Simulation — позволяют комбинировать эти подходы в одной модели.

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

При этом от желания попробовать создать какую-то свою модельку - остановила необходимость что-то кодить на Java. Может и стоило попробовать, кто знает?

Постепенно я начал узнавать про какое-то стратегическое управление, бизнес-планирование, различную отёчность для руководства, операционные модели, объёмные и календарные планирования. Что это и зачем? Какими инструментами обеспечивается?

Глава 3. Знакомство с иерархией управления. И всякими прикольными штуками IBP, S&OP, DDAE

Мы вышли из зоны комфорта и попали в зону, где комфорта больше не существует в принципе.

Сложный для восстановления кусочек в моей памяти и того, что именно меня сподвигло на чтение таких вещей как: Теории ограничений Голдрата, S&OP, IBP, DDAE. Но последовательность была примерно такая. Параллельно с этим я также знал еще про SCM, и что оно тоже где-то и как-то стыкуется ну или по крайней мере должно с базовыми системами или методологиями. Также периодически встречались упоминания слоев управления: операционный, тактический и стратегический - вероятно они возникал из роста размеров компаний, а также увеличивающейся сложности и непредсказуемости мира. Интересно было узнать, что эта самая сложность и непредсказуемость - оказывается уже была классифицирована.

Фаза накопления теоретических знаний

Эволюция моделей описания мира

1. SPOD-мир (до 1980-х/90-х) — «Старый, добрый мир»

   SPOD описывает эпоху стабильности, предсказуемости и порядка. Это мир, в котором можно было планировать жизнь на десятилетия вперед. 

   • Steady — Устойчивый

   • Predictable — Предсказуемый

   • Ordinary — Простой (обычный)

   • Definite — Определенный 

   Характеристика: Четкие причинно-следственные связи: если вы хорошо учитесь, вы получите хорошую работу. 

2. VUCA-мир (1980-е — 2020) — «Мир перемен»

   На смену SPOD пришел мир высоких технологий, интернета и глобализации. Стабильность сменилась нестабильностью. 

   • Volatility — Нестабильность

   • Uncertainty — Неопределенность

   • Complexity — Сложность

   • Ambiguity — Неоднозначность 

   Характеристика: Изменчивые правила игры: чтобы оставаться на плаву, нужно постоянно учиться новому и быстро реагировать на перемены.

3. BANI-мир (2020 — настоящее время) — «Мир хаоса»

   Концепция, предложенная футурологом Jamais Cascio в 2020 году, описывает реальность, в которой старые инструменты (даже из VUCA) перестали работать из-за пандемии, климатических изменений и геополитики. 

   • Brittle — Хрупкий (системы рушатся неожиданно)

   • Anxious — Тревожный (всего боимся)

   • Nonlinear — Нелинейный (усилия не гарантируют результат)

   • Incomprehensible — Непостижимый (логика не работает) 

     Характеристика: Иллюзия контроля: даже идеальный план может рассыпаться в любой момент, а огромные усилия — не привести к результату.

4. Следующий мир (после BANI)

   После 2022 года эксперты начали говорить о переходе к новым моделям, так как BANI оказался недостаточно точным для описания текущего уровня хаоса. Основные кандидаты на «следующий мир»: 

   • SHIVA-мир (основная концепция 2022-н.в.):

     • Split — Расщепленный (мир разделился, нет единой логики)

     • Horrific — Ужасный/Страшный

     • Inconceivable — Немыслимый (события кажутся невозможными)

     • Vicious - (Беспощадный/Жестокий). Мир перестал быть «мягким»: теперь ошибки стоят очень дорого, а внешняя среда агрессивна.

     • A — Arising (Возрождающийся). Самая важная буква: она означает, что на обломках старого порядка начинает зарождаться что-то совершенно новое.

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

Теория Ограничений (TOC).

Теория ограничений систем (TOC — Theory of Constraints) Элияху Голдратта — это метод управления, фокусирующий усилия на устранении «узких мест» (ограничений), которые лимитируют пропускную способность всей компании. Главная идея: эффективность системы определяется не суммой улучшений её частей, а оптимизацией самого слабого звена. 

Основные положения:

• «Узкое место» (бутылочное горлышко): Ресурс, чья пропускная способность меньше или равна потребности в нем.

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

• Фокус: Не нужно улучшать всё подряд; достаточно устранить ограничение, чтобы вырастить общую эффективность. 

Управление цепочками поставок.

SCM (Supply Chain Management — Управление цепочками поставок) — это комплекс процессов и программных решений, направленных на планирование, контроль и автоматизацию перемещения товаров, услуг, информации и финансов от поставщика сырья до конечного потребителя. 

Главная цель SCM — минимизация издержек (логистики, хранения, производства) при максимизации эффективности и удовлетворении спроса клиентов. 

Ключевые области SCM

1. Планирование: Прогнозирование спроса, планирование производства и уровня запасов.

2. Закупки (Sourcing): Выбор поставщиков, закупка сырья и материалов.

3. Производство: Управление производственными мощностями и очередностью заказов.

4. Логистика и транспортировка: Управление перемещением, складированием и доставкой продукции.

5. Возврат: Обработка возвратов товаров от клиентов. 

S&OP (Sales and Operations Planning)

S&OP (Sales and Operations Planning) — это ежемесячный управленческий процесс, синхронизирующий планы спроса (продажи/маркетинг) и предложения (производство/закупки) с финансовыми целями компании. Цель — создать единый, реалистичный план на 3–18 месяцев, обеспечивающий прибыльность, снижение издержек и минимизацию разрывов в цепочке поставок. 

Ключевые аспекты:

• Согласование: Объединяет разрозненные планы отделов в единый функциональный план.

• Горизонт планирования: Среднесрочный (обычно 3–18 месяцев).

• Регулярность: Ежемесячный цикл встреч.

Интегрированное бизнес-планирование (IBP — Integrated Business Planning)

Интегрированное бизнес-планирование (IBP — Integrated Business Planning) — это процесс управления, объединяющий стратегическое, финансовое и операционное планирование в единую систему. IBP позволяет синхронизировать спрос, поставки и финансовые цели, оптимизируя прибыль и снижая риски за счет моделирования различных сценариев. 

Ключевые особенности и цели IBP:

• Единая экосистема: Объединяет прогнозы продаж, планирование цепочек поставок (закупки, производство, логистика) и финансовые планы.

• Сквозное планирование: Связывает деятельность всех подразделений — от продаж до финансов.

• Управление сценариями: Позволяет моделировать сценарии «что, если» (what-if) для принятия решений в условиях неопределенности.

• Оптимизация прибыли: Главная цель — найти баланс между спросом и возможностями поставок для максимизации денежного потока.

• Системы поддержки: IBP-системы (например, SAP IBP, российские решения) автоматизируют процессы расчета, прогнозирования и планирования.

Demand Driven Adaptive Enterprise (DDAE)

Demand Driven Adaptive Enterprise (DDAE) — это модель управления предприятием, разработанная Demand Driven Institute (DDI), направленная на создание гибкой системы, способной быстро адаптироваться к высокой волатильности рынка (VUCA-мир). Она переносит фокус с прогнозов («push-система») на реальный спрос («pull-система»), обеспечивая непрерывный поток информации и материалов. 

DDAE объединяет принципы Lean, TOC (Теории ограничений) и MRP II. 

Три Уровня DDAE

DDAE охватывает все уровни управления: оперативный, тактический и стратегический. 

1. DDOM (Demand Driven Operating Model) — Операционный уровень

   • Суть: Это сердце системы — DDMRP (Demand Driven Material Requirements Planning), DD Scheduling и Execution.

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

   • Фокус: Работа с текущими заказами, приоритезация исполнения.

2. DDS&OP (Demand Driven Sales & Operations Planning) — Тактический уровень

   • Суть: Процесс управления буферами (настройками DDOM) в соответствии с изменениями спроса и рынка.

   • Задача: Двусторонняя связь между стратегией (AS&OP) и операциями (DDOM). DDS&OP корректирует настройки DDMRP (размеры буферов, уровни).

   • Фокус: Тактические адаптивные циклы (регулярный пересмотр параметров, обычно раз в месяц или чаще).

3. AS&OP (Adaptive Sales & Operations Planning) — Стратегический уровень

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

   • Задача: Анализ рыночных тенденций, принятие решений о смене бизнес-модели, внедрении новых продуктов или изменении производственных мощностей.

   • Фокус: Формирование стратегического направления, которое затем через DDS&OP транслируется в изменения параметров DDOM. 

Фаза анализа.

Что со всем этим делать?

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

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

В итоге я начал постепенно классифицировать. С пониманием, что если я когда то решусь на создание классификации и она окажется неточной я извинюсь и смогу её уточнить и поправить. Ну а если она окажется полезной и интересной — то еще лучше. Худшим решением казалось - ничего не делать.

Сначала я попробовал самый прямолинейный подход. Выписал всё в столбик: S&OP, SCM, IBP, DDAE, MRP, ERP, APS, WMS, TMS, DRP и ещё штук двадцать менее центральных. Столбик получился унылый — как список диагнозов, где каждое название тем, кто не в теме, не говорит ничего, а тем, кто в теме, говорит слишком много сразу. Потом попытался нарисовать стрелочки между ними — и сразу застрял. Потому что одни аббревиатуры — это процессы, другие — классы софта, третьи — философии управления, четвёртые — просто жаргонные ярлыки для одного и того же в разных школах. Рисовать стрелочки между ними — это как рисовать стрелочки между «киносъёмкой», «камерой», «Оскаром» и «Спилбергом». Связано всё со всем, и не следует ничего из ничего.

Тогда я зашёл с другой стороны — исторической. Не «что есть что», а «когда каждое появилось и какую проблему решало». И вот как будто бы было понятней.

Картинка, которая в итоге сложилась, оказалась интересной в своей логичности. Каждая из этих аббревиатур — это не «очередная методология». Это исторический слой. Ответ на конкретный уровень хаоса в конкретный момент времени. И если положить их рядом с моделями описания мира — SPOD, VUCA, BANI, SHIVA — становится видно: чем сложнее становился мир, тем больше слоёв управления приходилось доращивать к компаниям. Как кольца на спиле дерева.

SPOD-мир и рождение S&OP

В 1950-х мир был устойчивым, предсказуемым, простым и определённым — то, что сейчас называют SPOD (steady, predictable, ordinary, definite). Заводы выпускали стандартные продукты для стабильного спроса, послевоенная экономика США росла линейно, конкуренции почти не было. Казалось бы, рай. Но даже в этом «золотом веке» обнаружилась неприятная структурная вещь - отделы внутри одной компании смотрят на мир по-разному: продажи обещают клиентам невыполнимые сроки, производство не успевает, снабжение покупает не то, в итоге склады забиты не тем, что нужно.

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

Ответом стал S&OP — Sales & Operations Planning. Первая попытка собрать ключевых руководителей за одним столом и заставить их договориться на единый месячный план. Никакого софта — только дисциплина и бумага. И самое смешное: S&OP до сих пор работает. Даже сегодня, когда у компании есть только Excel и пара упёртых менеджеров. Потому что это не технология, а процесс. А процесс не устаревает.

VUCA-мир и появление SCM

К концу 1980-х простота закончилась. Глобализация, аутсорсинг, азиатские поставщики, интернет, ускорение жизненных циклов продуктов — мир стал VUCA: нестабильным, неопределённым, сложным, неоднозначным. Компании больше не управляли «своим заводом». Они управляли цепочкой, в которой собственное производство было одним из звеньев. Сырьё из одной страны, сборка в другой, склад в третьей, клиент в четвёртой.

SCM, Supply Chain Management — это не методология в смысле S&OP, а общая дисциплина управления всей цепочкой создания ценности: от поставщика поставщика до клиента клиента. Зонтик, под которым живут и S&OP, и операционные процессы, и логистика, и закупки. Технологически SCM воплотился в специализированные системы — Manugistics, i2, потом SAP APO, JDA, Kinaxis. Надстройки над ERP, которые умели видеть всю цепочку целиком и оптимизировать её.

И вот здесь я вроде бы что-то понял про отношения между S&OP и SCM. Раньше я воспринимал их как два конкурирующих модных слова — а они вообще не конкурируют, они на разных уровнях. SCM — это уровень системы. S&OP — это уровень процесса внутри системы. Одна маленькая мысль, но без неё нельзя двигаться дальше, потому что иначе все следующие слои перепутаются ещё хуже.

Развилка: одна проблема — два ответа

К 2000-м S&OP уже не справлялся. В большинстве компаний он застрял на уровне «штук и тонн» — балансировал спрос и производство, но не связывал этот баланс ни с деньгами, ни с волатильностью рынка. И вот здесь произошло то, что зацепило меня сильнее всего: индустрия разошлась на два параллельных пути.

Первый путь — IBP (Integrated Business Planning). Школа Oliver Wight. Логика такая: S&OP — хороший процесс, но узкий. Давайте расширим его — подключим финансы, маркетинг, R&D, HR, свяжем операционный план со стратегией и деньгами. План в штуках автоматически пересчитывается в P&L и Cash Flow. Появляются сценарии «что если». IBP отлично работает там, где спрос относительно предсказуем, а главная боль — синхронизация большой матрицы регионов и продуктов с финансовыми целями. Классические клиенты: крупный FMCG (Nestlé, Unilever, P&G), фарма, продуктовый ритейл. У них рынок волнуется, но в обозримых пределах; промо и маркетинг важнее, чем срывы поставок.

Второй путь — DDAE (Demand Driven Adaptive Enterprise). Школа Кэрол Птак и Чада Смита, оформившаяся в 2010-х на идейном фундаменте теории ограничений Голдратта. Логика прямо противоположная: S&OP плох не потому, что узкий, а потому, что слишком сильно верит прогнозу. Давайте перестанем пытаться угадать будущее — давайте разместим динамические буферы в стратегических точках цепочки и будем реагировать на реальное потребление. Не прогноз ведёт нас, а спрос. DDAE отлично работает там, где спрос волатилен, номенклатура широкая, циклы поставки длинные, а цена ошибки прогноза высокая. Электроника, индустриальные комплектующие, автомобильный aftermarket, медтехника, специальная химия.

Когда я разложил эти две школы рядом, я поймал тот самый момент, ради которого вообще занимался систематизацией. Это не последовательные этапы зрелости. Это два разных ответа на один и тот же вопрос: «что делать, когда классический S&OP не справляется». IBP отвечает: «делайте его шире и точнее». DDAE отвечает: «делайте его адаптивнее и перестаньте полагаться на точность». И какой ответ правильный — зависит не от уровня зрелости компании, а от характера её домена.

У FMCG-гиганта спрос настолько массовый и усреднённый, что точный прогноз действительно даёт большую ценность — ему подходит IBP. У дистрибьютора запчастей спрос на конкретный SKU настолько случайный, что улучшать прогноз бессмысленно — ему подходит DDAE. Зрелые корпорации часто комбинируют: IBP сверху для общей финансовой картины, DDOM (операционная часть DDAE) внутри подразделений с волатильным спросом. Это нормально и правильно. Не нормально — пытаться натянуть одну методологию на всю компанию вне зависимости от характера её бизнесов.

Меня в этой развилке зацепило ещё вот что — и, кажется, как раз ради этого наблюдения и стоило вообще браться за систематизацию. В публичной риторике обе школы делают вид, что развилки нет. Консультанты IBP пишут «IBP — это эволюция S&OP», как будто это просто следующая ступенька. Консультанты DDAE пишут «DDAE — это эволюция S&OP», как будто следующая ступенька — это они. Получается такая параллельная пропаганда, в которой обе школы преподносят себя как «единственно правильное продолжение», и нейтрального обзора, в котором обе школы стояли бы на равных, я почти нигде не находил. Кажется, отчасти именно эта дыра — отсутствие обобщающих текстов от незаинтересованных авторов — и заставляет таких, как я, садиться и пытаться её закрыть самостоятельно, рискуя превратиться в "классификатор от неизвестного автора".

BANI: проверка боем

В 2020 году пандемия одним ударом проверила обе школы. Срыв глобальных цепочек, контейнерный кризис, дефицит чипов — мир стал BANI: хрупким, тревожным, нелинейным, непостижимым.

Результат проверки оказался поучительным. DDAE-компании в среднем перенесли шок легче, потому что их философия с самого начала допускала непредсказуемость. IBP-компании выжили за счёт сильной финансовой подушки и кризисного управления, но многие признали, что их прогнозы не стоили бумаги, на которой были напечатаны. Это не значит, что DDAE «победил». Это значит, что граница между доменами, где работает IBP, и доменами, где работает DDAE, сместилась. После 2020-го всё больше FMCG-компаний стали присматриваться к буферному управлению хотя бы на критичных категориях.

Для меня это было важным наблюдением сразу про две вещи. Про supply chain — что границы доменов двигаются, и любая классификация это карта на текущий момент, а не каменная скрижаль. И отдельно — про саму идею систематизации: даже самая аккуратная схема живёт ровно до следующего серьёзного потрясения, после которого её придётся перерисовывать. Это, кстати, неплохое лекарство от снобизма классификатора.

SHIVA и автономные цепочки

Если BANI расщепился до SHIVA — разделённая, ужасающая, немыслимая, стремительная и требующая адаптации реальность — то направление эволюции просматривается невооружённым глазом. Всё больше говорят про самообучающиеся цепочки поставок, autonomous supply chains, AI-первое планирование, где не человек настраивает буферы по правилам, а система сама учится на потоке данных. Это уже не «адаптивное предприятие» — это автономное предприятие.

И вот здесь моя школьная любовь к стратегиям и космосимам неожиданно сомкнулась с современной supply chain дискуссией. Autonomous supply chain — это ровно то, чем я в детстве считал любую игру про космос: система, которая сама себя ведёт, а человек только задаёт цели и смотрит, что получится. Разница в том, что в игре всё уже было запрограммировано разработчиком — а в реальной экономике мы только сейчас пытаемся строить такие системы, и пока непонятно, кто справится лучше: AI-усиленный IBP, AI-усиленный DDAE, или нечто третье, чему у нас пока даже нет названия.

Простая мнемоника, если коротко

SPOD-мир (до 1980-х) → S&OP: «давайте договариваться на совещаниях». VUCA-мир (1980-е) → SCM: «давайте видеть всю цепочку целиком». Поздний VUCA (2000-е) → развилка: IBP («свяжем операции со стратегией и деньгами», для предсказуемого спроса) и DDAE («перестанем верить прогнозам, начнём слушать спрос», для волатильного). BANI-мир (2020-е) → проверка боем: домены DDAE расширились. SHIVA-мир (?) → автономные цепочки на AI.

S&OP живёт внутри SCM. IBP и DDAE — параллельные истории развития S&OP для разных доменов. И всё это вместе живёт под крышей SCM как общей дисциплины.

Что я из этого вынес

В итоге у этой возни оказалось два урока, ради которых её стоило затевать.

Первый — уровни нельзя смешивать. S&OP живёт внутри SCM. IBP и DDAE — параллельные истории развития над S&OP. Если в голове это не разложено, ты неизбежно будешь читать статьи, в которых один уровень сравнивают с другим, как будто это сравнимые вещи, и удивляться, почему ничего не сходится. Не сходится потому, что сравнивают яблоки с яблонями.

Второй — методология должна соответствовать не только сложности мира, но и характеру конкретного бизнеса. Когда мир был SPOD, хватало совещаний. Когда стал VUCA, индустрия разошлась на две школы — и обе оказались правы, каждая в своём домене. Когда стал BANI, граница между этими школами сместилась. А что потребуется в SHIVA — мы как раз сейчас вместе и выясняем.

И ещё одно, побочное, но для меня лично важное. Когда я начинал, я боялся, что попытка структурировать всё это превратится в очередной "классификатор неизвестного автора". Честно говоря, я до сих пор не уверен, что в итоге получилось не он. Но я заметил, что в процессе сами вопросы стали другими. Раньше я спрашивал: «что такое DDAE и чем оно отличается от IBP?». Теперь я спрашиваю: «в какой части какой компании какой подход уместен, и что должно поменяться во внешней среде, чтобы этот выбор пересмотреть?». Смотреть на инструменты производственных компаний через полученную призму знаний - это уже другое качество, кажется ради него и стоило затевать всю эту систематизацию, даже если дочитают ее немногие.

Но из всего этого изучения - ускользало понимание, а как и что вообще оптимизируют, планируют и для чего создают расписания?

Глава 4. Знакомство с алгоритмами решения задач: эвристики, OR, MAS, цифровые двойники, ML и LLM-агенты

Сначала были совещания людей, затем их обещали заменить совещаниями агентов.

С методологиями всё казалось понятным. Каждая новая школа приходила как будто на смену предыдущей: S&OP вырастал из практик прошлого, IBP объявлял себя эволюцией S&OP, DDAE — тоже эволюцией, только с другой стороны. Между ними была конкуренция за право считаться «правильным» способом управлять системой.

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

Метаэвристики, линейное программирование, солверы, оптимизаторы, ML-модели, мультиагентные системы нескольких эпох, имитационное моделирование, цифровые двойники и хук с правой в виде последних SOTA-подходов на основе LLM, MARL, PINN.

Ну и совсем пугалки в виде автономных производственных систем будущего. В которых возможно в принципе не нужны все существующие инструменты ну или бОльшая их часть. И если раньше методологии и инструменты менялись через эволюционные принципы, то теперь должны меняться через революционные в которых человек не центральное действующие лицо, а скорее интерфейс/советник/валидатор для автономных систем? В ту же степь информация о появлении с "минуты на минуту" AGI/ASI.

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

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

Семь слоёв

Когда я начал раскладывать всё по хронологии, постепенно проявилась структура из семи слоёв.

1. Эвристики и правила

Самый старый уровень — простые практические правила.

FIFO — первым пришёл, первым обработан.
EDD — сначала задачи с ближайшим дедлайном.
SPT — сначала короткие операции.

Сюда же относятся локальные улучшения вроде right-shift, look-ahead и других «ручных» способов быстро улучшить расписание.

Эвристики почти никогда не гарантируют оптимум. Их задача другая: дать приемлемое решение быстро и дёшево.

Именно поэтому они никуда не исчезли. Даже сегодня большинство ERP-систем в базовом режиме работают именно на них.

2. Исследование операций и математическое программирование

Следующий слой — классический OR.

В 1947 году Данциг предложил симплекс-метод, а позже вокруг него выросло математическое программирование: LP, IP, MIP, branch-and-bound, decomposition methods и всё остальное ядро современной оптимизации.

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

В индустрию это пришло вместе с коммерческими солверами:

• CPLEX,

• Gurobi,

• Xpress,

• Mosek,

• SCIP,

• HiGHS,

• OR-Tools и другими.

Отдельной веткой развивался Constraint Programming — подход для задач, где логические ограничения важнее классической линейной структуры: расписания, конфигурации, планирование ресурсов.

Сильная сторона OR — точность и строгость.
Слабая — реальный мир плохо помещается в аккуратную математическую модель.

3. Метаэвристики

Почти сразу после расцвета классического OR стало понятно, что многие реальные задачи слишком большие и грязные для «чистого» оптимума.

Так появились метаэвристики:

• Genetic Algorithms,

• Simulated Annealing,

• Tabu Search,

• Ant Colony Optimization.

Они не пытаются доказать оптимальность. Вместо этого — умно исследуют пространство решений и стараются не застревать в локальных минимумах.

По сути это промежуточный слой между строгой математикой и практической инженерией.

Сегодня метаэвристики часто работают рядом с OR, а не вместо него: например, быстро находят хорошую стартовую точку для MIP-модели или дооптимизируют решение там, где строгий solver начинает захлёбываться по времени.

4. Multi-Agent Systems

Следующим открытием стало то, что мультиагентные системы появились гораздо раньше, чем я сначала думал — ещё в 1980–1990-х.

Contract Net Protocol, BDI-архитектуры, holonic manufacturing — всё это уже тогда предлагало альтернативу централизованной оптимизации.

Логика здесь противоположна классическому OR.

Вместо одного большого solvers:

• много локальных агентов,

• локальные правила,

• локальные цели,

• координация через взаимодействие.

Глобальное поведение системы возникает снизу — как emergent-эффект.

Здесь MAS очень близок к тому, что в моделировании называют Agent-Based Modeling (ABM). Разница скорее в акценте.

MAS исторически вырос из распределённого AI и инженерии: как заставить автономных агентов координироваться и принимать решения.

ABM пришёл из симуляционного моделирования и социальных наук: как из поведения отдельных участников возникает динамика всей системы.

На практике граница между ними часто размывается. Один и тот же подход может одновременно называться multi-agent system в AI-литературе и agent-based simulation в мире имитационного моделирования.

Долгое время MAS оставались нишевой технологией: гибкие производства, диспетчеризация AGV, распределённые сети. Но концептуально это оказался очень важный слой — особенно позже, когда индустрия начала двигаться в сторону распределённых и адаптивных систем.

5. Цифровые двойники

Именно здесь у меня впервые появилось ощущение, что я до этого смотрел на картину неполно.

Цифровой двойник — это не ещё один алгоритм. Это среда моделирования, внутри которой алгоритмы начинают работать вместе.

Концепция появилась в PLM ещё в 2000-х, а массово в индустрию пришла вместе с Industry 4.0.

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

Здесь есть ещё одна важная путаница, которую индустрия постепенно начала производить сама.

Под вывеской «digital twin» стали продавать почти любой сложный симулятор. Во многих случаях за громким названием оказывалось вполне классическое имитационное моделирование — discrete-event simulation, system dynamics или agent-based simulation, существовавшие задолго до моды на двойники. В иных случаях под ЦД подразумевают - перерисованные мнемосхемы и присоединенные ML-модели предсказывающие будущие поломки того или иного оборудования. Порой также нелегко сходу ответить про разницу между MES и ЦД.

Но разница всё же есть.

Имитационная модель может жить отдельно от реального объекта: её построили, прогнали сценарии, отложили.

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

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

Именно внутри таких моделей:

• OR проверяет достижимость решений,

• метаэвристики гоняют сценарии,

• RL-агенты обучаются без риска для реального производства,

• человек запускает what-if-анализ.

Это оказался не «следующий этап эволюции», а горизонтальный слой под всем остальным стеком.

И чем дальше я смотрел, тем сильнее казалось, что качество этого слоя определяет качество всех остальных.

Если цифровой двойник или имитационная модель плохи — RL учится на ошибочных данных, сценарии IBP становятся бесполезны, а агент начинает уверенно объяснять неверную модель мира.

6. Машинное обучение

ML пришёл в operations не как замена OR, а сначала как поставщик прогнозов.

Спрос, lead time, отказы оборудования, ETA, выход годных — всё это постепенно стало лучше предсказываться на данных, чем вручную моделироваться.

Позже появились более амбициозные направления:

• reinforcement learning,

• neural combinatorial optimization,

• learning-to-branch внутри solvers.

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

Во многих областях обучение на данных действительно начало конкурировать с ручной формализацией.

Но важно другое: ML почти никогда не вытеснил OR полностью. На практике они чаще работают вместе.

ML прогнозирует.
OR оптимизирует.
Метаэвристики страхуют там, где оптимизация становится слишком дорогой.

7. LLM-агенты

С 2022 года поверх этого стека начал формироваться ещё один слой.

LLM-агенты не похожи ни на классический OR, ни на обычный ML, ни на старые MAS-системы.

Они умеют другое:

• понимать постановку задачи на естественном языке;

• выбирать инструменты;

• вызывать solvers и модели;

• интерпретировать результаты;

• координировать процесс между людьми и системами.

Это не «ещё один решатель». Скорее orchestration layer над уже существующими подходами.

И именно здесь неожиданно соединились две старые идеи: цифровые двойники и агентные системы.

LLM даёт интерфейс и координацию.
Цифровой двойник — безопасную среду для проверки решений.

До появления LLM такая связка была слишком дорогой и неудобной: человеку приходилось работать через сложные интерфейсы моделирования. Теперь часть этой нагрузки начинает брать на себя агент.

Где сломалась старая модель

В прошлой главе работала простая логика: новая школа приходит на смену предыдущей.

Здесь она не сработала.

Симплекс-метод не исчез после появления Gurobi — он продолжил жить внутри solvers.
Метаэвристики не заместили OR — они встроились рядом.
MAS не отменил централизованную оптимизацию.
ML не вытеснил математическое программирование.
LLM-агенты вообще ничего не заменили — они просто начали координировать уже существующий стек.

Это оказалась другая форма эволюции.

Не замещение, а наслоение.

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

Именно поэтому рядом спокойно существуют:

• эвристики 1950-х,

• MIP-модели 1980-х,

• ML 2010-х,

• LLM-агенты 2020-х.

Где всё-таки есть конфликты

Полного мира между подходами тоже нет.

Есть локальные напряжения.

OR vs ML

В маршрутизации и scheduling ML-подходы иногда реально конкурируют с классическими solver-based системами. Где-то выигрывает строгая оптимизация, где-то — обучение на данных.

Централизация vs распределение

Большая централизованная MIP-модель и мультиагентная система — две очень разные философии управления.

Реальные данные vs симуляция

RL почти всегда упирается в вопрос: учить на истории или внутри цифрового двойника. И то и другое несовершенно.

Но ни один из этих конфликтов не выглядит серьёзным противостоянием. Обычно обе стороны всё равно используют друг друга.

Что я из этого вынес

Главный вывод оказался неожиданно простым.

Методологии замещают друг друга.
Алгоритмы накапливаются.

Когда появляется новая управленческая школа, имеет смысл спрашивать: что она пытается вытеснить?

Когда появляется новый вычислительный слой, вопрос обычно другой: как он встроится в уже существующий стек?

Это меняет взгляд почти на всё:

• на внедрение,

• на архитектуру систем,

• на обучение команды,

• на ожидания от «новых технологий».

И ещё одна вещь стала для меня важной.

Раньше я смотрел в основном на сами алгоритмы. Теперь всё сильнее кажется, что ключевой элемент современного стека — это среда, в которой они взаимодействуют.

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

Спасибо что дочитали до конца! Обратная связь приветствуется, также как и пожелания - хотели бы вы увидеть следующую часть, но я скорей всего все равно ее напишу =)