З того моменту, коли ми припиняємо керувати своїм ювелірним магазином на папері і починаємо використовувати систему, питання інтеграції її зі сторонніми системами стає неминучим для переміщення даних вперед-назад між цими системами та нашою.
Є багато прикладів того, які платформи можуть знадобитися вашому ювелірному магазину або системі управління виробництвом: Rapnet, GIA, QuickBooks, витягування ринкових цін на метали, курси валют, спілкування з постачальниками послуг доставки, система управління відносинами з клієнтами, ваш веб-сайт чи інші веб-сайти як Shopify або Etsy, або різні інтеграції платіжних шлюзів.
Навіщо потрібні ці інтеграції?
Перш за все, це може допомогти автоматизувати багато ваших ручних процесів; по-друге, оскільки централізація всіх ваших даних та інформації забезпечить величезну перевагу. Оскільки вся інформація зберігатиметься та управлятиметься в одній системі, вам не доведеться мати справу з повторним копіюванням та передачею даних з однієї системи в іншу.
Просто подумайте про те, як створюються ярлики для доставки та замовлення вставляються в систему автоматично, і ви побачите, як така інтеграція може допомогти, так що вам більше ніколи не доведеться робити це вручну.
Тож питання навіть не в тому, чи корисна інтеграція з іншими системами, а в тому, як насправді здійснюється ця інтеграція.
Інтеграцію можна здійснити принципово трьома методами:
1 Пряма інтеграція
2 Інтеграція EDI
3 Інтеграція API
1 пряма інтеграція
Пряма інтеграція – це коли ви змушуєте дві системи спілкуватися між собою, змішуючи їх код – в основному програма зв’язується з іншою програмою, наприклад, якщо вона є частиною тієї ж програми, на рівні коду. Це може бути фактичний код програми або код бази даних, але результат однаковий – дані плавно і швидко, в режимі реального часу, передаються від однієї програми до іншої.
Пряма інтеграція, як правило, дуже трудомістка для реалізації, оскільки вам потрібно мати глибоке розуміння обох систем на рівні коду і точно знати, як форматувати дані – також вам потрібно переконатися, що всі ваші дані передаються без помилок, або напишіть великі правила перевірки помилок і перевірки. Тому через це прямі інтеграції трапляються рідко і виконуються лише тоді, коли немає іншого варіанту, наприклад EDI або API.
2 edi (електронний обмін даними)
EDI – це комунікаційна технологія, що використовується для передачі даних з однієї системи в іншу. EDI народився в 1940-х та вдосконалений у 1970-х. Хоча за останні 45 років більшість технологій стали значно вдосконаленішими, EDI не модернізували, оскільки можливості Інтернету зросли. Хоча це може здатися необхідним інструментом комунікації в ювелірній галузі, особливо якщо ви працюєте зі старими роздрібними системами, але нові та інноваційні варіанти, такі як API (інтерфейси прикладних програм), швидко замінюють його, оскільки вони швидші та забезпечують більшу гнучкість .
Таким чином, спілкування через EDI в наші дні вважається повільним, одностороннім спілкуванням – порівняння EDI з API – це як порівняння комутованого Інтернету з кабельним.
Основний спосіб роботи EDI полягає в тому, що дані зберігаються у певному форматі залежно від інформації, яку потрібно передати, наприклад замовлення на придбання або рахунка-фактури, а потім пересилають без підтвердження, подібно до факсу. Затримка зберігання може уповільнити процес, а прогалини передачі даних можуть призвести до прийняття рішень на основі інформації, яка, можливо, вже змінилася. Крім того, оскільки дані не в реальному часі, попереджувальні рішення не можуть прийматись із використанням інформації, яка може бути застарілою.
Тепер той факт, що EDI все ще використовується, можна пояснити високими витратами, пов’язаними з переходом на нову систему. Наприклад, більші роздрібні мережі все ще використовують EDI, оскільки їх ланцюг поставок в основному базується на цій технології.
Однак, на мою думку, перехід на використання API – це лише питання часу і для них – витрати на відсутність актуальної інформації та тісну інтеграцію з постачальниками стають все більш актуальними і для них самих.
3 api (інтерфейс прикладної програми)
Поширене використання API – це крок до модернізації – насправді, колись Forbes назвав його «цифровим клеєм», оскільки він акуратно і щільно пов’язує системи.
Знаєте ви це чи ні, ви щодня взаємодієте з API в Інтернеті. По суті, API – це те, що дозволяє швидко і в режимі реального часу переміщувати дані між програмами. Ви коли-небудь замислювались, як ви можете використовувати свій ідентифікатор Facebook для входу на веб-сайти, на яких ви ніколи раніше не були? Так, ви можете подякувати цьому API Facebook.
Чи слід використовувати edi або api?
Отож, оскільки безпосередня інтеграція зустрічається рідше через негнучкість інтеграції та трудомісткий розвиток, залишається питання: чи слід використовувати EDI або API як наш метод інтеграції та підключення?
Природно, ми б сказали API, враховуючи, що це технологія майбутнього, але на даний момент варто зазначити, що технологія EDI все ще використовується досить часто через свою популярність та необхідність інтеграції зі старими великими системами .
Чим новіша система, тим більша ймовірність того, що вона має API, з яким ми можемо працювати, але заміна систем на базі EDI не відбудеться, м’яко кажучи, ще через кілька років. Існує оцінка, що 90% світового ланцюжка поставок все ще покладається на застарілі моделі EDI, принаймні частково у своїх операціях.
Тож коли ви вирішили інтегруватися з іншою системою, з якими труднощами ви зіткнетесь під час інтеграції? Деякі з таких питань, наприклад:
1 Хто виконуватиме інтеграційну роботу? Якщо вже не розроблено жодного методу API, то чи розробить його постачальник? Якщо ні, чи є у них принаймні EDI готовий до роботи? Якщо це теж не варіант, чи варто робити пряму інтеграцію?
2 Кожен інтеграційний проект відрізняється – наприклад, інтеграція веб-сторінок не може бути стандартизованою, оскільки зазвичай кожна ювелірна компанія має різні стилі та компоненти та різні способи визначення своїх компонентів та їхніх атрибутів. Через це неможливо уникнути користувальницького програмування під час інтеграції, щоб отримати ці дані таким чином, щоб зрозуміли обидві системи, як би створивши загальний знаменник “даних”. Тому в більшості випадків не існує рішення для інтеграції, яке працює одним натисканням кнопки – все-таки потрібно деяке програмування.
3 Сторонні постачальники можуть вирішити змінити свої API в будь-який час – якщо це трапиться, зв’язок може перерватися між інтегрованими системами та частиною або, можливо, доведеться переробити всю інтеграцію знову.
4 Низька якість даних із застарілих систем – дані заповнені не повністю або введені неправильно; також, коли користувачі змінюються протягом багатьох років, кожне покоління користувачів може вводити різні дані, які потрібно спочатку очистити перед інтеграцією
5 Дві системи не завжди збігаються за структурою. Наприклад, одна система може мати поле електронної пошти для працівників, а інша – ні. Як можна здогадатися, іноді для цього потрібно вводити дані вручну в іншу систему, щоб переконатися, що всі необхідні дані синхронізовані між цими двома системами.
6 Інтеграція, що з’єднує як EDI, так і API – іноді для використання інтерфейсів між системами потрібно використовувати EDI і API – ви можете використовувати мостове програмне забезпечення – також зване проміжне програмне забезпечення – яке зчитує та записує EDI, але надає функціональність API іншим системам – це зазвичай це робиться, коли одна стара система повинна бути підключена до кількох новіших систем, а стара система лише “розмовляє” EDI, але всі нові системи “розмовляють” лише через API. Це може заощадити час та гроші на інтеграцію, оскільки вам потрібно лише один раз інтегруватися з платформою EDI, а не окремо для кожної нової системи – ви можете використовувати API для них, а також для будь-якої іншої майбутньої системи, яка буде інтегрована пізніше.
Підпишіться на ювелірні вироби наступного рівня
Важливо врахувати також те, що передача файлів з однієї системи в іншу за допомогою файлів CSV або електронних таблиць Excel також іноді вважається інтеграцією. Зараз деякі постачальники пропонують ці варіанти для «обміну» даними між системами, але вони не дають зрозуміти своїм клієнтам, що їх рішення не є автоматизацією і, звичайно, не інтеграцією в реальному часі, як рішення на основі API.
Отже, коли справа доходить до інтеграції, вам дійсно потрібно зрозуміти, які варіанти інтеграції доступні, і використовувати інтеграції на основі API, коли це можливо.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/vlog-integrating-your-jewelry-software-third-party-systems-torok/.
Piro Blog https://www.gopiro.com/blog
Zsolt Torok люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 