Система планирования производства поверх 1С: порядок партий, переналадки и сроки заказов

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

Какие задачи решаем

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

• Много переналадок. Смена цвета, размера, рецептуры или оснастки занимает время, дает потери на старте партии, и порядок партий сильно влияет на то, сколько таких смен будет.
• Заказы с разными сроками. Нужно одновременно собрать похожие партии вместе и не сорвать срочное.
• Широкий ассортимент. Модели, размеры, цвета и упаковки дают сотни вариантов, которые вручную не перебрать.
• Частые изменения. Новый заказ, поломка машины или нехватка сырья требуют пересчитать план, а это часы ручной работы.
• План зависит от одного человека. Знание о том, какие переходы дешевые, не записано нигде.

Как устроены уровни планирования, чем отличается APS-система от своей модели и как порядок партий меняет число переналадок, мы подробно разобрали в статье про планирование производства с ИИ. Здесь о том, что мы делаем и как проходит внедрение.

Как устроена система планирования производства

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

Мощности. График смен, доступные машины и линии, плановые ремонты. Модель не поставит партию на машину, которая стоит в ремонте.

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

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

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

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

С какими системами интегрируем

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

Наш опыт: план выпуска на производстве колготок

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

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

Что делаем в проекте:

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

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

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

1. Бесплатный разбор, 30-40 минут. Разбираем, кто и как составляет план, где теряются деньги: переналадки, просрочки, простои, лишний запас.
2. Данные из 1С. Получаем выгрузку заказов, остатков, норм и смен за прошлые периоды, проверяем полноту.
3. Матрица переналадок. Несколько встреч с технологом и планировщиком, чтобы записать правила переходов в рублях и минутах.
4. Модель и проверка. Строим оптимизатор для одного участка и прогоняем на прошлых периодах: сколько было бы переналадок и просрочек с алгоритмом и сколько было на самом деле.
5. План в цехе. Планировщик работает с вариантами плана, мы сравниваем результат с прошлыми периодами.
6. Расширение. Подключаем другие участки, автоматизируем обмен с 1С.

Срок фиксируем после разбора: он зависит от полноты данных в 1С, числа машин и сложности правил переналадки.

Когда система планирования окупается, а когда нет

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

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

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

Сколько стоит

Разбор процесса 30-40 минут бесплатно. Пилот от 300 000 ₽. Точную цену фиксируем после разбора, она зависит от числа участков и машин, систем, из которых берем данные, и того, нужна ли автоматическая выгрузка плана обратно в 1С.

Работаем под NDA. При необходимости модель разворачиваем на сервере в контуре предприятия, и производственные данные не покидают компанию.