ИИ-агент в SolidWorks: загрузка цехов, брак и простои

На машиностроительном заводе SolidWorks стоит годами: конструкторы ведут в нём модели, сборки и чертежи, а версии файлов живут в SolidWorks PDM (Product Data Management — управление данными об изделии). При этом загрузка цехов считается в отдельной таблице, брак разбирают на планёрке по памяти, а простой объясняют словами «не привезли деталь». Система проектирования работает, а решение по смене принимается без её данных.

Инженерное программное обеспечение в России за 2025 год выросло примерно на 20% и составило порядка 50–55 млрд рублей, причём лучшая динамика — как раз в сегментах САПР (система автоматизированного проектирования), PLM (Product Lifecycle Management — управление жизненным циклом изделия) и PDM. Это значит, что модели и состав изделия в цифре у заводов уже есть: их не нужно создавать заново, к ним нужно подключить производственный слой.

SolidWorks отвечает на вопрос «что должно быть изготовлено»: какая конструкция, какие детали, какие допуски, какая ревизия чертежа актуальна. Цех отвечает на вопрос «что реально можно изготовить сегодня»: какие станки свободны, где стоит оснастка, кто в смене, что уже в работе. Между этими двумя ответами обычно и живёт вся ручная работа мастера, диспетчера и технолога, а расхождение обнаруживается на приёмке — когда партия уже сделана.

Коротко

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

Содержание

• Что такое SolidWorks и какие процессы в нём живут
• Где заканчиваются возможности системы
• Почему загрузка цехов видна поздно
• Что съедает время между изменением модели и решением по цеху
• Что делает ИИ-агент поверх SolidWorks
• Какие данные нужны на старте
• Какие риски это снимает
• Сколько часов это возвращает
• Что остаётся за человеком
• Как проверить, что агент не ошибается
• Как это выглядит на практике
• Как внедрить поэтапно
• Чеклист перед пилотом

Что такое SolidWorks и какие процессы в нём живут

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

Внутри этого контура живут четыре вещи, которые дальше нужны производству:

• Модель и чертёж. Геометрия, размеры, допуски, материал, покрытие. Черновик и утверждённая версия отличаются, и это нормально — вопрос в том, какая из них попала в цех.
• Состав изделия. Перечень деталей и сборочных единиц с количеством: то, что завод покупает, отливает, фрезерует и собирает.
• Конфигурации. Одно изделие в разных исполнениях: другая длина, другой фланец, другая комплектация. Именно здесь чаще всего и рождается путаница — «сделали как в прошлый раз», а исполнение уже другое.
• История версий. Кто, когда и зачем изменил конструкцию. В PDM это есть, и это самый недооценённый источник данных для производства.

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

Где заканчиваются возможности системы

SolidWorks и PDM описывают изделие, но не описывают цех. В них нет ни фактической загрузки оборудования, ни причин простоя, ни журнала брака с привязкой к ревизии чертежа. Система честно отвечает на вопрос «что за конструкция», но не отвечает на вопрос «что с ней будет на участке».

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

Разрыв видно и в цифрах по отрасли. Загрузка производственных мощностей в России во втором квартале 2026 года составила 76,9% против 77,6% кварталом ранее — по данным мониторинга предприятий Банка России, в котором участвуют более 15 тысяч компаний. Иными словами, примерно пятая часть мощностей не загружена, и вопрос «куда поставить этот заказ, чтобы не сорвать другой» решается каждую неделю. При этом MES (системы управления производством) стоят далеко не везде: объём российского рынка таких систем по итогам 2025 года — около 18 млрд рублей, по оценке IBS. То есть у части заводов данные о смене вообще не собираются в систему, а живут в рапортах и разговорах.

Почему загрузка цехов видна поздно

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

1. Конструктор выпускает изменение и фиксирует его в PDM.
2. Технолог получает новую ревизию и правит маршрут.
3. Диспетчер смотрит план и решает, в какой цех поставить заказ.
4. Мастер получает задание и обнаруживает, что деталь нужна другая, оснастка занята или материал не тот.

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

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

Что съедает время между изменением модели и решением по цеху

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

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

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

Что делает ИИ-агент поверх SolidWorks

ИИ-агент — программа, которая по заданному правилу сама читает документы и данные, выполняет шаги и возвращает результат. Поверх SolidWorks он не проектирует и не «улучшает чертежи», а связывает конструкторские данные с производством:

