Внедрение ERP на предприятии. Этап 3 – сменное задание из ERP в SCADA.

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

На данном этапе внедрения нам становится недостаточно информации из работающих сменных заданий: ДСЕ + количество. Теперь нам необходимо точно указать, на каком станке будет выполняться, та или иная деталь. Если этого не сделать в сменном задании, то это всё равно придется сделать мастеру, но уже в оперативном режиме, скорее всего устно раздавая задачи каждому рабочему. И следов от этой работы в системе не останется, как и не будет возможности заранее подгрузить в SCADA программу для выполнения операций с ДСЕ

Предыдущая статья: Внедрение ERP на предприятии. Этап 2 – SCADA.

Ежедневное, а точнее – ежесменное получение такой информации возможно только при наличии контроля движения ДСЕ по всей цепочке изготовления.

Каковы цели?

• Определить точки контрольных операций.
• Определить и установить партии передачи деталей между операциями.
• Перенос сменного задания из ERP в SCADA.

Что имеем?

В ERP из PLM передаются:

• пооперационные технологии;
• нормы отпуска материалов и комплектность отпуска ДСЕ;
• нормы времени выполнения операций и переналадки;

В ERP ведется:

• поступление и отпуск МКИ на материальных складах;
• поступление и отпуск ДСЕ на складах деталей и сборочных единиц;
• сменное задание в формате: ДСЕ + количество к изготовлению за смену + 100% обеспечен МКИ и/или ДСЕ.

В SCADA из PLM передаются:

• программы на операции с ДСЕ для станков ЧПУ.

В SCADA ведется:

• подсчет количества изготовленных ДСЕ.

Что делаем?

Определить точки контрольных операций.

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

Что вообще такое – контрольные точки. Речь идет об операциях, прохождение которых является некоей вехой выполнения ДСЕ, как правило, к таким точкам относят:

• операции, на которых по техпроцессу осуществляется контроль каких-либо параметров ДСЕ на точность изготовления;
• операций с технологически заложенным процентом технологического отхода;
• технологически сложные или длительные по времени операции;
• операции, выполняемые в рамках программы станка ЧПУ;
• операций, с наиболее часто возникающим браком.

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

Определив перечень операций, подлежащих оперативному контролю в ERP, Вы начинаете формировать список групп операций, подлежащих контролю:

• список последовательных операций, лежащих между предыдущей операцией контроля и последующей;
• это список включает в себя и одну из контрольных операций, как правило – последующую, т.е. ту, которой заканчивается список.

И хотя это прозвучит не очень логично, потому что группы операций для контроля нужны именно и только в ERP, однако идеальным решением является выделение и отметка таких групп не в ERP, а в PLM. Это связано сразу с несколькими моментами:

1. если в части нормативной базы, эталоном которой является PLM, возникают расхождения или появляется дополнительная объективная информация об НСИ только в ERP, то дальнейший перенос данных НСИ из PLM в ERP начинает обрастать особенностями и исключениями, которые рано или поздно приведут к конфликту переноса или противоречию в данных;
2. даже если удастся избежать конфликтов интеграции между системами, то любое изменение технологии в PLM после бесконфликтного переноса изменений в ERP потребует от технологов производства, как минимум полного просмотра всего маршрута на предмет влияния новых операций или удаленных операций на изменение состава групп контрольных операций.

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

Что я имею ввиду?
На многих предприятиях при внедрении ERP на производстве отметки о прохождении операций осуществляют плановики, или распреды, или специально обученные операторы, нанятые только и исключительно для этой работы (наихудший вариант решения вопроса). Всё это является следствием опережающего темпа внедрения относительно готовности ИТ инфраструктуры.

Если мы хотим получать в ERP данные о прохождении операций оперативно (с наименьшим промежутком времени между фактическим выполнением операции и заведением данных об этом в систему), то нам необходимо:

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

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

• доверие – наиболее распространенный аргумент. Рабочий заинтересован в том, чтобы сдать как можно больше деталей в объеме максимально близком к тому, что разрешено закрывать в течение планового периода. Этот подход часто расходится с реально изготовленным объемом и по этой причине, информация, в частности об объеме брака и фактически изготовленном объёме идет с большим искажением или просто скрывается сколько возможно;
• брак – что происходит при участии рабочего, описано чуть выше, однако не лучше картина обстоит и при автоматическом подсчете деталей. Даже при самом точном методе подсчета, через программу ЧПУ, мы получим в качестве результата общий объем деталей, изготовленных на станке, без учета брака и техотхода, что является искажением реального хода производства и фактически переданного объема на следующую группу операций;
• потеря времени рабочим на ввод, относится к непроизводственным потерям и при большом числе разных деталей с малым временем выполнения суммарно может составить вполне измеряемую и подлежащую учету величину, сопоставимую по времени с изготовлением какой-либо ДСЕ. При любой оптимизации по Lean – это будет первое, что попадет под «оптимизацию» процесса, не порождающего стоимости (да – применение Lean тупо и в лоб, как это часто бывает, выглядит довольно плоско).

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

