APS-система планирования производства: как считается расписание и когда нужна своя разработка

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

ERP отвечает на вопрос «что и сколько нужно выпустить и закупить». Расчёт потребности разворачивает спрос по спецификациям и получает: к 14-му числу нужно 200 корпусов, для них — столько-то листа. Но стандартный расчёт не проверяет, есть ли 14-го свободный станок и не занят ли он в этот момент другим заказом.

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

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

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

• Маршруты и операции — последовательность, что можно делать параллельно, что строго после чего.
• Нормы времени — основное, подготовительно-заключительное, на партию и на штуку отдельно.
• Переналадки — длительность зависит от того, что стояло на станке до этого. Это матрица, а не одно число, и часто именно здесь сидят главные потери.
• Календари — графики смен, праздники, обеды, плановые ремонты и остановы.
• Оборудование — взаимозаменяемые станки с разной производительностью, ограничения по габаритам, материалу, точности.
• Люди — квалификация и допуски, сколько единиц оборудования обслуживает один оператор.
• Оснастка и инструмент — одна пресс-форма на два станка означает «одновременно нельзя», хотя оба станка свободны.
• Технологические паузы — сушка, остывание, вылежка, карантин по качеству. Интервалы, которые нельзя сжать переработкой.
• Партии — минимальный запуск, кратность тары, объём печи или ванны.

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

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

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

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

Справочник оборудования не соответствует цеху. Два станка списаны, один куплен и не заведён, у трёх дублирующиеся наименования с разными кодами.

Номенклатура с дублями. Одна и та же деталь под тремя кодами — потребность разъезжается на три части, а план собирается по каждой отдельно. Это уже задача порядка в справочниках, то есть управления мастер-данными, и решать её приходится до планирования.

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

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

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

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

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

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

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

На своих проектах мы берём открытые движки оптимизации: например, CP-SAT из библиотеки OR-Tools под лицензией Apache 2.0 умеет и жёсткие ограничения, и взвешенный критерий, и разворачивается в контуре предприятия без зависимости от лицензионной политики вендора.

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

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

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

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

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

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

Начинать с MES при этом не обязательно. Рабочий минимум — терминал на участке, где мастер или оператор отмечает начало и конец операции сканированием, а простой выбирает из короткого списка причин. Это цеховое автоматизированное рабочее место на планшете или в киоске, и собирается оно быстрее полноценной системы исполнения.

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

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

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

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

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

Отдельный сценарий: планирование в 1С:ERP закрывает объёмно-календарный уровень само. Если предприятие живёт в 1С, а потребность в пооперационном расписании возникает на одном-двух узких участках, дешевле и быстрее сделать модуль поверх платформы, чем ставить рядом отдельную систему и связывать их обменами.

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

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

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

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

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

Описать модель участка. Ресурсы, маршруты, переналадки, календари, оснастка. Здесь же проверяются нормы — фактическими замерами, а не доверием к справочнику.

Согласовать критерий и веса письменно. С производством и коммерцией в одной комнате. Устная договорённость на этом этапе разваливается при первом конфликте между сроком и переналадкой.

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

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

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

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

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

Второе, что помогает, — объяснимость. Система должна показывать, почему операция встала именно здесь и что мешает поставить её раньше: занят ресурс, не готова оснастка, не пришёл материал. Расчёт в виде чёрного ящика не принимают, и это правильная реакция, а не саботаж.

Ориентиры по нашим проектам: модуль планирования поверх 1С — от 3 млн ₽; заказная система расписаний под процесс предприятия — от 1,7 млн ₽; интеграция с учётной системой, ERP или оборудованием — от 150 тыс. до 1,5 млн ₽ за контур в зависимости от сложности обмена; аудит кода и архитектуры существующего решения — 200–600 тыс. ₽.

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

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

Автоматизировать хаос. Если технология не соблюдается систематически и «как получится» — норма, система аккуратно зафиксирует беспорядок в цифровом виде и добавит к нему отчётность. Сначала стабильность процесса, потом оптимизация.

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

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

• Найти узкое место — участок или единицу оборудования, которая ограничивает выпуск. Планировать имеет смысл его.
• Проверить нормы на нём — две недели фактических замеров против справочника. Это дешёвая проверка, которая экономит месяцы.
• Записать критерий одной фразой и согласовать её с производством и продажами. Если фраза не формулируется, проект не готов к старту.
• Посмотреть, есть ли факт выполнения операций и в каком виде он собирается сейчас.
• Оценить, ложится ли ваша модель ограничений в готовый продукт. Если ложится — брать продукт, это дешевле.