1. Читает состав изделия и ревизии из PDM. Для каждого заказа собирает перечень деталей, количество, актуальную версию чертежа и дату изменения.
2. Сверяет с планом и фактом смены. Смотрит, что запущено, что закрыто, что стоит в очереди, и находит расхождения: деталь в плане по старой ревизии, количество не совпадает, позиция отсутствует в запуске.
3. Считает загрузку по цехам и оборудованию. Показывает, где очередь выходит за горизонт смены, а где мощность простаивает, и предлагает перенос с оценкой последствий для соседних заказов.
4. Связывает брак с ревизией и настройками. По журналу брака проверяет, совпадает ли ревизия чертежа у забракованной партии с актуальной, и отделяет конструкторскую причину от технологической.
5. Собирает простои в одну картину. Группирует остановки по причине, цеху, станку и смене, отделяя ожидание материалов и оснастки от поломок и переналадок.
6. Возвращает результат туда, где работают люди. Короткий список расхождений — мастеру, сводка по загрузке — диспетчеру, причины брака и простоев — технологу и директору по производству. В том же виде, в каком они привыкли читать: задание, отчёт, список.
7. Ведёт журнал. Каждое расхождение сохраняется со ссылкой на источник: файл, версия, строка состава, номер смены. Через месяц видно, откуда берутся повторяющиеся проблемы.

Важно, что агент не заменяет PDM и не создаёт вторую правду о конструкции. Источник остаётся один, а решение о том, что делать с расхождением, принимает человек.

Какие данные нужны на старте

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

• состав изделия и история версий из PDM за 3–6 месяцев;
• план и факт по сменам из 1С:ERP или MES — в том виде, в каком они есть, даже если это выгрузка в Excel;
• справочник цехов, участков и оборудования;
• журнал брака и простоев. Если он ведётся на бумаге, его придётся оцифровать — без этого агенту не с чем сверять;
• список типовых причин: «нет материала», «нет оснастки», «поломка», «переналадка», «нет человека».

Обычно выясняется, что часть данных есть, но в разных справочниках: одна и та же деталь называется по-разному в PDM, в 1С и в журнале мастера. Приведение справочников — самая скучная и самая полезная часть проекта: без неё любой отчёт расходится на ровном месте.

Какие риски это снимает

Простой, который никто не планировал

Среднее промышленное предприятие теряет около 27 часов в месяц из-за незапланированных простоев — это примерно 326 часов в год, по данным отчёта Siemens The True Cost of Downtime 2024. Для среднего и малого производителя верхняя оценка стоимости часа простоя доходит до 150 тысяч долларов, а в automotive она измеряется миллионами за час. Часы простоя складываются не из поломок, а из ожиданий: не привезли, не поставили в приоритет, не тот инструмент.

Брак из-за устаревшей ревизии

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

Перегруз цеха и обещание клиенту

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

Потеря прослеживаемости при рекламации

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

Зависимость от конкретного человека

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

Сколько часов это возвращает

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

Типовой расчёт для завода с четырьмя цехами и тремя сменами:

Показатель	Вручную	С агентом
Сверка состава изделия с запуском, часов в месяц	90	12
Разбор причин брака по журналам, часов в месяц	48	14
Сведение простоев и подготовка сводки, часов в месяц	40	10
Согласование переносов между цехами, часов в месяц	32	18
Итого, часов в месяц	210	54

При стоимости часа 900 рублей с начислениями 210 часов — это около 189 тысяч рублей в месяц. После внедрения остаётся 54 часа, то есть примерно 49 тысяч; экономия — около 140 тысяч рублей в месяц на одной площадке. На трёх площадках сопоставимого масштаба порядок — около 420 тысяч рублей в месяц.

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

Что остаётся за человеком

• Решение о переносе заказа между цехами и изменении приоритета.
• Остановка партии и допуск брака — только человек с полномочиями.
• Изменение конструкции: агент показывает расхождение, но не правит модель и не выпускает ревизию.
• Работа с людьми: перевод в другую смену, сверхурочные, обучение.
• Разговор с заказчиком о сроках. Агент даёт расчёт, обещание даёт человек.

Агенту запрещены действия, которые меняют производственный план или документы: он не выпускает задания, не подтверждает приёмку, не закрывает наряды. Это граница, которая должна быть зафиксирована в правилах доступа, а не «подразумеваться».

Как проверить, что агент не ошибается

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

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

Второй приём — разметка мастером. Каждое расхождение получает одну из трёх пометок: подтвердилось, ошибка данных, ошибка правила. Через две недели видно, где проблема: если преобладает «ошибка данных», надо чинить справочники; если «ошибка правила» — переписывать условие. Это дешевле, чем спорить о доверии к ИИ в общем виде.

