Когда план уплывает — это уже сигнал
Первое внедрение «АвтоЗавода» идет на производстве в Подмосковье, которое делает облицовочные панели разной сложности для зданий. Производство там на практике делится на два крупных блока: изготовление форм, в том числе сложных 3D-форм, и изготовление самих изделий — заливка бетона, цикл выдержки, съем, повтор.
Внутри каждого заказа — много типов изделий, иногда сотни. У каждого типа своя форма, и для одного типа может потребоваться много циклов. При этом все идет параллельно: пока делается изделие №1, уже может стартовать форма №2, и дальше цепочка живет одновременно в двух блоках.
У предприятия уже был собственный алгоритм планирования внутри 1С. И это важный момент: проблема обычно не в том, что планирование ведут вручную или в табличке, а в том, что на определенном масштабе существующим решениям перестает хватать скорости, расширяемости и способности адекватно реагировать на сложные комбинации ограничений. В какой-то момент план на горизонте мог сдвигаться почти вдвое. Это не просто неудобство, а признак системной потери управляемости.
После внедрения эффект был заметен даже в боевом режиме, где чисто измерить результат всегда трудно. Но уже на глаз стало видно важное изменение. Если раньше разворачивающуюся проблему на производстве могли не замечать до 12 дней, то с новой системой ее начинали видеть примерно через шесть дней. То есть лаг реакции сократился примерно вдвое. В практическом смысле это означает не абстрактную оптимизацию, а дополнительные недели на принятие решений по критическим отклонениям.
На предприятиях план не пересчитывают раз в месяц. Его двигают постоянно: новые заказы, сбои, приоритеты, задержки, переналадки. Если пересчет слишком долгий, люди перестают верить системе и возвращаются к ручному управлению. Тогда APS превращается в отчет, а не в инструмент.
Идеала нет, задача — минимизировать проблемы
Ключевая задача APS — работа именно в плохие дни. Это ситуации, когда соблюсти все сроки физически невозможно, заказчиков много, у каждого свой уровень важности, с кем-то можно договариваться о переносе, с кем-то нельзя, а решение надо принять сейчас.
В таком режиме задача планирования превращается не в поиск идеального плана, а в поиск наименее плохого. Руководитель задает правила, а система ищет вариант, который минимизирует ущерб.
Это особенно важно там, где стоимость опоздания неодинакова. Для одного клиента перенос на день — рабочая история. Для другого — это риск потерять контракт. Поэтому в хорошей APS-системе штрафы за просрочку должны задаваться в точном соответствии с реальностью бизнеса. В нашей логике можно выделять категории клиентов: тех, кого нельзя двигать вообще, тех, кого можно двигать с небольшим штрафом, и тех, для кого перенос допустим в определенных пределах. Количество таких категорий и сами штрафы задаются заказчиком. Это не декоративная настройка, а часть целевой функции модели. Именно на таких местах, кстати, и ломаются многие красивые APS-решения, которые хорошо работают в идеальном мире, но плохо умеют жить в ситуации, когда кого-то неизбежно придется подвинуть.
Как бонус, это сильно повышает качество разговоров с заказчиками. Вы приходите с пониманием вариантов — кого мы двигаем, почему, во что это обходится и какая альтернатива была бы хуже.
Реальность всегда сложнее выстроенной модели
Идеальных процессов не существует — важная мысль, которую на производстве очень быстро начинаешь уважать. На самом деле я лукавлю — они существуют, но только в презентациях и в первом ТЗ.
Один из самых полезных выводов из внедрений для меня состоит в том, что к каждому клиенту надо сначала ехать на завод и смотреть все своими глазами. Причем ехать надо даже тогда, когда кажется, что заказчик отлично все описал. Иногда именно хорошо сформулированное ТЗ оказывается ловушкой. Оно выглядит аккуратно и логично, но в процессе выясняется, что за его пределами осталось множество мелочей, которые в реальной жизни влияют на план не меньше базовой логики. Если эти особенности увидеть на месте заранее, многие ограничения можно было бы сразу заложить в модель, а не добавлять потом по ходу проекта.
Это вообще нормальная история для цифрового двойника производства. На первых этапах почти всегда всплывает, что реальность чуть сложнее, чем модель. Например, система может показать — добавьте еще один станок, и узкое место исчезнет. А потом оказывается, что на деле упирается все не в станок, а в одного наладчика, которого просто не внесли в ограничения. Такие расхождения при внедрении возникают постоянно. Но в этом есть и хорошая новость. Именно они показывают, что предприятию нужно оцифровывать дальше. Модель не обязана с первого дня описывать мир идеально. Она должна начать приносить пользу раньше, чем будет оцифрована каждая мелочь. А потом, постепенно взрослеть вместе с производством.
На мой взгляд, это и есть правильная логика автоматизации: не пытаться заменить людей сказкой про «само все считает», а шаг за шагом поднимать уровень решений. Люди при этом никуда не исчезают — они просто перестают тратить время на рутину и поднимаются на уровень выше.
Для успеха нужно сгенерировать несколько сценариев
По сути, хорошее APS — это тренажер для управленческой мысли. Вы можете играть с параметрами и задавать неприятные, но очень полезные вопросы: что будет, если изменить приоритеты заказчиков? Что будет, если добавить смену? Где настоящее узкое место — формы, ЧПУ, участок заливки, сушка, сборка?
Режим «что если» заказчикам нужен почти всегда. Но есть парадокс: про него часто спрашивают, а платить за него готовы редко. Потому что этот режим требует и доработки алгоритма, и способности самой производственной системы жить в логике множественных планов. Нужно уметь генерировать несколько сценариев, сравнивать их, хранить, обсуждать. Это усложняет проект и по стоимости, и по организационной зрелости. Тем не менее, в нашем случае такая логика возможна: систему можно перезапускать с разными параметрами и видеть, как меняется результат, а при необходимости — подсвечивать, какие именно ограничения мешают выполнить тот или иной заказ. На практике чаще всего этого хватает уже в полуручном режиме.
Еще один важный момент — скорость. Можно сколько угодно рассуждать про глубину оптимизации, но если расчет работает слишком долго, им просто не будут пользоваться. Я обычно делю такие режимы на несколько психологических классов. Первый — секунды или до минуты: это идеальный режим для живой демонстрации и совещаний. Второй — около пяти минут: с этим удобно работать в течение дня. Третий — около часа: уже терпимо, если задача сложная. Четвертый — ночь: когда вечерний запуск дает результат к утру. А все, что дольше, — уже почти всегда плохая новость для заказчика. Поэтому в реальном APS важна и вычислительная дисциплина, или насколько быстро система способна пересчитать план так, чтобы с ней реально работали.
ИИ как помощник, который может усложнять систему
Основа «АвтоЗавода» — математическая модель. В таких задачах критично правильно описать ограничения, задать приоритеты, собрать целевую функцию и выбрать методы решения. Здесь настоящую производственную математику пока нельзя отдать на откуп ИИ.
Нейросеть может помогать вокруг модели, но не вместо модели. Она может ускорять подготовку данных, автоматизацию рутины, генерацию отчетов, формулировок, вариантов объяснений. Но если говорить именно о времени операций и реальном ходе производства, то в наших проектах мы пока опираемся прежде всего на первичную информацию от клиента. При этом сам подход может учитывать вариативность. Если отклонения во времени операций небольшие, можно работать со средними значениями. Если разброс критичен, можно закладывать несколько сценариев сразу — условно средний, умеренно пессимистичный и другие варианты. Настоящий диспетчер всегда держит в голове несколько реальностей. И автоматическое планирование в принципе тоже может работать так же. Просто это делает систему заметно сложнее, поэтому на практике почти всегда начинают с усредненной модели, а дальше уже наращивают глубину.
А что внутри продукта на самом деле типовое
В разговоре о продукте всегда возникает честный вопрос: если каждое производство уникально, что тогда вообще можно масштабировать?
Масштабируется не волшебная кнопка, а продуктовый каркас. Если заводы достаточно похожи, между ними может переноситься модель целиком, вместе со стандартными ограничениями; дальше добавляются только те особенности, которых раньше не было. Если же у нового клиента вычислительная сложность оказывается слишком высокой, модель приходится перерабатывать, ускорять, специализировать. Тогда она по-прежнему строится на базе имеющегося ядра, но уже сильнее затачивается под конкретный завод. Помимо математической части, переносятся и отдельные интерфейсные элементы, и некоторые стандартизированные сценарии взаимодействия, и даже часть облачной инфраструктуры, если клиенту нужен соответствующий контур развертывания.
То есть продукт в таких системах — это не одинаковый шаблон для всех, а повторно используемый набор сильных решений: математическое ядро, типовые ограничения, интеграционные паттерны, элементы интерфейса, инфраструктурные заготовки.
Как это встраивается в ИТ-ландшафт предприятия
Вопрос, который всегда возникает у промышленных компаний: «АвтоЗавод» — это отдельная система или надстройка над 1С?
Обычно это отдельная система, особенно если задача вычислительно тяжелая. В зависимости от нагрузки она может жить на компьютере заказчика, на отдельном сервере или в облаке. Интеграция с 1С идет через стандартный API, а пользовательский интерфейс во многих случаях остается внутри привычного контура предприятия. Проще говоря, расчетный модуль может быть для пользователя «черным ящиком», который получает данные, считает и возвращает план обратно в систему. В ряде кейсов этого достаточно. Иногда интерфейс нужно дорабатывать отдельно, и тогда появляются собственные UI-решения или доработки со стороны интеграционных партнеров. Если до внедрения в 1С уже был развитый интерфейс ручного планирования, то после автоматизации часть этого интерфейса может вообще оказаться лишней и схлопнуться: там, где раньше двигали прямоугольнички руками, теперь часть логики берет на себя расчетный модуль.
Вообще, хорошее APS повышает управляемость, а не создает идеальные решения. Система не отменяет хаос реального производства. Она просто позволяет раньше его заметить, аккуратнее оценить последствия и принять решение не вслепую. А это уже очень много. Потому что в реальном заводском дне выиграет не тот, у кого самые красивые слайды про цифровизацию, а тот, кто на шесть дней раньше понял, что план уже поехал, и успел что-то с этим сделать.
