Как да интегрирате OEE данни с вашата ERP без тежка ИТ работа

Вашите OEE данни са в една система, а поръчките в друга. Някой поиска двете да се срещнат и първата оферта често споменава middleware и дълъг проект.

Може да нямате нужда от това. Тази страница е стълба с четири степени.

За всяка от тях получавате оценка на усилието, кой я прави и знакът, че сте я надраснали.

Три въпроса преди която и да е степен

Попитайте първо тези. Отговорите решават колко високо трябва да се изкачите.

• Кое ERP решение се променя с тези данни? Калкулациите на себестойност, приключване на поръчки и планиране на капацитета изискват различни полета. Ако никой не може да назове решение, спрете тук.
• Колко късно могат да са данните? Приключването на поръчки често може да изчака до края на смяната. Решете това с човека, който използва числото.
• Кой коригира неуспешен ред? Назовете един човек. Връзка без собственик може да срива месеци, преди някой да забележи.

Стълбата накратко

Усилието на тази страница означава работно време за една проста еднопосочна връзка, след като картата на идентификаторите вече съществува. Изминалото време обикновено е по-дълго, защото одобренията и промяната на защитни стени отнемат собственото си време.

Стъпките описват методи общо. Те не ви казват какво точно носи всеки продукт, затова проверете това при доставчика.

Стъпка 1: Excel или CSV файл

Експортирайте данните, проверете ги и след това ги импортирайте в ERP. Ако ERP няма безопасен импорт, контролер може да въведе сумите от файла ръчно.

Това се брои като интеграция. Двете системи сега се срещат по график и вие научавате кои полета наистина имат значение.

• Кой: планиращ или контролер, с администратора на ERP за първия импорт.
• Усилие: най-малкото. Един тестов импорт за настройка, след това кратка ръчна процедура всеки път.
• ИТ работа: почти никаква, след като импортът е разрешен.

Много ERP системи имат инструмент за импорт, така че попитайте администратора какво предлага вашият. Един пример: data import and export jobs в Dynamics 365 finance and operations приемат Excel и делимитирани файлове, могат да използват временни таблици за предварителна проверка и показват неуспешни записи в историята на задачата.

Също така попитайте какво задейства публикуваният ред: движения на склад, разходи или статус на поръчката. Изпробвайте го на тестова поръчка, преди да му се доверите.

Преминете нагоре когато: изпълнението е закъсняло или пропуснато, някой преписва колони ръчно или човекът, който го прави, излезе в отпуск и това спре.

Стъпка 2: Zapier

Zapier прехвърля данни между приложения, когато се случи нещо, без код. Напреднал потребител може да създаде поток, например „когато дойде това събитие, добави ред в листа, който планиращият импортира“.

• Кой: напреднал потребител в операциите или финансите.
• Усилие: малко. Един поток, над импортния път от степен 1.
• ИТ работа: малко, но вашите данни сега минават през още една компания, така че попитайте ИТ първо.

Прочетете ограниченията преди да изградите:

• Webhooks by Zapier не е в всички планове на Zapier и има ограничения за полезния товар и скоростта. Проверете това, ако вашият поток го използва.
• Една заявка с няколко записа може да стартира отделно изпълнение на всеки запис, което се натрупва при натоварена линия.
• Ако достигнете лимита на таскове, изпълненията се задържат, не се губят. Трябва някой да забележи и да ги пусне отново, когато тасковете са налични.

Преминете нагоре когато: вашият ERP няма път от Zapier, ограниченията започнат да пречат или ИТ не приеме трета страна в пътя.

Стъпка 3: webhooks

Webhook е push: източникът изпраща данни до ваш адрес, когато се случи събитие. Подходящ е за единични събития повече отколкото за сборове.

Кои събития изпраща дадена система е въпрос към нейния доставчик.

Малка програма получава събитието, проверява го и го предава на ERP.

