З’єднання SAP, Dynamics 365 і Business Central із цехом

Кожен виробник, який має і ERP, і цехові системи, рано чи пізно стикається з тією самою розбіжністю. ERP показує замовлення виконаним; цех знає, що дві палети переробляли. ERP показує матеріал списаним за нормою; фактичне споживання включало брак, який ніхто не провів. Жодна із систем не бреше. Вони описують різні моменти: ERP описує план і його фінансові наслідки, цех описує фізичну реальність, а інтеграція є дисципліною тримати ці два описи узгодженими.

Перше проєктне рішення стосується напрямку володіння даними, і помилка тут найчастіше стоїть за інтеграціями, які ніколи не стабілізуються. Основні дані (клієнти, постачальники, матеріали, специфікації, маршрути, ціни) належать ERP і течуть униз. Дані виконання (фактичні час початку й завершення, фактичні обсяги випуску, брак, причини простоїв, стани верстатів, призначення операторів, реальне споживання матеріалу) народжуються в цеху й течуть угору. Коли обом системам дозволено редагувати одну й ту саму сутність, у вас виходить регулярна суперечка з розкладом синхронізації.

Потік униз зазвичай простіший. Виробничі замовлення, випущені в ERP, з’являються в MES зі своїми операціями, маршрутами та переліками матеріалів. Зміни в довіднику номенклатури розповсюджуються. Дані про клієнтів і постачання доходять до систем, яким вони потрібні. Головна практична складність полягає в деталізації: виробниче замовлення в ERP часто відповідає кільком цеховим операціям на різних робочих центрах, і відповідність між структурою ERP і виконуваною структурою треба визначати свідомо.

У потоці вгору зосереджені і цінність, і складність. Підтвердження (повідомлення про те, що ця операція випустила стільки-то, спожила стільки-то матеріалу, тривала стільки-то, дала стільки-то браку) живлять запаси, собівартість і показники потужності в ERP. Коли їх збирають автоматично з верстатів і терміналів операторів і ніхто не набирає їх наприкінці зміни з пам’яті, цифри ERP перестають бути наближеннями. Собівартість покращується одразу, бо нормативний час замінюється фактичним.

Доступні шаблони інтеграції різняться передусім затримкою та зв’язністю. Файловий обмін простий, підтримується всюди й неминуче пакетний. Прямий доступ до бази даних швидкий і крихкий: він ламається під час оновлень вендора у спосіб, який важко передбачити. Опубліковані інтерфейси сьогодні є стандартом за замовчуванням і значно спокійніше переживають зміну версій: SAP через IDoc (обмін повідомленнями ALE), BAPI/RFC чи OData; Dynamics 365 і Business Central через їхні опубліковані API OData/REST. Черги повідомлень додають стійкості для високочастотних подій, бо цех продовжує виробляти дані незалежно від того, доступна ERP чи ні.

Останній пункт заслуговує на наголос, бо саме тут крихкі інтеграції себе викривають. Виробництво не зупиняється, коли зупиняється ERP. Якщо ваша інтеграція синхронна, а ERP недоступна через планове обслуговування, то або стане цех, або дані загубляться. Буферизована конструкція з чергою дозволяє MES далі збирати дані та передати накопичене, коли зв’язок відновиться. А на заводі з кількома змінами це трапляється щомісяця.

Локальні та регіональні ERP-системи ускладнюють картину в специфічний спосіб. Глобальні пакети мають задокументовані інтерфейси та великі екосистеми інтеграторів. Регіональні продукти (Panteon, Logo, Nebim і їхні аналоги на інших ринках) поширені серед середніх виробників, часто глибоко доопрацьовані й рідко мають готовий конектор до MES. Це не привід замінювати ERP, яка працює. Це привід ставитися до інтеграційного шару як до повноцінної частини проєкту.

Звіряння зазвичай викидають із планів проєкту, а потім воно з’їдає перші три місяці експлуатації. Повідомлення падають. Підтвердження відхиляється, бо матеріал заблокований. Виробниче замовлення видаляють в ERP після того, як цех уже почав його виконувати. Кожній інтеграції потрібні черга, яку можна переглянути, механізм повторних спроб, стан помилки, що сповіщає людину, і періодичний звіт про звіряння, який доводить, що записане в цеху й те, що тримає ERP, досі збігаються. Інтеграції без цього тихо розходяться з реальністю, і це гірше за гучну відмову.

Порада щодо обсягу, яка витримує зустріч із реальністю: почніть з одного типу замовлень на одній лінії, доведіть повний цикл від випуску в ERP до виконання в цеху й підтвердження назад в ERP, і лише тоді розширюйтеся. Інтеграції «великим вибухом» одразу по всіх майданчиках і типах замовлень провалюються так, що це вкрай важко діагностувати, бо коли все нове, ніщо не може бути еталоном.