1С:ERP 2 + Preactor APS Модель планирования производства для машиностроения


Сегодня мы кратко рассмотрим взаимодействие двух систем: ERP-системы и системы Preactor как системы оперативного планирования.


Начнем с исходных данных, которые у нас имеются в ERP-системе. В данной модели мы рассмотрим производство вилочного погрузчика. Данный ресурс спецификации на вилочный погрузчик, мы видим, что у нас описан производственный процесс с детализацией до участка. Есть материалы, которые потребляются и работы, причем, здесь указано, что шток, кабина и противовес еще и сами являются производимыми. Если мы перейдем в номенклатуру штока, то мы увидим, что у него действующая спецификация и ресурсная спецификация на шток тоже имеет свой технологический процесс. В рамках техпроцесса могут быть заданы еще и ограничительные ресурсы, которые являются тем самым барабаном при системе планирования барабан, буфер, веревка. Здесь задан, и мы можем видеть в ресурсной спецификации в производственном процессе на сборку заданная группа сборочных постов. То есть, система при планировании учитывает еще загрузку узких мест.

1.png

Мы понимаем, что мало ресурсных спецификаций. Надо еще создать заказы на производство, и заказы на производство детализировать до этапов на производство. Этапы на производство можно планировать по кнопке «Планировать» либо весь заказ, либо выбранные этапы. Результатом мы увидим, что на вилочный погрузчик или на шток появится конкретное время, которое будет определять начало и завершение данного этапа. Что здесь еще можно посмотреть? Визуально результат планирования в таком виде. Это по одному этапу и взаимодействие с другими этапами не представляется возможным посмотреть. Интерактивности хотелось бы побольше. Это то, что пока на данный момент есть. При этом мы можем говорить о том, что данные по этапам мы можем выгрузить в «Внешние системы оперативного планирования» Preactor и посмотреть, что можно с ними там сделать.

