Управление производством в 1С:ERP

Материал — часть цикла «Управление производством в 1С:ERP» на вики-хабе ВЦ «Раздолье».

Несколько лет подряд типовой ответ на вопрос «а можно ли в 1С:ERP нормально управлять машиностроительным предприятием» звучал уклончиво. Можно, но с оговорками: требуется доработка, а также пара рабочих мест, написанных с нуля. Оговорки никуда не делись, но список их заметно сократился.

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

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

Два момента, которые вызывали сложности

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

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

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

Такой документооборот нормально работал только на очень быстром производстве: если продукция выпускается буквально за несколько дней. И, что более важно: все рабочие процессы должны устояться. Любое отклонение (в КД или в производстве) приводило к необходимости находить и корректировать большое количество заранее созданных документов.

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

Обходили всё это одинаково — писали обработки и рабочие места, которые корректировали и удаляли документы системы.

Из этой практики и выросла динамическая структура.

Статическая никуда не исчезла и отменять её не собираются. Но развивается только динамическая, и новые проекты имеет смысл делать на ней. Включается функциональной опцией в разделе «Производство». Старые заказы остаются статическими, новые становятся динамическими (фактически это признак внутри Заказа на производство).

Конвертации не предполагается. Старые заказы должны быть закончены по старой схеме.

Заказ в 1С:ERP — распоряжение на то, что нужно сделать. Фактически это – объект управления на уровне ПДО.

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

Сущность заказа на производство зависит от конкретного предприятия. В целом их можно разделить на два типа:

• Заказ клиента сформировал потребность. Если на складе нет продукции, то на основании Заказа клиента ПДО открывает Заказ на производство.
• Производство работает по плану. И Заказы на производство – это план на какой-то период (месяц/неделя/день).

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

В любом случае объектами управления будут именно заказы на производство, только создаваться они будут по-разному: на основании Заказа клиента или на основании потребности, или на основании планов производства.

Динамическая структура заказа — это «дерево», в котором описан производственный процесс. Корень дерева – продукция (или ДСЕ) из Заказа на производство. Ствол – производственные этапы из ресурсной спецификации. Ветки – полуфабрикаты со своими производственными этапами. Листья – потребность в материалах как самой продукции, так и полуфабрикатов.

Основное свойство дерева – перестроение «на лету». Купили материалы, или, наоборот, забрали на более приоритетный заказ ранее купленные – пересчет происходит сразу. Открыли большой «сводный» заказ на производство общеприменимых ДСЕ, «дерево» это увидело и учло, что часть «веток» будет им обеспечена, что ему не надо больше думать, как их производить.

Аналогичная ситуация с изменениями КД. Если были внесены изменения в ресурсную спецификацию, то программа проинформирует о необходимости пересчитать структуру. Изменения в КД по понятным причинам не отрабатываются автоматом. Если ПДО подтвердит, то программа пересчитает «дерево». При этом есть возможность остаться на старой схеме.

Преимущества схемы очевидны: динамическое «дерево» потому так и называется, что не формирует сразу тяжеловесных документов. Все пересчитывается «на лету».

Дерево строится по данным ресурсной спецификации, которая выбрана в Заказе на производство. В ней есть длительность производственного процесса, а также материальный состав. По каждому элементу из вкладки «Материалы» программа смотрит Схему обеспечения, на основании которой определяет, каким образом ТМЦ появится в производстве.

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

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

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

В первую очередь МПЗ будут резервироваться на заказы с «Высоким» приоритетом, потом – со «Средним» и т.д.

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

Но тут важно понимать, что до тех пор, пока МПЗ не забран, любой поступивший более важный заказ будет «расталкивать» менее приоритетные.

Исключение – обособленные МПЗ. Мы это будем дальше смотреть на примерах.

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

Когда приближается срок производства, то с помощью специального АРМ сотрудник ПДО формирует Производственные партии. Фактически – это знакомый нам по статической структуре документ «Этап производства». Но теперь он умеет собирать потребность в схожих деталях с разных заказов и объединять в одну партию.

Как только Этап появился, динамическая структура передает управление данной партией на уровень ПДБ. Его автоматом программа двигать или изменять не будет. «Дерево» будет ждать результатов его выполнения.

А вот если в процессе производства возникнут какие-то отклонения, подвижки по срокам и т.д., тогда система будет двигать остальную часть «дерева» в соответствии с отклонениями.

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

В схемах обеспечения у меня для материалов стоит одинаковый срок закупки: 30 дней + 1 день на перемещение.

Этапы в спецификации по плану идут 3 дня.

Введем Заказ на производство на 20 штук Продукции с датой начала – 26.08. На складах в данный момент у меня ничего нет.

Проведем и запланируем заказ. Получаем следующее дерево заказа:

Программа посчитала рабочие дни (31) на доставку материалов до кладовой. Определила, что производство Полуфабриката можно будет начать 09.10.

Плюс 3 рабочих дня. Значит, ПФ 1 появится на складе 13.10.

Так как склады выпуска и потребления совпадают, Этап 1 производства Продукции может быть начат сразу, 14.10.

Плюс по 3 рабочих дня на два Этапа. Получаем срок производства 21.10.

Теперь введем Заказ поставщику на М2 и М3 с датой поступления – 01.09.

Программа сдвинула структуру влево.

Однако поставила дату начала этапа 1 для ПФ – 06.10, а не 01.09. Давайте разберемся, почему.
Смотрим на Материал М1. Его в планах работ нет. Соответственно, теперь он держит начало этапа.
Добавим в заказ поставщику материалы 1 и 4. Смотрим структуру.

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

Теперь введем второй заказ на производство с более высоким приоритетом.

Как видим, он забрал на себя все нужные ему материалы.

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

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

Теперь предположим, что мы решили запустить отдельный заказ на производство для ПФ 1 с датой выпуска 17.09.

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

При этом логично предположить, что заказ 3 мы в эти сроки не сможем произвести, потому что материалы заняты приоритетным заказом № 2.

Программа это отслеживает самостоятельно и сигнализирует сотруднику ПДО о проблемах.

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

Картинка в форме календаря сигнализирует о необходимости пересчета заказа.

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

Теперь давайте по Заказу 3 сформируем производственные партии, то есть Этап производства.

Я начну этап и поставлю плановую дату выпуска – 10.09.

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

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

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