Інтеграція ERP-системи: SAP, Oracle, Dynamics — хто володіє якими даними?

Відділ продажів ставить просте запитання: скільки ще залишилося виготовити за замовленням 4711? ERP-система каже 320. Розклад планувальника — 308. Цех каже: «готово». Три системи, три відповіді, і кожна правильна за своїми правилами. Саме цю проблему й має розвʼязати інтеграція з ERP-системою.

Інтеграція ERP-системи для планування виробництва — це зʼєднання вашої ERP-системи (SAP, Oracle, Microsoft Dynamics 365 чи іншої) з інструментом, який планує виробництво і складає виробничий розклад, так щоб замовлення, запаси й підтвердження означали те саме в обох системах. Найскладніше тут рідко технічне зʼєднання. Найскладніше — домовитися, яка система володіє якими даними і що означає кожне число.

Три відповіді, одне замовлення

Замовлення 4711 — на 500 придатних одиниць. Поки що машина обробила 192: 180 придатних і 12 бракованих.

• ERP-система віднімає придатні одиниці: 500 − 180 = залишилося 320.
• Інструмент планування відняв усе, що пройшло через машину: 500 − 192 = залишилося 308.
• Цех отримав виробниче завдання на партію цього тижня — 192 одиниці. Цю партію завершено, тож для цеху все готово.

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

Одне часткове підтвердження в обох системах

Виробниче замовлення на 100 кронштейнів має три операції: 10 — різання, 20 — зварювання, 30 — фарбування. Зварник підтверджує 60 придатних штук на операції 20 і йде додому.

• В інструменті планування на операції 20 залишається 40 штук, перенесених на завтра. Фарбування може почати роботу з 60 штуками, якщо ваші правила передачі дозволяють часткові партії. Виробниче завдання позначено як частково виконане, і воно й далі повʼязане із замовленням клієнта.
• В ERP-системі замовлення отримує часткове підтвердження на 60 штук на операції 20. Оприбуткування готової продукції ще немає — воно відбудеться лише після фарбування.

А тепер дві речі, які в реальному житті йдуть не так.

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

Кількість виправлено. Наступного ранку контроль виявляє, що 5 із 60 зварних швів браковані. Підтвердження змінюється на 55 придатних і 5 бракованих, тож потрібно ще 45 штук, а не 40. Хтось має вирішити: чи вирізати 5 додаткових деталей, чи клієнт прийме 95. Це рішення для людини, а не для інтерфейсу.

Бажана, розрахована та підтверджена дата

Більшість замовлень мають три дати, і вони не повинні перезаписувати одна одну:

• Бажана: та, яку попросив клієнт, — 10 березня. Вона змінюється, лише якщо її змінює клієнт.
• Розрахована: та, яку інструмент планування вважає реальною, — 14 березня. Вона може змінюватися з кожним перерахунком розкладу.
• Підтверджена: та, яку відділ продажів підтвердив, побачивши розраховану дату, — 15 березня. Вона змінюється, лише коли хтось вирішить дати клієнтові нову обіцянку.

Класична помилка — записувати розраховану дату прямо в підтверджену. Тоді кожен перерахунок розкладу непомітно змінює те, що пообіцяли клієнтові. Краще так: якщо розрахована дата виходить за підтверджену, сповіщайте відділ продажів. Не перезаписуйте. Як обіцянку перевіряють із самого початку, описано у статті від замовлення клієнта до виробництва.

Хто якими даними володіє під час інтеграції з ERP-системою

Правило: у кожного поля рівно один власник — єдина система, якій дозволено його змінювати. Інша лише читає. Типовий розподіл:

У вас розподіл може бути іншим. Головне — щоб його було записано.

Уявіть двох кухарів, які солять один і той самий борщ. Кожен куштує, вважає, що несолоно, і досолює. Обидва діяли розумно. Борщ зіпсовано. З даними, що мають двох власників, відбувається те саме.

Міф: «Добра інтеграція синхронізує все, в обидва боки й у реальному часі»

Якщо надсилати кожне поле в обидва боки, дві системи гарантовано перезаписуватимуть одна одну. Добра інтеграція вибіркова: лише те, що потрібно іншій стороні, тоді, коли це потрібно, і в одному напрямку для кожного поля. Підтвердження можуть надходити кожні кілька хвилин, номенклатурні дані — раз на день.

SAP, Oracle, Dynamics: запитання ті самі

Від бренду все це не залежить. З SAP, Oracle чи Microsoft Dynamics 365 вам однаково треба домовитися, що означає «залишилося», яка дата яка і хто володіє кожним полем. Зіставлення полів відрізняється залежно від системи та її налаштувань, тому спершу врегулюйте питання власності. Чому взагалі потрібен окремий шар планування, пояснено у статті чому ERP-система вважає, що кожне замовлення триває 10 днів.

Як допомагає factory.online

factory.online інтегрується з SAP і Microsoft Dynamics 365. Якщо у вас Oracle чи інша ERP-система, запитайте, що знадобиться для підключення у вашій конфігурації. У платформі factory.online планувальник бачить кожне виробниче замовлення з його виробничими завданнями та підтвердженнями придатних і бракованих виробів за кожною операцією, тож 60 зварених кронштейнів і 40, що залишилися, видно разом, у звʼязку із замовленням клієнта. Виготовлені партії зберігають свою історію для простежуваності партій.

Якщо ваша ERP-система, ваш планувальник і ваш цех дають три різні відповіді, запишіться на демонстрацію — і ми разом простежимо одне з таких замовлень.