Переходим в систему планирования Preactor. Вот наши интеграционные вещи, с помощью которых мы загрузили исходные данные. Выглядят они следующим образом. Вот наша технология изготовления. Вот наш вилочный погрузчик. Он делается из пяти этапов производства: сборка, монтаж, заправка. На каждом из этапов указан участок, который может выполнить данную операцию, и указано то самое узкое место. В терминологии Preactor они являются вторичными ограничениями и указано, что 8 часов необходимо для данного вторичного ограничения. Так все необходимые номенклатурные позиции здесь загружены.
Ресурсная спецификация в части вхождения отражается в Preactor в справочнике «Спецификация». Мы видим, что кабина требует определенной комплектующей на входе и наш вилочный погрузчик тоже требует шток, кабину, противовес и так далее. Указано количество, все из управляющей ERP-системы.
Система Preactor может контролировать остатки, которые есть у системы. Это остатки, как по материалам, так и по деталям, узлам, агрегатам, незавершенное производство. Также система может предоставлять возможность контролировать директивные даты отгрузки, в частности, по готовой продукции. Мы видим, что надо по одному вилочному погрузчику отгрузить 16-18 марта. Этапы мы загрузили в соответствующий справочник «Этапы производства», та самая нумерация, которая у нас была, выпускаемая продукция по этапам и подэтапы, которые предполагаются по цехозаходам тоже здесь все есть.
Теперь мы можем перейти в окно планировщика и посмотреть, как это все будет выглядеть. Мы имеем перечень участков слева. Сверху временная шкала, чуть ниже снабжение, это наши остатки и будущие поставки. В нижней части – наши директивные даты отгрузки. Для того, чтобы нам построить расписание, есть несколько вариантов планирования. Ко всей совокупности, если мы сейчас не делаем никакой выборки, мы можем применить прямой порядок, причем, не просто прямой, а по приоритету, по дате исполнения, по файлу, если за нас уже ERP-система посчитала или по какому-то произвольному сочетанию. То же самое можно сделать в обратном порядке, от даты отгрузки точно в срок запланировать или же применять другие правила планирования, которые будут реализовываться в рамках проекта. В прямом порядке мы можем просто спланировать и получим следующую картину. У нас вся картинка перед глазами. Мы видим наши участки, видим какие группы этапов на каждый участок запланированы. Можем использовать такие методы подсветки в одну и другую сторону. Можем подсвечивать весь заказ для того, чтобы проанализировать, как у нас выполняется то или иное изделие. Если много будет участков, можем сделать компактный вид, все лишние участи будут устранены и при выборке определенного этапа у нас будут оставаться только те участки, которые задействованы в данном этапе. Это упрощает нам навигацию и работу.
Кроме того, что мы все можем спланировать в прямом или обратном порядке, мы можем делать и выборку. Мы можем выбрать только по признаку «Кабина» и какое-то действие применить к нему. В данном случае можем сбросить с доски расписание. Можем взять «Кронштейны», подсветить, сбросить. Затем к уже неспланированным операциям можем только кронштейны сейчас взять, и их спланировать, допустим, в обратном порядке. Таким образом, в обратном порядке или в прямом порядке.
Причем, система контролирует соблюдение техпроцесса. Если я что-то вручную начинаю динамически перестраивать, то система у меня проконтролирует этот процесс. Если я нарушил техпроцесс, я поставил предыдущую операцию позже, чем последующую, то мне система при проверке это явным образом скажет.
Есть механизм исправления, который позволит нам опять выровнять расписание и построить правильно техпроцесс. Кроме всей совокупности, я могу брать не только по производимым, а по этапам. Могу конкретно каждый этап брать и его планировать. Кроме самой диаграммы неразборчиво 08.47. есть другие варианты представления информации. Давайте мы ее в прямом порядке построим. Есть табличный, более удобный для анализа большого количества данных. Здесь можно сделать такие группировочки, допустим, по продукту и по этапу. Мы увидим, что мы делаем два этапа здесь, по кабине три этапа и так далее. Эти группировочки можно менять.
Следующий вариант – это графики. В графиках мы увидим использование наших узких мест. Здесь мы видим, что лентопильный станок у нас не используется, а группа сборочных постов используется. У нас максимум используется 8 из доступных 24 часов. Дальше загрузка ресурсов в графиках наших участков. В графическом виде все это можно посмотреть.
Следующий вариант представления информации – это диаграмма слежения. Особенность ее в том, что она позволяет не только в разрезе участков, но и по выпускаемой продукции посмотреть, допустим, как у нас делаются пластины, как у нас производство штока выполняется по времени. Удобство ее еще в том, что, давайте мы сейчас сделаем ситуацию, когда у нас что-то будет опаздывать, можно ее нормализовать. Мы с вами увидим относительно даты сдачи насколько далеко у нас то или иное опоздание. Здесь мы сразу видим «-1», здесь «-3 дня» опоздание. Таким образом, можем сразу принимать какие-то управленческие решения.
Следующий вариант представления информации, который здесь, во-первых, само по себе есть, во-вторых, как механизм, Preactor работает с остатками и будущими поставками в режиме реального времени. Для него будущие остатки точно так же, как текущие остатки имеют свое время, свое количество и они доступны именно в тот момент, когда они появятся. Мы видим производственный заказ, производственный этап, потребляет лист, который находится на складе. При этом пластина, выходящая из этого производственного этапа идет в другой производственный этап, производство петли и петля дальше идет в дверцу заднюю. Кроме пластины еще петля потребляется, и она сейчас видно, в дефиците. Петля показана в дефиците, и система явным образом вам это может сказать. Вот перечень дефицитных позиций, которые сейчас по данному набору данных необходимо восполнить.
Мы на один шаг углубились, еще раз провалились в производственный этап. Теперь мы видим выпуск дверцы, еще раз проваливаемся, доходим до кабины и вот такая уже у нас сборка контролируется Preactor, держится в оперативной памяти и это все в рамках каждого дня. По каждому этапу он помнит время начала и окончания, здесь указаны даты, когда это необходимо, а здесь указано, когда это будет произведено. 7 марта две кабины будут произведено. Дальше эти кабины идут в сборку окончательную вилочного погрузчика, такой техпроцесс, идет по датам и два остаются неиспользованными. Причем, здесь мы видим график будущих остатков в прогнозном режиме по этому расписанию. Мы видим, что какие-то заказы, какие-то этапы поднимают остатки, какие-то уменьшают. Так по всем входящим комплектующим.
Это расписание можно сохранить. Вариантов расписаний может быть несколько. Для анализа налету можно воспользоваться отчетом. Отчеты могут быть те, которые с системе поставляются, но на самом деле, их необходимо реализовывать под каждого конкретного заказчика. В данном случае, я открываю «Рисковые заказы», это заказы, которые заканчиваются в последний день, таковых у нас нет. А вот «Опаздывающие заказы» у нас есть, один заказ. В данном случае мы можем использовать отчеты, можем использовать различные представления информации и самое главное, что у нас в результате планирования появляется время, назначенное начало и завершение. Кроме этого, появляется назначенный участок. Эту информацию мы можем выгрузить в управляющую ERP-систему и таким образом, замкнуть цикл нашего планирования. В каждом конкретном этапе появится назначенное Preactor время начала, окончания и соответствующий цехозахват. Таким образом можно две системы интегрировать и получать максимум от тех возможностей, которые имеются на данный момент.