• именно он будет отвечать за сдаваемый объем изготовленных ДСЕ на другой участок или склад ДСЕ, где количество будет перепроверено и пересчитано;
• именно он будет сдавать детали в изолятор брака, подписываться под ним и техотходом;
• именно ему рабочие будут задавать вопрос – почему мне столько заплатили, и именно он будет первой инстанцией, обязанной объясняться по столь неудобным вопросам с рабочими;
• и именно он будет сигнализировать о ненормальной работе оборудования, некачественном МКИ, отсутствии или изношенном инструменте и т.д.

Иными словами, баланс обстоятельств требует от него объективной информации об изготовленном объеме, хотя даже в этих условиях, при недостаточном контроле, скажем за расходом материалов или загруженностью оборудования, мастера умудряются давать ложные данные, имея возможности наверстать объемы за счет перерасхода МКИ, сверхурочных часов, или завышенных норм.

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

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

Результат подпункта.

После проведения этой работы в ERP имеются:

• группы операций, которые подлежат отметкам в ERP;
• контрольные операции, которыми заканчивается каждая группа операций и после прохождения которых должны проставляться отметки в ERP.

На реальном производстве:

• список должностей, привязанных к организационной структуре, ответственных за ввод данных в ERP;
• выделенные места размещения технических ИТ средств ввода данных в ERP.

На планировке:

• отметки мест, для подвода и размещения элементов ИТ инфраструктуры.

Определить и установить партии передачи деталей между операциями.

Ни одна деталь, если мы на конвейерной сборке, не передается на следующий этап изготовления сразу после выполнения предыдущей операции. Для перемещения детали на следующую операцию (группу операций), т.е. к следующему рабочему месту необходимо осуществить транспортировку ДСЕ к следующей единице оборудования. Даже если станок, следующий в цепочке изготовления ДСЕ, стоит буквально в двух шагах, нет практики передачи каждой детали. Это связано с тем, что циклы обработки ДСЕ (т.е. суммарное время выполнения операций над ДСЕ) на каждой конкретной единице оборудования разные и передача ДСЕ в режиме реального времени будет вызывать простои на единицах с короткими циклами. Для того, чтобы нивелировать разное время выполнения операций на разном оборудовании в цепочке изготовления – рассчитывается или определяется опытным путем оптимальная партия передачи ДСЕ между единицами оборудования.

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

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

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

Я не знаю, кто это придумал на самом деле, не удивлюсь, если в СССР в 60-х годах, однако сейчас это пропагандируют японцы в рамках реализации Lean мероприятий. В ходе анализа времени процесса производства, которое не добавляет стоимости, они выявили устойчивые потери после и перед каждой операцией (группой операции) на любых деталях и изделиях. Это были потери времени на пересчет деталей при  передаче и приёме партий ДСЕ.

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

Японцы предложили довольно не дешевый, но очень эффективный путь решения данной проблемы:

• сделать ящики для каждой ДСЕ с дискретным количеством под партии передачи;
• на дне ящика сделать места под профиль заготовки ДСЕ;
• изготовить для каждой ДСЕ такое количество ящиков, которого достаточно для постоянного проведения в них ДСЕ при стабильной программе изготовления.

В чем суть:

• дискретность – полностью заполненный деталями ящик должен быть подъемным по массе и по габаритам без дополнительных приспособлений, а детали должны лежать в один слой или два визуально просматриваемых, друг на друге;
• профиль под заготовку – детали должны ложиться каждая в свою ячейку, т.е. профилей в ящике должно быть столько же, сколько штук ДСЕ в партии передачи или дискретно меньшее значение (зависит от размера и веса ДСЕ). Например, в партии передачи 20 штук ДСЕ, значит ящик может быть либо под 4, либо под 10, либо под 20 штук – т.е. при любом раскладе с полным заполнением перед передачей на следующий этап изготовления;
• подсчет – не числа ДСЕ в ящике, я беглый визуальный осмотр пустых ячеек ящика.

Звучит очень красиво, правильно, просто и понятно!

Однако, на деле, всё куда сложнее. Количество такой тары будет довольно большим. Вы можете посчитать сами. Для примера возьмём какую-нибудь одну ДСЕ на одном участке. Представим, что вся ДСЕ делается именно на нём, и на выходе сдается на склад ДСЕ для передачи в другой цех. В цепочке изготовления участвует пять станков при партии передачи между каждым станком 20 шт. и стабильной программе. Мы получаем, что у каждого станка должно стоять:

• один ящик с деталями, пришедшими с предыдущей операции или с другого участка;
• один ящик, куда складываются детали, прошедшие обработку на этом станке, т.е. ящик под передачу на следующий станок.

Итого: 5 станков x 2 ящика на станок = 10 ящиков. Хм..

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

