Як інтегрувати MES з ERP: погляд з виробничого цеху
Disclosure: M365.FM host Mirko Peters works at iFAKT GmbH. This page describes the company factually; paid partnerships and links are labelled as advertising.
By Mirko Peters ·
Як інтегрувати MES з ERP з боку MES: що цеху потрібно від ERP, що ERP потрібно отримувати назад, як узгоджувати майстер-дані та яких проєктних пасток уникнути.
Automatically translated with AI from the original post. Read the English original
Щоб інтегрувати MES з ERP, спочатку погодьте короткий перелік об'єктів даних і повідомлень, а потім створюйте їх у такому порядку: майстер-дані, випуск замовлень, зворотний зв'язок з цеху та обробка помилок. З боку MES завдання просте: отримати, що виготовити, і повідомити, що сталося. Складні частини в тому, що обидві системи мають однаково розуміти «номенклатуру», «операцію» та «завершено», а також у тому, що хтось повинен відповідати за помилки. Ця стаття призначена для керівників виробництва, які відповідають за боку цеху в проєкті.
Головне
- З боку MES інтеграція має два завдання: отримувати, що виготовити і з якими даними, та повертати, що сталося, у формі, яку ERP може провести.
- Повідомлення про замовлення і довідкові дані є різними потоками: в інтерфейсі Microsoft для MES продукти, специфікації матеріалів і маршрути отримуються окремо через сутності даних або OData.
- Перш ніж створювати будь-який інтерфейс, погодьте, що означає «завершено», як повідомляється брак і як працюють виправлення.
- Майстер-дані потребують власника, відображення ідентифікаторів і регулярної звірки, адже MES успадковує кожну помилку в маршрутах і часових нормах ERP.
- Навмисно тестуйте збої і визначте, хто бачить повідомлення, яке не пройшло, адже тиха черга відхилених підтверджень завершується розбіжностями в запасах.
Що MES потрібно від ERP?
Три речі, і передаються вони по-різному.
По-перше, замовлення. MES потрібні випущені виробничі замовлення з продуктом, кількістю, датами та пізнішими змінами статусу. В інтерфейсі Microsoft для сторонніх MES MES очікує бізнес-подію, коли замовлення випускається або змінює статус. Інші ERP-системи використовують інші механізми, але принцип той самий: ERP оголошує, MES забирає.
По-друге, довідкові дані. Це опис того, як виготовляти продукт: номенклатура, специфікації матеріалів, маршрути, часи налагодження. На тій самій сторінці Microsoft зазначено, що її повідомлення стосуються лише подій на виробничому майданчику і не містять майстер-даних. MES отримує продукти, специфікації матеріалів і маршрути з ERP через сутності даних або OData. Плануйте це як окреме інтеграційне завдання, адже саме його команди найчастіше забувають.
По-третє, інформація про ресурси. Стандарт ISA-95 визначає чотири види інформації, якими системи обмінюються між рівнем підприємства і рівнем операцій: матеріали, обладнання, фізичні активи та персонал з їхніми ролями і кваліфікаціями. Якщо ваш MES призначає роботи за навичками або за можливостями верстата, йому потрібна версія цих даних з ERP або з HR. Чітко визначте, яка система є джерелом.
Якщо ви використовуєте SAP, Dynamics 365 або будь-яку іншу ERP-систему, питання залишаються тими самими. Змінюються лише технічні назви.
Що ERP потрібно отримувати назад від MES?
Думайте про це як про підтвердження. Документація Microsoft описує для свого інтерфейсу такі процеси: початок замовлення, звітування про вироблену та браковану кількість, звітування про витрату матеріалів, звітування про час, витрачений на операцію, і завершення замовлення. Для кожного з них використовуються окремі типи повідомлень. Повідомлення про завершення потребує лише номера виробничого замовлення, а повідомлення про кількість містить рядки, які можуть включати позицію, кількість придатної продукції та причину браку.
Копіювати цю модель не обов'язково. Але перед створенням рішення вам треба визначити таке:
- Наскільки детальним має бути підтвердження? На рівні замовлення, операції чи зміни?
- Чи може оператор підтвердити часткову кількість і що з нею робить ERP?
- Як звітувати про брак і які коди причин існують в обох системах?
- Чи вимірюється витрата матеріалів на робочому місці, чи ERP розраховує її за специфікацією матеріалів?
- Як виправляти помилки: сторнуванням, коригуванням чи новим підтвердженням?
- Що означає «виготовлено», а що означає «завершено»? В огляді виробничих процесів Microsoft звітування про виготовлення додає товар до запасів, а завершення замовлення розраховує фактичну собестоимість і блокує подальші проводки з витрат. Ваша ERP може проводити межу в іншому місці.
Останнє питання викликає найбільше суперечок. Планування, фінанси та якість бачать один і той самий статус, і кожному з них від нього потрібне різне. Узгодьте визначення на короткій нараді з усіма трьома відділами, перш ніж хтось почне писати інтерфейс.
Як узгоджувати нормативно-довідкові дані між MES і ERP?
Замовлення є транзакціями. Нормативно-довідкові дані є описом вашого процесу, і MES успадковує кожну помилку в ньому. Маршрут, у якому операція тривалістю 12 хвилин насправді триває 20, виглядатиме як проблема продуктивності в цеху, поки хтось її не виправить.
Пройдіться цими пунктами для пілотної лінії:
- Визначте власника кожного об'єкта. Поширена домовленість така: ERP володіє номенклатурою, специфікаціями та маршрутами, а MES володіє налаштуваннями робочих місць і робочими інструкціями. Це рекомендація, а не правило. Важливо, щоб ніхто не мусив здогадуватися.
- Зіставте ідентифікатори. Робочий центр «WC-110» в ERP на виробництві може називатися «Press 3». ISA-95 навіть має для цього окрему частину: її модель служби псевдонімів визначає, як еквівалентні ідентифікатори пов'язуються та відображаються, згідно з описом стандарту від ISA.
- Порівняйте операції. Складіть перелік кроків у маршруті ERP і кроків, які оператори справді виконують. Розбіжності видно швидко, наприклад крок контролю або зачищення заусенців, який існує лише у цеху.
- Перевірте одиниці виміру, календарі та часові пояси. Штуки проти коробок і місцевий час проти UTC спричиняють тихі помилки.
- Встановіть правило змін. Коли інженерія змінює маршрут, хто повідомляє MES, як швидко ця зміна доходить і що відбувається із замовленнями, які вже виконуються?
- Повторюйте порівняння за графіком. Нормативно-довідкові дані з часом розходяться.
Ось гіпотетичний випадок. Маршрут в ERP має три операції, але оператори виконують п'ять, бо контроль і зачищення заусенців були додані багато років тому і ніколи не внесені до маршруту. MES може звітувати лише про те, що є в маршруті. Тож ERP показує операцію три як таку, що відстає, тоді як у цеху просто працюють над кроками, яких ERP не знає. Ніхто нічого не зробив неправильно. Дані неповні. Приклад вигаданий, але на виробництвах такі прогалини трапляються постійно.
Щодо форматів файлів, варто знати про B2MML. MESA описує його як набір визначень XML-схем, що реалізують ISA-95 і використовуються для інтеграції бізнес-систем, таких як ERP, з виробничими системами, такими як MES. Версія 7 додала першу JSON-схему. Використання опублікованої схеми дає спільний початковий словник, хоча не знімає потреби узгодити значення кожного поля.
Як інтерфейс має поводитися, коли щось іде не так?
Сценарій без помилок у демо спрацює. Витрачайте час проєкту на інші сценарії.
Документація Microsoft показує, як поводиться один продукт, і це хороший привід ставити питання власному постачальнику. Повідомлення для одного виробничого замовлення обробляються в тому порядку, в якому надійшли. Повідомлення для різних замовлень можуть оброблятися не по черзі, адже пакетні завдання виконуються паралельно. Повідомлення з помилкою повторно надсилається до трьох разів, а потім позначається як невдале. Сторінка моніторингу дає змогу переглядати, виправляти та повторно обробляти невдалі повідомлення, а сповіщення може повідомити ІT-адміністратора або начальника цеху.
Перетворіть це на чотири запитання для будь-якої пари ERP і MES:
- Що відбувається з підтвердженням, яке ERP відхиляє, наприклад тому, що замовлення вже закрите?
- Хто бачить помилку і як швидко?
- Чи може цех продовжувати працювати, коли ERP недоступна, і чи надсилає він усе згодом у правильному порядку?
- Чи може те саме підтвердження прийти двічі без подвійного проведення?
Якщо ніхто не відповідає за невдалі повідомлення, вони накопичуються, доки хтось не знайде розбіжність у залишках наприкінці місяця. Назвіть конкретну особу, а не команду.
Чи впливає тип виробництва на інтеграцію?
Так. В статті Automation World про впровадження ISA-95 інженерне виробництво під замовлення названо, мабуть, найвимогливішою інтеграцією, адже корпоративні та системи управління мають обмінюватися даними майже в реальному часі. Прикладом є авіабудування: конструкції визначають планування, але можуть змінюватися під час виконання. Коли зміна відбувається, виконання призупиняється, доки планування її не відобразить, а нові операції, наприклад додаткові перевірки, передаються в цех. Та сама стаття попереджає, що різні трактування стандартів постачальниками можуть спричиняти проблеми сумісності.
З цього випливають два висновки. Якщо ваші продукти конфігуруються або проєктуються під замовлення, закладайте сценарій змін уже в перший пілотний проєкт, а не в останній. І тестуйте інтерфейси на основі стандартів на власних даних, адже «стандартний» не означає «ідентичний».
Як крок за кроком інтегрувати MES з ERP?
Тримайте обсяг малим, а перевірки щоденними.
- Оберіть одну лінію і одну родину продуктів.
- Складіть таблицю інтерфейсу з колонками: об'єкт, відправник, одержувач, тригер, частота та власник. Рядок без власника є вашим першим ризиком.
- Узгодьте майстер-дані для цієї родини продуктів, як описано вище.
- Домовтеся про статуси та про значення «завершено», «брак» і «переробка».
- Спершу побудуйте замовлення, підтвердження початку і завершення. Матеріали та час додайте пізніше.
- Навмисно тестуйте збої: надішліть хибну кількість, зупиніть інтерфейс, перезапустіть його, надішліть дублікат.
- Вирішіть, що відбувається із замовленнями, які вже виконуються в день запуску.
- Запускайте новий процес паралельно зі старим протягом кількох тижнів і щодня порівнюйте в обох системах добру кількість, брак, години та матеріал на замовлення.
- Порахуйте додаткові кроки для операторів. Якщо підтвердження в MES займає більше часу, ніж паперова форма, з'ясуйте причину, перш ніж розгортати систему далі.
- Розширюйте на наступну лінію лише тоді, коли розбіжності пояснені.
Типові помилки
- Сприйняття майстер-даних як одноразового завантаження, а не як постійного процесу.
- Проєктування інтерфейсу лише з точки зору ERP, через що MES не може звітувати з тією деталізацією, з якою працює цех.
- Використання одного й того самого слова для статусу з різним значенням у кожній системі.
- Відсутність правила для замовлень у роботі на момент запуску.
- Тестування лише штатного сценарію.
- Невдалі повідомлення без власника.
- Вимога до операторів вводити ті самі дані двічі, окремо в кожній системі.
Де тут Polaris
Якщо ваша проблема полягає в циклі між планом ERP і цехом, варто розглянути iFAKT Polaris. iFAKT описує Polaris як ШІ плюс цифровий двійник виробництва, який працює з даними ERP. Модуль Polaris Designer перетворює дані ERP, специфікації матеріалів, часи процесів і структури ресурсів на граф знань «продукт–процес–ресурс». Модуль Polaris Operator передає плани в цех у вигляді завдань, прив'язаних до часу, і повертає до планування дані про хід виконання, затримки та збої. Окреме питання: які підтвердження ваша ERP має проводити для обліку залишків, калькуляції та простежуваності. Складіть їх список до того, як вирішувати, що має охоплювати будь-який інструмент.
Пов'язані теми для вивчення
- ISA-95 простою мовою: які дії належать до рівня ERP, а які до рівня операцій.
- Замкнений цикл планування: як підтвердження з виробничого цеху змінюють наступний графік.
- Захист з'єднання між мережами заводу та бізнесу: облікові записи, сегментація та оновлення інтерфейсів.
- Звітність з цеху без повноцінної MES: що можуть покрити сканування та прості підтвердження.
Наступний крок
Візьміть одну родину продуктів і запишіть у таблиці кожен об'єкт, який має переходити між вашою MES і ERP, з вказанням відправника, отримувача та власника. Якщо ви хочете інтегрувати MES з ERP без несподіванок, принесіть цю таблицю на першу нараду з ІТ та вашим постачальником.