Інтеграція ERP для виробництва: з’єднання SAP, Dynamics і Navision із цехом

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

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

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

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

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

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

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

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

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