• Кой: някой, който може да напише и хоства малка програма.
• Усилие: реално. Трябва да се напише, хостне и поддържа малка програма.
• ИТ работа: реална. Облачна система трябва да може да достигне вашия адрес, което може да означава обсъждане на защитна стена, ако ERP работи на място.

Слабият момент е тишината: webhook може да се провали тихо, ако вашият адрес е недостъпен и подателят не прави повторни опити.

Вашата програма трябва да обработва повторни опити, да проверява подписи и да записва какво е неуспешно.

Преминете нагоре когато: пропуснато събитие ви струва пари или финансовият отдел се нуждае от сборове, които да се балансират в края на смяната.

Стъпка 4: планирана REST API задача

Задача се изпълнява по график, например в края на смяна. Тя изтегля данните, групира идентификаторите, публикува в ERP и записва резултата.

• Кой: разработчик или интегратор.
• Усилие: най-голямото, главно картографиране и тестване на неуспехи. Очаквайте повече, ако ERP няма готово API за това, което публикувате.
• ИТ работа: планирана, с данни за достъп, хостинг и назован собственик.

Тази степен е по-тежка за изграждане, но може да е по-лесна за работа от степен 3. Извличането е обичайният избор когато не можете да приемете входящи заявки или трябва да синхронизирате цялото състояние по график.

Тъй като задачата извиква вън, може да не се налага ново отваряне на защитната стена за входящи връзки.

Изградете я така, че повторното изпълнение да е безопасно. Използвайте номер на поръчка, работен център, дата и смяна като ключ, така че публикуването два пъти да не удвоява бройките.

Много ERP системи добавят нов запис вместо да обновят стария. Ако вашият прави това, накарайте задачата да провери за ключа преди публикуване.

Преминете нагоре когато: имате нужда от нещо, което еднопосочна задача не може да направи, като двупосочна синхронизация с правила за конфликтите. Това е персонализиран интеграционен проект и тук „тежка ИТ“ е справедливо описание.

Задачата, която нито един инструмент не върши: картата на идентификаторите

Машината, наречена Line 3 във вашия завод, има различен код в ERP. Никакъв конектор няма да оправи това сам по себе си.

Създайте една таблица преди да изградите каквото и да е:

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

За по-широкия въпрос кой притежава кой обект, прочетете това ръководство за потоците данни и собствеността между MES, OEE и ERP.

Къде стои Fabrico на тази стълба

Ние продаваме Fabrico, лек MES за OEE и време на престой, така че теглете този раздел със съзнанието за това. Ето маршрута, който той предлага за всяка степен:

• Степен 1: всеки списък се експортира в Excel или CSV и данните могат да се импортират масово от Excel.
• Степен 2: Zapier.
• Степен 3: webhooks.
• Степен 4: REST API.

Над стълбата тези ERP връзки съществуват:

• SAP PM: синхронизира се и в двете посоки. SAP PM е модулът за поддръжка на SAP, така че не го читайте като потвърждение за производство.
• SAP S/4HANA: Fabrico се свързва с него. Съгласувайте кои обекти са в обхвата преди да планирате около него.
• Microsoft Dynamics или Oracle: свързани чрез персонализирана интеграция, така че третирайте това като проект, а не като превключване.

Други системи се свързват чрез webhooks, REST API или Zapier. Днес няма конектор за Epicor или AVEVA PI.

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

Какво Fabrico не прави: разпределение на задачи, BOM, маршрутни листи и генеалогия остават в ERP, а планирането на производството не е част от него. Ако се нуждаете от това в една система, Fabrico не е то.

Данните идват от машината: PLC през OPC UA, Modbus, PROFIBUS, PROFINET, EtherNet/IP или EtherCAT, IoT устройство с сензори на по-стари машини или AI камера там, където няма машинен сигнал.

Операторите маркират причините за спиране на таблет или телефон. Вижте прегледа на Fabrico MES и OEE.

Fabrico е облачен софтуер и приложението няма офлайн режим, така че приложението изисква работеща връзка на линията. Ако връзката прекъсне, gateway буферира машинните данни за период по споразумение с вас, по подразбиране до 30 дни.