Третий приём — доля ручных проверок. Пока агент работает в режиме подсказки, часть его выводов человек перепроверяет вручную. Доля таких проверок должна снижаться: если через месяц она та же, значит агент показывает очевидное и пользы не даёт. Если упала до нуля в первый же день — скорее всего, его просто перестали читать.

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

И последнее: считать надо не только найденные расхождения, но и снятые вопросы. Если мастер перестал звонить диспетчеру по три раза за смену, это тоже результат — просто он не попадает в отчёт, пока его не начали измерять отдельно.

Как это выглядит на практике

В работе с производственной компанией численностью 350–500 человек мы начинали не с модели, а с разбора того, что уже есть: какие данные о составе изделия доступны, где живёт план смены, как фиксируется брак. Программа строилась под конкретные задачи производства — сверку состава с запуском, сводку по простоям и разбор причин брака.

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

Что важно из этого опыта: проект не начинается с вопроса «какой ИИ использовать». Он начинается с вопроса «где лежит правда о детали и что с ней происходит в цехе». Если ответа нет ни у кого, сначала появляется справочник, потом агент. Измеренного эффекта в этом проекте мы не фиксировали — цифры в разделе расчёта выше это модель, а не наш замер.

Как внедрить поэтапно

1. Разобрать один процесс. Не «загрузку цехов вообще», а конкретно сверку состава изделия с запуском по одному цеху за месяц.
2. Свести справочники. Деталь, узел, цех, станок — одинаково названные в PDM, учётной системе и журнале мастера.
3. Собрать исторический срез. 3–6 месяцев данных, чтобы агент проверялся на прошлом, а не только на будущем.
4. Сделать сверку в режиме подсказки. Агент показывает расхождения, но ничего не меняет; мастер отмечает, что было верно.
5. Добавить простои и брак. Второй и третий сценарии подключать после того, как первый перестал давать ложные срабатывания.
6. Закрепить правила и роли. Кто получает сводку, кто подтверждает перенос, что агенту запрещено, где хранится журнал решений.

Чеклист перед пилотом

• Состав изделия и ревизии выгружаются из PDM без ручной правки.
• План и факт смены доступны за 3 месяца и в одном справочнике.
• Журнал брака ведётся хотя бы в таблице, а не только в памяти мастеров.
• Есть один цех-пилот и один человек, который отвечает за проверку результата.
• Определены правила доступа: что агент читает, что пишет, что ему запрещено.
• Есть понятный критерий успеха: например, доля расхождений, найденных до старта смены, а не после приёмки.

Что в итоге

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

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

Источники

• Стоимость и структура простоев промышленности: Siemens, The True Cost of Downtime 2024 — 11% выручки и 1,4 трлн долларов потерь у 500 крупнейших компаний мира; среднее предприятие — 27 часов незапланированных простоев в месяц и около 326 часов в год. assets.new.siemens.com
• Стоимость часа простоя по отраслям: Siemens, The True Cost of an Hour’s Downtime — 2,3 млн долларов в час в автопроме, рост вчетверо в тяжёлой промышленности за пять лет, до 150 тыс. долларов в час у средних производителей. blog.siemens.com
• Загрузка производственных мощностей и деловая активность: Банк России, Мониторинг предприятий, сентябрь 2026 года — 76,9% во втором квартале 2026 года против 77,6% в первом, опрос более 15 тыс. предприятий. cbr.ru
• Распространённость ИИ в российских организациях: ИСИЭЗ НИУ ВШЭ — около 5,2% крупных и средних организаций применяют технологии ИИ (+0,4 п. п. к 2024 году), в компаниях с численностью более 500 человек — 17%. issek.hse.ru
• Объём российского рынка систем управления производством: исследование IBS — около 18 млрд рублей по итогам 2025 года. ibs.ru
• Рынок инженерного программного обеспечения в России: CNews со ссылкой на «Системный софт» — 50–55 млрд рублей по итогам 2025 года, рост около 20%, лучшая динамика в САПР, PLM/PDM и BIM. cnews.ru
• Возможности линейки и функции на базе ИИ: описание продуктов SolidWorks у Dassault Systèmes — 2D/3D-проектирование, управление данными, машинное обучение и генеративное проектирование в браузерных приложениях. 3ds.com

Смежные разборы по производственному контуру: ИИ-агент в КОМПАС-3D, ЛОЦМАН:PLM, 1С:MES, MasterSCADA, предиктивное обслуживание оборудования, T-FLEX CAD., ИИ-агент в Global ERP