Інтеграція з ERP та цифровізація робочих процесів

SAP, Dynamics, NetSuite, Odoo та багато регіональних систем ERP через стандартні конектори; усе інше підключається через REST API або обмін файлами.

Рівень інтеграції зіставляє індивідуальні поля та логіку; доопрацювання для нас є нормою.

MSF доповнює ERP. Фінанси та комерція залишаються там, де вони є, а ви отримуєте виробничий рівень світового класу.

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

Так, якщо підтвердження мають проводитися назад. Усе, що створює рух матеріалу або закриває операцію, є записом, і ваші ERP-фахівці захочуть робити його через штатні інтерфейси: BAPI, OData-сервіси або staging-таблицю, без прямого доступу до бази. Перший етап лише на читання цілком розумний: тягнете замовлення, показуєте їх на панелях у цеху, а проводки поки що робите вручну, доки цифри не зійдуться.

Тижні, якщо з боку ERP є конкретна відповідальна людина, тестовий контур, схожий на продуктив, погоджені інтерфейси та більш-менш коректні нормативно-довідкові дані; довше, якщо цього немає. Сама робота над конектором рідко затягується. Довго тягнуться очікування вікна змін, погодження транспортів і відповіді на питання, який із чотирьох кодів номенклатури справжній. Якщо ви сьогодні не можете назвати контактну особу по ERP, плануйте терміни в місяцях.

Через вивантаження CSV чи XML за розкладом на SFTP, через staging-таблицю на боці ERP або через представлення в базі, яке робить і підтримує ваш вендор ERP чи ваша власна ERP-команда; читати прикладні таблиці самотужки зазвичай не дають, та й на оновленні це ламається. Втрачаєте ви миттєвість: затримка дорівнює інтервалу, який ви поставили в розкладі, найчастіше раз на зміну або вночі. Для зворотного напрямку потрібне завдання імпорту на боці ERP, з відповідальним і з правилом, що робити із записами, які воно відхилило.

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

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

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