• ящики имеют свойство ломаться и требовать ремонта или изготовления нового в замен сломанного;
• ДСЕ могут менять форму (это просто надо учесть в размере ячейки);
• появляются новые ДСЕ и снимаются с производства старые.

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

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

Результат подпункта.

Определены партии передачи каждой ДСЕ на каждом участке и заведены в ERP.
Подготовлена необходимая тара для транспортировки ДСЕ по маршруту техпроцесса.

Перенос сменного задания из ERP в SCADA.

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

Что нужно в новом сменном задании:

• ДСЕ;
• группа операций в ДСЕ;
• количество ДСЕ;
• станок для выполнения групп операций.

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

• мастер выбирает в ERP ДСЕ для включения в работу следующей смены и указывает, какое количество хочет сделать;
• по этой ДСЕ ему показывается набор групп операций, доступных для обработки по маршруту на его участке. Он выбирает нужную группу операций;
• к этой группе операций автоматически подставляется оборудование, так как связь ДСЕ-первая операция группы-инвентарный номер единицы оборудования приходит к нам из PLM;
• поскольку у нас в ERP есть нормы изготовления, то система автоматически подсчитывает, какое количество времени от смены (8 часов) займет выполнение указанного количества выбранных операций для конкретной ДСЕ с учетом времени пролёживания до формирования количества соответствующего установленной партии передачи;
• дальше, тот же набор процедур и операций при формировании плана на смену, который был описан в складском учете.

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

Для этого Вам необходимо сделать интеграцию из ERP в SCADA по данным:

• ДСЕ;
• код группы операций;
• инвентарный номер станка для выполнения операций над ДСЕ;
• код программы ЧПУ к группе операций;
• количество к изготовлению.

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

Поскольку двустороннюю интеграцию PLM со SCADA по переносу программ для станков ЧПУ мы выполнили в предыдущей статье, то перенос данной информации позволит SCADA:

• автоматически подставлять нужную программу для выполнения при выборе ДСЕ + код группы операций;
• показывать для каждого станка только те ДСЕ и группы операций, которые назначены для выполнения в смену именно на этом станке.

Это позволит рабочему, после выбора станка в SCADA, на котором он будет работать в эту смену, увидеть не весь список ДСЕ на эту смену, а довольно короткий список работ именно на этом станке. Это сильно сократит время подготовки рабочего к выполнению операций.

Однако, на крупных предприятиях в формировании сменного  задания всё не так однозначно, как описано выше:

• на одном участке может находиться сразу несколько единиц оборудования, на которых могут быть выполнены выбранные операции над ДСЕ;
• в PLM и соответственно в ERP однотипные единицы оборудования в рамках одной организационной единицы могут быть объединены в группы, для упрощения работы с ними. В одну группу часто будут включены несколько единиц оборудования.

Это грозит серьезным ростом нагрузки на мастера!

Разница во времени, между:

• выбором ДСЕ + указанием количества к изготовлению (прежние требования к данным сменного задания);
• и выбором ДСЕ + указанием количества к изготовлению + выбором группы операций изготовления + выбором конкретного станка из открывшейся групп оборудования (новые требования к данным сменного задания);

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

В этом случае Вам придется серьезно задуматься об:

• организационной трансформации для выхода на нормы управляемости – 5-7 человек это управляемый и контролируемый коллектив;
• искусственном увеличении численности в местах с выполненной нормой управляемости, но чрезмерным объемом суточных ДСЕ-операций.

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

Как бы то ни было, сменное задание должно быть трансформировано и вестись в ERP – этот уровень дисциплины необходимо, как минимум сохранять!

Результат подпункта.

В ERP получено сменное задание с привязкой к конкретному станку на участке.
Создана интеграция из ERP в SCADA для автоматического переноса сменного задания в SCADA.
Сменное задание автоматически переносится в SCADA из ERP.
Рабочий видит только короткий список ДСЕ к выполнению именно на той единице оборудования, на которой он будет работать текущую смену.
Программа ЧПУ автоматически подгружается на станок из SCADA после выбора из сменного задания конкретной ДСЕ-операции к выполнению.

Скорее всего, увеличено число мастеров на участке, для обеспечения своевременного формирования сменного задания и контроля его исполнения в течение смены. Да, факты ставят под серьезное сомнение миф о том, что внедрение ERP, и вообще любой системы автоматизации, приводит к сокращению численности персонала. По факту, пока Вы идете к определенному уровню автоматизации, которая действительно позволит сократить персонал, Вам придется пройти стадию РОСТА – увеличения численности или нагрузки на персонал для обеспечения заведения в ERP необходимой, дополнительной (ранее не использовавшейся) информации, повышающей масштаб, достоверность и оперативность учета – т.е. того, ради чего система и приобреталась.

Следующая статья: НЗП и ДПЦ при внедрении ERP на предприятии.

Автор: Андрей Лабутин