Планирайте около 1 месец за инсталиране и свързване на устройства и 3 до 4 месеца за пълно разгръщане. ERP връзката може да последва, след като данните от линията са доверени.

Поискайте демо или Свържете се с нас и ни кажете кой ERP използвате.

Чести грешки

• Изпращане на сурови спирания. ERP няма полза от 40-секундно спиране. Изпращайте обобщения.
• Първо изграждане на пълна двупосочна синхронизация. Настройте първо един поток правилно, преди да добавите следващия.
• Пропускане на паралелно изпълнение. За определен период, например две седмици, сравнявайте добрата бройка в двете системи за всяка поръчка и оставете стария начин да работи.
• Няма правило за несъответствие. Съгласувайте толеранс и коя система печели, когато разликата е по-голяма.
• Доверие на думата „интегрирано“. Може да означава всичко от живо четене до нощен файл. Попитайте за списъка с полета.

Най-малкият набор от данни за изпращане

На която и да е степен да сте, започнете с тези полета. Всичко останало може да почака, докато някой не поиска.

Изпращайте съставките, не процента OEE

Процентът не може да се сумира или просто усредни.

Пример: 80 процента OEE за 8 часа и 40 процента за 2 часа изглежда като 60 процента при простото средно. Претеглено по време, това е 72 процента.

Изпращайте бройки и минути, за да може отчетът да изчисли правилно наличността и качеството.

За да пресъздадете пълното OEE, също се нуждае от идеално циклово време за всеки продукт. Вижте OEE calculation за това как се комбинират тези части.

Пример: една поръчка, две смени

ERP поръчките често преминават през смяна, докато OEE обикновено се чете по смени. Затова изпращайте по един ред на поръчка и смяна и нека редовете се сумират до поръчката.

Преди да строите по която и да е степен, проверете дали вашата OEE система може да произведе тези седем полета.

Номерът на поръчката е обичайният пропуск. Данните могат да се разделят по поръчка само ако нещо записва коя поръчка е работила кога, като списък на поръчките от ERP или човек, който отбелязва началото и края.

Решете това първо.

Какво хората питат след това

Кой инструмент да купя за синхрон в реално време?

Попитайте първо кое ERP решение го изисква. Ако числото се използва в края на смяна, задача в края на смяна е по-проста и по-лесна за проверка.

Ако ви трябва инструмент, типовете са no-code автоматизационни инструменти, интеграционни платформи за връзка на много системи и персонализирана задача, изградена от интегратор.

Използвайте по-бърз път за единичните събития, където забавянето ви струва.

Може ли без никакво ИТ?

Степен 1 е близо, а степен 2 изисква лека проверка. Степени 3 и 4 изискват някой, който програмира, и човек, който притежава резултата.

Казвайте на ИТ рано и при двата варианта, защото правата за импорт и трансфери на данни са тяхно решение.

Трябва ли ERP данните да текат и в OEE системата?

Често да, и списъкът с поръчки може да е първи, защото ред по поръчка трябва да знае коя поръчка е работила. Продукти и главни ID са други обичайни кандидати.

Дръжте го малко: една линия и само данните, нужни за следващата стъпка.

Нашето ERP не е назовано на тази страница. Закъсани ли сме?

Не. Файл, webhook или API задача имат нужда от начин да влезе в ERP, а не от назован конектор.

Попитайте администратора на ERP какви импорти съществуват и след това поискайте списъка с полета от доставчика на OEE.

Какво да проверя при сравнение на OEE инструменти за това?

Искайте примерен експорт, списък с полета и какво се случва с неуспешен ред. За още тестове на връзка вижте OEE software integration with MES, SCADA and PLC.

След това използвайте това ръководство за OEE software categories за да изградите шортлиста.

Искате да видите коя стъпка подхожда на вашето съоръжение? Поискайте демо или Свържете се с нас.