Как Surf за несколько недель связал производственный план с реальной работой завода

На производственном заводе недельный план собирали в нескольких Excel-книгах. Его качество зависело от опыта планировщика: только он знал, какие заказы можно объединить, как сократить переналадки и при этом не оставить следующие участки без материала. Факт проходил через журналы, накладные и повторный ручной ввод, а между отметками «передано» и «получено» могла потеряться часть продукции.

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

Проблема была не в Excel, а в потерях управления

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

План устаревал до начала смены

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

Факт приходил на следующий день

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

Продукция терялась между участками

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

Локально выгодное решение вредило общему потоку

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

Начали не с интерфейсов, а с восстановления логики завода

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

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

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

*Открыть таймлайн в полном размере. Хронология агрегирована по 263 коммитам репозитория с 12 августа по 30 сентября 2026 года. Исходник диаграммы создан в SVG; для безопасной раздачи через медиатеку сайта используется его PNG-рендер.*

Планирование и исполнение замкнулись в один цикл

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

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

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

Система учитывает физическое движение продукции

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

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

Передача и приёмка стали отдельными действиями. Если один участок отправил 40 единиц, а следующий принял 30, ещё 10 остаются видимыми в пути. Внутренняя логистика получает конкретное задание на забор и доставку, а код упаковки связывает физический объект с записью системы.

Сигнал оборудования также хранится отдельно от подтверждённого производственного факта. SCADA может сообщить об остановке, а сотрудник — связать её с заказом и указать причину. Машинное наблюдение не подменяет решение человека.

У каждой роли появилась своя часть общей картины

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

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

Работоспособность проверили действиями, а не количеством экранов

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

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

Почему такой объём появился за несколько недель

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

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

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

Начать можно с одного проблемного маршрута

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