Был опыт работы программистом в компании, которая выпускает очистные сооружения для воды. Это сложные изделия, состоящие из тысяч деталей. Некоторые поставляются, другие изготавливаются внутри предприятия. Производство состоит из нескольких цехов: механическая обработка, сварка, покраска, сборка. Всего работает более 500 человек. Так что этим опытом я и хотел поделиться в данной статье.
Часть 1: Зачем и как
Всё это время производство велось на самописной конфигурации на платформе 1С: Предприятие 8.3 (толстый клиент) . Никакой ERP, никакой «большой автоматизации» — просто свое придуманное производство, свои справочники, документы и регистры. Не спрашивайте "Зачем так?" - речь не об этом.
Управленческий учет был, но без единого плана работ. Каждое утро мастер ходил по цехам, звонил, спрашивал — кто чем занят, успеем ли к сроку? Понятно, что так долго не продержишься. Особенно когда заказчики начинают требовать точных дат поставок, а ты не можешь точно сказать — получится или нет.
Было принято решение: пора внедрять систему планирования. Не готовую, типа 1С УНФ, а свою — под нашу специфику. Потому что:
- Изделия большие, сложные, собираются из множества деталей.
- Одни детали уже есть на складе, другие нужно изготовить перед сборкой.
- Работы выполняются разными бригадами, у каждой — своя специализация и загрузка.
- Есть приоритетные клиенты, есть жёсткие сроки.
- Хотелось видеть прогноз — попадаем мы в эти сроки или нет.
Мне поставили задачу: сделать систему, которая будет формировать ежедневный план работ для каждого цеха, учитывая все эти факторы.
Первым делом я встретился с главным инженером. Хотел понять, как на самом деле работает производство, какие этапы есть у каждого изделия, как сейчас распределяются задачи. Оказалось, что за всей кажущейся хаосом стоит логика — просто записанная в головах людей и паре Excel-файлов. Файлы были красивые разноцветные. В них даже велась переписка: одна бригада оставляла сообщения новой бригаде о производственных процессах.
На основе этого были выделены ключевые требования:
- Планирование должно начинаться с готового изделия (например: «К 19 ноября клиент А должен получить изделие»).
- Система должна разложить это изделие на комплектующие и операции.
- Должна учитываться загрузка бригад (шаг в 5 минут).
- Бригады могут быть разной численности и специализироваться на разных типах работ.
- Важно иметь возможность менять приоритеты и перераспределять задачи.
Так-же заказчик ставил свои требования к реализации. Например это должен был быть документ "Планирование производства" , который станет основой системы.
Документ должен был содержать:
- Список клиентов и их заказов.
- Перечень изделий, которые нужно произвести.
- Даты поставок.
- Детализацию этапов производства по каждому изделию.
- Привязку операций к бригадам.
- Возможность расчёта загрузки по времени.
- Гибкость в изменении приоритетов и сроков.
Если документ проведен — система использует его для планирования. Если не проведен — работает как раньше, без учёта этих данных. Такое разделение позволит внедрять систему поэтапно, безболезненно для текущих процессов.
Часть 2: Создание документа и выбор логики
После того как стало понятно, что именно нужно автоматизировать, началась реализация. Всё должно было строиться вокруг одного ключевого элемента — документа «Планирование производства» .
Структура документа
Документ должен был содержать три основные части:
- Общие данные : клиент, изделие, дата поставки.
- Состав изделия : список всех комплектующих, наличие на складе, что нужно изготовить дополнительно.
- План работ : привязка операций к бригадам, расчёт времени выполнения, периоды работ.
Это позволило объединить в одном месте всё необходимое для формирования плана: кто заказчик, что нужно сделать, из чего это состоит и кто этим будет заниматься.
Подход к распределению работ
Каждое изделие собирается из множества деталей, а каждая деталь проходит через несколько этапов обработки: механическая обработка, сварка, покраска и т.д. Эти этапы выполняются разными бригадами, у которых есть свои рабочие часы, график занятости и ограничения по количеству одновременных задач.
Значит, нужен был алгоритм, который сможет:
- Пройти по всем изделиям.
- Разложить их на дерево комплектующих.
- Сформировать список операций.
- Распределить эти операции по бригадам.
- Учесть текущую загрузку каждой бригады.
- Проверить, успеваем ли мы к сроку поставки.
Вариантов реализации было несколько. Один из самых простых — последовательный перебор данных и выстраивание плана работ по свободным периодам.
Реализация в 1С
Работа велась в 1С: Предприятие 8.3 (толстый клиент) . Это важно, потому что ограничивает возможности по скорости и сложности алгоритмов. Значит, всё должно быть просто, но эффективно.
Я решил хранить данные о плановых работах в регистрах сведений:
- "План работ по бригадам" — фиксируем, какая операция, когда и какой бригадой должна выполняться.
- "Загрузка бригад" — считаем процент занятости и свободное время.
Эти регистры позволили строить графики нагрузки и отслеживать конфликты.
Что дальше?
На этом этапе у меня уже был документ и базовая логика, как будут формироваться данные. Но сам механизм распределения задач ещё только предстояло реализовать.
Часть 3: Полная реализация системы
Когда стало понятно, что именно нужно автоматизировать, началась реализация всей системы целиком. Основной задачей было не просто создать документ и механизм распределения задач, но и связать всё это с уже существующими частями конфигурации: учёт материалов, выпуск продукции, движение по складам и контроль исполнения.
Документ «Планирование производства»
Основным элементом системы стал документ «Планирование производства» . Он состоял из трёх вкладок:
- Общие данные : клиент, изделие, дата поставки.
- Состав изделия : список всех комплектующих, наличие на складе, что нужно изготовить дополнительно.
- План работ : привязка операций к бригадам, расчёт времени выполнения, периоды работ.
Если документ проведен — система учитывает его при формировании плана. Если нет — работает как раньше, без учёта этих данных. Такое разделение позволило внедрять систему поэтапно, безболезненно для текущих процессов.
Алгоритм распределения задач
Для каждой бригады проверяется график занятости. Ищется свободный временной интервал, достаточный для выполнения операции. Если такой интервал находится — задача закладывается туда.
Алгоритм работает так:
- Из документа собираются все изделия.
- Для каждого строится дерево комплектующих.
- Формируется список операций.
- Операции группируются по типам (обработка, сварка и т.д.).
- Перед распределением задачи можно отсортировать:
- По дате поставки
- По приоритету клиента
- По длительности операции
- По типу работ
Это позволяет гибко менять логику в зависимости от ситуации.
График нагрузки
График строился на основе регистра сведений "План работ по бригадам" . Он показывал:
- Рабочие смены
- Запланированные операции
- Перегрузки
- Свободные периоды
Интервал времени — 5 минут , чтобы можно было точно оценивать доступность бригады под новые задачи.
Форма графика была сделана через элемент управления "Таблица", где каждая строка — это временной интервал, а цвет ячейки — степень занятости. Это не идеальное решение визуализации, но в рамках 1С 8.3 Толстый клиент — рабочий вариант.
Пользователь может выбрать нужный период, фильтр по цеху или типу работ. График обновляется в реальном времени при изменении плана.
Интеграция с учётом материалов
Реализовал связь с остатками на складах. Для каждой детали, которая входит в состав изделия, система проверяет:
- Есть ли она на складе.
- Если есть — можно использовать без дополнительного производства.
- Если нет — добавляется задача на её изготовление.
Также был добавлен механизм резервирования. Когда изделие попадает в план, система помечает необходимые материалы как "зарезервированные". Это помогло избежать ситуаций, когда две бригады начинают использовать одни и те же детали на разные заказы.
Связь с выпуском продукции
После того как операция выполнена, мастер закрывает её в соответствующем документе. Эта информация записывается в регистры и используется для:
- Обновления остатков на складе.
- Контроля исполнения плана.
- Пересчёта графика нагрузки (после завершения одной задачи освобождается время для следующей).
Также была реализована обратная связь: если какая-то операция задерживается, система отмечает это и пересчитывает сроки по всем связанным задачам.
Контроль исполнения
Добавил механизм контроля исполнения:
- Для каждой операции фиксируется дата начала и окончания.
- При завершении сравнивается запланированная и фактическая дата.
- Если операция выполнена позже — система помечает это как отклонение.
На основе этих данных строились отчёты:
- По отклонениям от графика.
- По загрузке бригад.
- По причинам задержек.
Это дало возможность не просто видеть текущий план, но и анализировать, что работает хорошо, а что требует доработки.
Возможности ручной корректировки
Даже самый умный алгоритм не всегда угадывает, что нужно человеку. Поэтому я предусмотрел возможность ручной корректировки:
- Вручную изменить дату поставки.
- Скорректировать приоритет клиента.
- Переназначить задачу другой бригаде.
- Удалить отдельную операцию из расчёта.
- Сбросить план и пересчитать заново.
Это дало пользователям гибкость — если что-то пошло не так, они могли быстро вмешаться и исправить ситуацию.
Часть 4: Итоги
После нескольких недель работы система была готова. Она представляла собой не просто набор документов и регистров, а полноценный механизм планирования, интегрированный с уже существующими процессами учёта и производства.
Что получилось
Система позволила:
- Формировать план работ автоматически , на основе документа «Планирование производства».
- Распределять задачи по бригадам , учитывая их загрузку и специализацию.
- Строить график нагрузки , который показывает занятость, перегрузки и свободные периоды.
- Интегрироваться с учётом материалов , проверяя наличие деталей на складе и добавляя задачи на изготовление недостающих комплектующих.
- Контролировать исполнение , сравнивая плановые и фактические даты выполнения операций.
- Видеть прогноз по заказам , чтобы заранее понимать, успеваем ли мы к сроку или стоит предупредить клиента о задержке.
- Резервировать материалы , чтобы избежать ситуации, когда две бригады начинают использовать одни и те же детали на разные заказы.
- Вручную корректировать план , если алгоритм не угадал приоритеты или произошли внешние изменения.
Время работы системы
Расчёт плана занимал около 5 минут . Это время было приемлемым для текущих задач. Попытки вынести расчёт на Java рассматривались, но были отложены — проще поддерживать всё в рамках 1С.
Как это помогло производству
- Мастера больше не собирали информацию по Excel-таблицам — теперь вся информация в одном месте.
- Не нужно было каждый день звонить по цехам , чтобы узнать, чем заняты бригады.
- Появилась возможность видеть план на год вперёд , а не только на завтра.
- Удалось увидеть реальные узкие места : какие бригады перегружены, а какие могут взять дополнительные задачи.
- Снизились ошибки из-за нехватки комплектующих — система сама отслеживает, что готово, а что ещё нужно изготовить.
Выводы
Создание системы планирования с нуля заняло около месяца. Не потому что задача была простой, а потому что подход был правильным:
- Сначала поняли, зачем это нужно.
- Затем определили, как будет работать система.
- Потом реализовали документ и алгоритм.
- И только потом связали всё с остальными частями конфигурации.
Система не идеальная, но она работает. А главное — решает конкретные задачи:
План формируется автоматически.
Бригады знают, что делать.
Руководители видят картину целиком.
Клиенты получают изделия вовремя.
Считаю ли я свою систему совершенной? О нет. Во первых я не сторонник выдумывать решение с нуля, если есть на рынке много альтернатив, с более, возможно, удачной проработкой. Во вторых, я понимаю так-же, что с ростом производства мое планирование будет рассчитываться ощутимо дольше. Вероятно все-же стоило перенести расчетную часть на java. Но в данной ситуации при данных условиях такое решение оправдано. Возможно эта статья поможет тем, кто столкнется с подобными сложностями что и я, и поможет обойти те трудности с которыми пришлось столкнуться мне.
